Watching the Gateway Is Not Watching Every API

“Every API goes through the gateway. It is logged. We run DAST on every release. We would catch an authorization flaw.”

Would you?

Name the last one you caught.

Not the last one somebody emailed you about.

Watching the gateway is not watching every API.

Your gateway log records the traffic that crossed your gateway.

Your discovery tool inventories the endpoints it could see from where it sits.

Your scanner tests the endpoints in the specification you gave it, as the user you gave it.

Three useful controls.

Three different fields of view.

And the failure you are worried about, a caller reaching a record or an operation it should not, arrives as a well-formed request with a valid credential.

Salt Security’s State of API Security research reports that 99% of the attack attempts its team analysed came from sources that were authenticated at the network layer.

Not anonymous scanning noise.

Logged-in callers.

Now look at who found the documented API exposures.

Panera Bread’s sequential account IDs: an outside researcher, Dylan Houlihan, in August 2017.

USPS’s Informed Visibility API, which let any logged-in usps.com user look up roughly 60 million other accounts: disclosed by Krebs on Security in November 2018.

First American Financial’s document system, about 885 million files behind sequential document numbers: disabled after outside notification, in 2019, having been open since at least March 2017.

Nobody’s dashboard went red first.

You would not accept “we have a smoke detector in the lobby, so the building is monitored for fire.”

Put the smoke detector in front of api.example.com and suddenly it covers the basement.

1. “But Everything Goes Through the Gateway.”

Everything you routed through the gateway goes through the gateway.

That sentence is true by definition and tells you nothing about the rest.

Traffic-based discovery at a gateway, CDN or reverse proxy is the dominant practical way to build an API inventory. It watches what actually flows through the choke point and catches endpoints nobody bothered to register.

That is its strength and its boundary.

An endpoint that never crosses the vantage point is invisible to it. However clever the analysis.

Three things routinely never cross it.

Internal, service-to-service calls that stay inside a private network segment.

APIs behind mutual TLS that terminates before the monitored proxy.

Hosts stood up outside the primary routing entirely. A beta host. A staging deployment. A test network.

Australia’s 2022 Optus breach is that third case at full size.

Roughly 10 million current and former customers’ names, birth dates, addresses, passport and driver’s licence numbers, exposed through an API that, according to Australian government and insider accounts, had been “accidentally left exposed to a test network that had access to the Internet.”

No meaningful check ran on it at all.

Your gateway’s logs of that period would be spotless.

Spotless is not the same thing as covered.

Traffic discovery finds what you already watch faster and more completely than a spreadsheet. It does not find what was stood up outside the watch.

2. “But the WAF Would Flag Attack Traffic.”

It would flag traffic that looks like an attack.

Authorization abuse doesn’t.

A Broken Object Level Authorization request is a valid token asking for a real record by a real identifier. The only thing wrong with it is whose record it is.

A Broken Function Level Authorization request is a valid session calling an operation its role should never reach.

No payload to match.

No malformed header.

No signature.

The USPS case is the clean illustration. Any user logged in to usps.com could query email, username, account number, address and phone for roughly 60 million other accounts, and the API also accepted requests to modify other users’ data through the same unchecked path.

Nicholas Weaver of UC Berkeley put the root cause in one line: “the only access control they had in place was that you were logged in at all.”

Every one of those requests was authenticated.

Every one of them would pass a WAF that asks whether the request is well formed.

That is Salt’s 99% in practice. A system tuned to spot hostile-looking traffic is looking at the wrong property.

The log is still valuable. It records which identity called which endpoint, with which response code, how often, in what sequence.

But a log is a record, not a question.

It becomes detection only when someone, or a behavioural baseline, asks it the right thing.

3. “But Our Scanner Runs on Every Release.”

Which scanner, logged in as whom?

Traditional web-application DAST authenticates as a single user and fires generic payloads at the inputs it discovers.

It structurally cannot find BOLA or BFLA.

Both failures exist only in a comparison: what one identity can reach against what a different identity should not.

A scan with one identity has nothing to compare.

It will report that user A can read user A’s invoice.

Correct.

Useless.

API-aware scanning closes this by testing with several roles at once. One documented approach, StackHawk’s, has a higher-privileged test identity create a resource, then tries to read or write that same resource ID with a lower-privileged identity’s credentials. If the unauthorised call succeeds, that is a BOLA finding.

That approach has preconditions the tool cannot supply for you.

Valid credentials at two or three defined privilege levels.

And, in most current implementations, an OpenAPI specification the tool can walk to learn which operations and objects exist.

Cloudflare’s API vulnerability scanner pushes the idea further. It uses a 120-billion-parameter open-weight model to infer an API’s call graph from its OpenAPI specification, then walks that graph injecting owner and attacker credentials to find BOLA paths.

By Cloudflare’s own account, the first release still depends on an uploaded specification, and at launch covers API-focused findings only, with SQL injection and XSS left to a separate scanner.

Read those preconditions again.

The scanner tests the endpoints you documented, with the roles you provisioned.

An undocumented endpoint is invisible to it for the same reason it is invisible to traffic discovery: nobody pointed the tool at it.

A green scan certifies the specification.

Not the estate.

4. “But Deprecated Endpoints Are Switched Off.”

Deprecated is a status in a document.

Switched off is a fact about a host.

A zombie API is exactly the gap between them. A real, once-documented endpoint, formally deprecated, never actually decommissioned, still reachable, still running whatever authorization logic it shipped with, unpatched.

A shadow API is the mirror image. Never brought under governance at all. Deployed by a team outside the normal release process, or shipped in a hurry without being registered anywhere a security team would look.

Both defeat your central controls for one reason.

A rate limit, a schema check or an authorization rule configured centrally only protects the endpoints someone remembered to point it at.

OWASP made this its own category. API9:2023 is Improper Inventory Management, sitting in the same Top 10 as the authorization failures it enables.

Discovery tooling helps by enumerating what is actually live instead of trusting a static list.

But discovery has its own edge.

Invicti notes that legacy systems rarely have accurate or complete API inventories, and that tools tuned only for modern REST or JSON endpoints routinely miss older SOAP and XML services still running in production.

So the one class of endpoint most likely to be a forgotten zombie is the class your discovery tool is least likely to recognise.

That is not a coincidence you can configure away.

Coverage of the discovery tool is bounded by the protocols it was built to see.

5. “But the API Is Fully Documented in Our Spec.”

Then your spec is the most important input to your scanner.

Which means it is also its ceiling.

Everything in section 3 depends on it. The multi-role scanner walks the specification. Anything missing from it is never exercised.

And a specification describes the contract you intended, not the fields your framework will actually accept.

Mass assignment is the illustration. A framework binds every field in a request body onto an internal object, with no allowlist, and a field the client was never supposed to set, an is_admin flag, a role, gets written because the caller included it.

CVE-2023-32079 in Netmaker, versions before 0.17.1 and 0.18.6, let a non-admin user reach full administrative privileges that way. CVSS 3.1 base score 8.8.

In traffic, that looks like a legitimate write carrying one or two extra fields.

It only stands out if you compare the fields the endpoint accepts against the fields the schema declares.

The response side is worse.

Excessive data exposure is a server returning a full internal object and trusting the client to discard what it doesn’t display. The request is entirely legitimate. It is caught only by inspecting response payloads against what the calling context actually needed.

OWASP’s 2023 list folds mass assignment and excessive data exposure into one category, API3, Broken Object Property Level Authorization. Three of the ten 2023 categories are authorization failures by name: API1, API3 and API5.

None of the three is visible from “the request matched the documented route.”

6. “But an Exposure That Large Would Show Up in Monitoring.”

The documented ones didn’t.

First American Financial issued sequential, nine-digit document numbers in URLs, and no authentication was required to read the documents. Anyone holding one valid link could walk to the next by incrementing the number.

Roughly 885 million files, with records dating back to 2003.

Open since at least March 2017, going by Internet Archive snapshots.

Disabled in 2019, after notification from outside.

Panera Bread returned full customer records, name, email, physical address, birthday, last four digits of a stored card, loyalty number, to anyone who incremented a sequential account ID.

Reported in August 2017.

Acted on eight months later, only after Krebs on Security published in April 2018. The estimate then moved from 7 million records to potentially more than 37 million.

Those two ran long.

The shorter windows were not short.

T-Mobile’s January 2023 API breach harvested names, billing addresses, phone numbers, dates of birth and account numbers on roughly 37 million accounts. It began around 25 November 2022 and was detected on 5 January 2023.

That is 41 days by the calendar: 5 remaining in November, 31 in December, 5 in January.

An Experian identity-verification bypass ran 47 days, 9 November to 26 December 2022, before it was fixed.

None of these numbers measure attacker sophistication.

They measure how long a missing check can run before anyone outside the attacker’s own traffic notices.

Size does not make an exposure loud.

A walk through an identifier space, one well-formed request at a time, is a very large quiet event.

Salt Security also found that 32% of surveyed organisations had an API security incident in the past year, and 47% had delayed an application deployment over API security concerns.

That is not a problem that only happens to other people’s gateways.

7. No, This Does Not Mean Gateways, Logs and Scanners Are Pointless.

They aren’t.

Each one catches real failures inside its own view.

Traffic discovery finds endpoints nobody registered, as long as they cross the vantage point.

API-aware scanning with several roles finds BOLA before release, as long as the endpoint is in the specification and you gave it the credentials.

And a sequential-ID enumeration is visible in access logs to anyone who asks. A single credential making thousands of sequential-identifier requests in a short window is a pattern, even when every individual request is well formed. That is the Panera signature. That is the First American signature.

The point is narrower and harder.

None of these layers sees what never reaches it.

And authorization flaws do not look like attacks at the network layer.

Each blind spot is different, which is precisely why you run all three rather than picking the cheapest. Discovery misses what never crosses its vantage point. Logging is only as good as the question asked of it. Scanning needs credentials and a specification that neither of the others guarantees exist.

Deploying one is a partial defence.

Deploying three without reconciling them is three partial defences with a shared assumption.

8. What You Should Actually Do

Reconcile the inventory against independent discovery. Your API catalogue, your gateway’s observed traffic and a discovery pass that covers internal service-to-service calls and legacy SOAP and XML services. Every endpoint that appears in one and not the others is a finding.

Decommission deprecated endpoints, then check. Send the request. If it answers, it is not switched off.

Test authorization with every privilege level against every endpoint, documented and discovered. Two or three real test identities, at minimum. One identity creates the object; the others try to read and change it. Feed discovered endpoints into the specification the scanner walks, or the scanner never sees them.

Baseline per-identity access and alert on identifier walks. Which caller touched which objects, how many, in what order. An identity stepping through an ID space is the signal Panera and First American both produced.

Compare response payloads against what each caller needs. Excessive exposure never shows in the request.

Compare accepted fields against declared fields. Mass assignment hides in the difference.

Prove the detection works. OWASP’s crAPI, the Completely Ridiculous API, is a deliberately vulnerable reference API. Point your discovery, logging and scanning at it and see which Top 10 classes they actually catch.

Better to learn that on crAPI than from Krebs.

9. The Model Is Not Complicated.

Discovery answers: which endpoints crossed the place you watch?

Logging answers: what did those endpoints do, if you ask?

API-aware scanning answers: can one of your provisioned roles reach another’s objects, on the endpoints you documented?

Authorization failure is a valid caller reaching the wrong object or the wrong operation.

It looks like normal traffic, because it is normal traffic.

A monitoring layer covers only the traffic, endpoints and identities it is given.

Use the gateway.

Keep the logs.

Run the scanner.

Then ask the question that usually clears the room.

Which of your APIs has never been seen by any of them?

If the answer is “none, as far as we know,” that is not an answer. At Panera, USPS and First American, the answer came from outside.