Technical guide · Web applications

OWASP Top 10:2025,
category by category

The 2025 edition changed the list: two new categories, SSRF moved into access control, a new order. What each risk means, what a scanner finds, what only a person finds and how to fix it.

Updated 9 min read 13 cited sources
Contents
  1. What the OWASP Top 10 is, and is not
  2. What changed since 2021
  3. The ten categories, explained
  4. What a scanner finds, and what only a person finds
  5. Self-assessment: where your application stands
  6. APIs and mobile apps: the sister lists
  7. OWASP and regulations
  8. How we test an application against the Top 10
  9. Frequently asked questions
  10. 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.
Edition
2025 1
Data
2.8M applications 2
New categories
A03 and A10 1
Verification
ASVS 5.0 4

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

2025Compared with 2021
A01 Broken Access ControlStays 1st; SSRF (formerly A10) moves here. Every application tested had some form of the problem 11.
A02 Security MisconfigurationRises from 5th to 2nd 1.
A03 Software Supply Chain FailuresNew; extends outdated components (A06:2021) 1.
A04 Cryptographic FailuresDrops from 2nd to 4th 1.
A05 InjectionDrops from 3rd to 5th; includes XSS 1.
A06 Insecure DesignDrops from 4th to 6th 1.
A07 Authentication FailuresStays 7th, with a shorter name 1.
A08 Software or Data Integrity FailuresStays 8th 1.
A09 Security Logging and Alerting FailuresStays 9th; “monitoring” becomes “alerting” 1.
A10 Mishandling of Exceptional ConditionsNew 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.

CategoryThe scannerThe tester
A01 Access (IDOR)Does not know who owns the objectTests with two accounts, on every role 7
A02 MisconfigurationFinds a lot, with noiseConfirms what is exploitable
A05 InjectionFinds classic casesConfirms blind and second-order injections
A06 Business logicDoes not reach it at all 6Abuses flows and limits
A07 AuthenticationWeak on multi-step flowsReset, 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.

  1. A01 Does every request check on the server that the requested object belongs to the user?
  2. A02 Are configurations (headers, ports, default accounts) checked after every release?
  3. A03 Do you know which dependencies and versions run in production and who can publish them?
  4. A04 Is sensitive data encrypted with current algorithms, with keys outside the code?
  5. A05 Do all queries use parameters, and is output encoded by context?
  6. A06 Have critical flows (payment, reset, discounts) been analysed for abuse?
  7. A07 Do you have MFA, rate limiting and sessions invalidated on logout?
  8. A08 Are updates and serialised data verified (signature, integrity)?
  9. A09 Would an ongoing attack reach a person as an alert within hours?
  10. A10 On an error, does the application deny and roll back the operation, without showing technical details?

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.

ListTop three
API Security Top 10:2023API1 BOLA · API2 authentication · API3 object property level authorization 8
Mobile Top 10 (2024)M1 credentials · M2 supply chain · M3 authentication and authorization 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

  1. Scope and accounts

    One account per role, plus two accounts on the same role — without them, A01 cannot be tested.

  2. Mapping the application

    Every function, API and flow, including those the interface does not show.

  3. Automated testing as support

    The scanner quickly covers A02 and classic A05; its findings are confirmed manually.

  4. Manual testing by category

    Access control, business logic, authentication and errors, following the WSTG tests 5.

  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?
The 2025 edition, presented in November 2025 and finalised in December 2025. It replaces the 2021 edition 113.
Which new categories does the 2025 edition add?
A03 Software Supply Chain Failures (extended from outdated components) and A10 Mishandling of Exceptional Conditions. SSRF, separate in 2021, moved into A01 1.
Is the OWASP Top 10 a compliance standard?
No. OWASP calls it an awareness document and “the bare minimum”; for verifying an application it recommends ASVS 34.
Can an automated scanner cover the whole Top 10?
No. Scanners cover misconfigurations and classic injections well, but cannot verify access control between users or business logic, which need context and human creativity 67.
What is the difference between the Top 10, ASVS and WSTG?
The Top 10 says which risks exist, ASVS which requirements the application must meet (345, on three levels, in version 5.0), and WSTG how each is tested 345.
Does the Top 10 apply to APIs?
Partly; for APIs, OWASP keeps a dedicated list, the API Security Top 10:2023, with broken object level authorization (BOLA) in first place 8.

Sources

Every statement about a law or standard links to its official source. Consulted on the date shown.

  1. OWASP Top 10:2025owasp.org · accessed 22 October 2026
  2. OWASP Top 10:2025 — introduction and methodologyowasp.org · accessed 22 October 2026
  3. OWASP Top 10:2025 — using the Top 10 as a standardowasp.org · accessed 22 October 2026
  4. OWASP Application Security Verification Standard (ASVS) 5.0owasp.org · accessed 22 October 2026
  5. OWASP Web Security Testing Guide (WSTG) v4.2owasp.org · accessed 22 October 2026
  6. WSTG — introduction to business logic testingowasp.org · accessed 22 October 2026
  7. WSTG-ATHZ-04 — Insecure Direct Object References (IDOR)owasp.org · accessed 22 October 2026
  8. OWASP API Security Top 10:2023owasp.org · accessed 22 October 2026
  9. OWASP Mobile Top 10 (2024)owasp.org · accessed 22 October 2026
  10. PCI Security Standards Council — document library (PCI DSS v4.0.1)pcisecuritystandards.org · accessed 22 October 2026
  11. A01:2025 Broken Access Controlowasp.org · accessed 22 October 2026
  12. OWASP Top 10:2025 — next steps (X01–X03)owasp.org · accessed 22 October 2026
  13. 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.

The Pentest.md teamSecurity engineers holding CEH, CISSP, CISA and CISM certifications

Related guides

Want your application tested on all ten?

Manual testing against OWASP Top 10:2025 and ASVS, with evidence, remediation steps and a retest.