The API Discovery Problem

The surface you do not know about

Here is a question I ask at the start of every API security engagement: how many API endpoints does your organization expose?

The honest answer, almost always, is some variant of "we don't know." Not because the people I'm talking to are incompetent. They aren't. It's because the problem is structurally hard. Microservice architectures generate endpoints. Internal tools get exposed. Acquisitions bring in entire API ecosystems nobody mapped. Feature flags ship new routes. Deprecation timelines slip. API gateways capture some traffic, but not all of it. OpenAPI specs exist for some services, are stale for others, and are absent for the rest.

The result: organizations routinely have hundreds or thousands of API endpoints, and their security teams have tested a fraction of them. Not because they chose to skip them, but because they didn't know they existed.

This is the API discovery problem, and it is more consequential than any individual vulnerability class.

Why traditional pentesting does not solve this

A standard penetration test is a point-in-time engagement. A team of consultants gets a scope document, spends a few weeks testing, and delivers a report. This model has been the default for decades, and it has real value. But it has structural limitations when applied to API security at scale.

Scope is defined by what the client knows about. If the client gives you a list of 50 endpoints and you test those 50 endpoints thoroughly, you've done good work. But if there are 500 endpoints and the client only documented 50, you've tested 10% of the surface. Your report says "no critical findings," and everyone feels good about a result that covers a tenth of reality.

Point-in-time assessments decay immediately. The week after your pentest report lands, a deploy ships three new endpoints. A configuration change exposes an internal service. An engineer adds a debug route and forgets to remove it. Your report is now a historical document, not a security posture statement.

Manual testing does not scale to the endpoint count. A senior security engineer might deeply test 10-15 API endpoints per day, accounting for authentication flows, authorization matrix testing, input validation, business logic, and data exposure checks. At that rate, covering 1,000 endpoints takes months. Most organizations ship faster than that.

None of this is a criticism of pentesters. I am one. It's a statement about the model. The model was designed for a world where the attack surface was knowable and relatively static. That world no longer exists.

What continuous discovery looks like in practice

The alternative is automation that discovers endpoints, catalogs them, and tests them continuously. I've built systems like this at multiple organizations, and the architecture tends to follow a similar pattern:

Discovery layer. Ingest API definitions from every available source: OpenAPI specs, API gateway logs, traffic captures, service mesh telemetry, code repository scanning, infrastructure-as-code parsing. Cross-reference and deduplicate. The goal is a living inventory of every endpoint, with metadata about authentication requirements, request schemas, and deployment status.

Authentication modeling. For each endpoint, determine what authentication and authorization is expected. Map the matrix: which roles should have access, which shouldn't, what happens with no credentials, expired tokens, tokens from other tenants. This is where most of the security value lives. A surprising number of endpoints either don't enforce auth at all or enforce it inconsistently.

Continuous test execution. Run the tests automatically. Not once, but on every deploy, on a schedule, or on both. When a new endpoint appears in the discovery layer, it gets tested automatically. When an existing endpoint changes, it gets retested. Alert on regressions.

This is the approach I formalized in the Catalina API Security Testing Framework, which became the subject of a US patent application while I was building cloud-scale API discovery at Oracle Cloud Infrastructure. The core insight isn't complicated: you cannot secure what you haven't enumerated, and enumeration must be automated because the surface changes faster than humans can catalog it.

Real-world impact

Numbers make this concrete. At one cryptocurrency exchange, the API security testing before I arrived was manual and periodic. Continuous auth coverage was effectively zero: no automated system was checking whether endpoints enforced authentication and authorization correctly on an ongoing basis.

After building and deploying an automated discovery and testing framework, we reached over 75% authentication and authorization test coverage across the public API surface. That means three-quarters of every endpoint had automated checks verifying that auth was enforced correctly, running continuously, catching regressions the same day they were introduced.

The delta matters more than the absolute number. Going from 0% to 75%+ continuous coverage means you've moved from "we test some things sometimes" to "we have systemic assurance across most of the surface." That's a different security posture, not a marginal improvement.

At a major cloud infrastructure provider, a similar discovery-first approach uncovered thousands of API calls that had never been systematically tested. The project was prioritized as the #1 security investment for the following fiscal year. Not because anyone was negligent before, but because the discovery layer revealed a surface that nobody had been able to see.

What this means if you are buying security services

If you are evaluating security providers, here are the questions that separate useful engagements from expensive checkboxes:

• Does the provider discover endpoints or only test what you hand them? If you're defining the scope, you're limiting the value. The provider should be finding things you didn't know about.
• What happens after the report? A PDF that sits in a SharePoint folder is a compliance artifact, not a security improvement. Ask about continuous testing, regression detection, and integration with your deploy pipeline.
• Can they demonstrate coverage metrics? "We tested your APIs" is not the same as "we tested 847 of your 1,123 endpoints and here's the auth coverage matrix." Demand specificity.
• Do they build the automation, or just run someone else's scanner? Generic API scanners find generic bugs. The high-value findings come from understanding your specific authentication model, your business logic, your authorization boundaries. That requires custom work.

The security industry has a tendency to sell pentests the way insurance companies sell policies: annual renewal, standard scope, standard price, report that looks like last year's report. That model serves the provider's revenue predictability more than the client's security posture.

The compounding advantage

The reason I keep building discovery-first security systems is that they compound. A pentest gives you a snapshot. An automated discovery and testing platform gives you a living inventory that gets more complete over time. Every new data source you connect, every new test you add, every endpoint that gets cataloged makes the next test cycle more valuable than the last.

After six months of continuous operation, these systems know more about your API surface than any human does. After a year, they've caught regressions that no annual pentest would have detected because the vulnerability was introduced and fixed between engagement windows.

This is where security engineering diverges from security consulting. Consulting delivers expertise at a point in time. Engineering delivers systems that accumulate expertise continuously.

You cannot secure what you have not enumerated. And in 2026, if your enumeration is manual, it is incomplete.