You are viewing a free preview of this lesson.
Subscribe to unlock all 10 lessons in this course and every other course on LearningBro.
Web application security is the practice of protecting websites, web applications, and web services from threats that exploit vulnerabilities in application code, configuration, or design. As organisations increasingly rely on web-based systems, understanding how to secure them is essential for every developer, administrator, and security professional.
Web applications are the primary interface between organisations and their users:
A single vulnerability can lead to data breaches, financial loss, regulatory fines, and irreparable damage to an organisation's reputation.
The attack surface of a web application includes every point where an attacker can interact with the system:
| Component | Description | Example Attack |
|---|---|---|
| User input fields | Forms, search boxes, URL parameters | SQL injection, XSS |
| Authentication systems | Login pages, session tokens | Credential stuffing, session hijacking |
| APIs | REST, GraphQL, SOAP endpoints | Broken access control, injection |
| File uploads | Document and image upload features | Malicious file upload, path traversal |
| Third-party integrations | Payment gateways, analytics scripts | Supply chain attacks |
| Server configuration | Web server, application server settings | Security misconfiguration |
| Client-side code | JavaScript, cookies, local storage | XSS, insecure storage |
Never rely on a single security control. Layer multiple defences so that if one fails, others still protect the application:
[User] ──▶ [WAF] ──▶ [Input Validation] ──▶ [Authentication] ──▶ [Authorisation] ──▶ [Database]
│
[Logging & Monitoring] ◀──────────────┘
Grant users and systems only the minimum permissions they need to perform their function. A web application should not run with database administrator privileges.
Systems should be secure out of the box. Features that increase risk (such as debug modes or verbose error messages) should be disabled by default and only enabled intentionally.
When an application encounters an error, it should fail in a way that does not expose sensitive information or leave the system in an insecure state.
| Term | Definition |
|---|---|
| Vulnerability | A weakness in software that can be exploited |
| Exploit | Code or technique that takes advantage of a vulnerability |
| Threat | Any potential event that could harm the application |
| Risk | The likelihood and impact of a threat exploiting a vulnerability |
| Attack vector | The path or means an attacker uses to access the target |
| Payload | Malicious code delivered to the target as part of an exploit |
| Zero-day | A vulnerability that is exploited before the vendor is aware of it |
| CVE | Common Vulnerabilities and Exposures — a standardised identifier for known vulnerabilities |
| WAF | Web Application Firewall — filters and monitors HTTP traffic |
| Goal | Web Application Example |
|---|---|
| Confidentiality | Ensuring user passwords are hashed and personal data is encrypted in transit and at rest |
| Integrity | Preventing attackers from modifying order totals, account balances, or database records |
| Availability | Protecting against DDoS attacks that could take the application offline |
Understanding architecture helps identify where security controls are needed:
Browser ──▶ Web Server (Apache/Nginx) ──▶ Application Server (PHP/Java/Python) ──▶ Database
Security controls are primarily server-side: input validation, session management, and access control all happen on the server.
Browser (React/Angular/Vue) ──▶ API Server (REST/GraphQL) ──▶ Database
SPAs shift rendering to the client, making API security and client-side input handling critical. The API must enforce all security rules — the browser cannot be trusted.
Browser ──▶ API Gateway ──▶ Service A ──▶ Database A
──▶ Service B ──▶ Database B
──▶ Service C ──▶ External API
Each service is an independent attack surface. Service-to-service authentication (mTLS, JWTs) and API gateway security become essential.
| Framework | Description |
|---|---|
| OWASP | Open Web Application Security Project — provides free tools, guides, and the famous Top 10 list |
| NIST SP 800-53 | Comprehensive security and privacy controls for information systems |
| ISO 27001 | International standard for information security management systems |
| PCI DSS | Payment Card Industry Data Security Standard — required for any application handling card data |
| GDPR | General Data Protection Regulation — EU regulation governing personal data protection |
| SOC 2 | Service Organisation Control 2 — audit framework for data security, availability, and privacy |
| Metric | Statistic |
|---|---|
| Average cost of a data breach | Over $4 million (IBM 2023 report) |
| Most common initial attack vector | Stolen credentials and phishing |
| Average time to identify a breach | Over 200 days |
| Percentage of breaches involving web applications | Over 40% |
Key takeaway: Investing in application security during development is far cheaper than dealing with a breach after deployment.
Web application security is about protecting the software that runs on the web from threats that exploit vulnerabilities. It requires a layered, defence-in-depth approach spanning input validation, authentication, access control, encryption, and monitoring. The attack surface of modern web applications is large and growing, making security a shared responsibility across development, operations, and security teams. Understanding the fundamentals covered in this lesson — the attack surface, core principles, key terminology, and industry frameworks — provides the foundation for the deeper topics ahead.