OWASP Top 10 (2025): The Full Technical Breakdown for AppSec Teams

The OWASP Top 10 is a ranked list of the ten most critical web application security risks, published by the Open Worldwide Application Security Project and rebuilt roughly every three to four years from real-world incident data, bug bounty submissions, and CWE mapping across hundreds of contributing organizations. The 2025 edition reorders several categories, folds SSRF into access control, expands "vulnerable components" into a full software supply chain category, and adds an entirely new class of failure: mishandling of exceptional conditions.

Most AppSec teams already know the list exists. Fewer know why a category moved, what CWE cluster sits underneath it, or why their last three pentests missed half of what is actually exploitable in this list. This page goes past the summary. It is written for the people who have to defend against these categories, not just cite them in a compliance doc.

What Changed in the 2025 Edition

The 2021 list had ten categories built mostly around vulnerability class (injection, XSS, deserialization). The 2025 list reorganizes around failure mode and consolidates categories that kept showing up as duplicates in incident data. Three changes matter most for how you scope a test.

First, Server-Side Request Forgery folds into Broken Access Control rather than standing alone, because in practice SSRF is almost always an access control failure at the trust-boundary level: the app trusts a URL or hostname it should have validated as an authorization decision, not just an input format issue. Second, "Vulnerable and Outdated Components" becomes "Software Supply Chain Failures," widening scope from patch lag to build pipeline integrity, dependency confusion, and CI/CD compromise. Third, "Mishandling of Exceptional Conditions" is new. It captures the failure class where error paths, retries, timeouts, and fallback logic leak information or bypass controls that the happy path enforces correctly.

None of this is cosmetic. Two of the three changes (SSRF folding, exceptional conditions) point directly at logic and workflow, categories that pattern-matching scanners cannot see because there is no signature for "this retry loop skips the auth check on the third attempt."

A01: Broken Access Control

Access control failures remain the top category because they are structurally hard to test at scale. The core CWEs are CWE-284 (improper access control), CWE-639 (IDOR, insecure direct object reference), CWE-862 (missing authorization), and now CWE-918 (SSRF) folded in under this heading.

The classic exploit chain: a user changes /api/invoice/1042 to /api/invoice/1043 and pulls another tenant's invoice because the backend checks that a valid session exists but never checks that the session owner matches the resource owner. Multiply this across a modern API with 200+ endpoints and hundreds of parameter combinations, and manual testers physically cannot check every object reference for every role in a one or two-week engagement window.

SSRF folded into this category plays out as: an app fetches a user-supplied URL for a "preview" or "webhook validation" feature, and that fetch call is issued from inside the cloud VPC, reaching the metadata endpoint at 169.254.169.254 and pulling IAM role credentials. It is an access control failure because the app never validated that "fetch this URL" was a decision the requester was authorized to make against internal infrastructure.

Why it is hard to catch: broken access control is a business-logic property, not a syntax pattern. A DAST scanner can flag a reflected parameter; it cannot know that user A should never see user B's record. Static rule-based scanners flag "public S3 bucket" but miss "authenticated user of role X can access role Y's records via a nested API call three hops deep."

This is exactly the class of finding FireCompass agents are built to test systematically rather than sample. Agents enumerate object references across every authenticated role in a multi-account test plan and attempt IDOR and BOLA (Broken Object Level Authorization) access on each one, cross-role and cross-tenant, not just against a handful of endpoints picked by a time-boxed manual tester. Every confirmed IDOR or BOLA finding ships with a proof-of-concept request and response showing the exact unauthorized record retrieved, so the finding is verifiable evidence, not a theoretical pattern match. This is the same access control depth referenced directly in the vendor questions and RFP criteria later on this page.

A02: Security Misconfiguration

This covers CWE-16 (broad misconfiguration), CWE-209 (verbose error disclosure), CWE-1188 (insecure default configuration), and cloud-specific issues like open storage buckets, permissive CORS, and exposed admin interfaces (Kubernetes dashboards, Jenkins, cloud consoles left on default credentials).

The mechanics are almost always the same story: a default configuration ships permissive because it is easier to demo, and nobody hardens it before production. Debug mode left on in a framework leaks stack traces with file paths and sometimes database credentials. CORS configured with a wildcard origin plus Allow-Credentials: true lets any origin read authenticated responses, which is a direct token-theft path.

Detection difficulty is low for the obvious cases (an exposed .git directory, a debug endpoint) and scanners catch these reliably. It gets hard when misconfiguration is conditional: a permissive CORS policy that only triggers for a specific subdomain pattern, or an S3 bucket policy that is fine on its own but combined with a Lambda role becomes a privilege escalation path. That combination requires chaining, not single-finding detection.

A03: Software Supply Chain Failures

Expanded from "Vulnerable and Outdated Components" (CWE-1104, use of unmaintained third-party components) to include CI/CD pipeline compromise, dependency confusion (CWE-427, uncontrolled search path), typosquatted packages, and build artifact tampering, echoing incidents like SolarWinds and the more recent wave of npm and PyPI supply chain attacks.

The exploit path that scanners miss entirely: an attacker registers an internal-sounding package name on the public npm registry before a company registers it internally, and the build pulls the public (malicious) version because the package manager resolves public before private by default in a misconfigured registry priority. No CVE exists for this. It is a naming and trust-resolution problem, not a code vulnerability.

This is why software composition analysis (SCA) alone is not enough: SCA tells you a component has a known CVE, but not whether your build pipeline can be poisoned, whether your CI runner has excessive permissions, or whether a compromised maintainer account just pushed a backdoored point release that has no CVE yet because it was published six hours ago.

A04: Cryptographic Failures

Formerly "Sensitive Data Exposure," renamed because the root cause is almost always the crypto implementation, not the exposure itself. Core CWEs: CWE-327 (broken or risky algorithm), CWE-321 (hardcoded key), CWE-295 (improper certificate validation), CWE-798 (hardcoded credentials).

Common exploit chains: JWTs signed with alg: none accepted by a misconfigured verification library, letting an attacker forge a token with arbitrary claims. TLS certificate validation disabled "temporarily" for a test environment and never re-enabled, exposing the app to trivial man-in-the-middle interception. Encryption keys committed to a public repo, then rotated but the old ciphertext still decryptable because the rotation never re-encrypted data at rest.

Detection difficulty is split. Weak TLS configuration and expired certificates are trivially scannable. Logic-level crypto misuse (a JWT library that silently accepts unsigned tokens, or key reuse across environments) requires reading the actual verification code path, which most scanners do not execute at runtime.

A05: Injection

The oldest category, still present because injection is not one bug class, it is a family: CWE-89 (SQL injection), CWE-79 (cross-site scripting), CWE-78 (OS command injection), CWE-611 (XXE), and increasingly CWE-1321 (prototype pollution in JavaScript, which cascades into property injection and sometimes remote code execution in Node backends).

The reason injection persists after 20+ years of awareness is parameterized queries and ORMs solved the simple case, but complex applications still build dynamic queries for reporting engines, admin search tools, and GraphQL resolvers where string concatenation creeps back in under deadline pressure. Second-order injection is the harder variant: input is sanitized on write but the sanitized value is later read and used unsafely in a different context (a stored XSS payload that only fires when an admin views a support ticket, for example).

Modern injection increasingly shows up in AI-adjacent surfaces: prompt injection into an LLM-backed feature that then executes a tool call or database query based on unsanitized user text is functionally the same class of failure as classic SQL injection, just one abstraction layer up. Scanners built for SQLi signatures do not look here at all.

A06: Insecure Design

This is a threat-modeling category, not a code-pattern category, which makes it the hardest to test with any automated tool. Relevant CWEs include CWE-657 (violation of secure design principle) and CWE-841 (improper enforcement of workflow sequence).

Example: a password reset flow that is technically implemented correctly (tokens expire, tokens are single-use, tokens are cryptographically random) but the design allows unlimited reset requests without rate limiting, so an attacker can flood a target's inbox or, worse, race a token before the legitimate user clicks it. Nothing here is a "bug." The design itself has no abuse-case handling.

Insecure design is why threat modeling during architecture review matters more than late-stage scanning. By the time a workflow-sequence flaw ships to production, fixing it usually means redesigning a user flow, not patching a line of code. This category is almost undetectable by any tool that does not understand the intended business workflow, which is exactly why it requires an entity (human or agent) that can reason about intent, not just pattern-match syntax.

A07: Authentication Failures

Covers CWE-287 (improper authentication), CWE-307 (no lockout on repeated attempts), CWE-620 (unverified password change), and session-management flaws like predictable session tokens or session fixation.

Credential stuffing is the volume attack here: an attacker replays breached username/password pairs from unrelated breaches against a login endpoint with no rate limiting or bot detection, and success rates of 0.1 to 2 percent against large user bases still yield thousands of compromised accounts. Roughly 22 percent of breaches trace back to credential abuse in some form, which makes this category one of the highest-frequency real-world entry points on the entire list, not just a theoretical risk.

Multi-factor authentication bypass is the more advanced variant: MFA fatigue attacks (spamming push notifications until a user approves out of annoyance), or backend logic that only checks the first factor and treats the second factor as advisory in an API path that a mobile app forgot to gate the same way the web app does.

A08: Software or Data Integrity Failures

Covers CWE-502 (deserialization of untrusted data), CWE-345 (insufficient verification of data authenticity), and auto-update mechanisms that do not verify signatures before executing pulled code.

Insecure deserialization is the marquee exploit here: an application deserializes attacker-controlled data into objects without validating the object type, and if the deserialization library supports polymorphic types, an attacker can instantiate a gadget chain (a sequence of otherwise-benign object constructors and destructors) that ends in arbitrary code execution. This is how several major Java and .NET RCEs have worked for the last decade.

Data integrity failures also cover CI/CD pipelines that pull build dependencies or container base images without verifying a signature or checksum, meaning a compromised upstream mirror can inject malicious code that ships to production with a green build.

A09: Security Logging and Alerting Failures

Covers CWE-778 (insufficient logging), CWE-117 (log injection), and the operational gap where logs exist but nobody is alerting on the events that matter. This category does not produce a breach on its own. It determines how long every other category's breach goes undetected.

The mechanic that gets missed: applications log failed logins but not successful logins after a string of failures, meaning a slow-and-low credential stuffing campaign that eventually succeeds looks identical in the logs to normal user behavior. Log injection (CWE-117) is the offensive angle: an attacker embeds newline characters or fake log entries into a field that gets logged unsanitized, poisoning the audit trail or breaking log-parsing automation downstream.

This category is unusual in the list because you cannot "pentest" your way to fixing it. A finding here is "your team did not get alerted," which is a detection engineering and SIEM tuning problem, not a code-level fix, and it is why logging failures are consistently underweighted in engagements that stop at the finding and do not check whether the finding would have triggered an actual alert.

A10: Mishandling of Exceptional Conditions

New for 2025. Covers CWE-703 (improper check for unusual conditions) and the broader class of failures in error handling, retry logic, timeout behavior, and fallback paths. This category exists because incident data showed that a huge share of real breaches happen not on the primary code path, but in the code that runs when something goes wrong.

Concrete pattern: a payment API enforces strong validation on the primary transaction path, but the retry handler for a timed-out request skips revalidation and replays the last-known-good state, letting an attacker manipulate the retry to double-spend or change transaction parameters that the happy path would have blocked. Another pattern: a rate limiter fails open (allows all requests) when the backing Redis instance is unreachable, meaning an attacker who can trigger that dependency failure also disables the rate limit.

This is the single hardest category on the 2025 list to test with a conventional scanner or a time-boxed manual engagement, because it requires deliberately inducing failure conditions (timeouts, dependency outages, malformed responses) and then testing the app's behavior under that induced failure, which is rarely in scope for a standard week-long pentest.

Detection Difficulty, Ranked

Category	Scanner (DAST/SAST) detects reliably	Requires logic-aware testing	Requires induced-failure testing
A01 Broken Access Control	Rarely	Yes, cross-role/cross-tenant	No
A02 Security Misconfiguration	Often, for obvious cases	Yes, for chained misconfig	No
A03 Supply Chain Failures	Partially, known CVEs only	Yes, for pipeline trust	No
A04 Cryptographic Failures	Often, for config-level	Yes, for logic-level misuse	No
A05 Injection	Often, for classic patterns	Yes, for second-order/prompt injection	No
A06 Insecure Design	Rarely	Yes, always	Sometimes
A07 Authentication Failures	Partially	Yes, for MFA/session logic	No
A08 Integrity Failures	Partially, known gadget chains	Yes, for custom deserialization	No
A09 Logging Failures	No	Yes, requires detection validation	No
A10 Exceptional Conditions	No	Yes, always	Yes, always

"Logic-aware testing" means the tester or agent must reason about intended business behavior, not just match a known vulnerability signature.

Why This List Keeps Getting Missed in Practice

Annual pentest programs, which is still the default cadence for most enterprises, typically cover about 20 percent of the attack surface in a given testing window, because scope gets negotiated down to fit a fixed budget and a one to two-week engagement calendar. Attackers do not wait for the next scheduled test. CVEs are exploited in the wild in about 3 days on average, and roughly 20 percent of breaches trace back to a peripheral asset nobody remembered was in scope.

This is where FireCompass fits, not as a replacement for understanding the categories above, but as a way to test all ten continuously instead of once a year against a fraction of the surface. FireCompass runs autonomous AI agents that execute proof-of-exploit validation across the full OWASP Top 10:2025, including the logic-heavy categories (A01, A06, A10) that signature-based scanners cannot reach, at under 2 percent false positive rate versus 40 to 70 percent for traditional scanners. In an internal evaluation, these agents beat top human researchers 60 to 70 percent of the time. On public benchmarks the results are 104/104 on XBEN, 12/12 PoC-validated on Acuart, and all levels cleared on DVWA, fully autonomously with no manual steering.

Questions to Ask Vendors

Use these when evaluating any pentest firm, scanner vendor, or MSSP, not just FireCompass. The answers reveal whether a vendor actually tests the hard categories or just runs a scanner and calls it a pentest.

1. How do you test for IDOR and cross-tenant access control across every role and object type, not just a sample? A good answer names a systematic method (role matrix, automated cross-role replay). A bad answer says "our testers check this manually," which means sampling, not coverage.
2. Can you show a proof-of-exploit chain for a finding, not just a scanner alert? Good vendors produce reproducible steps and, ideally, working exploit code. A bad answer is a CVSS score with no reproduction steps.
3. How do you test insecure design and business-logic flaws that have no CVE and no signature? Good answers describe threat-modeling or abuse-case testing methodology. A bad answer conflates this with generic OWASP checklist scanning.
4. Do you test how the application behaves under induced failure (timeouts, dependency outages, malformed retries)? This maps directly to the new A10 category. Most vendors have never been asked this and will not have a good answer, which itself is informative.
5. What is your measured false positive rate, and how was it measured? A credible vendor cites a number and a methodology. A vendor that cannot name a number is asking you to trust triage effort you cannot verify.
6. How do you validate software supply chain risk beyond known-CVE component scanning? Good answers mention build pipeline integrity, dependency confusion, and unsigned artifact checks. A bad answer is "we run an SCA tool."
7. What percentage of our actual attack surface will be in scope, and how was that scope determined? Good vendors ask for a full asset inventory or run discovery first. A bad answer accepts a fixed IP/URL list from the client with no independent verification.
8. How quickly can you re-test after a code change or a new CVE disclosure? Good answers describe a same-day or on-demand re-test capability. A bad answer requires a new engagement cycle measured in weeks.
9. Will your findings include working exploit code we can hand to engineering to reproduce and verify the fix? Good vendors provide this by default. A bad answer treats exploit code as a paid add-on or refuses on liability grounds without offering an alternative.
10. How do you handle authenticated testing across multiple roles and permission tiers in a single engagement? Good answers describe explicit multi-role test plans. A bad answer tests only an admin account, which misses most access control bugs.
11. What happens to findings after the engagement ends: do you retest for free, or is every retest billed as new scope? This reveals whether the vendor's incentive is fixing risk or selling more hours.
12. Can you demonstrate detection of a second-order or stored injection flaw, not just reflected input? Good vendors can show a worked example. A bad answer treats all injection as equivalent to a single-request reflected case.

RFP Criteria

Criteria to write directly into a formal RFP for web application and API pentesting, usable regardless of which vendors respond.

Criterion	What to require
Full OWASP Top 10:2025 coverage	Vendor must confirm explicit test methodology for all ten categories, including insecure design (A06) and exceptional conditions (A10), not a generic "OWASP-aligned" claim.
Proof of exploit per finding	Every finding must ship with reproducible steps, and where applicable, working exploit code, not a CVSS score alone.
Measured false positive rate	Vendor must disclose a false positive rate with methodology behind the number, not an unverifiable marketing claim.
Multi-role, authenticated test scope	Test plan must explicitly cover every user role and permission tier, with cross-role and cross-tenant access checks documented.
Business logic and abuse-case testing	Vendor must describe a threat-modeling or abuse-case methodology distinct from automated scanning, with named examples from prior engagements.
Software supply chain scope	Test must extend beyond known-CVE component scanning to build pipeline integrity, dependency confusion, and unsigned artifact risk.
Re-test cadence and cost	Contract must specify re-test turnaround time and whether re-tests after remediation are included or separately billed.
Attack surface discovery method	Vendor must describe how test scope is determined: independent discovery versus accepting a client-provided asset list at face value.
Continuous or on-demand testing option	RFP should require a stated option for continuous, CI/CD-triggered, or on-demand testing beyond a single annual engagement.
Data handling and audit trail	Vendor must document what data is accessed during testing, how it is stored, and provide an auditable trail of every action taken against the environment.

Vendor Evaluation Criteria

A scoring rubric to differentiate competing vendors on this specific capability during a bake-off or proof of concept.

Criterion	What Good Looks Like	Red Flag
Access control testing depth	Systematic cross-role and cross-tenant testing across every object type, with documented method	Testing limited to a single admin account or a small manual sample
Business logic coverage	Named abuse-case methodology with real examples of logic flaws found in past engagements	All findings map to generic OWASP checklist items with no logic-specific examples
False positive rate	Vendor states a measured number (ideally under 5 percent) with methodology	Vendor cannot state a number or says "we manually verify everything" with no data behind it
Exploit validation	Every finding includes reproduction steps and, where relevant, working exploit code	Findings are scanner output with a CVSS score and no reproduction path
Supply chain depth	Testing covers build pipeline integrity and dependency trust, not just known CVEs in components	"Supply chain testing" means running an off-the-shelf SCA tool and forwarding the report
Exceptional condition testing	Vendor can describe how they test retry, timeout, and fallback logic under induced failure	Vendor has never considered this a testable category
Re-test speed	Same-day or on-demand re-test after a fix, at low or no additional cost	Re-test requires a new full engagement cycle measured in weeks
Scope determination	Independent discovery of the real attack surface before testing begins	Vendor tests only the fixed URL/IP list the client hands over, with no verification
Reporting clarity	Findings are prioritized by exploitability and business impact, written for both engineers and executives	Report is a raw list of CVEs and generic severity scores with no business context
Cadence flexibility	Supports continuous, CI/CD-triggered, or on-demand testing in addition to point-in-time engagements	Only offers a fixed annual engagement with no option to retest between cycles

Frequently Asked Questions

How often is the OWASP Top 10 updated?

Roughly every three to four years. The prior major revision was 2021; the 2025 edition reflects updated incident data, CWE mapping, and community contribution data collected since then.

Is the OWASP Top 10 a complete list of web application risks?

No. It represents the ten highest-impact categories by aggregated data, not an exhaustive vulnerability catalog. A compliant application can still carry serious risk outside these ten categories, and a test that only checks these ten is a floor, not a ceiling.

Why was SSRF folded into Broken Access Control in the 2025 list?

Because in practice, SSRF is almost always the result of a missing authorization check at a trust boundary (the app treats a URL fetch as a data operation rather than an authorization decision), rather than a distinct injection or input-validation issue.

What is new in the 2025 edition compared to 2021?

SSRF merges into Broken Access Control, "Vulnerable and Outdated Components" expands into the broader "Software Supply Chain Failures," and a new category, "Mishandling of Exceptional Conditions," captures failures in error handling, retries, and fallback logic.

Can automated scanners cover the full OWASP Top 10 on their own?

No. Scanners reliably catch signature-based issues (misconfiguration, known-CVE components, classic injection patterns) but structurally cannot detect logic-driven categories like Insecure Design, Broken Access Control across roles, or Mishandling of Exceptional Conditions, all of which require reasoning about intended application behavior.

How does annual pentesting cadence compare to the pace of real-world exploitation?

Annual programs typically test around 20 percent of the attack surface in a given cycle, while CVEs are exploited in the wild in about 3 days on average. The mismatch between a 365-day testing cadence and a 3-day exploitation window is the core argument for continuous testing.

What is the difference between a vulnerability scanner finding and proof of exploit?

A scanner finding flags a pattern that might be exploitable. Proof of exploit means the finding was actually triggered against the live application, with reproducible steps or working exploit code confirming real impact, which is why proof-of-exploit programs report false positive rates under 2 percent versus 40 to 70 percent for pattern-based scanners.

Related Terms