State of API Security 2026: An AI-Native Testing Perspective

BOLA is the most consequential category in the OWASP list and one of the least tested. In 71% of suites that include BOLA coverage, those tests were AI-generated; manual authors almost never write cross-user access assertions unless explicitly asked. The reason is intuitive: developers write tests from their own perspective, verifying that their user can access their resource. The adversarial question of whether a user can access someone else's resource requires a deliberate shift in mindset that most test authors don't make without a prompt.

67% of authentication failures in the dataset involve an edge case rather than the primary auth flow. The most common pattern: an expired token that keeps returning valid responses because the server checks the token's structure and signature, but not its expiry timestamp. Despite this being the most frequent auth failure type, only 18% of test suites include a test that sends an expired token. This is one of the widest coverage gaps in the dataset: a failure mode observed in the majority of cases, tested in fewer than one in five suites. In practice, it means that credentials revoked after an employee departure, a partner offboarding, or a suspected breach may continue granting API access for the remainder of their token lifetime.

Object property level authorization, which covers both excessive data exposure and mass assignment vulnerabilities, shows a meaningful gap between schema validation and targeted security probing. While 41% of suites validate response bodies against a declared schema, only 14% include a mass assignment probe: a request that attempts to write to a field that should be read-only or inaccessible to the requesting user. Mass assignment failures are both common and easy to miss in manual testing because they require deliberate adversarial thinking about the request body.

Rate limiting is the one category in this dataset where coverage roughly tracks observed failure rate: approximately 23% of organizations show a rate limit bypass as a measurable failure, and approximately 19% of test suites include a rate limit probe. The remaining gap is partially explained by the difficulty of testing rate limiting deterministically in a CI/CD context: a reliable rate limit test requires precise control over request timing and volume, which standard test frameworks do not easily provide. For pricing, inventory, and data-export endpoints, that untested gap is the direct attack surface for competitive intelligence scraping and automated order manipulation.

Function level authorization failures, where a standard user token is accepted by an endpoint that should require elevated permissions, appear in 28% of cases involving administrative or elevated-privilege endpoints. Only 17% of test suites include any privilege escalation check (across all suites in the dataset, not filtered to those with admin endpoints). This category is one where AI-generated tests show the largest improvement over manual suites, because generating a test that deliberately uses an under-privileged token against a privileged endpoint requires no domain knowledge; it requires only the systematic application of a security testing pattern.

Business flow abuse, including coupon stacking, inventory manipulation, order replay, and price tampering, is the hardest OWASP category to test systematically because it requires understanding the business semantics of an API, not just its technical schema. Only 11% of test suites include a business logic abuse scenario, and where present these tests are almost exclusively written by humans with domain knowledge rather than generated by AI systems. This is the category where automated testing has the most ground still to cover.

SSRF is the lowest-coverage category for manual test suites; in the dataset, SSRF test payloads are exclusively found in AI-generated test suites. Manual authors almost never include SSRF probes in standard API test suites, likely because SSRF is more commonly associated with infrastructure security testing than API-layer concerns. Only 8% of all suites include any SSRF coverage. The practical implication is that for the 92% of organizations with no SSRF coverage, the only path to closing that gap without significant manual effort is AI-assisted test generation. This is the starkest example in the dataset of a vulnerability class where human authorship has effectively zero coverage and AI authorship has measurable coverage.

Security misconfiguration, including verbose error messages, missing security headers, and permissive CORS policies, is the one category where coverage tracks observations most closely. 31% of APIs in the dataset return verbose error messages in production environments, and 27% of test suites include validation of error response content. The relative alignment suggests that error message testing is well-established enough in testing culture to be included consistently, even if not universally.

API inventory management, covering the risk of shadow APIs, deprecated endpoints, and undocumented routes, surfaces in 43% of API imports in the dataset, where at least one endpoint discovered during import was not present in the organization's documented API surface. This is not testable from suite analysis alone, since test suites by definition test known endpoints. The 43% figure represents a risk signal rather than a testable coverage metric; it is a strong argument for continuous API discovery as a complement to test suite analysis. An endpoint that does not appear in any test suite is an endpoint that receives no security assertions of any kind: no auth checks, no input validation, no schema enforcement. Shadow APIs are not just an inventory problem; they are a coverage exclusion.

Unsafe consumption of third-party APIs, specifically the failure to validate responses from external dependencies before passing data downstream, is the lowest-tested category overall. Only 24% of test suites that consume external APIs include response schema validation (base: suites with at least one outbound third-party call, approximately 31% of all suites in the dataset). This coverage gap is directly relevant to supply chain risk: an API that passes unvalidated third-party data into its own response surface is vulnerable to any compromise of that third-party. See Section 6 for a detailed analysis of supply chain threats and the testing gap they represent.

Financial services organizations show the highest OWASP coverage in the dataset, averaging coverage across 7 of 10 categories, and the highest auth failure rate at 41%. These two facts are not contradictory: high coverage means more failures are surfaced and measured, not that fewer exist. Regulatory frameworks including PCI-DSS and RBI guidelines have created a compliance pull toward security testing that is absent in other verticals. Organizations in this sector show 2.4x higher auth edge case coverage compared to the dataset average, driven by mandated testing requirements for token management and session lifecycle. The implication for non-regulated industries is direct: the fintech failure rate is high because fintech test suites actually look for failures. Most other industries are not looking.

SaaS and technology companies show the highest share of AI-generated tests in the dataset, and the data reflects the coverage advantage this confers: organizations in this vertical with the highest AI adoption rates show 47% higher OWASP category coverage than those in the same vertical relying primarily on manually authored suites. That gap is not a tooling gap; it is an adoption gap. Input validation is the dominant failure category, driven by the diversity of API consumer types and the challenge of validating inputs across multi-tenant architectures, where a validation failure for one tenant can expose data belonging to another.

Healthcare organizations present the most concerning risk profile in the dataset: a high auth failure rate (33%), a dominant failure pattern in excessive data exposure, and the second-lowest OWASP category coverage at 4 of 10. HIPAA and GDPR create strong compliance incentives around data handling practices, but neither regulation translates directly into API security test requirements. The gap between regulatory intent and engineering test coverage is wider in healthcare than in any other vertical.

PHI exposure via poorly scoped API responses is the highest-consequence failure type in this sector. For healthcare teams looking to close that gap, three test types are highest priority: (1) response body scoping assertions that verify patient-identifiable fields are not returned outside their authorized context; (2) cross-user resource access probes on any endpoint that returns records keyed to a patient or user ID (a direct BOLA test for FHIR-style resource APIs); and (3) explicit scope validation for any OAuth token that accesses clinical data, verifying that read-only tokens cannot write and that patient-level tokens cannot access population-level queries. These map directly to the HIPAA Security Rule's access control requirements and are testable today with standard API testing tooling.

E-commerce APIs are disproportionately exposed to rate limiting and business flow abuse; the combination of high request volumes, publicly accessible endpoints, and economically motivated adversaries creates a distinct threat model. Rate limiting is the top failure category, driven by pricing and inventory endpoints that can be queried to extract competitive intelligence or manipulate order outcomes. Only 4 of 10 OWASP categories are covered on average, with business logic abuse scenarios notably absent despite being among the highest-consequence failure types for this vertical.

Enterprise and consulting organizations show the lowest OWASP coverage in the dataset at 3 of 10 categories on average, and the lowest AI test adoption rate. Testing culture in this segment is predominantly manual: suites are authored by QA teams or consultants working from documented requirements, with security testing treated as a periodic audit concern rather than an engineering discipline embedded in CI. The dominant failure pattern is security misconfiguration: verbose error responses, missing security headers, and permissive CORS policies that accumulate in internally-deployed APIs built on the assumption that network perimeter controls are sufficient. That assumption does not hold once APIs are exposed externally, which is the standard trajectory for enterprise software under digital transformation programs. The consequence is that the organizations with the largest API surface areas and the longest-running systems are also the ones with the least security test coverage per endpoint. They are not the organizations most likely to detect a breach early.

These are not theoretical failure modes. The following patterns appear repeatedly across the dataset and are representative of how auth failures manifest in real production APIs:

New endpoints carry a disproportionate share of auth failures. Endpoints in their first 30 days of production availability have a 3.1x higher auth failure rate than endpoints older than 90 days, and this pattern holds consistently across all verticals and endpoint types. The explanation is straightforward: new endpoints get added in feature branches under time pressure, with authorization logic copied from nearby endpoints that may not correctly inherit the scope requirements for the new functionality, and with the least test coverage. Security testing should be most rigorous for the newest code. The data shows the opposite is true.

This finding is significant beyond the auth failure rate itself. The ability to observe failure rates by endpoint age is a function of platform-level telemetry across thousands of organizations, not something visible from inside a single team's test suite. The practical implication is that security coverage should be weighted toward recently added endpoints in every CI pipeline. The organizational implication is that the riskiest moment in any API's lifecycle is the period immediately after it ships.

The scale of the supply chain threat has grown by orders of magnitude over five years. The escalation is not gradual; it is structural, driven by the expansion of the open source ecosystem, the proliferation of automated CI pipelines that execute third-party code directly, and the increasing value of the credentials and API keys that live inside those pipelines.

The current API security testing toolchain, including the OWASP API Top 10 framework, dynamic analysis tools, and AI-generated test suites, is designed to test the behavior of APIs you own and control. It tests whether your endpoints correctly enforce authentication, reject invalid inputs, and return appropriate status codes. It does not, and structurally cannot, test:

In the KushoAI dataset, only 24% of test suites that consume third-party APIs validate the response schema before passing that data downstream, the most basic check for OWASP API10. The deeper supply chain risk, covering compromised packages, poisoned pipelines, and compromised CI actions, has no corresponding test category in any current automated testing framework. There is no test you can write today that will tell you whether a package you installed last week has been tampered with since.

That gap is not a criticism of the OWASP framework or of the tools built around it. It is a structural consequence of how API security testing was defined before supply chain attacks became a primary threat vector. The framework tests what your API does. It was never designed to test what your API is built from.

The trajectory documented in this section points to a necessary expansion of scope. First-party API security testing needs to be complemented by supply chain signal: continuous dependency integrity monitoring, build artifact verification, and response schema validation for all third-party API consumption treated as a mandatory assertion rather than an optional check. These are not speculative capabilities. The tooling exists in adjacent spaces: SCA tools, SBOM platforms, CI security scanners. But it is not integrated into the API testing workflow where the coverage gap actually lives.

For engineering organizations, the immediate question is not whether supply chain attacks will affect their API infrastructure. The incidents documented here span early-stage SaaS products and large financial institutions, automated package managers and manually pinned dependencies, internal-only APIs and publicly exposed ones. The question is whether the testing coverage in place today would surface a compromise before it reaches production. For most organizations, based on the data in this report, the answer is no.

Auth edge cases. AI-generated suites cover auth edge cases at 78% vs 31% for manual suites. Almost all of that gap is in the edge cases: AI systems generate tests for expired tokens, revoked credentials, tokens used after logout, and malformed authorization headers as a matter of course. Manual authors write the happy path reliably and edge cases only when they remember to.

BOLA probes. The 46 percentage point gap in BOLA coverage is the second largest in the dataset. Testing for BOLA requires asking an adversarial question: can my token access a resource that belongs to a different user? That question does not come naturally to a developer writing tests for their own feature. AI systems ask it automatically.

Boundary inputs across all fields. AI-generated suites send oversized payloads, malformed values, and out-of-range numbers across the entire API surface, not just the fields that look obviously security-sensitive. Manual authors tend to focus boundary testing on passwords, tokens, and IDs, and skip fields that seem low-risk. Production vulnerabilities do not respect that distinction.

The organizations in this dataset with the lowest security failure rates do not have the most thorough security audits. They have security assertions in their CI pipeline: tests that run on every commit and block deployment on failure, the same as any functional test. The shift from "security as a periodic review" to "security as a continuous assertion" is underway, but unevenly. The tooling exists. The gap is adoption.

The highest-impact near-term change is not sophisticated attack simulation. It is adding two specific test types to every CI pipeline: cross-user access probes (BOLA) and token scope validation tests. Both are structurally simple, both can be generated by AI without domain knowledge, and together they address the two most common failure categories in this dataset. Teams that add just these two test types to their standard CI suite will close the majority of their auth and authorization coverage gap.

Security teams find failures that engineering test suites miss. Part of this is mindset: security teams think adversarially, engineers think functionally. Part of it is tooling: security testing runs in a separate workflow, disconnected from the CI pipeline. AI-assisted test generation at the engineering layer narrows this gap by applying adversarial patterns at the point where tests are written. The end state is not two parallel testing disciplines; it is one suite that covers both functional correctness and security assertions, running in the same pipeline, enforced at the same deployment gate.