No security without an API Gateway: the right order in API infrastructure

T-Mobile case, Shadow API, inventory, and a Gateway-first roadmap for API security.

37 million customers lost, 41 days of invisible attack

January 2023. T-Mobile disclosed an API data breach affecting 37 million customer accounts. The attacker had begun unauthorized use of an API on November 25, 2022. For 41 days, no one noticed. Names, addresses, phones, emails, birth dates — everything leaked.

How did this happen? The answer is simple but painful: They could not protect an API whose existence they did not know.

Salt Security's analysis is clear: this was a "Shadow API" case. Security teams were unaware of this API's existence, the data it processed, or its security posture. It was outside the scope of the API management and security program.

And this was T-Mobile's 8th breach. Since 2018. They had agreed to pay $350 million for a 2021 breach.

But the real question is: didn't T-Mobile have an API Security product? They probably did. So why didn't it work?

Field reality: "should we buy an API Security product?"

In meetings over the past few months with banks, public agencies, and defense industry customers — security teams, infrastructure, system architects, service managers, enterprise architects — the same question kept coming up: "Should we buy an API Security product?"

They had attended many presentations, run PoCs, but still had no clear answers. Every API Security vendor tells a different story. Some talk about behavior analysis, some API discovery, some promise ML-based threat detection. Some "catch problems in mid-air" — which is a real quote.

I asked the same question in every meeting: "When you say API Security, what do you mean and what do you expect?"

Their real needs were:

Know all APIs exposed and consumed inside and outside the organization
Master API inventory
Know who owns and is responsible for each API (or at least who to hold accountable when something goes wrong)

The behavior analysis and threat detection capabilities that API Security products offer? That was second — or even third — the cherry on top.

The answer was always the same: mastering inventory is the top priority.

The T-Mobile case shows exactly that: without inventory, the attack stayed invisible for 41 days.

What exactly happened at T-Mobile

For 41 days the attack went undetected because:

The API was outside central management (shadow API)
It did not go through a gateway
There was no visibility
No behavioral baseline had been built
Anomaly detection was not in place

Result: the API Security product wasn't even aware of this API's existence. How could it protect it?

"No API Security product can see traffic that does not pass through an API Gateway. It cannot protect what it cannot see. It is useless for Shadow APIs."

So the order is critical:

Gateway first → all traffic through a single point
Then Management → build inventory, assign ownership
Security last → only then does protection make sense

Otherwise you buy an expensive API Security product and, like T-Mobile, may not see the attack for 41 days.

How API Security products actually work

API Security products are not blind, but they need eyes to see.

They need:

To operate by observing API Gateway or WAF traffic
To analyze HTTP request–response pairs
To learn normal behavior patterns
To detect anomalies

If you have no central traffic point, the security product stays blind.

These products require full visibility to do:

API discovery (which APIs exist?)
Behavioral analysis (what is normal?)
Anomaly detection (where is the deviation?)
Shadow API detection (where are unregistered APIs?)
Threat intelligence (what are the attack patterns?)

Is the SOA story repeating?

When I saw this, my years of experience on the SOA side came to mind. Back then everyone was talking about SOA. Global vendors sold products under the SOA name. ESB products, SOA governance platforms, service registries. Millions of dollars were spent.

Most of those projects failed. The ones that continued did so because no one dared touch them.

Why? Because they trusted the product and said "the product will solve everything." The forgotten truth was:

SOA is not a product; it is an architectural approach.

Like Lego pieces, you have to build it. You must first understand the architectural principles, then define your governance model, then build your infrastructure step by step. Buying a product did not mean having SOA.

Is the same movie repeating in API Security?

Many organizations act with this logic:

"Let's buy an API Security product first; security is the priority."
"We'll think about the gateway later."
"Inventory will emerge gradually."

This is the opposite of the right approach. Like buying an ESB and saying "we have SOA now." Money is spent, expectations are not met, shadow APIs remain invisible, and the project is shelved.

What the data says

Gartner 2024 Market Guide for API Protection: "Shadow and dormant APIs cause, on average, larger data leaks than other breaches."
Salt Security & LevelBlue Research (2024): "94% of organizations experienced a security issue in production APIs in the past year."
Dark Reading (Nov 2024): "The most urgent problem for organizations is the lack of inventory of all external APIs."
OWASP API Security Top 10 #9: "Improper Inventory Management: poor management of API assets. Lack of awareness of all APIs leads to security vulnerabilities."

The pattern is clear: without a Gateway and inventory, API Security products stay blind.

The T-Mobile case: a closer look

November 25, 2022 — day zero. The attacker gained unauthorized access to one of T-Mobile's APIs — a Shadow API: unregistered, undocumented, and unknown to security teams.

November 26 — January 4 (40 days). Silence. The attacker accessed 37 million customers' data every day, systematically: names, billing addresses, emails, phone numbers, birth dates, T-Mobile account numbers.

Security teams? Unaware. SIEMs did not alarm. API Security products were silent — because we're talking about an API they couldn't see.

January 5, 2023 — detection. After 41 days, an anomaly was detected.

January 6, 2023 — stopped. T-Mobile stopped the attack one day after detection.

Notable point: if it could be stopped in one day once detected, why was it invisible for 41?

Root cause: Shadow API and API sprawl

The problem is not "we forgot an API." It's the result of a systematic issue called API sprawl:

Shadow APIs. Unregistered, unknown APIs — developers create them for testing and forget; legacy, undocumented endpoints; uncontrolled growth in microservices; unintegrated APIs from acquired companies.
Zombie APIs. APIs thought to be unused but still active. No security updates, no monitoring, known vulnerabilities.
Ghost APIs. APIs that exist in documentation but behave differently in reality.

T-Mobile's reality: this was their 8th breach in 8 years, even after paying $350M for a 2021 breach and committing $150M to cybersecurity. They bought products. They did not build a central Gateway, inventory all APIs, or institutionalize lifecycle management.

Three critical questions before you buy an API Security product

1. Do you have an API inventory?

Answers I got in the field:

"We don't know exactly but around 200" (turned out there were 847)
"Each department has its own APIs; no one knows the total"
"We don't even know if we have APIs in our legacy systems"
"Since we moved to microservices, we've lost control"

An inventory is not an Excel list. It should include name, version, endpoints, HTTP methods, hosting, owner, technical lead, business unit, lifecycle state, authentication, authorization, data types (PII, PCI), compliance, tech stack, dependencies, SLA, and rate limits.

Real scenario: a financial institution bought a $2M API Security platform. After 6 months: it detected 180 APIs (those through the gateway); manual inventory found 540 APIs; 360 APIs were running where the product couldn't see. $2M spent, most APIs still invisible.

"Buying API Security without inventory is like running a police patrol in a city with no map."

2. Do you have a central API Gateway?

This question is even more critical. API Security products work by observing Gateway traffic.

Without a central Gateway:

Traffic monitoring impossible
Baseline learning impossible
Anomaly detection impossible
Threat intelligence impossible

"We use a WAF; isn't that enough?" No. WAF and API Gateway are different:

WAF. Layer 7 attacks (SQL injection, XSS), pattern-based, not API-aware, cannot build API inventory, cannot detect API-specific attacks (BOLA, Mass Assignment).
API Gateway. Manages API traffic, rate limiting / throttling, builds API inventory, request / response transformation, gives API Security products full visibility.

Gartner 2024: Shadow API rate 68% without central Gateway, 23% with. A 3x difference.

3. Can you distinguish internal and external APIs?

Real case: an e-commerce company said "we only have 12 external APIs. The rest are internal." After a network scan: 47 APIs were exposed to the internet; 35 were exposed "by mistake."

Accidentally external APIs are a gold mine for attackers — minimal security, weak or no auth, not monitored.

Bottom line

Saying NO to all 3 = money lost. The API Security product can't see what it needs to see; behavioral analysis doesn't work; anomaly detection is impossible; Shadow APIs cannot be detected.

"You can't protect what you can't see"

A golden rule in cybersecurity:

"You can't protect what you can't see."

T-Mobile couldn't see the attack for 41 days. Why? Because they couldn't see that API.

Three levels of visibility:

Asset visibility. Which APIs exist? Count, hosting, endpoints, internal / external, versions.
Traffic visibility. How are your APIs used? Who calls, how often, parameters, response times, error rates.
Data visibility. What data do your APIs process? PII, financial, health, credentials, regulatory categories.

Visibility = Control = Security.

"But Gateway adds latency"

A false dilemma. Modern API Gateways add about 5–15 ms, compared to:

DNS (20–120 ms)
TCP (50–200 ms)
TLS (50–100 ms)
DB (50–500 ms)
External calls (200–2000 ms)

Gateway is 1–2% of total request time. Using a Gateway is 3–4x more economical than not using one.

Gateway → Management → Security: the right roadmap

Wrong order: Buy API Security → deploy → only 30–40% of APIs visible → Shadow APIs not detected → low ROI → project shelved.

Right order:

STEP 1: GATEWAY (visibility) — 0–6 months. Goal: 100% visibility.

Gateway selection and setup (HA, rate limiting, throttling, caching, monitoring, security tool integration, Kubernetes, APIOPS / CI-CD)
Quick wins: central auth, rate limiting for DDoS, basic logging
API migration by priority: external, PII, high-traffic, legacy, internal
Discovery & baseline: all APIs through Gateway, traffic patterns learned

STEP 2: MANAGEMENT (inventory & governance) — 6–12 months. Goal: control and governance.

Build the inventory: name, version, endpoints, owner, tech lead, business unit, data classification, SLA, auth, compliance
Lifecycle: design → develop → test → deploy → monitor → deprecate → retire
Governance: new APIs must be in inventory; deprecated closed in a controlled way; version standard; documentation mandatory
Shadow API elimination: Gateway traffic vs inventory; find shadows; assign ownership; integrate or shut down

STEP 3: SECURITY (protection & anomaly) — 12–18 months. Now buy an API Security product. You have 100% visibility, inventory, baseline, and governance.

Platform selection: Gateway integration, behavioral analysis, OWASP API Top 10, threat intelligence
PoC on production traffic
Deployment & tuning, baseline learning (2–4 weeks), policies, alert tuning
Operationalization: SOC training, playbooks, incident response, KPIs

Output: attack detection in minutes, not 41 days.

Tomorrow may be too late

"Nice article but it won't happen to us. We're different." T-Mobile thought so too. Even after paying $350M.

Ten simple questions:

Can you say how many APIs you have in 5 minutes?
Have you said "where did this API come from?" in the last 6 months?
For a random API, who's the business owner?
Do all APIs go through one Gateway?
Do you have APIs written 3+ years ago still running?
New vendors / integrations?
Can every team deploy their own API freely?
Does your Security product see all APIs?
Any API security incident in the last 2 years?
Do you sleep well at night?

Your answers show the real picture.

"The most dangerous API is the one you don't know."

"The most expensive vulnerability is the one you don't see."

"The biggest mistake is saying 'it won't happen to us.'"

You can buy the best API Security product. You can spend millions. But if your APIs don't go through a Gateway, that product only protects what it sees — not what it doesn't. Can you see 100% of your APIs? Can you detect your Shadow APIs? Does all API traffic pass through a single point? If you answer NO to these, you're very close to T-Mobile's 41 days.