If you commission a web application, sooner or later someone will mention the OWASP Top 10. OWASP, the Open Worldwide Application Security Project, is a nonprofit community that publishes free security guidance. Its Top 10 is a ranked list of the most critical security risk categories for web applications, compiled from vulnerability data contributed by many organizations and a survey of practitioners. It is not a law or a certification, but it is the most widely used shared vocabulary for web security, and contracts, audits and penetration test reports regularly refer to it.
This guide follows the most recent edition, published in 2025, which updated the earlier 2021 list. Each entry below explains what the risk means in everyday terms, gives a typical example, and suggests a question you can ask your developers. The official text, with technical detail and references, is on the OWASP Top 10 project page.
The OWASP Top 10, one by one
A01: Broken Access Control
In plain terms: users can see or do things they should not be allowed to. Example: a customer changes /invoice?id=1041 to /invoice?id=1042 in the address bar and sees someone else's invoice. This category now also includes server-side request forgery (SSRF), where an attacker tricks the server into fetching internal URLs on their behalf. Ask: "Is every request checked on the server to confirm this user owns or may access this record?"
A02: Security Misconfiguration
In plain terms: the software is fine but set up unsafely. Examples: default admin passwords left in place, detailed error messages showing database details to visitors, cloud storage buckets open to the public, debug mode enabled in production, missing security headers. Ask: "Is there a hardened, documented configuration for each environment, and how is it checked?" You can spot some misconfigurations yourself with an HTTP header checker.
A03: Software Supply Chain Failures
In plain terms: the risk comes from code you did not write. Modern applications rely on hundreds of open-source libraries, plus build tools and deployment pipelines. Example: a popular library has a known vulnerability, or an attacker publishes a malicious package with a name similar to a real one. Ask: "How do you track our dependencies, and how quickly are vulnerable ones updated?"
A04: Cryptographic Failures
In plain terms: sensitive data is not protected properly by encryption. Examples: pages served over plain HTTP, passwords stored with a fast hash like MD5, encryption keys committed to source code, outdated TLS versions. Ask: "Which data is encrypted in transit and at rest, and how are passwords hashed?" (The answer should name a slow password-hashing algorithm such as Argon2id or bcrypt.)
A05: Injection
In plain terms: user input is treated as code. Examples: SQL injection, where typing ' OR '1'='1 into a login form changes the database query; cross-site scripting (XSS), where a comment containing a <script> tag runs in other users' browsers. Ask: "Do you use parameterized queries everywhere, and is output encoded by default in the templates?"
A06: Insecure Design
In plain terms: the flaw is in the plan, not the code. Even perfect code cannot fix a process that was designed without abuse in mind. Example: a password reset that relies on easily researched security questions, or a referral scheme with no limit that lets one person create thousands of fake accounts. Ask: "Did we discuss how features could be abused before building them?" This is often called threat modelling.
A07: Authentication Failures
In plain terms: weaknesses in how users log in and stay logged in. Examples: no protection against automated password guessing, session IDs that do not change after login, "remember me" tokens that never expire, no two-factor option for administrators. Ask: "Is login rate-limited, are sessions invalidated on logout, and is two-factor authentication available?"
A08: Software or Data Integrity Failures
In plain terms: the application trusts code or data without checking it has not been tampered with. Examples: automatic updates downloaded without signature checks, or loading a script from a third-party CDN that could be modified. Ask: "Do we verify the integrity of updates, plugins and externally hosted scripts?"
A09: Security Logging and Alerting Failures
In plain terms: an attack happens and nobody notices. Example: thousands of failed logins or a sudden bulk data export produce no alert, so a breach is discovered months later by a customer. Ask: "Which security events are logged, how long are logs kept, and who gets alerted?"
A10: Mishandling of Exceptional Conditions
In plain terms: the application behaves unsafely when something unexpected happens. Examples: an error halfway through a payment leaves an order marked as paid, or a failed permission check "fails open" and grants access instead of denying it. Ask: "When something fails, does the system fail safely, and do errors avoid revealing internal details?"
What changed from the 2021 list
For readers comparing with older reports: Security Misconfiguration moved up to second place; "Vulnerable and Outdated Components" was broadened into Software Supply Chain Failures; SSRF, which had its own entry in 2021, was folded into Broken Access Control; and Mishandling of Exceptional Conditions is new. Category names were also simplified in places. If an older audit refers to the 2021 numbering, map the findings by category name rather than number.
How to use the list in your business
- In contracts and briefs: ask that a new web application be built and tested with the OWASP Top 10 in mind, and that a summary of how each category was addressed is delivered at handover.
- For deeper requirements: OWASP's Application Security Verification Standard (ASVS) turns these categories into detailed, testable requirements. It is a better basis for a formal specification than the Top 10 itself.
- For testing: a penetration test report should map findings to these categories so you can track recurring problem areas.
- For older applications: a review against the list is a sensible first step before deciding whether to fix, rebuild or retire them.
Remember that the Top 10 is an awareness document, a list of the most common and serious risk areas, not a complete checklist. An application can avoid all ten and still have other flaws.
Key takeaways
- The OWASP Top 10 is the standard shorthand for the most critical web application risks.
- Broken access control remains the top risk: always check permissions on the server.
- Supply chain and configuration problems are as important as bugs in your own code.
- Use the list to ask better questions of developers; use OWASP ASVS for detailed requirements.