Hosting and security
The OWASP Top 10 for your dev team
The OWASP Top 10:2025 adds supply chain failures and exception handling. Use it for your review checklist and tests, but as proof of security it is too narrow.
The OWASP Top 10 is a list of the ten most important risk categories for web applications. The current edition is the Top 10:2025, presented in November 2025 as the first new version since 2021. OWASP itself calls the list an awareness document. It gives your team a shared vocabulary and a basis for the review checklist and the tests, but as proof that your application is secure it is too narrow.
The 2025 list
| No. | Category | What it looks like in your code |
|---|---|---|
| A01 | Broken Access Control | a user can view or change someone else's data; SSRF now falls under this category too |
| A02 | Security Misconfiguration | debug mode in production, default passwords, a public storage bucket |
| A03 | Software Supply Chain Failures | a vulnerable or hijacked dependency, a poorly secured build pipeline |
| A04 | Cryptographic Failures | sensitive data stored unencrypted, outdated or home-made crypto |
| A05 | Injection | SQL, shell commands or HTML built from user input |
| A06 | Insecure Design | a check missing from the design itself, such as no attempt limit on a password reset |
| A07 | Authentication Failures | weak password rules, no MFA, sessions that never expire |
| A08 | Software or Data Integrity Failures | updates or data you use without checking where they came from |
| A09 | Security Logging & Alerting Failures | an attack is not logged, or nobody gets an alert |
| A10 | Mishandling of Exceptional Conditions | an error where the application fails open and grants access anyway |
What changed since 2021
Two categories are new and one was merged. Server-Side Request Forgery, a category of its own in 2021, has been rolled into A01. Software Supply Chain Failures expands the old Vulnerable and Outdated Components category to cover the whole process of building, distributing and updating software. Mishandling of Exceptional Conditions is entirely new. Security Misconfiguration moved up from fifth to second place.
To me this means that configuration and the supply chain deserve as much attention as your own code. How attacks through package registries play out is covered in supply chain attacks on npm and PyPI.
How OWASP sees the list
If you use the Top 10 as a coding or testing standard, OWASP says you have the bare minimum and a starting point. No tool can fully detect or test for the risks on the list, and OWASP discourages any claim of full coverage.
For a standard you can verify against, OWASP points to the Application Security Verification Standard (ASVS), now at version 5.0. My advice is to use the Top 10 to decide what your team pays attention to, and the ASVS to record which requirements your application meets.
In code review
Turn the categories into questions a reviewer asks on a pull request. Pick only the questions that fit your application, because a fixed list of ten questions on every change stops being read within a week. For example:
- Does every new route check whether the logged-in user may access this specific object? (A01)
- Does all input go through parameterised queries or the framework's escaping? (A05)
- Is a new dependency being added, and who maintains it? (A03)
- What happens if this external call fails or takes too long? (A10)
- Are denied access and failed logins logged? (A09)
Put the questions in your pull request template. How to set up reviews in a distributed team is covered in code review in a remote team.
In tests and the pipeline
Part of the list can be checked automatically. A dependency scan catches known vulnerabilities from A03, static analysis finds many injection patterns and a secret scan keeps keys out of the repository. A scan of the running test environment finds misconfiguration, such as missing security headers.
A scanner rarely finds broken access control, because it does not know who may see which data. That is why OWASP recommends including access control in your unit and integration tests. Write authorisation tests per role: user A cannot open user B's invoice, and a regular user cannot call an admin endpoint. These tests are dull to write, and they cover the category at the top of the list.
Test the error paths as well, such as a database that drops out or an external service that returns nonsense. For A10, your application should deny access in those cases.
In refinement and team meetings
Discuss one category at a time, with an example from your own codebase. When refining new features, spend ten minutes on the question of what could go wrong. That is how you deal with A06, because a design flaw cannot be fixed with a better implementation.
Sometimes the best measure is to leave something to others. At KiKa, payments go through PCI-DSS certified providers and the platform never stores card data itself, so no card data can leak from it.
Our developers use AI coding tools such as Claude Code every day. Generated code goes through the same review and the same scans as any other code, and the developer who submits it must be able to explain every line.
Sources
Frequently asked questions
What is the latest version of the OWASP Top 10?
The OWASP Top 10:2025, presented in November 2025. It is the first new edition since 2021 and adds two categories: Software Supply Chain Failures and Mishandling of Exceptional Conditions.
Is the OWASP Top 10 a security standard?
OWASP calls the list an awareness document, and the bare minimum if you use it as a coding or testing standard anyway. For a standard you can verify against, OWASP points to the Application Security Verification Standard (ASVS).
How do you use the OWASP Top 10 in code review?
Turn the categories that apply to your application into concrete questions on your review checklist, such as: does this endpoint check whether the user may access this object? Leave whatever a tool can find to the pipeline.
About the author
Erik Schoorl
CTO and lead architect
Erik founded ESBL together with Bas. He is CTO of Brainpower Group and has final responsibility for architecture and delivery.
More from Erik
