Web application security
By the end of this module you will be able to:
- Apply all ten OWASP Top 10:2025 categories to a web application design
- Write a parameterised query that eliminates SQL injection risk
- Distinguish stored, reflected, and DOM-based XSS and select the correct mitigation
- Configure HTTP security response headers to reduce client-side attack surface
- Choose between the OWASP Top 10 and ASVS for a given assurance question
MOVEit Transfer and the Cl0p SQL injection wave
In May 2023, security researchers identified a critical SQL injection vulnerability in MOVEit Transfer, a managed file transfer application widely used by payroll processors, healthcare organisations, and government agencies. Within days, the Cl0p ransomware group had exploited it against more than 2,000 organisations worldwide.
In the United Kingdom, the breach reached Zellis, a payroll provider whose MOVEit installation was compromised, exposing payroll data for employees of the BBC, British Airways, Boots, and the NHS.
The vulnerability, CVE-2023-34362, was a SQL injection flaw: the application constructed SQL queries by concatenating user-controlled HTTP POST parameters. Progress Software released a patch on 31 May 2023 but exploitation had already begun on 27 May. Organisations with a software inventory and patch management programme would have applied the fix within hours of release rather than days.
OWASP Top 10:2025 overview
The is updated approximately every three to four years based on analysis of real vulnerability data from hundreds of organisations. The 2025 edition, released in November 2025, retains at A01 and elevates Software Supply Chain Failures to A03, reflecting the SolarWinds, MOVEit, and xz-utils incidents. dropped from A03 to A05 as parameterised queries and ORMs became more widely adopted. Two entirely new categories were added. The ten categories are:
- A01:2025 Broken Access Control - privilege abuse, BOLA, missing deny-by-default
- A02:2025 Security Misconfiguration - default credentials, verbose errors, cloud misconfiguration (up from A05:2021)
- A03:2025 Software Supply Chain Failures - compromised dependencies, unsigned updates, insecure CI/CD (new name, elevated from A08:2021)
- A04:2025 Cryptographic Failures - weak encryption, data exposure (moved from A02:2021)
- A05:2025 Injection - SQL, LDAP, command injection (dropped from A03:2021)
- A06:2025 Insecure Design - missing threat modelling, insecure architecture
- A07:2025 Authentication Failures - weak passwords, missing MFA (renamed from "Identification and Authentication Failures")
- A08:2025 Software or Data Integrity Failures - unsigned updates, insecure deserialisation
- A09:2025 Security Logging and Alerting Failures - missing audit trails (renamed: "Monitoring" → "Alerting")
- A10:2025 Mishandling of Exceptional Conditions - error handling failures, uncaught exceptions (entirely new)
Note: , which was A10:2021, is now folded into A01 Broken Access Control in the 2025 edition.
The Top 10 and the OWASP answer different questions: the Top 10 is an awareness document that names what commonly goes wrong, while ASVS is a verification standard of testable requirements you check an application against. You design against neither as an architecture specification, but when you need to prove an application is secure you verify against ASVS, not against the Top 10.
A01: Broken Access Control
Broken Access Control covers any scenario where a user can act outside their intended permissions, including vertical escalation (accessing admin functions) and horizontal escalation (accessing another user's data). OWASP reports 94% of tested applications had some form of broken access control.
The most reliable mitigation pattern is deny-by-default: all access is denied unless a positive authorisation decision exists for the combination of principal, resource, and action. Access control must be enforced server-side on every request. Client-side controls such as hidden fields, disabled buttons, and JavaScript checks are trivially bypassed.
A04: Cryptographic Failures and A05: Injection
A04:2025 Cryptographic Failures (formerly A02:2021 "Sensitive Data Exposure") covers: data transmitted in cleartext over HTTP, passwords hashed with MD5 or SHA-1 (both unsuitable due to speed; use bcrypt, Argon2, or PBKDF2), symmetric encryption using ECB mode (reveals plaintext patterns), and hard-coded cryptographic keys in source code. In June 2021, the RockYou2021 compilation of approximately 8.4 billion credential pairs revealed how widespread unsalted MD5 password storage was: MD5 can be computed at billions of hashes per second on consumer GPU hardware.
A05:2025 Injection occurs when untrusted data is sent to an interpreter as part of a command or query. The vulnerable pattern: concatenating user input into a SQL string. The correct pattern: a parameterised query that binds user input as data. If the input admin' -- is supplied to a concatenated query, it becomes a SQL comment that removes the password check. In a parameterised query, the same input is treated as a literal string and returns no results. LDAP injection, command injection, and template injection follow the same pattern: parameterise or use a safe API that separates code from data.
XSS (Cross-Site Scripting)
attacks inject malicious scripts into web pages viewed by other users. Three variants exist:
- Stored XSS: malicious script is persisted in the server's data store and served to all users who view the affected content. Highest impact because it affects every visitor without requiring a crafted link.
- Reflected XSS: malicious script is embedded in a URL parameter and reflected in the server's response. Requires the victim to click a crafted link. Search result pages that echo back the query term without escaping are a common vector.
- DOM-based XSS: the attack occurs entirely in the browser. Client-side JavaScript reads from a source (such as location.hash) and writes to a sink (such as innerHTML) without sanitisation. DOM-based XSS bypasses server-side encoding mitigations entirely.
Mitigation strategy: (1) output encoding using context-aware libraries such as OWASP Java Encoder or DOMPurify; (2) Content Security Policy header restricting script execution to approved sources; (3) HttpOnly cookies preventing JavaScript from reading session tokens even if a script executes.
SSRF inside A01, and security response headers
The 2025 edition folds SSRF into A01, so treat it as an access-control failure: the server is manipulated into reaching a destination it should never be authorised to reach. Server-Side Request Forgery causes the server to make HTTP requests to an arbitrary destination, typically an internal network address or cloud metadata service, that the attacker cannot reach directly. In cloud environments, AWS, Azure, and GCP all expose an Instance Metadata Service at 169.254.169.254. A successful SSRF against an EC2 instance can retrieve the IAM role credentials attached to that instance.
In July 2019, Paige Thompson exploited SSRF via a misconfigured AWS WAF protecting a Capital One EC2 instance. The server-side request reached the IMDS endpoint and retrieved IAM role credentials, enabling download of over 106 million customer records from S3 buckets. Capital One was fined $80 million by the OCC in 2020. Mitigations: validate and allowlist outbound request targets; block requests to private IP ranges (RFC 1918) and link-local addresses (169.254.0.0/16); use AWS IMDSv2 which requires a PUT request before metadata can be read.
Security response headers that every application must include: Content-Security-Policy (restricts script origins, mitigates XSS), Strict-Transport-Security (forces HTTPS, prevents SSL stripping), X-Frame-Options: DENY (blocks clickjacking), X-Content-Type-Options: nosniff (prevents MIME-type attacks), Referrer-Policy: strict-origin, and Permissions-Policy (restricts browser API access). These headers must be applied to every origin, not just login pages.
Common misconception
“Security response headers only need to be added to the login page.”
Security headers must be applied to every origin your application serves, including API endpoints, subdomains, CDN edges, documentation portals, and error pages. An XSS or clickjacking attack on a status page or documentation subdomain can be used to steal credentials or pivot to authenticated areas. Automated header audit tools such as Mozilla Observatory should scan all configured origins during CI/CD pipeline runs.
Common misconception
“HTTPS (TLS) protects web applications from injection attacks and XSS.”
TLS protects data in transit from eavesdropping and tampering between the client and server. It has no effect on injection vulnerabilities (SQL injection, command injection) or XSS, which are server-side processing failures that occur after the TLS connection terminates. An application that uses HTTPS and also concatenates user input directly into SQL queries is simultaneously encrypted and trivially SQL-injectable. Input validation, parameterised queries, output encoding, and Content Security Policy are the controls relevant to injection and XSS, not TLS.
A web application reflects the search term in the page title without escaping it. An attacker crafts a link containing a script tag that reads document.cookie and posts it externally. The response has no CSP header. Which XSS type is this, and which mitigation would have prevented cookie theft even without CSP?
A developer finds a PHP application that concatenates a raw URL parameter into a SQL string. A tester submits the ID as '1 UNION SELECT username, password, 3, 4 FROM users--'. What has occurred and what is the correct fix?
A penetration tester identifies a reflected XSS vulnerability on a financial services website: the search parameter is included in the response without HTML encoding, allowing arbitrary JavaScript execution in the victim's browser. The application uses HttpOnly cookies for session tokens. The security team argues this is low severity because HttpOnly prevents cookie theft. Evaluate this assessment.
A 2019 penetration test flags a server that can be tricked into fetching any URL the attacker chooses, including the cloud metadata endpoint at 169.254.169.254. The 2021 report filed this under A10 Server-Side Request Forgery. Which 2025 category does the same defect belong to?
A developer adds a Content-Security-Policy header with the directive default-src 'self'. A third-party analytics script loaded from https://analytics.example.com stops working. What is the most appropriate fix?
Core distinctions
- OWASP Top 10:2025 retains Broken Access Control at A01 and elevates Software Supply Chain Failures to A03. Enforce deny-by-default server-side authorisation on every request, never client-side.
- SQL injection is prevented by parameterised queries or prepared statements. String concatenation of user input into SQL is never acceptable regardless of prior input validation.
- XSS has three forms: stored (highest impact), reflected (requires crafted link), and DOM-based (bypasses server-side encoding). Output encoding, CSP, and HttpOnly cookies work together as complementary controls.
- SSRF allows attackers to reach internal services and cloud metadata APIs via a vulnerable server. Allowlist outbound request targets and use AWS IMDSv2 on cloud instances.
- Security response headers (CSP, HSTS, X-Frame-Options, X-Content-Type-Options) must be applied to every origin and subdomain, not just login pages.
You can now identify and remediate the OWASP Top 10:2025 web vulnerabilities, and decide when to reach for ASVS rather than the Top 10 to verify an application. The next module covers API and service security using the OWASP API Security Top 10, where broken access control returns as broken object-level authorisation.
Standards and sources cited in this module
OWASP Top 10:2025 (November 2025)
Primary vulnerability classification reference covering A01:2025 through A10:2025. Replaces the 2021 edition.
OWASP Top 10:2025 Introduction
Explains that the Top 10 is an awareness document rather than a verification checklist, which is why an application is verified against ASVS.
The verification standard of testable requirements. Use it to check an application, where the Top 10 only raises awareness of what commonly goes wrong.
NIST SP 800-95: Guide to Secure Web Services
Web application security architecture guidance from NIST.
Content Security Policy directive reference and nonce-based CSP configuration guidance.
MOVEit Transfer SQL injection vulnerability: the case study for this module.