OWASP Top 10 2025: What Changed and How to Scan for It

The OWASP Top 10 is the most widely referenced standard in application security — the list your auditors cite, your customers ask about, and your security questionnaire is built from. The 2025 edition is the first update since 2021, and it is a more substantial revision than the two before it.

The headline: two new categories, one category removed as a standalone entry, and a reordering that pushes configuration and supply chain risk to the top.

The OWASP Top 10:2025

What actually changed

SSRF was merged into Broken Access Control, not promoted

Server-Side Request Forgery was its own entry at A10 in 2021. In 2025 it is gone as a standalone category — but not because it stopped mattering. OWASP rolled it into A01:

> "Server-Side Request Forgery (SSRF) has been rolled into this category."

The reasoning is that SSRF is an access control failure: the server is persuaded to reach a resource the requester should not be able to reach. Grouping it with the other access control failures puts it next to the controls that actually prevent it.

Practically, nothing changes about how you defend against it. If your compliance mapping references A10:2021-SSRF, it now points at A01:2025.

Software Supply Chain Failures replaced Vulnerable and Outdated Components

This is the most consequential change. A06:2021 was about running dependencies with known CVEs. A03:2025 is much broader:

> "A03:2025 - Software Supply Chain Failures is an expansion of A06:2021-Vulnerable and Outdated Components to include a broader scope of compromises occurring within or across the entire ecosystem of software dependencies, build systems, and distribution infrastructure."

Read that list again: dependencies, build systems, and distribution infrastructure. A clean npm audit no longer covers this category. A compromised CI token, a poisoned GitHub Action, a typosquatted package, an unsigned artifact, a publish credential stolen from a runner — all in scope now, none of them detected by scanning your lockfile for known CVEs.

The category moved from #6 to #3 because this is where real incidents have been coming from. We wrote up one of them in From Trivy to CanisterWorm: a compromised CI token in a security scanner led to a self-propagating npm worm across 141 package versions. Nothing in that chain was a vulnerable dependency in the 2021 sense.

Mishandling of Exceptional Conditions is new at A10

A new category covering 24 CWEs: improper error handling, logic that fails open, unhandled edge cases, and the general problem of systems behaving insecurely when something unexpected happens.

This is a root-cause category, and it is the one most likely to be under-tested in your codebase, because the failure only appears when something else has already gone wrong:

// Fails open — an outage becomes an authorization bypass
async function canAccess(userId: string, docId: string) {
  try {
    return await authService.check(userId, docId);
  } catch {
    return true;   // "don't block users if auth service is down"
  }
}

That catch was written to protect availability. It converts an authorization service outage into an authorization bypass for every user at once. Failing closed is the correct default; if availability genuinely matters more, that has to be a deliberate, documented, narrowly scoped decision — not a bare catch.

Security Misconfiguration moved from #5 to #2

Configuration overtook cryptography, injection, and design. That reflects where applications now live: container images, orchestrators, IAM policies, CORS rules, storage buckets, CSP headers, and framework defaults. Most of these have a secure setting available and an insecure default, and the gap between them is one line of config nobody reviewed.

Injection dropped from #3 to #5

Injection did not become less dangerous. Parameterised queries, ORMs, and framework-level escaping became the default, so the *incidence* fell. Where injection still appears, it is usually in the seams: raw SQL assembled for a reporting feature, a shell command built from user input, a template engine rendering untrusted content.

Two renames worth noting

A07 is now "Authentication Failures", dropping "Identification and". A09 is now "Security Logging and Alerting Failures" — the change emphasises that logging without alerting is not a control. A log nobody reads has never stopped an attack.

Why the list was restructured

The 2025 edition deliberately moves toward root causes rather than symptoms. Supply Chain Failures and Mishandling of Exceptional Conditions are both categories of *how things go wrong*, not *what the payload looks like*. Merging SSRF into Broken Access Control does the same thing from the other direction — grouping a symptom under the cause that permits it.

For your program, that means checklists organised by attack payload map less cleanly onto the 2025 list than checklists organised by control.

How Ship Safe covers OWASP 2025

Ship Safe's 29 agents map to every 2025 category:

Note that SSRFProber still exists and still runs. The category moved; the check did not.

Beyond the web Top 10, Ship Safe also covers:

• OWASP Top 10 for LLM Applications via LLMRedTeam, MCPSecurityAgent, RAGSecurityAgent, MemoryPoisoningAgent
• OWASP Agentic AI Top 10 (ASI01–ASI10) via AgenticSecurityAgent and the Hermes agent set
• OWASP Mobile Top 10 via MobileScanner
• OWASP CI/CD Top 10 via CICDScanner

Scanning against OWASP 2025

npx ship-safe audit .

Every finding carries its OWASP 2025 category, a CWE identifier, and a prioritised fix. The scoring engine weights findings by category severity to produce a 0–100 score.

To fail a build below a threshold:

npx ship-safe audit . --threshold 70

For compliance reporting, findings also map to SOC 2 Type II, ISO 27001:2022, and NIST AI RMF controls.

What to do about it this quarter

1. Re-map your compliance references. Anything pointing at A10:2021-SSRF moves to A01:2025. Anything citing A06:2021 needs rescoping to the wider supply chain definition.

2. Extend supply chain coverage past `npm audit`. Pin GitHub Actions to commit SHAs rather than tags, require signed artifacts, and scope CI tokens to the minimum. Lockfile CVE scanning is now a fraction of A03.

3. Grep your codebase for failing open. Search for catch blocks that return a permissive default — return true, return null, next(). Each one is an A10 candidate.

4. Audit configuration as code. A02 is now #2; treat container, CORS, CSP, IAM, and storage configuration as reviewable code rather than deployment detail.

5. Check that your logs alert. A09's rename is a hint. Confirm at least one alert actually fires to a human.

FAQ

What is the OWASP Top 10 2025?

It is the 2025 edition of OWASP's ranked list of the ten most critical web application security risks, the first revision since 2021. It adds two categories — Software Supply Chain Failures at A03 and Mishandling of Exceptional Conditions at A10 — and merges Server-Side Request Forgery into Broken Access Control.

What changed in the OWASP Top 10 between 2021 and 2025?

Security Misconfiguration rose from #5 to #2. Software Supply Chain Failures entered at #3, expanding the old Vulnerable and Outdated Components category to cover build systems and distribution infrastructure. Mishandling of Exceptional Conditions is new at #10. SSRF was merged into A01. Cryptographic Failures fell from #2 to #4, Injection from #3 to #5, and Insecure Design from #4 to #6. A07 and A09 were renamed.

Was SSRF removed from the OWASP Top 10?

No. SSRF was merged into A01:2025 Broken Access Control rather than dropped, on the reasoning that it is an access control failure. The risk is unchanged; only its classification moved. Update compliance mappings from A10:2021 to A01:2025.

Is the OWASP Top 10 2025 the same as the OWASP Top 10 for LLM Applications?

No, they are separate lists. The Top 10 covers web application risks. The Top 10 for LLM Applications covers risks specific to language-model systems — prompt injection, insecure output handling, training data poisoning, excessive agency. There is also a separate Agentic AI Top 10 for autonomous agent systems. Applications with an LLM in them generally need more than one.

How do I check my application against OWASP 2025?

Run npx ship-safe audit . in your project root. Findings are tagged with their OWASP 2025 category and CWE, ranked by severity, and scored 0–100. No account or API key is required for a local scan.

Related reading

• From Trivy to CanisterWorm: How We Hardened Ship Safe — a real A03:2025 incident, end to end
• How to Secure Your Next.js App: A Complete Guide — A01, A02 and A05 in one framework
• MCP Security Is Becoming the New API Security — where the LLM Top 10 takes over
• Vibe Coding Is Fast, But Is It Safe? — A06 Insecure Design, arriving at speed

Ship fast. Ship safe.