T-Mobile, Peloton, and Optus all had active security programs. All three were breached through API vulnerabilities that existing tests never caught, because the exploited endpoints were not in anyone's inventory.
Security teams that rely on pre-deploy testing pass audits and still get breached. API attack surface drifts after deploy. No static scanner can test what it doesn't know exists.
Your OpenAPI Spec Is Not Your Attack Surface
Production APIs diverge from documentation within weeks. Shadow endpoints accumulate through feature flags, deprecated versions that were never deactivated, and side-channel leaks in microservices. None of these endpoints are visible to scanners that operate on code.
Security teams running comprehensive discovery for the first time consistently find more endpoints than documented — the gap between the specification and what runs in production is substantial. Shadow APIs account for a significant share of API traffic at mid-to-large enterprises, with security teams unaware they exist.
The 2022 Cequence report recorded 5 billion malicious requests out of 16.7 billion total, all targeting unknown and unmanaged APIs. OWASP API9:2023 names this Improper Inventory Management: beta endpoints frequently lack the rate limiting and authentication equivalent to production, and the absence of documentation lets them be exploited without the security team knowing they exist.
The 2022 Optus breach made the cost concrete. An undocumented, unauthenticated endpoint exposed data on 9.7 million customers. The endpoint appeared in no OpenAPI spec. SAST and DAST inherit the developer's endpoint list and never test what they don't know exists.
BOLA Has Led the List for Five Years Because Auth Only Breaks at Runtime
Object-level authorization failures are not detectable through static analysis. They require real user IDs, real objects in the database, and runtime context. Every static scanner misses this category by design.
The 2021 Peloton breach exposed more than 4 million user records, including accounts configured as private. Authenticated users could access any other user's data by swapping the ID in the request path. Peloton had authentication working. It had no per-object authorization check on each endpoint.
T-Mobile in 2023 saw 37 million customers affected by an API without adequate authorization checks. The class action settlement reached 350 million dollars. OWASP has ranked BOLA as API1:2023 for five consecutive years, and the category appears in roughly 40 percent of all documented API attacks.
The technical reason is straightforward: BOLA requires active runtime context. A valid user session, real objects in the database, and a sequence of requests that crosses ownership boundaries between users. No code scanner can simulate that context. The vulnerability is not in the source code -- it lives in business logic executing with production data. That structural gap is why BOLA has led the list since 2019.
JWT Misconfigs Survive Code Review Because They Are Config Bugs, Not Code Bugs
The most critical JWT vulnerabilities exist in the deployed configuration, independent of source code. Updating the library version does not fix a misconfigured token validation endpoint in the API gateway.
CVE-2024-31033 affects JJWT: incorrectly configured signing keys allow token forgery with weaker authentication than expected. CVE-2026-29000 affects pac4j-jwt in versions before 4.5.9, 5.7.9, and 6.3.3. An attacker with access only to the RSA public key can forge JWTs with arbitrary claims and authenticate as any user, including administrators.
The alg:none attack works as follows: the attacker removes the token signature and sets the algorithm field to none. The server accepts the token if it does not explicitly reject that value in configuration. The RS256-to-HS256 confusion attack uses the RSA public key as an HMAC secret. An attacker who knows the public key signs tokens that the server accepts as valid.
SAST sees the JWT library import in the code. It does not see the token validation configuration deployed in the API gateway or server environment variables. The code can be correct while the configuration is wrong. That distinction is what makes this vulnerability class survive complete code reviews. Tools that test active endpoints, like the jwt_scanner at intel.mago.team, detect these misconfigurations at runtime.
The OWASP API Top 10 Is a Taxonomy, Not a Detection Workflow
Most practitioners use the OWASP Top 10 as a code review checklist. The actual detection workflow requires active endpoint discovery, runtime probing, and drift comparison against inventory. No static tool executes these steps.
The major API security vendor blogs follow the same pattern: they explain the categories with generic examples and provide no end-to-end detection methodology. SAST identifies code patterns but does not detect authorization gaps, configuration drift, or undocumented endpoints. DAST tests running applications but needs a known endpoint list, so shadow APIs are never tested.
Authorization failures, business logic abuse, and multi-step flow exploitation depend on runtime context and sequencing that static analysis cannot see. The fundamental gap is this: knowing which vulnerability categories exist is not the same as knowing whether your deployed API is vulnerable to them. The taxonomy describes what can happen. The detection workflow determines what is happening now, with your active endpoints.
The Detection Workflow Starts with Discovery, Not Scanning
Effective API security testing follows a fixed sequence: passive discovery to find what exists, fingerprinting to understand the stack, targeted probing for each category. Skipping the first step means scanning a fraction of the real surface.
Step 1: discovery via subdomain enumeration, JavaScript bundle extraction, path traversal on API gateways, and fingerprinting with Shodan and Censys. Step 2: inventory baseline, mapping discovered endpoints against the documented spec and flagging shadow endpoints and deprecated versions still active. Step 3: authentication probing on each endpoint, testing auth bypass, alg:none acceptance in JWT, and missing required authentication headers.
Step 4: BOLA and BFLA testing. For each endpoint that handles objects, probe with valid authentication but a different user context and verify whether the response is 403 or 200 with another user's data. Step 5: continuous comparison, re-running discovery weekly and generating a diff against the last known inventory to detect drift. Each step depends on the previous one. Without full discovery, scanning tests only the endpoints you already documented.
Runtime and Development Posture Diverge at Deploy Time
Protecting production APIs requires continuous external testing against active endpoints, from the same perspective an attacker has. Internal testing from the development side does not detect the configuration, routing, and endpoint drift that emerges in production.
The scenario documented in OWASP API9:2023 is direct: a beta API without rate limiting was used to brute-force password reset tokens. The production API had rate limiting. The beta version did not. The security team tested the production version and passed the audit.
The scale of the problem is growing faster than review cycles can track. Organizations with more than 100 API endpoints went from 4 percent in 2024 to 38 percent in 2025. 84 percent of security professionals reported API-related incidents in the past 12 months, most involving endpoints unknown to the internal team.
External API testing, conducted from outside the network perimeter, detects routing misconfigurations, exposed internal endpoints, and authentication gaps that internal tools cannot reach. Each new API version creates shadow endpoints until the documentation is updated. The intel.mago.team approach combines continuous external discovery with jwt_scanner and technology fingerprinting on active endpoints, not on code.
The scanner testing your pipeline doesn't know what the deploy delivered.
Top comments (0)