The OWASP Top 10 web application risks and their defences
In short: The OWASP Top 10 is a widely used awareness list of the most important web application security risks. The 2025 edition puts broken access control first and adds software supply chain failures. Each category has well-known defences that developers and testers should know.
What the OWASP Top 10 is
The Open Worldwide Application Security Project (OWASP) is a non-profit community that publishes free application security guidance. Its Top 10 is an awareness document listing the most significant categories of web application risk, built from contributed testing data and a community survey. It is refreshed every few years; the current edition is the 2025 list.
The Top 10 is not a complete testing standard. For full coverage, testers use the OWASP Web Security Testing Guide and developers use the Application Security Verification Standard (ASVS). But the Top 10 is the common language used in job interviews, training and many security policies.
The categories and their fixes
| Category | Example | Main defence |
|---|---|---|
| A01 Broken Access Control | Changing an ID in the URL shows another customer's invoice; server-side request forgery also sits here | Check authorisation on the server for every request; deny by default |
| A02 Security Misconfiguration | Default admin account, directory listing, verbose errors | Hardened, repeatable builds; remove samples and defaults |
| A03 Software Supply Chain Failures | An outdated or compromised library or build tool | Inventory components (SBOM), update, verify sources |
| A04 Cryptographic Failures | Passwords stored with a fast hash, data sent without TLS | TLS everywhere, strong algorithms, slow password hashing |
| A05 Injection | SQL injection, cross-site scripting, OS command injection | Parameterised queries, output encoding, input validation |
| A06 Insecure Design | A password reset that relies on easily guessed questions | Threat modelling and secure design patterns early |
| A07 Authentication Failures | No rate limiting, weak session handling | MFA, rate limiting, secure session management |
| A08 Software or Data Integrity Failures | Auto-updates or serialised data accepted without checks | Signatures and integrity checks on code and data |
| A09 Security Logging and Alerting Failures | Repeated failed logins never trigger an alert | Log security events and alert on them |
| A10 Mishandling of Exceptional Conditions | An error leaves a transaction half-done or fails open | Handle errors safely; fail closed |
Compared with the 2021 edition, misconfiguration moved up, vulnerable components were broadened into supply chain failures, server-side request forgery was folded into access control, and the exceptional-conditions category is new.
A closer look at two classics
Broken access control is first because it is so common. The cause is usually simple: the application checks that you are logged in but not that the record belongs to you. The fix is equally simple in principle: every request must be authorised on the server, never by hiding buttons in the browser.
Injection happens when user input is treated as part of a command or query. The lasting fix is to keep data separate from code:
# Unsafe: input becomes part of the SQL text
query = "SELECT * FROM users WHERE email = '" + email + "'"
# Safe: the driver sends the value separately as a parameter
cursor.execute("SELECT * FROM users WHERE email = %s", (email,))Using the Top 10 at work
- Developers: use it as a training checklist and in code review.
- Testers: use it to structure report findings so developers recognise them.
- Managers: require secure coding training and testing against it before release.
Tip: practise these flaws only on deliberately vulnerable training applications in your own lab, never on live websites. The web application testing note shows how testers approach them.
Real-world example: a booking app before launch
A small fitness studio pays a developer to build a class booking web app. Before launch, the owner asks a tester to review it against the OWASP Top 10. The tester finds two issues. First, changing the booking number in a link shows other members' bookings, a broken access control problem. Second, the admin page still uses a default password from the framework's setup, a security misconfiguration. The developer adds a server-side check that each booking belongs to the signed-in member, removes the default account and enables MFA for admins. Both fixes take a day, far less than handling a data breach after launch.
Practice
A user changes /orders/1001 to /orders/1002 in the address bar and sees someone else's order. Which category is this?
What is the most effective defence against SQL injection?
Why is the Top 10 not enough on its own for a full test?
Key takeaways
- The OWASP Top 10 is an awareness list of major web application risk categories.
- In the 2025 edition broken access control is first and supply chain failures are new.
- Access control must be enforced on the server for every request.
- Injection is fixed by separating data from code with parameterised queries.
- Use the list for training and reporting; use WSTG and ASVS for full testing.
Original content written by Mohamed Fayas for FM TecHub. © 2026 FM TecHub. You're welcome to share a link to this page; please don't copy the text elsewhere without permission.