OWASP Top 10 2025: what changed, by the numbers

The OWASP Top 10 is the reference list of web application security risks. It underpins audits, requirement documents and a good share of developer training. The 2025 edition, presented on November 6, 2025, is the first update since 2021. It relies on data supplied by testing tool vendors and audit firms, covering more than 2.8 million applications.

How the ranking is built

The data covers 589 CWEs (the standard catalog of software weakness types), 248 of which end up grouped into the ten categories. Eight categories are picked from the data: how often they occur in tested applications, crossed with an exploitability and impact score computed from the matching CVEs. The other two, A03 and A09, are carried by a practitioner survey, to surface risks that automated tools still measure poorly.

1. 1.A01 Broken Access Control: stays first, now absorbs SSRF.
2. 2.A02 Security Misconfiguration: climbs from 5th to 2nd.
3. 3.A03 Software Supply Chain Failures: new, it broadens the old "vulnerable and outdated components" category.
4. 4.A04 Cryptographic Failures: drops from 2nd to 4th.
5. 5.A05 Injection: drops from 3rd to 5th.
6. 6.A06 Insecure Design: drops from 4th to 6th.
7. 7.A07 Authentication Failures: same rank, simpler name.
8. 8.A08 Software or Data Integrity Failures: unchanged.
9. 9.A09 Security Logging and Alerting Failures: same rank, the focus shifts from monitoring to alerting.
10. 10.A10 Mishandling of Exceptional Conditions: new.

A01: access control, still on top

The category groups 40 CWEs and totals 1,839,701 occurrences in the data, with 32,654 associated CVEs. On average, 3.74% of tested applications show at least one of these weaknesses, and up to 20.15% depending on the data source. Folding in SSRF (CWE-918) acknowledges a simple idea: letting the server fetch a user-supplied URL amounts to lending the user the server's network privileges.

The most common form is also the simplest: a route that returns an object by its identifier without checking that it belongs to the logged-in user (IDOR, or BOLA in API terms). Authentication works, but authorization doesn't exist.

// app/api/invoices/[id]/route.ts
export async function GET(_req: Request, { params }: { params: Promise<{ id: string }> }) {
  const { id } = await params;
  const user = await requireUser(); // authenticated...

  // Vulnerable: any logged-in user can read any invoice by changing the id
  // const invoice = await db.invoice.findUnique({ where: { id } });

  // Fixed: the query itself enforces ownership, and a miss looks like a 404
  const invoice = await db.invoice.findFirst({ where: { id, ownerId: user.id } });
  if (!invoice) return new Response(null, { status: 404 });
  return Response.json(invoice);
}

A02: configuration moves to second

Misconfiguration (16 CWEs, 719,084 occurrences) affects 3% of tested applications on average, and up to 27.70% in some sources: the highest maximum rate in the ranking. OWASP attributes this to configuration's growing role in how a modern application behaves. The scenarios cited are concrete: default accounts left active on an admin console, directory listing enabled, detailed error traces returned to visitors, cloud storage open to the Internet by default.

A03 and A10: the two newcomers

A03 replaces "vulnerable and outdated components" with a broader notion: the software supply chain as a whole, meaning dependencies, but also build tools, CI/CD pipelines and package registries. Its rank comes partly from the practitioner survey, and matches the news: npm worms like Shai-Hulud, a hijacked maintainer account on axios.

A10 groups 24 CWEs about handling abnormal situations, with 769,581 occurrences. Two of them directly concern the web: CWE-209, an error message that reveals sensitive information (SQL query, file path, framework version), and CWE-636, failing "open", when an error leaves the system in a more permissive state than before.

// Fails open: if the permission service times out, everyone is allowed
async function canAccess(user: User, doc: Doc) {
  try {
    return await permissions.check(user.id, doc.id);
  } catch {
    return true;
  }
}

// Fails closed: an error denies access and is logged, never shown
async function canAccess(user: User, doc: Doc) {
  try {
    return await permissions.check(user.id, doc.id);
  } catch (err) {
    logger.error({ err, userId: user.id, docId: doc.id }, "permission check failed");
    return false;
  }
}

How to use it

The Top 10 is neither a compliance standard nor an exhaustive list: it's an awareness and prioritization tool. To verify an application point by point, OWASP points to the ASVS (Application Security Verification Standard). The ranking is still useful for deciding where to start: the first three categories cover most of what an attacker finds on an exposed web application.