OWASP Top 10:2025 for Penetration Testers — What Actually Changed?
A tester's reading of the 2025 list: what each category means in an engagement, what to look for, and what the changes say about where risk has moved.
The OWASP Top 10 is an awareness document, not a testing standard. Used as a checklist it produces shallow engagements. Used as a map of where risk has concentrated, it is genuinely useful — particularly the movement between editions, which says more than any individual entry.
Two changes in the 2025 edition are worth a tester's attention. Software supply chain failures move up and broaden beyond vulnerable dependencies to the whole build and distribution path. And a new entry covers the mishandling of exceptional conditions — error paths, failure modes and the states a system enters when something goes wrong.
How to use the list in an engagement
Treat each category as a prompt for a line of enquiry rather than a test case. The sections below give a tester's framing for each: what it means, what to look for, and what the defensive takeaway is. Refer to the official OWASP publication for the authoritative definitions and data.
A01 — Broken Access Control
What it means. The application does not consistently enforce what an authenticated caller may reach or do.
What to look for. Object-level checks on every verb, not just read. Role checks that stand in for ownership checks. Endpoints added after the original CRUD surface — exports, admin tooling, integrations. Authorization performed in the client. Internal service calls that trust the network.
Why it stays first. It cannot be centralised the way authentication can. Every handler has to get it right, and the number of handlers only grows.
A02 — Security Misconfiguration
What to look for. Defaults left in place, verbose errors, permissive CORS, storage and bucket policy, unnecessary features enabled, management interfaces reachable, and differences between environments where staging is configured more loosely than production but holds the same data.
Testing question. Was this configuration decided, or inherited? Inherited configuration is where the findings are.
A03 — Software Supply Chain Failures
What changed. The scope is wider than known-vulnerable dependencies. It reaches the build pipeline, package sources, plugins, container base images and the distribution path.
What to look for. Whether an inventory exists at all. Integrity verification on artefacts. Who can modify a pipeline definition. Where build secrets live and what they can reach. Whether a dependency can execute code at install time. Whether an internal package name could be resolved from a public registry.
Why it moved up. The pipeline is a production system with production credentials, and it is frequently excluded from the scope of the assessments that cover the application it builds.
A04 — Cryptographic Failures
What to look for. Data classified correctly in the first place; transport configuration and certificate validation, including internal hops; key management and rotation; storage of secrets; password hashing choices; and the use of encryption where integrity was the actual requirement.
Testing question. Not "is it encrypted" but "what threat does this encryption address, and does the key management support that claim?"
A05 — Injection
What to look for. Injection has broadened well past SQL: template engines, expression languages, command construction, LDAP, XML, NoSQL query objects, and now prompt construction in LLM-backed features. The common shape is the same — data crossing into a context where it is interpreted.
Defensive takeaway. Parameterisation where the interpreter supports it; strict allow-lists where it does not; and context-correct encoding at the point of output.
A06 — Insecure Design
What it means. The implementation is faithful to a design that was not safe. No amount of correct coding fixes it.
What to look for. Missing rate limits on operations with real-world cost. Recovery flows that weaken the authentication they are meant to support. Trust assumptions between services that nothing verifies. Business processes with no enforced sequence. This category is where threat modelling earns its place.
A07 — Authentication Failures
What to look for. Session lifecycle — fixation, rotation on privilege change, invalidation on logout and password change. Multi-factor coverage including recovery and legacy paths. Credential stuffing resistance. Token handling: expiry, audience, signature verification, and whether the algorithm is pinned.
A08 — Software or Data Integrity Failures
What to look for. Unsigned updates, deserialisation of untrusted data, CI/CD steps that pull unverified artefacts, and client-side dependencies loaded without integrity checks. Distinct from A03: this is about trusting content that was never verified, not about the provenance of the supply chain.
A09 — Security Logging & Alerting Failures
What to look for. Whether security-relevant events are recorded at all; whether they contain the subject, object and action needed to reconstruct a sequence; whether logs are tamper-resistant; and whether anything is actually alerted on. Ask the detection question during the test: did anyone see the testing traffic?
Why it matters to a tester. This is the category that determines whether the next real incident is discovered internally or reported by a third party.
A10 — Mishandling of Exceptional Conditions
What changed. A new entry covering how systems behave when something goes wrong — errors, timeouts, partial failures, unexpected states.
What to look for. Whether failures fail closed or open. Whether an error path skips a downstream check. Whether a timeout mid-transaction leaves an object in a state the state machine does not define. Whether error output discloses internals. Whether retries are idempotent.
Testing approach. Deliberately induce failure: interrupt a flow, force a dependency to time out, submit values that break an assumption, run concurrent operations against one object. The happy path is usually well tested. The error path frequently is not.
Conclusion
For a tester, the practical value of the 2025 edition is the reminder that the perimeter of an assessment is usually drawn too tightly. If the pipeline that builds the application and the error paths that run when it fails are both out of scope, two of the categories cannot be evaluated at all.
Use the list to argue for scope. Then test the application properly, which means going well past ten categories.
References
- OWASP Top 10 — official project page
- OWASP Web Security Testing Guide
- OWASP Application Security Verification Standard
- OWASP Proactive Controls
Bring this to your own environment.
If any of the above describes a system you are responsible for, the fastest next step is a conversation about scope.