The OWASP Top 10

Why it matters

Security defects rarely appear in functional tests, because the application behaves as specified for the honest user. They appear when someone sends a request the UI never sends: another user's id, an admin path, a token after logout, a quote inside a field. The Top 10 names the categories of weakness that testing data shows are widespread, weighted by how exploitable and damaging they are, so covering it covers failures that are both common and serious.

It is also a shared language: developers, security specialists and auditors know what an "A01 finding" means, so a report that names the category is understood and prioritised faster. And it marks what a QA tester covers before a specialist penetration test goes deeper into the same categories.

What the Top 10 is, and what it is not

OWASP publishes a new edition every few years; 2025 replaced 2021. Eight of the ten categories come from testing data contributed by organisations that test applications, ranked by a score that combines how often each weakness is found (its incidence rate) with its exploitability and impact; a community survey of practitioners adds the other two, for risks the data under-represents (A09's 2025 page says it was voted in, and A03 was the survey's top-ranked concern). Three changes matter in 2025: A10 Mishandling of Exceptional Conditions is new; A03 grew from 2021's Vulnerable and Outdated Components into the whole build, distribution and update chain; A09 was renamed to stress alerting, not only logging. Each category maps to a list of CWEs: the Common Weakness Enumeration is MITRE's catalogue of weakness types (a CVE, by contrast, names one vulnerability in one product), and many scanners label their findings with CWE ids.

It is neither a standard nor a complete checklist. The Application Security Verification Standard (ASVS) turns security into verifiable requirements, the Web Security Testing Guide (WSTG) gives step-by-step test procedures, and the OWASP API Security Top 10 (2023) covers API-specific risks. Use the Top 10 to decide where to look first, ASVS and WSTG to decide how thoroughly.

• Always quote the year: positions move between editions, and A03 meant Injection in 2021 but Software Supply Chain Failures in 2025.
• Test only systems you own or have written permission to test. Every check in this lesson is a non-destructive observation, not an exploit.

The ten categories of 2025 and the tester's first check

For each category: what it groups, then the first check a tester makes. Later lessons in this module go deeper into each area; here the goal is to recognise every category and know where to look.

• A01:2025 Broken Access Control: acting outside one's permissions, for example reading another user's record by changing an id. Check: repeat the request with a valid token for the wrong user and the wrong role; expect 403 or 404.
• A02:2025 Security Misconfiguration: default accounts, unnecessary features, verbose errors, missing security headers, permissive permissions. Check: read the response headers, trigger an error page, try documented default credentials on the test environment.
• A03:2025 Software Supply Chain Failures: vulnerable, unmaintained, untracked or compromised components, build tools and update channels. Check: ask for the dependency inventory with versions and whether advisories are reviewed before each release.
• A04:2025 Cryptographic Failures: sensitive data sent or stored without encryption, weak algorithms, hard-coded keys. Check: confirm TLS on every endpoint; look for passwords, card numbers or tokens stored or logged in clear text.
• A05:2025 Injection: untrusted input reaching an interpreter (SQL, OS command, template, HTML) unescaped; cross-site scripting (XSS), where input ends up running as script in another user's browser, belongs here. Check: a quote, an angle bracket or a semicolon in each field; watch for errors, changed results or rendered markup.
• A06:2025 Insecure Design: the business logic allows abuse even with correct code, such as a coupon applied twice. Check: walk the flow as a dishonest user and try to break the rule without any technical trick.
• A07:2025 Authentication Failures: weak passwords accepted, no lockout or throttling, user enumeration, sessions that survive logout. Check: wrong-password attempts, messages that differ for existing and unknown accounts, an old token after logout.
• A08:2025 Software or Data Integrity Failures: code or data trusted without verification: scripts from an untrusted CDN, unsigned updates, an unprotected CI/CD pipeline. Check: ask how build artefacts and updates are verified, and whether data the client sends back, such as a serialised object in a cookie, is accepted without an integrity check.
• A09:2025 Security Logging and Alerting Failures: logins, failed logins and high-value transactions not logged, logs not monitored, alerts not raised. Check: after your tests, ask whether your forbidden requests appear in the logs and whether anyone was alerted.
• A10:2025 Mishandling of Exceptional Conditions: errors not handled where they occur, failing open (allowing the action when a check itself errors), exposed stack traces, inconsistent state after a failure. Check: send a missing parameter, a huge value or a wrong type; expect a clean error and a closed door.

Try it: Security Header Analyzer Try it: API Authentication Tester Try it: Cookie Analyzer

Worked example: one endpoint through the ten categories

A customer portal lets a logged-in customer download an invoice as a PDF. Walking this request through the list takes a few minutes and gives a short, prioritised set of test conditions.

• A01: repeat the request with customer B's token for A's invoice 8812. Expected: 403 or 404, never the PDF. Ask too whether the stored PDF has a predictable direct URL that skips this check. First priority: invoices hold personal and financial data.
• A07 and A04: with no token the request must get 401; the token must stop working after logout and expiry; the response must use TLS and must not be cacheable by a shared cache (Cache-Control: no-store or private).
• A02 and A10: request /api/invoices/abc/pdf and /api/invoices/99999999/pdf. Expected: a short error with the right status, no stack trace, no framework version in the headers.
• A05 and A09: the id is numeric, so also send an id with a quote, 8812'; a database error in the response is a finding even without exploitation. After the run, ask the developer to find your forbidden requests in the log.
• A03, A06 and A08 are questions for the team: which PDF library and version renders the invoice (A03), can an invoice be produced for an unpaid order (A06), and is the PDF built from the server's own records or from values the client sends, such as an amount, without verification (A08).

GET /api/invoices/8812/pdf HTTP/1.1
Host: portal.example.com
Authorization: Bearer <access token of customer A>
Accept: application/pdf

Try it: API Request Builder Try it: JWT Claims Analyzer Try it: Special Character Dataset Generator

Frequently asked questions

References

• OWASP Top 10:2025OWASP Foundation · 2025The ten most critical web application security risks, with how to test for and prevent each.
• OWASP Web Security Testing Guide (WSTG)OWASP FoundationThe reference methodology for testing web applications and APIs for security weaknesses, test by test.
• OWASP Application Security Verification Standard (ASVS)OWASP FoundationA checklist of verifiable security requirements for web applications, grouped in three assurance levels.
• OWASP API Security Top 10 (2023)OWASP Foundation · 2023The ten most common API weaknesses: broken object-level authorization, broken authentication, unrestricted resource consumption and more.