What is the OWASP Top 10?
The OWASP Top 10 is a periodically updated ranking of the ten most critical web application security risks, published by the OWASP Foundation, a not-for-profit that develops open, vendor-neutral application security resources. It is not a list of individual bugs. Each entry is a risk category bundling a family of related weaknesses seen repeatedly in real-world applications.
The current edition is published as the OWASP Top 10:2025, and the project's canonical landing page is owasp.org/Top10, which always redirects to whichever edition is current. First published in 2003, the list has been revised repeatedly since, with the 2025 edition following the 2021 one.
The reason it carries so much weight is that it functions as a common vocabulary. When a developer, a security tester, an auditor and a compliance framework all refer to 'A01' or 'injection', they mean the same thing. Frameworks such as PCI DSS v4.0, published by the PCI Security Standards Council, reference the OWASP Top 10 as an example of an industry-standard secure development methodology, and it is one of the frameworks most penetration test and vulnerability reports map findings against.
The OWASP Top 10:2025 categories
Here is the current list, in order, with a plain-English summary of what each category actually covers. The authoritative text for each one lives at owasp.org/Top10/2025.
| Code | Category | In short |
|---|---|---|
| A01:2025 | Broken Access Control | Users can act or see data outside what their role permits. |
| A02:2025 | Security Misconfiguration | Insecure defaults, verbose errors, needless features left on. |
| A03:2025 | Software Supply Chain Failures | Compromise via dependencies, build systems or third-party code. |
| A04:2025 | Cryptographic Failures | Weak, missing or misapplied encryption exposes sensitive data. |
| A05:2025 | Injection | Untrusted input is interpreted as a command or query. |
| A06:2025 | Insecure Design | Security controls were never designed in, not just misconfigured. |
| A07:2025 | Authentication Failures | Weaknesses in confirming a user, device or system is genuine. |
| A08:2025 | Software or Data Integrity Failures | Code or data trusted without verifying it has not been tampered with. |
| A09:2025 | Security Logging and Alerting Failures | Logging exists but nobody, or nothing, acts on it. |
| A10:2025 | Mishandling of Exceptional Conditions | Errors, edge cases and failure states are handled insecurely. |
A01: Broken Access Control
The top category in both the 2021 and 2025 editions. It covers any case where an application fails to properly restrict what an authenticated, or even unauthenticated, user is allowed to do: viewing another customer's records by changing an ID in a URL, reaching an admin function as a normal user, or bypassing a permission check entirely. Server-Side Request Forgery, its own category in the 2021 list, is now treated as a specific pattern of access control failure and has been folded into this category for 2025.
The simplest test for it is an identifier swap: request GET /api/v1/invoices/1042 while authenticated as a user who owns invoice 1043, and check whether the response is a 403 or a 200 carrying somebody else's data. In attacker terms the credential-driven variant is Valid Accounts (T1078) in MITRE ATT&CK.
A02: Security Misconfiguration
Jumped from fifth place in 2021 to second in 2025, reflecting how much modern application behaviour is driven by configuration rather than code. Default credentials left in place, unnecessary services or ports left enabled, verbose error pages that leak stack traces, missing security headers, and overly permissive cloud storage permissions all fall here.
A quick response-header check catches a surprising share of it. Look for Strict-Transport-Security, a Content-Security-Policy that is not simply default-src *, and X-Content-Type-Options: nosniff; then confirm that error responses return a generic message rather than a stack trace or framework version banner.
A03: Software Supply Chain Failures
New for 2025. It expands what used to be a narrower category about vulnerable and outdated components into a broader look at the entire software supply chain: compromised open-source dependencies, breached update mechanisms, tampered build pipelines, and attacks against the systems that assemble and ship software, not just the libraries an application imports.
This is the web-application view of what MITRE ATT&CK catalogues as Supply Chain Compromise (T1195). A software bill of materials is the practical starting point, because you cannot correlate dependencies against known vulnerabilities you have never inventoried.
A04: Cryptographic Failures
Was the second-ranked category in 2021. Covers weak or outdated cipher choices, hard-coded encryption keys, sensitive data transmitted or stored unencrypted, and improper certificate or key validation, any of which can expose data that should have been protected.
A05: Injection
The category most people picture when they think of a web vulnerability. Untrusted input gets interpreted as part of a command or query instead of pure data: SQL injection, command injection, and cross-site scripting are all injection variants, spanning from high-frequency, lower-impact issues like reflected XSS to lower-frequency, high-impact issues like SQL injection against an unauthenticated endpoint.
Each variant has a precise identifier in CWE, which is what a good report cites rather than the loose word injection. Where the injectable endpoint is internet-facing, successful exploitation is the behaviour catalogued as Exploit Public-Facing Application (T1190).
A06: Insecure Design
Distinct from misconfiguration: this is about controls that were never designed in at all, rather than controls that exist but were set up incorrectly. Missing threat modelling, business logic that implicitly trusts a client it should not, and architectures with no concept of rate limiting or abuse resistance are all design failures, not coding bugs.
A07: Authentication Failures
Weaknesses in confirming identity: credential stuffing resistance, weak password policy, session fixation, and missing multi-factor authentication on privileged accounts. The 2025 edition notes this category's occurrence rate is trending down as standardised authentication frameworks see wider adoption, though it remains a common finding in practice.
The attacker behaviour here is Brute Force (T1110), whose sub-techniques cover password spraying and credential stuffing specifically. Testing should confirm that repeated failures across many accounts are throttled and alerted, not only that repeated failures on one account are.
A08: Software or Data Integrity Failures
Covers failures to verify that software or data can actually be trusted before it is used: insecure deserialisation of untrusted data, plugins or updates applied without signature verification, and CI/CD pipelines that lack integrity checks on what they build and deploy.
A09: Security Logging and Alerting Failures
Renamed from 'Monitoring' to 'Alerting' in the 2025 edition to make a specific point: logging that generates records nobody reviews and nothing acts on provides minimal security value. This category covers missing logs for authentication attempts and access control failures, and logs that exist but are never wired to an alert.
A10: Mishandling of Exceptional Conditions
The other new category for 2025. It covers improper error handling, logic errors in exception paths, and systems that 'fail open' (defaulting to allow) rather than 'fail closed' (defaulting to deny) when something unexpected happens. These edge cases are easy to miss in code review because the application usually behaves correctly on the happy path.
What changed from the 2021 edition
The 2025 edition keeps the same ten-slot structure but reshuffles what fills it, based on a fresh review of vulnerability data and community input since 2021. The headline changes:
- Broken Access Control stays at number one, and now absorbs Server-Side Request Forgery, which was its own category (A10:2021) in the previous edition.
- Security Misconfiguration jumped from fifth to second, reflecting how much risk now sits in configuration rather than application code.
- Software Supply Chain Failures is a new category at A03, expanding what used to be a narrower 'Vulnerable and Outdated Components' category into the broader dependency and build-pipeline ecosystem.
- Mishandling of Exceptional Conditions is new at A10, giving error handling and fail-open logic its own dedicated category for the first time.
- Security Logging and Monitoring Failures was renamed to Security Logging and Alerting Failures, sharpening the emphasis on acting on logs rather than merely collecting them.
- The remaining categories (Cryptographic Failures, Injection, Insecure Design, Authentication Failures, and Software or Data Integrity Failures) persist from 2021, with updated framing rather than a structural change.
The OWASP API Security Top 10
APIs fail differently to traditional web applications: there is usually no browser rendering HTML to mask a mistake, and every endpoint is a direct line to backend logic and data. OWASP maintains a separate list on its own release cycle for this, the OWASP API Security Project, whose current edition is the API Security Top 10:2023. It has not moved in lockstep with the 2025 web application edition. See API security best practices for how to act on it.
| Code | Risk | In short |
|---|---|---|
| API1:2023 | Broken Object Level Authorization | An endpoint returns or edits another user's object by ID. |
| API2:2023 | Broken Authentication | Authentication tokens or flows are implemented incorrectly. |
| API3:2023 | Broken Object Property Level Authorization | Individual fields on an object are exposed or editable when they should not be. |
| API4:2023 | Unrestricted Resource Consumption | No limits on calls, payload size or cost, enabling denial of service or cost abuse. |
| API5:2023 | Broken Function Level Authorization | A lower-privilege user can reach a higher-privilege function. |
| API6:2023 | Unrestricted Access to Sensitive Business Flows | A legitimate flow is automated or abused at a scale that harms the business. |
| API7:2023 | Server Side Request Forgery | The API fetches a remote resource without validating the supplied URI. |
| API8:2023 | Security Misconfiguration | Customisable, complex API configuration is left insecure. |
| API9:2023 | Improper Inventory Management | Old, undocumented or shadow API versions stay reachable. |
| API10:2023 | Unsafe Consumption of APIs | Data pulled from a third-party API is trusted more than user input, without the same validation. |
Why the OWASP Top 10 matters beyond the list itself
The value of the OWASP Top 10 is less about the exact ranking and more about what it standardises: a shared taxonomy that development teams, security testers, auditors and compliance frameworks can all point to without redefining terms every time. A finding labelled 'A01: Broken Access Control' means the same thing whether it came from an internal code review, a penetration test, or a customer security questionnaire.
It is also one of the frameworks most compliance reporting maps against, alongside standards such as PCI DSS v4.0, NIST 800-53, HIPAA, GDPR, ISO 27001 and SMB1001. Being able to say 'here is every A01 finding across the last three assessments' is far more useful to a security team than a flat list of individual bugs with no shared structure.
It is worth being precise about what the OWASP Top 10 is not. It is not a certification, and passing an assessment that maps to it is not a claim that an application 'is compliant' with anything. It is a risk taxonomy that findings get mapped against, used to structure and prioritise remediation work.
How it fits with the other OWASP material
The Top 10 tells you which risk categories matter. It does not tell you how to test for them. That job belongs to the OWASP Web Security Testing Guide, a far larger catalogue of concrete web test cases, currently at version 4.2. A credible web assessment cites the Top 10 for the risk taxonomy and the WSTG for the test coverage.
How it fits with CWE, CVSS and KEV
Four references do different jobs and are often confused. The OWASP Top 10 groups risks into categories. CWE names the specific weakness type. CVSS scores severity, ideally reported as a full vector such as CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H rather than a bare word. The CISA Known Exploited Vulnerabilities catalogue says whether the weakness is being exploited in the wild, which is usually the strongest single signal for what to fix first.
How testing actually detects each category
Different OWASP Top 10 categories call for different testing techniques. A single scan type will not cover all ten well; a credible testing programme layers several approaches, typically the ones described in what penetration testing actually involves.
Authorisation and access control testing
Detecting Broken Access Control (A01) means systematically testing what happens when one authenticated identity tries to reach another identity's data or a higher-privilege function, not just checking that a login screen exists. In practice that means replaying the same request under at least three identities: the owner, a peer account, and no session at all.
Configuration and baseline review
Security Misconfiguration (A02) is found by comparing live configuration, default credentials, exposed services, headers and error handling against known-good baselines, the same approach used for CIS Benchmark checks on cloud and Kubernetes configuration.
Dependency and component analysis
Software Supply Chain Failures (A03) is caught by identifying known-vulnerable components and correlating them against CVE databases and CVSS v3.1 severity, with CISA KEV data used to prioritise the ones under active exploitation.
Payload-driven and fuzzing techniques
Injection (A05) is where automated testing is at its strongest: systematically sending crafted payloads to every input point and observing how the application responds, then, where authorised, safely proving impact rather than only flagging a suspicious response. A response that changes measurably under a timing payload is evidence; a response that merely echoes a payload back is a candidate.
Credential and session testing
Authentication Failures (A07) are surfaced through credential testing against password policy, session handling review, and checking whether privileged accounts actually enforce multi-factor authentication rather than merely offering it.
Logging, alerting and evidence review
Security Logging and Alerting Failures (A09) and Mishandling of Exceptional Conditions (A10) are harder to automate: they need a tester to trigger failure states and edge cases deliberately, then check whether the application logged the event and whether that log would actually trigger a response.
How PentestOps helps
PentestOps tests web applications and APIs against OWASP Top 10 and API Top 10 categories, including SQLi, XSS, SSRF, IDOR and auth bypass, over REST and GraphQL, with a live finding stream over WebSocket during the scan. See web application penetration testing and API penetration testing for the detail.
Confirmed findings are validated with safe, RoE-gated exploitation rather than left as unverified detections, and reports map every finding to 8 compliance reporting frameworks (OWASP Top 10, PCI DSS v4.0, NIST 800-53, SOC 2, HIPAA, GDPR, ISO 27001, SMB1001) plus CIS Benchmarks for AWS, Azure, GCP and Kubernetes, exported as PDF, CSV or JSON/API.
Pricing is asset-wise with scans unlimited within fair use. Run a free demo scan to see live findings against these categories, or start a 7-day free trial; a card is required to start your trial and is only charged after the trial ends, unless you cancel first.