We Want Better

OWASP Top 10:2025 Is Here: What QA and Test Teams Must Add to Their Checklists

September 01, 2026 3 min read

OWASP's first Top 10 refresh since 2021 adds two new risk categories and reshuffles the rest. Here's what changed and how testers should update their security and exception-handling test coverage.


A Long-Awaited Refresh Lands

After four years, the OWASP Top 10 has been refreshed. The release candidate for the OWASP Top 10:2025 was unveiled on November 6, 2025 at the Global AppSec conference in Washington, D.C., marking the first major revision of the world's most widely referenced web application security standard since 2021. For software testers, this isn't just a security-team concern — it directly reshapes what belongs on functional, exploratory, and automated test checklists.

What's New in the 2025 List

The headline change is the arrival of two brand-new categories: Software Supply Chain Failures and Mishandling of Exceptional Conditions. Server-Side Request Forgery (SSRF), which stood alone in 2021, has been folded back into Broken Access Control, and Security Misconfiguration has jumped from fifth place all the way to number two, reflecting how much risk now sits in cloud and CI/CD configuration rather than in application code alone.

The current release-candidate ranking looks like this:

  • A01:2025 – Broken Access Control
  • A02:2025 – Security Misconfiguration
  • A03:2025 – Software Supply Chain Failures (new)
  • A04:2025 – Cryptographic Failures
  • A05:2025 – Injection
  • A06:2025 – Insecure Design
  • A07:2025 – Authentication Failures
  • A08:2025 – Software or Data Integrity Failures
  • A09:2025 – Logging & Alerting Failures
  • A10:2025 – Mishandling of Exceptional Conditions (new)

Why This Matters to Testers, Not Just Developers

Two of the changes map almost directly onto skills QA teams already own:

  • Software Supply Chain Failures (A03) expands the old "Vulnerable and Outdated Components" category into a much broader concern: compromised open-source dependencies, tampered build pipelines, and malicious updates. Testers who run dependency scans, verify build provenance, or validate CI/CD pipeline integrity as part of release testing now have an explicit, high-priority category to point to when justifying that work in sprint planning.
  • Mishandling of Exceptional Conditions (A10) is essentially a security lens on classic negative testing and edge-case coverage. It covers improper error handling, logical errors, and systems that "fail open" instead of "fail closed" when something unexpected happens. This is territory testers already know well from boundary-value analysis and error-path testing — it just now carries explicit security weight.

Meanwhile, the jump of Security Misconfiguration to the number-two spot is a signal that environment and configuration testing — checking default credentials, verbose error pages, exposed cloud storage, and overly permissive access — deserves more attention in test plans, not less.

What Test Teams Should Do Now

  • Update security test checklists and DAST/SAST rule sets to reflect the new category boundaries once tooling vendors catch up.
  • Add explicit test cases for dependency integrity, build pipeline tampering, and third-party package verification.
  • Expand negative and exception-path test suites to probe fail-open behaviour, unhandled exceptions, and inconsistent error responses.
  • Revisit access-control test cases to ensure SSRF-style scenarios are still covered now that the category has merged.

Because this is currently a release candidate, final wording and CWE mappings may still shift before the finalized version ships. Testers should treat this as an early-warning window: the earlier your team bakes these categories into automated regression and exploratory charters, the less scrambling there will be once the standard is finalized.

Looking for tools to match this read?

Jump into our independent side-by-side comparisons.

Compare Tools