OWASP Top 10 Guide

The OWASP Top 10 is the most widely cited list of web application security risks, and it is also one of the most misused: teams treat it as a standard, buy tools that claim to "cover" it, and then miss the categories no scanner can find. The current edition, the OWASP Top 10:2025, adds two new categories (Software Supply Chain Failures and Mishandling of Exceptional Conditions), folds server-side request forgery into Broken Access Control and renames two others. This guide explains each category, its CWEs, prevention and testing, how OWASP builds the list, and how to turn it into a testing programme rather than a compliance checkbox. It is written for application security engineers, developers, testers and security leads who run or buy application testing.

Key takeaways

• The 2025 list is the current edition. Broken Access Control stays at A01, Security Misconfiguration rises to A02, and Software Supply Chain Failures (A03) and Mishandling of Exceptional Conditions (A10) are new.
• Each category is a bundle of CWEs, not a single bug. The 2025 edition maps 248 CWEs across the ten categories, capped at 40 per category, so "A05 Injection" means 37 distinct weakness types.
• It is an awareness document, not a standard. OWASP itself says to use the Application Security Verification Standard (ASVS) for verifiable requirements and discourages any claim of full Top 10 coverage by a tool.
• Several categories cannot be found by scanners. Insecure Design, Logging and Alerting Failures and much of Broken Access Control need threat modelling, design review, manual testing and interviews.
• Identity runs through the list. A01, A04 and A07 are about who can do what with which credential, and A03 and A08 increasingly fail through stolen publishing tokens and signing keys.

The OWASP Top 10:2025 at a glance

The table lists the 2025 categories with their 2021 position and the number of CWEs OWASP mapped to each on the category page. Notable CWEs are those OWASP names in the category text.

How OWASP builds the list

• Contributed testing data: the 2025 dataset covers over 2.8 million applications from contributors including Accenture, Bugcrowd, Veracode, Semgrep and Sonar. Prevalence counts applications with at least one CWE in a category, not individual findings, so A04 Cryptographic Failures shows an average incidence of 3.80% of tested applications rather than a count of bugs.
• Community survey: OWASP picks only eight of the ten categories from the data "because it's incomplete"; the remaining places come from a practitioner survey. Supply chain was ranked first by 50% of survey respondents, and logging has been voted in three times because it is hard to test and under-represented in CVE data.
• CWE mapping: 589 CWEs were analysed and 248 made it into the ten categories, with an average of 25 per category and a cap of 40.
• Exploit and impact weighting: about 175,000 CVE-to-CWE records feed weighted exploit and impact scores from CVSS v2 and v3. CVSS v4 was not used because its scoring algorithm changed and no longer yields separate exploit and impact sub-scores.

OWASP describes the result as "data-informed, but not blindly data-driven". A lower rank does not mean lower risk for your application, and hard-to-test categories (design, logging) are kept on the list deliberately.

The ten categories in practice

For each category: what goes wrong, the controls OWASP recommends and where testing fits. WSTG references are to Web Security Testing Guide v4.2 categories.

A01 Broken Access Control

Users act outside their intended permissions: viewing another customer's record by changing an identifier (insecure direct object reference, CWE-639), reaching admin functions, path traversal or forcing the server to make requests on the attacker's behalf (SSRF, CWE-918). OWASP reports that every application in its testing data had some form of broken access control. The Capital One breach shows SSRF reaching cloud role credentials, which is why SSRF now sits here.

• Prevent: deny by default; implement access control once in trusted server-side code and reuse it; enforce record ownership rather than letting users act on any ID; minimise CORS; log and alert on access control failures; invalidate server-side sessions at logout and keep JWTs short-lived. See the Authorisation Models Guide.
• Test: WSTG-ATHZ tests with two accounts per role, swapping object IDs and calling privileged functions as a low-privilege user.

A02 Security Misconfiguration

Default accounts, verbose errors, unnecessary features, missing security headers, permissive cloud storage and unsafe XML parser settings (XXE, CWE-611). Exposed databases such as the DeepSeek ClickHouse exposure are the cloud-era version.

• Prevent: a repeatable, automated hardening process with identical configurations across environments (different credentials); a minimal platform; configuration review as part of patching; disable external entity resolution in XML parsers; send security headers.
• Test: WSTG-CONF, configuration scanning of infrastructure as code and cloud posture, and DAST for headers and error pages.

A03 Software Supply Chain Failures

Breakdowns or compromises in building, distributing or updating software: untracked or unsupported components (including transitive dependencies), components from untrusted sources, weak change management and a CI/CD pipeline less secure than the systems it deploys. OWASP's examples include SolarWinds, the 2025 Bybit theft and the Shai-Hulud npm worm, which spread through stolen npm tokens; see the Shai-Hulud campaign.

• Prevent: generate and maintain an SBOM for the whole stack; remove unused dependencies; monitor CVE, NVD and OSV; obtain components from official sources and prefer signed packages; use staged or canary rollouts; harden repositories, build servers and developer workstations with MFA, least privilege, separation of duties, signed builds and provenance. See the Open Source Security Guide and the SLSA and Build Provenance Guide.
• Test: software composition analysis (SCA) in every build, plus review of pipeline permissions and publishing credentials. The pipeline side is covered by the OWASP Top 10 CI/CD Security Risks.

A04 Cryptographic Failures

Sensitive data exposed through missing or weak cryptography: broken algorithms (CWE-327), weak randomness (CWE-331, CWE-338) and poor key handling.

• Prevent: classify data and keep sensitive data only as long as needed; TLS 1.2 or later with forward secrecy and HSTS; avoid MD5, SHA-1, CBC mode and PKCS#1 v1.5; prefer authenticated encryption; hash passwords with Argon2, yescrypt, scrypt or PBKDF2-HMAC-SHA-512; keep high-value keys in an HSM. OWASP also asks teams to prepare so high-risk systems are post-quantum safe "no later than the end of 2030". See the Cryptographic Key Management Guide.
• Test: WSTG-CRYP, TLS configuration scans, and code review of key storage and random number generation.

A05 Injection

Untrusted data interpreted as a command or query: cross-site scripting (CWE-79, over 30,000 CVEs), SQL injection (CWE-89, over 14,000 CVEs), OS command injection (CWE-78) and expression language injection. The McKinsey AI platform hack began with SQL injection in unauthenticated APIs.

• Prevent: keep data separate from commands and queries with parameterised interfaces or safe APIs; positive server-side input validation as a supporting control, not the fix; context-aware output encoding and a Content Security Policy for XSS.
• Test: WSTG-INPV and WSTG-CLNT; SAST and DAST both perform reasonably well here, which is why injection is the category most tools report against.

A06 Insecure Design

Missing or ineffective control design, such as business logic that allows unlimited discount codes or a recovery flow with no rate limit. OWASP's distinction matters: "An insecure design cannot be fixed by a perfect implementation."

• Prevent: a secure development lifecycle with AppSec input at design time; a library of secure design patterns or paved-road components; threat modelling for authentication, access control and key business flows; security requirements in user stories; unit and integration tests for misuse cases; tenant isolation by design; OWASP SAMM to structure the programme.
• Test: design review and WSTG-BUSL business logic testing. OWASP notes this category is "beyond the scope of most forms of testing".

A07 Authentication Failures

Credential stuffing, password spraying, default or breached passwords, weak recovery, missing MFA, hard-coded credentials (CWE-798) and session flaws such as fixation (CWE-384). The 23andMe breach is the credential stuffing case; the McHire default password flaw combined A07 with an IDOR from A01.

• Prevent: MFA wherever possible; no default credentials; check new passwords against breached and common password lists; follow NIST SP 800-63B rather than forced rotation; identical responses for all login and recovery outcomes; progressive delays on failures; a new high-entropy session ID after login, invalidated on logout, idle and absolute timeout; validate aud, iss and scopes on JWTs. See the MFA Guide, the Password Security Guide and the Token and Session Security Guide.
• Test: WSTG-ATHN, WSTG-SESS and WSTG-IDNT, plus secrets scanning for hard-coded credentials.

A08 Software or Data Integrity Failures

Code or data trusted without verifying integrity: unsigned updates, plugins from untrusted sources, and insecure deserialisation (CWE-502) that can lead to remote code execution. A03 is the supply chain; A08 is the application trusting what it receives.

• Prevent: verify digital signatures on updates and artefacts; do not accept unsigned or unencrypted serialised data from untrusted clients; restrict deserialisable types; protect signing and machine keys, because a stolen key turns forged payloads into trusted ones, as the ToolShell SharePoint exploitation showed.
• Test: code review for deserialisation sinks, SAST rules for unsafe deserialisers, and review of update and plugin verification.

A09 Security Logging and Alerting Failures

The rename adds "Alerting": logs only help if they lead to action. Failures include logging successful but not failed logins, logs stored only locally, missing alert thresholds, sensitive data in logs (CWE-532) and unencoded log input (CWE-117).

• Prevent: log login, access control and input validation failures with user context; encode log data; use append-only or tamper-resistant audit trails; define alerts and SOC playbooks; place honeytokens. See the Log Management and Retention Guide.
• Test: OWASP notes this can only be assessed through interviews and sampling of real incident responses. Run a test attack and check whether an alert fired.

A10 Mishandling of Exceptional Conditions

Software that fails to prevent, detect or respond to unusual situations: sensitive error messages (CWE-209), unchecked return values (CWE-252), null dereferences (CWE-476) and failing open (CWE-636). The CrewAI error message flaw exposed an admin GitHub token through an error response.

• Prevent: handle errors where they occur, with a global handler as a safety net; roll back multi-step transactions completely (fail closed); apply rate limits and quotas; centralise error handling; return generic messages to users.
• Test: WSTG-ERRH, fuzzing, stress testing and code review of exception paths.

Which testing method finds what

OWASP states that "Tools cannot comprehensively detect, test, or protect against the OWASP Top 10". Plan test coverage per category instead of per tool.

Using the Top 10 properly

OWASP says plainly: "The OWASP Top 10 is primarily an awareness document." Used as a coding or testing standard it is "the bare minimum and just a starting point".

• For requirements, use ASVS: OWASP encourages anyone adopting an application security standard to use the ASVS, "as it's designed to be verifiable and tested". ASVS 5.0.0 (May 2025) has three verification levels and version-qualified requirement IDs, so cite requirements as, for example, v5.0.0-1.2.5.
• For test procedures, use WSTG: map each test to WSTG IDs so results are comparable between testers and years.
• For developers, use the Cheat Sheet Series and Proactive Controls: they describe what to build, while the Top 10 describes what goes wrong.
• Top 10 versus CWE Top 25: the CWE Top 25 ranks individual weaknesses by CVE data across all software (XSS, SQL injection and CSRF lead the 2025 list); the OWASP Top 10 groups weaknesses into web application risk categories. Use the Top 25 to tune SAST rules and the Top 10 to brief people.
• Vendor claims: OWASP "discourages any claims of full coverage of the OWASP Top 10, because it's simply untrue". Ask which CWEs a tool detects and test it on your own code.

Small teams can adopt the Top 10 as a training syllabus and code review checklist, with SCA and one SAST tool in CI. Larger organisations should set ASVS levels per application tier (for example level 2 for internet-facing applications handling personal data) and report findings by CWE, mapping to Top 10 categories only for executive reporting.

Building a Top 10-based testing programme

1. Inventory and tier applications by exposure and data sensitivity; assign an ASVS level to each tier.
2. Train developers on the 2025 categories using examples from your own code.
3. Add SCA and secrets scanning to every build first: they are high signal, cover A03 and part of A07, and break little. Run them in report-only mode for two to four weeks, then block on critical findings.
4. Add SAST tuned to your languages, starting with injection and deserialisation rules; triage the first results to remove noisy rules before failing builds.
5. Run authenticated DAST against staging, never production first, with test accounts for each role so authorisation can be tested.
6. Threat model new features that touch authentication, authorisation, payments or tenant boundaries before coding starts.
7. Commission manual penetration tests scoped to the categories tools miss: A01, A06, A07 recovery flows and A10 transaction handling.
8. Prove detection: after each test, confirm the SOC saw the activity; log a gap against A09 if it did not.

Roll back a blocking gate that causes more than a small number of false build failures by returning it to report-only and fixing the rule set, rather than adding blanket suppressions.

Measuring progress

• Findings density by CWE and category per application, trended per release.
• Mean time to remediate critical and high findings, split by category, so slow-to-fix design and access control issues are visible.
• Coverage: percentage of in-scope applications with SCA, SAST, authenticated DAST and a threat model in the last 12 months.
• Escape rate: vulnerabilities found in production or by bug bounty that pre-release testing should have caught.
• Detection rate: percentage of penetration test actions that produced an alert, the measurable form of A09.
• Dependency age: share of components more than one major version behind or unmaintained (CWE-1104).

Related OWASP Top 10 lists

Use the OWASP list that matches the system under test.

Framework mapping

Common failure patterns

• Treating a clean scan as Top 10 compliance: scanners say little about A01, A06 and A09.
• Still testing against the 2021 list: checklists built from it have no tests for A10:2025 exceptional conditions.
• Dependency scanning without publisher hygiene: SCA finds known CVEs but not a malicious version published with a stolen token, as in the XZ Utils backdoor and the SolarWinds compromise.
• Authorisation tested with one account: object-level access bugs only appear when a second user, tenant or role is used.
• Verbose errors left on in production: stack traces and debug mode leak paths, versions and sometimes tokens (A02 and A10 together).

Practitioner checklist

• Update training, checklists and reporting to the 2025 category names and numbering.
• Adopt ASVS 5.0.0 as the requirements baseline and set a level per application tier.
• Map every test case to WSTG IDs and every finding to a CWE.
• Run SCA and secrets scanning in every build and keep an SBOM per release.
• Test authorisation with at least two users per role and across tenants.
• Threat model features that touch authentication, payments or tenant boundaries.
• Enforce MFA, breached-password checks and server-side session invalidation.
• Prove that penetration test activity raises alerts in the SOC.

Standards and references

• OWASP: Top 10:2025
• OWASP: Top 10:2025 Introduction and Methodology
• OWASP: How to use the OWASP Top 10 as a standard
• OWASP: Application Security Verification Standard (ASVS)
• OWASP: Web Security Testing Guide
• MITRE: 2025 CWE Top 25 Most Dangerous Software Weaknesses
• OWASP: Non-Human Identities Top 10
• OWASP GenAI Security Project: Top 10 for LLM Applications

Related NHI Mgmt Group resources: Vulnerability Management Guide · Open Source Security Guide · Token and Session Security Guide · LLM Security Guide · Top 10 Agentic AI Identity Issues