The average enterprise now manages more than 900 active APIs. Salt Security's reporting has put the year-over-year growth in API attacks as high as 681%, and 87% of surveyed organisations said they experienced an API-related security incident in 2025. Web application attacks overall rose 73% between 2023 and 2025.
Growth figures like these get quoted a lot and change very little, because they do not tell you what to do on Monday. The number that does is the gap between the APIs an organisation runs and the APIs it can enumerate. That gap is where the incidents happen.
The three kinds of API you cannot see
Shadow APIs. Endpoints deployed without going through whatever review process exists. A team needed an integration, shipped it, and it works. It is in production, serving traffic, and absent from the API gateway config, the documentation, and the security team's list.
Zombie APIs. Old versions still running. /api/v1 was superseded by /api/v2 two years ago, but v1 was never decommissioned because one partner might still be on it. It receives no maintenance, no dependency updates, and no security review — while still being reachable and still holding a database connection. We have written about zombie APIs as a category before; they remain the most common finding in a first-time API inventory.
Undocumented parameters and methods. The endpoint is known; its full behaviour is not. A PATCH verb nobody documented, a debug parameter left enabled, an admin field the frontend never sends but the backend still accepts.
All three share one property: they are absent from the artefact your security tooling is configured from. If your DAST scanner takes an OpenAPI spec and the spec describes 600 of your 900 endpoints, your coverage is 67% and your report says 100%.
Why the OWASP API Top 10 keeps describing the same failures
The OWASP API Security Top 10 2023 remains the authoritative list as of mid-2026 — there is no published 2026 revision. Its top entries are dominated by authorisation failures: broken object-level authorisation, broken function-level authorisation, broken object property-level authorisation.
These persist because API authorisation is per-object and per-field, and there is no framework default that gets it right. A web application can often protect a whole route with one middleware. An API has to answer "may this caller read this record's this field," and that question has to be answered correctly at every endpoint, every time, by every developer.
Which means authorisation correctness degrades exactly as endpoint count grows — and it grows fastest in the endpoints nobody is tracking.
Building an inventory that is actually accurate
The recurring mistake is treating inventory as a document. Documents describe intent at a point in time; APIs change weekly. What works is deriving inventory from sources that cannot go stale:
Traffic observation. What is actually being called, at the gateway, load balancer, or service mesh. This finds shadow and zombie endpoints because it does not care whether anyone documented them. It is the single highest-yield source.
Code and route analysis. Route definitions extracted from source at build time. This catches endpoints that exist but receive no traffic yet — including the ones an attacker will find before your users do.
Gateway and infrastructure configuration. Authoritative for what is exposed, incomplete for what exists behind it.
Spec files, last. Useful as a statement of intent and for diffing against the other three. The difference between the spec and observed traffic is the finding: endpoints in traffic but not in spec are shadow APIs; endpoints in spec but not in traffic are candidates for decommissioning.
Run those four together and the gap closes. Run only the fourth and you have documentation, not inventory.
What to do with the inventory once you have it
Decommission aggressively. The cheapest way to secure an endpoint is to remove it. Zombie APIs usually serve near-zero traffic; traffic data tells you which ones can go today.
Test authorisation per object, not per route. The Top 10's leading risks require a test that authenticates as user A and requests user B's resources. Generic scanners rarely do this, because it needs to know what a valid identifier for another tenant looks like. It is the highest-value API test to build in-house.
Attach ownership. An endpoint with no owning team gets no patching and no review. Ownership is a security control.
Feed the inventory into your scanning. Coverage should be measured as a percentage of the discovered surface, not the documented one.
The AI acceleration
Worth flagging because it changes the trajectory: Akamai's research identifies APIs as the primary attack surface for AI transformation.
Agentic systems consume APIs, at machine speed and in volume. That has two effects. Endpoint count grows faster, because every agent integration wants a service. And the traffic pattern shifts from human-paced to machine-paced, which breaks anomaly baselines and makes rate limiting a functional requirement rather than an abuse control.
An API estate that was manageable when humans drove it through a UI becomes something else when agents call it directly, and the inventory problem compounds accordingly.
How Safeguard helps
API endpoints as inventoried assets. Safeguard's Supply Chain Core inventories the services and endpoints your applications expose alongside packages, containers, models, and MCP servers, deriving the surface from build-time route analysis rather than from a spec file someone maintains by hand.
Shadow and zombie detection through observed-versus-declared comparison. The finding is in the difference: endpoints serving traffic that appear in no spec, and endpoints in the spec that no longer serve anything. Safeguard surfaces both as actionable lists with ownership attached.
Reachability applied to API surface. A vulnerable dependency inside a decommissioned-but-running v1 endpoint is a genuinely different risk from the same dependency in an unreachable code path. Safeguard's reachability analysis incorporates whether the exposing endpoint is live.
Prioritisation weighted by exposure. An internet-facing endpoint holding customer data outranks an internal service with the same CVSS. Safeguard combines exposure, KEV membership, EPSS, and reachability rather than sorting by base score.
Griffin for the remediation backlog. Endpoint decommissioning, dependency upgrades, and authorisation-check additions across many services are mechanical changes at scale. Griffin authors and tests them as reviewable pull requests in parallel.
Ask for your organisation's API count from two sources — the gateway and the documentation. The difference between those two numbers is your actual security posture.
Sources: CybelAngel — API Security Risks · AppSecMaster — OWASP API Security Top 10 · Astra — Common Web Application Vulnerabilities in 2026 · Akamai research via Barchart
