OWASP Top 10:2025: What Changed and How to Test It

What is in the OWASP Top 10:2025?

OWASP analysed 589 CWEs this cycle, up from about 400 in 2021, and mapped 248 of them into the ten categories. Contributed data covered more than 2.8 million applications from 13 contributors. As in previous editions, eight categories come from the data and two from a community survey that captures risks testing data under-represents.

Why does SSRF now sit under Broken Access Control?

SSRF is fundamentally the server accessing something it should not, on behalf of someone who should not be able to direct it. Grouping it with access control is a useful nudge for testers: an application that fetches URLs is making an authorization decision about destinations, whether it knows it or not.

In practice we test SSRF alongside other access-control checks: webhooks, URL previews, PDF and image renderers, import-from-URL features, and OAuth or metadata discovery. We try cloud metadata endpoints, internal hostnames, alternative IP encodings, DNS rebinding, and redirects from an allowed host to a disallowed one.

What does Software Supply Chain Failures cover?

The 2021 category focused on running known-vulnerable components. The 2025 category widens that to the whole chain that produces your software: dependencies and their maintainers, build systems, CI/CD pipelines, artifact repositories, and how releases are signed and distributed. It reflects a shift that 2025 and 2026 made obvious, where attackers compromise publishers and pipelines rather than waiting for a CVE. See our write-up of the npm worm waves for concrete examples.

For an application assessment, this means asking questions that a dependency scanner cannot answer:

• Can a pull request from outside the organisation run code with access to secrets or publishing credentials?
• Are builds reproducible from a lockfile, and are dependency install scripts allowed to run?
• Is there an SBOM, and does anyone use it when a new advisory lands?
• Who can publish a release, and does that path require phishing-resistant authentication?

What is Mishandling of Exceptional Conditions?

This new category covers what software does when things go wrong: errors, timeouts, partial failures, unexpected input, and resource exhaustion. The recurring security failure is failing open, where an exception path skips a check that the happy path enforces.

// Fails open: an exception in the entitlement service grants access
function canDownload(user, file) {
  try {
    return entitlements.check(user.id, file.id);
  } catch (err) {
    log.warn('entitlement check failed', err);
    return true;            // "don't block customers during an outage"
  }
}

// Fails closed: errors deny, and are visible to operators
function canDownload(user, file) {
  try {
    return entitlements.check(user.id, file.id) === true;
  } catch (err) {
    metrics.increment('entitlement_check_error');
    return false;
  }
}

How we test for it:

• Force dependency failures. Make a payment provider, identity service, or feature flag service time out or return malformed data, and observe whether orders are marked paid, sessions are created, or checks are skipped.
• Interrupt multi-step flows. Abandon a transaction halfway, replay the last step, or send steps out of order, and check whether the state is consistent and safe.
• Send malformed input. Look for stack traces, internal paths, SQL fragments, or secrets in error responses.
• Race the application. Send parallel requests to redeem, withdraw, or invite endpoints to find limits enforced only under normal timing.
• Exhaust resources. Use large payloads, deep nesting, and expensive queries to see whether the application degrades safely.

Why did Security Misconfiguration rise to second place?

Modern applications are assembled from configurable parts: cloud services, identity providers, API gateways, CDNs, object storage, and SaaS integrations. Each has defaults, and many are exposed directly to the internet. We regularly find permissive CORS, public storage buckets, debug endpoints left enabled, verbose error pages, missing security headers, and admin interfaces reachable without network restrictions. Configuration review is now part of every web application test we run, not an optional extra.

How should you use the Top 10 in a security program?

The Top 10 is best used to set priorities and create shared vocabulary between engineering, security, and leadership. It is not a complete test plan. For scoping and depth, use:

• OWASP ASVS to define the verification level an application should meet.
• OWASP WSTG for test procedures.
• Your own threat model for business logic, which no generic list covers well.

A penetration test report that only lists Top 10 categories hit is a checklist, not an assessment. Findings should be tied to a realistic attack path and a business impact.