A retail bank we worked with last year had, on paper, mature application security. Penetration tests on customer-facing applications were comprehensive. Static analysis ran in CI. Dynamic application security testing was deployed in staging. Their externally-facing attack surface, as their internal application security team understood it, comprised eleven web applications and a mobile app.
A two-week external attack surface mapping exercise identified 247 internet-facing API endpoints, of which 23 were not in any inventory. Three were partner integrations the bank had decommissioned commercially eighteen months earlier; the endpoints were still live. Two were development APIs deployed during a partner integration project that had been paused but not formally closed. One was a payment routing API that had been moved to a new domain, with the old domain still resolving and still authenticated against the same backend.
This is not a rare scenario. We see it consistently. The bank’s situation was, in fact, modestly better than average — they were able to stand up a dedicated API security workstream within six weeks. Most enterprises take longer.
How the API surface grows when nobody is watching
The mechanics of API sprawl are organisational, not technical. APIs proliferate because they are the right architectural answer for almost every modern integration problem. Mobile apps consume them. Partner integrations expose them. Microservices communicate via them. Marketing platforms, analytics tools, and SaaS providers ingest data through them.
In a traditional enterprise, web applications were owned by a small number of identifiable teams. Each application had a product owner, a security champion, and a place in the application portfolio. APIs do not work that way. They are created in the course of building other things, by teams whose primary mandate is the other thing, with security review (when it happens at all) focused on the originating application rather than the API itself.
When that originating project is decommissioned, retired, or restructured, the APIs that supported it usually persist. Nobody decommissions an API that “still works”, because the cost of breaking an unknown consumer is borne by whoever takes the decision, while the security risk of leaving it active is borne by everyone else.
The result, accumulated over years, is an attack surface that the organisation cannot describe, that grows monotonically, and that does not appear in any architecture diagram.
What attackers are doing with this
The 2025 OWASP API Security Top 10 was an unusually consequential update. Broken authorisation (BOLA) and excessive data exposure remain the dominant categories, but the most rapidly-growing exploit type is business logic abuse — using an API in a way the API permits but the developer did not anticipate.
Examples we have seen in client engagements over the last 18 months:
- An employee benefits API that authenticated correctly and authorised by employee ID, but did not validate that the requesting user’s employee ID matched the requested ID. Attackers iterated through employee IDs to extract personal data on the entire workforce.
- A pricing API on a B2B platform that did not rate-limit by tenant. A competitor scraped the entire pricing matrix in 12 hours.
- A document signing API that returned signed documents to anyone who knew the document GUID. The GUIDs were not random — they followed a predictable pattern that attackers reverse-engineered.
None of these were technically sophisticated. All of them required the attacker to discover the API in the first place, which is now a heavily-automated process. Tools that scan public DNS, certificate transparency logs, and JavaScript bundles for API endpoints run continuously across the open internet. Once an endpoint is known, testing for the OWASP API Top 10 categories is a matter of hours.
Why traditional application security misses this
The traditional application security model assumes a known set of applications, tested at known intervals, by a dedicated security team. APIs break this model in four ways:
Discovery is harder. APIs are often not browseable in the way web applications are. They have no homepage, no sitemap, no obvious entry point. Discovery requires either documentation (often outdated) or active scanning.
Authentication varies. Web applications typically have one authentication path. APIs in the same enterprise may use OAuth, mTLS, API keys, JWTs, custom token systems, and unauthenticated endpoints — sometimes all in the same product.
Testing tools are different. Traditional DAST tools struggle with REST APIs and rarely understand GraphQL, gRPC, or WebSocket APIs at all. Authorisation testing in particular requires specialised tooling that understands the API’s expected access model.
The development cycle is faster. A web application is updated quarterly. An API may change daily. Static security review at release time misses changes between releases.
The combined effect is that the organisations with the most mature traditional AppSec programmes are often the most exposed to API-specific attacks. They have not failed at AppSec; they have correctly identified that AppSec, as historically practiced, does not cover the surface that now matters most.
What “owning” API security actually requires
The remediation that works is structural rather than tooling-driven. The organisations that have controlled API sprawl have done three things in common.
First, they have named ownership. A specific team is accountable for the inventory of internet-facing APIs, regardless of which product team built each one. This is usually a small team — two to four people in a 5,000-employee enterprise — sitting in security or platform engineering. Their authority comes from executive sponsorship; their work product is a current, defensible inventory.
Second, they have deployed lifecycle tooling. 42Crunch, which we deploy for clients in financial services and SaaS, sits at the audit-and-protect end of the API security lifecycle: it audits API definitions for security issues at design time, generates security policies that protect the API in production, and validates the runtime behaviour against the original specification. Wallarm provides complementary capability at the runtime end — discovering APIs the design-time tooling never saw, and protecting them with behavioural detection.
Third, they have integrated API security into the SDLC rather than running it as a separate review function. APIs that go through the pipeline get tested. APIs that bypass the pipeline get flagged by external attack surface monitoring. Both paths feed the same inventory.
What to do this quarter
If you do not currently know the count of internet-facing APIs in your organisation — and most CISOs we ask cannot answer this within an order of magnitude — start with discovery. An external attack surface scan, run by a third party who does not depend on your internal inventory, is the fastest way to surface the gap.
The output will be uncomfortable. It will also be the most valuable output your security team produces this quarter. Without it, every other API security investment is operating on the wrong baseline.
The organisations that have done this work are not necessarily more secure than they were eighteen months ago. They are, however, substantially more able to defend the APIs they actually have — rather than the APIs they think they have.
That distinction is the only one that matters.
Mellivor works with enterprise teams on API security across the full lifecycle, deploying 42Crunch for design-time security and Wallarm for runtime API and application protection. To request an external API attack surface assessment, contact our advisory team.
