Contents
- What the OWASP Top 10 is, and is not
- What changed since 2021
- The ten categories, explained
- What a scanner finds, and what only a person finds
- Self-assessment: where your application stands
- APIs and mobile apps: the sister lists
- OWASP and regulations
- How we test an application against the Top 10
- Frequently asked questions
- Sources
In 30 seconds
- The current edition is OWASP Top 10:2025, presented in November 2025 and finalised in December 2025 113.
- It is based on data from over 2.8 million applications and 589 CWE categories analysed; 8 categories come from data, 2 from the community survey 2.
- Two new categories: A03 software supply chain and A10 mishandling of exceptional conditions; SSRF moved into A01 1.
- The Top 10 is an awareness document, “the bare minimum”; for verification OWASP recommends ASVS 5.0 34.
- Business logic flaws (A06) cannot be found by a scanner — OWASP’s own testing guide says so 6.
What the OWASP Top 10 is, and is not
The OWASP Top 10 is the list of the most important security risks for web applications, published by the OWASP foundation. The 2025 edition, the eighth, was presented as a release candidate in November 2025 and finalised in December 2025 113. The ranking starts from data on over 2.8 million applications, contributed by 13 organisations, plus a community survey; 589 CWE categories were analysed, 248 of which fall into the ten risks 2.
What it is not: a compliance standard. OWASP calls it “primarily an awareness document” and “the bare minimum”, and for verifying an application it recommends ASVS — 345 requirements on three levels, in version 5.0 from May 2025 34. The actual testing methodology is in the WSTG testing guide 5.
What changed since 2021
| 2025 | Compared with 2021 |
|---|---|
| A01 Broken Access Control | Stays 1st; SSRF (formerly A10) moves here. Every application tested had some form of the problem 11. |
| A02 Security Misconfiguration | Rises from 5th to 2nd 1. |
| A03 Software Supply Chain Failures | New; extends outdated components (A06:2021) 1. |
| A04 Cryptographic Failures | Drops from 2nd to 4th 1. |
| A05 Injection | Drops from 3rd to 5th; includes XSS 1. |
| A06 Insecure Design | Drops from 4th to 6th 1. |
| A07 Authentication Failures | Stays 7th, with a shorter name 1. |
| A08 Software or Data Integrity Failures | Stays 8th 1. |
| A09 Security Logging and Alerting Failures | Stays 9th; “monitoring” becomes “alerting” 1. |
| A10 Mishandling of Exceptional Conditions | New 1. |
OWASP has already listed three risks to watch for the next edition: lack of application resilience, memory management failures and inappropriate trust in AI-generated code 12.
The ten categories, explained
Open each category: what it means, what a manual tester checks and how to fix it. The WSTG codes point to the tests in the OWASP guide 15.
A01:2025Broken Access ControlBroken Access Control
- What it means
- A user does what they are not allowed to: sees another customer’s order, changes an ID in the URL and gets someone else’s data, reaches admin functions. Since 2025 it also includes SSRF.
- What we check manually
- We test with at least two accounts and every role: who can read, modify and delete whose objects (WSTG-ATHZ-02, -03, -04).
- How to fix it
- Ownership checks on the server, on every request; deny by default; never trust IDs coming from the client.
A02:2025Security MisconfigurationSecurity Misconfiguration
- What it means
- Default settings, forgotten test accounts, verbose error messages, missing headers, open cloud services. It rose from 5th to 2nd place.
- What we check manually
- A scanner finds a lot here; a person confirms what is exploitable and what is just noise, and links a weak setting to the rest of the attack.
- How to fix it
- Repeatable, minimal configuration, checked automatically at every release.
A03:2025Software Supply Chain FailuresSoftware Supply Chain Failures
- What it means
- New in 2025: compromise of how software is built, delivered or updated, including through dependencies. It extends the old outdated-components category; it ranked first in the community survey.
- What we check manually
- We check exposed versions, the JavaScript libraries in the page, who can publish to the pipeline and whether artefacts are verified.
- How to fix it
- A dependency inventory (SBOM), pinned versions, signed artefacts, least privilege in the delivery pipeline.
A04:2025Cryptographic FailuresCryptographic Failures
- What it means
- Unencrypted sensitive data, weak algorithms, keys in source code, predictable random numbers. It dropped from 2nd to 4th.
- What we check manually
- We follow sensitive data from the form to the database: transport, storage, tokens and password reset.
- How to fix it
- TLS everywhere, current algorithms, passwords hashed with dedicated functions (Argon2, bcrypt), keys in a vault, not in code.
A05:2025InjectionInjection
- What it means
- Untrusted data reaches an interpreter: SQL, system commands, the browser (XSS). It has the most CVEs of any category.
- What we check manually
- We manually confirm blind and second-order injections and contexts a scanner cannot verify (WSTG-INPV-05).
- How to fix it
- Parameterised queries, context-aware output encoding, allow-list validation.
A06:2025Insecure DesignInsecure Design
- What it means
- The control is missing by design, including business logic: a discount applied twice, a payment step skipped, a limit that does not exist.
- What we check manually
- A scanner does not reach here at all — WSTG says so itself. We abuse the flows: step order, limits, race conditions (WSTG-BUSL-01…09).
- How to fix it
- Threat modelling at design time, server-side limits, tests for abuse cases, not just happy paths.
A07:2025Authentication FailuresAuthentication Failures
- What it means
- A false identity is accepted as real: guessable passwords, sessions that never expire, abusable password resets, bypassed MFA.
- What we check manually
- Stateful, multi-step flows where scanners are weak: password reset, account lockout, session fixation (WSTG-ATHN-03, -04, -09; WSTG-SESS-03).
- How to fix it
- MFA, rate limiting, sessions invalidated on logout and password change, single-use reset tokens.
A08:2025Software or Data Integrity FailuresSoftware or Data Integrity Failures
- What it means
- Trusting code or data without verification: objects deserialised from requests, unsigned updates, scripts loaded from other domains.
- What we check manually
- We look for unsafe deserialisation and fields the client should not be able to write (mass assignment).
- How to fix it
- Signed updates, integrity on external scripts (SRI), allow-listed fields.
A09:2025Security Logging and Alerting FailuresSecurity Logging and Alerting Failures
- What it means
- Important events are not recorded or trigger no alert: the attack goes on for months unseen. “Monitoring” became “Alerting”.
- What we check manually
- During the test we note which of our actions should have been seen; at the end we compare with what your team actually saw.
- How to fix it
- Logs for authentication, access and errors, with alerts that reach a person within hours.
A10:2025Mishandling of Exceptional ConditionsMishandling of Exceptional Conditions
- What it means
- New in 2025: unusual situations are not prevented, detected or handled — errors that leave a transaction half-done, exceptions that open access instead of closing it.
- What we check manually
- We trigger errors at awkward moments and watch which state remains (WSTG-ERRH-01).
- How to fix it
- “Fail closed”: on error, deny and roll back the whole operation; messages without technical details.
What a scanner finds, and what only a person finds
Automated scanners are good at what shows in a single request: versions, headers, classic injections. They stay blind to anything that needs context — who owns an object, in what order the steps must happen, what a discount means. The OWASP guide states explicitly that business logic flaws “cannot be detected by a vulnerability scanner” 6.
| Category | The scanner | The tester |
|---|---|---|
| A01 Access (IDOR) | Does not know who owns the object | Tests with two accounts, on every role 7 |
| A02 Misconfiguration | Finds a lot, with noise | Confirms what is exploitable |
| A05 Injection | Finds classic cases | Confirms blind and second-order injections |
| A06 Business logic | Does not reach it at all 6 | Abuses flows and limits |
| A07 Authentication | Weak on multi-step flows | Reset, lockout, sessions |
Self-assessment: where your application stands
How ready is your application? 10 questions, one per category
Your answers stay in the browser. “Not sure” counts as a risk: what is not known has not been verified.
0 of 10 categories to check
Start with these; an application penetration test checks all ten, with evidence and remediation steps.
Well prepared Worth checking High risk Request a test on all ten →APIs and mobile apps: the sister lists
For APIs, OWASP keeps a separate list, the API Security Top 10:2023. First place goes to BOLA (broken object level authorization), the API equivalent of IDOR 8. For mobile apps, the Mobile Top 10 received a final release in 2024, with improper credential usage in first place 9.
OWASP and regulations
Standards do not require the “OWASP Top 10” by that name, but they do require defences against the same attack classes. PCI DSS v4.0.1, requirement 6.2.4, requires techniques that prevent injections and attacks on business logic and access control in bespoke software 10. In compliance audits, an application test covering the Top 10 and ASVS is the direct evidence that these requirements actually work.
How we test an application against the Top 10
- Scope and accounts
One account per role, plus two accounts on the same role — without them, A01 cannot be tested.
- Mapping the application
Every function, API and flow, including those the interface does not show.
- Automated testing as support
The scanner quickly covers A02 and classic A05; its findings are confirmed manually.
- Manual testing by category
Access control, business logic, authentication and errors, following the WSTG tests 5.
- Report and retest
Every finding with its OWASP category, severity, evidence and fix; after the fix, the retest closes it with evidence.
Frequently asked questions
What is the current edition of the OWASP Top 10?
Which new categories does the 2025 edition add?
Is the OWASP Top 10 a compliance standard?
Can an automated scanner cover the whole Top 10?
What is the difference between the Top 10, ASVS and WSTG?
Does the Top 10 apply to APIs?
Sources
Every statement about a law or standard links to its official source. Consulted on the date shown.
- OWASP Top 10:2025owasp.org · accessed 22 October 2026
- OWASP Top 10:2025 — introduction and methodologyowasp.org · accessed 22 October 2026
- OWASP Top 10:2025 — using the Top 10 as a standardowasp.org · accessed 22 October 2026
- OWASP Application Security Verification Standard (ASVS) 5.0owasp.org · accessed 22 October 2026
- OWASP Web Security Testing Guide (WSTG) v4.2owasp.org · accessed 22 October 2026
- WSTG — introduction to business logic testingowasp.org · accessed 22 October 2026
- WSTG-ATHZ-04 — Insecure Direct Object References (IDOR)owasp.org · accessed 22 October 2026
- OWASP API Security Top 10:2023owasp.org · accessed 22 October 2026
- OWASP Mobile Top 10 (2024)owasp.org · accessed 22 October 2026
- PCI Security Standards Council — document library (PCI DSS v4.0.1)pcisecuritystandards.org · accessed 22 October 2026
- A01:2025 Broken Access Controlowasp.org · accessed 22 October 2026
- OWASP Top 10:2025 — next steps (X01–X03)owasp.org · accessed 22 October 2026
- The OWASP Top 10 repository (release history)github.com · accessed 22 October 2026
About the authors
The guides are written by the team that does the testing, not a marketing department. We update them when the law, the standard or what we see in testing changes.