Introduction

OWASP released the Top 10:2025 at its Global AppSec conference in November 2025, finalizing it in January 2026, its first update since 2021 [1]. The list is built from analysis of more than 175,000 CVE records across roughly 2.8 million applications, combined with a practitioner survey, and the changes it introduces are not cosmetic [2]. Two categories are new. One long-standing category jumped three places. And the underlying data suggests that the way most organizations test their APIs and applications has not kept pace with where the risk actually sits.

For AppSec engineers and platform teams directly responsible for API testing programs, this update is worth treating as a testing-methodology problem, not only an awareness update. This piece breaks down what changed, why it matters specifically for API testing, and what a testing program needs to do differently as a result, using the underlying incident data rather than the ranking changes alone.

The core argument is straightforward: the categories that moved up, and the categories that are new, share a common trait. They are precisely the failure modes that traditional, point-in-time, CVE-lookup-based testing is structurally weak at catching. Understanding why is the first step toward closing that gap rather than simply noting that the rankings changed.

What Changed, and Why It Matters for Testing

Broken Access Control remains at number one, a position it has held for every edition of the list since 2003, a 22-year streak that reflects how structurally persistent authorization failures are relative to other vulnerability classes [2]. What changed is its scope: the 2025 edition explicitly folds Server-Side Request Forgery into this category and calls out Broken Object Level Authorization and Broken Function Level Authorization as specific patterns within it, the two authorization failures most associated with modern, API-heavy applications [1]. This matters for testing because BOLA and BFLA are not findings a traditional vulnerability scanner reliably catches. They require testing that actually attempts to access another user's object or another role's function using a valid, authenticated session, not just checking whether authentication exists at all.

Security Misconfiguration jumped from fifth to second place, the largest single-category move in the new edition [1]. Analysis from Qualys of the underlying data frames this precisely: continuous deployment without continuous scanning creates exposure windows that point-in-time testing cannot close, because a configuration that was compliant during last quarter's audit can drift out of compliance the same week without any code change at all [1]. For API testing specifically, this means configuration validation has to run against live, current deployments, not only against a pre-release checklist.

The most structurally significant change is a new category: Software Supply Chain Failures, debuting at number three with, per Qualys's analysis, the highest incidence rate of any category in the list at 5.19%, alongside notably low CVE coverage, meaning many of these attacks are happening in production before scanners have signatures to detect them [1]. OWASP's own description of the category cites two 2025 incidents directly: the Bybit theft of $1.5 billion, caused by a supply chain compromise in wallet software that activated only when a target wallet was actively in use, and the Shai-Hulud campaign, the first successful self-propagating npm worm, which harvested credentials from infected packages and used stolen npm tokens to automatically push malicious versions of any package the victim could access [3]. Neither incident was caught by conventional dependency scanning at the time it occurred.

Figure 1. APIs' share of published vulnerabilities vs. actively exploited (CISA KEV) vulnerabilities, 2025 (Wallarm).

A Case Study in Why CVE-Based Testing Is No Longer Sufficient

A 2026 incident makes the supply chain category's testing implications concrete. According to analysis from Patrowl, a vulnerability scanner itself was hijacked to distribute credential-stealing malware across thousands of CI/CD workflows; the CVE identifying that compromise, CVE-2026-33634, was only assigned and added to the CISA Known Exploited Vulnerabilities catalog after the exploitation had already occurred [4]. Patrowl's direct conclusion from this incident is that a testing program relying only on already-catalogued vulnerabilities is structurally always behind the threat it is trying to catch [4].

This has a specific implication for API testing programs, since APIs are frequently the delivery mechanism for the exact dependencies and build artifacts this category concerns. Wallarm's 2026 API ThreatStats Report found that 43% of vulnerabilities added to the CISA Known Exploited Vulnerabilities catalog in 2025 were API-related, and that broken authentication accounted for 52% of the 60 publicly disclosed API breaches Wallarm analyzed [5]. A testing program built primarily around checking whether a given API's dependencies appear in a known-vulnerability database will consistently miss the category of attack the 2025 data identifies as the fastest-growing and least detectable. The uncomfortable implication is that a clean software composition analysis report, showing zero known-CVE dependencies, provides less assurance against this category of risk than most teams currently assume it does.

The Other New Category: Mishandling of Exceptional Conditions

Software Supply Chain Failures is the category drawing the most attention, but the second new entry in the 2025 list, Mishandling of Exceptional Conditions at number ten, has direct relevance to API testing that has gotten less coverage. Analysis of the update notes this category was added because error-handling failures kept showing up across real breaches without a defined home on the previous list [7]. For APIs specifically, this covers a familiar but under-tested pattern: endpoints that behave securely on the expected, successful path but leak information, bypass authorization, or enter an unintended state when they receive malformed input, a timeout, a partial failure from a downstream service, or an unexpected error condition.

This category matters for testing programs because it describes exactly the kind of finding that functional API testing, which primarily validates expected behavior on valid requests, is not designed to catch. Effective coverage requires deliberately triggering failure conditions, malformed payloads, truncated requests, downstream timeouts, and rate-limit edge cases, and verifying that the API fails closed, returning an appropriately generic error, rather than failing open into a state that exposes data or bypasses a control that held on the happy path.

How This Connects to the API-Specific Top 10

It is worth being precise about how the general OWASP Top 10:2025 relates to the OWASP API Security Top 10, since the two lists serve different purposes and testing programs sometimes conflate them. The API-specific list, last updated in 2023, remains the more granular reference for API authentication and authorization failure patterns specifically, including the BOLA and broken authentication categories Wallarm's breach analysis identifies as the leading real-world causes of API compromise [5][6]. The general Top 10:2025 update does not replace that guidance; it confirms, from a much broader dataset spanning 175,000-plus CVEs across nearly 2.8 million applications, that the same failure patterns, authorization, configuration drift, and now supply chain integrity, are consistent across application security generally, not an API-specific anomaly [1][2]. A testing program that treats API security as a separate discipline from the rest of application security testing is, based on this convergence, testing against an increasingly artificial distinction.

Three shifts follow directly from the data above, rather than from general best-practice advice.

Authorization testing needs to be behavioral, not structural. Confirming that an endpoint requires authentication is a necessary but insufficient test. Effective BOLA and BFLA testing requires attempting to access resources and functions outside a given authenticated session's legitimate scope, using automated object-enumeration and privilege-escalation test cases rather than relying on manual code review alone.

Configuration testing needs to run continuously against live environments, not only at release. Given that Security Misconfiguration's rise to second place is explicitly linked to continuous deployment outpacing continuous scanning, testing programs built around pre-release gates alone are structurally unable to catch the drift that occurs between releases.

Dependency and build-pipeline testing needs to extend beyond CVE-catalog lookups. Software composition analysis tools that only flag components with an assigned CVE will miss exactly the pattern the Bybit, Shai-Hulud, and CVE-2026-33634 incidents illustrate: exploitation that occurs before, or entirely without, a corresponding CVE ever being cataloged. Behavioral monitoring of build and dependency-installation processes, not only static lookup against known-vulnerability lists, is necessary to close this gap.

A Practical Starting Checklist

The checklist below is ordered to match where the 2025 data shows the largest gaps between current common practice and what the incidents above actually required to catch. Teams with limited testing capacity should treat the first two items as the minimum viable response to this update, not the full program.

  • Add object-level and function-level authorization test cases to API test suites, specifically attempting cross-account and cross-role access with valid authenticated sessions.
  • Move configuration compliance checks from a pre-release gate to a continuously scheduled scan against live production configuration.
  • Inventory build and CI/CD pipeline dependencies separately from application-level dependencies, since the Shai-Hulud and Trivy-related incidents both targeted build tooling rather than application code directly.
  • Treat software composition analysis findings with an assigned CVE as a floor, not a ceiling, and supplement with behavioral or anomaly-based monitoring of dependency installation and build processes.
  • Add deliberate failure-condition testing, malformed input, forced timeouts, and downstream service failures, to confirm APIs fail closed rather than open.
  • Re-map existing API test coverage against the OWASP API Security Top 10 categories directly, since Wallarm's breach analysis shows broken authentication and authorization failures, not exotic vulnerability classes, account for the clear majority of real API breaches [5][6].

Conclusion

The OWASP Top 10:2025 update is not merely a reshuffling exercise conducted for its own sake. The rise of Security Misconfiguration and the debut of Software Supply Chain Failures both point to the same underlying testing gap: point-in-time, CVE-catalog-based testing cannot keep pace with continuously deployed environments and supply chain attacks that exploit before a CVE exists. For API testing programs specifically, closing that gap means testing authorization behaviorally, scanning configuration continuously, and treating the build pipeline as part of the API attack surface rather than a separate concern.

None of the changes in the checklist above require a full testing-program overhaul or new vendor tooling to begin. Behavioral authorization testing can be added incrementally to existing API test suites. Configuration scanning cadence is frequently a scheduling change rather than a tooling change. The larger shift is one of mindset: treating the OWASP Top 10:2025's reordering as a signal about where real 2025 incidents concentrated, and adjusting test coverage to match that evidence, rather than continuing to test against the assumptions the 2021 list encoded four years ago.

Strengthen Your API Testing Coverage with CyberTech Intelligence

CyberTech Intelligence helps AppSec and platform engineering teams align their API testing programs with current OWASP guidance, closing the gap between CVE-catalog-based testing and the behavioral, continuous testing the 2025 data shows is now required.

To assess how your current API testing coverage maps against the OWASP Top 10:2025 categories, connect with CyberTech Intelligence for an API Testing Coverage Review.

Connect With Us

References

[1] Qualys. What Changed in OWASP Top 10 2025? Full Breakdown & Recommendations. Qualys, 2026. https://blog.qualys.com/qualys-insights/2026/06/15/what-changed-in-owasp-top-10-2025-and-recommendations-for-each-category 

[2] Parasoft. OWASP Top 10 2025: What Changed & New Vulnerabilities. Parasoft, 2026. https://www.parasoft.com/blog/owasp-top-10/ 

[3] OWASP. A03:2025 Software Supply Chain Failures. OWASP Top 10:2025, OWASP Foundation, 2026. https://owasp.org/Top10/2025/A03_2025-Software_Supply_Chain_Failures/ 

[4] Patrowl. OWASP Top 10 2025: The Ranking, the Changes and the 2026 Data. Patrowl, 2026. https://patrowl.io/en/blog/owasp-top-10-2025-what-s-changed-and-the-2026-data 

[5] Wallarm. 2026 API ThreatStats Report. Wallarm, 2026. https://www.wallarm.com/reports/2026-wallarm-api-threatstats-report 

[6] OWASP. OWASP API Security Top 10. OWASP Foundation, 2023. https://owasp.org/API-Security/ 

[7] HackerDNA. OWASP Top 10 2025: Every Risk Explained with Examples. HackerDNA, 2026. https://hackerdna.com/blog/owasp-top-10