Because the rate limit lived in a component in front of the production host, not in the API code. A second host running the same API, such as a beta one, skipped that component, so the endpoints were open without the control. The fix is an inventory of hosts and controls that do not depend on one front door.
The scenario from OWASP
OWASP's API Security Top 10 uses this story to illustrate improper inventory management. A social network added a rate limiting mechanism to stop brute force guessing of password reset tokens. The mechanism was not part of the API code. It sat in a separate component between the client and the official API host.
A researcher found a beta API host that ran the same API, including the reset password feature, but without the rate limiter. By brute forcing the six digit token there, the researcher could reset the password of any user.
The story is about a gap between what the team knew about, one official host, and what actually existed.
Why it happens
- Controls are attached to a gateway, load balancer or web application firewall, not to the service.
- New hosts are created for testing, a migration or a mobile beta and never added to the gateway.
- Old versions stay up after a new version ships, connected to the same database.
- DNS records outlive the project that created them.
OWASP names the questions a blind spot leaves unanswered: which environment is this host in, who should have network access, and which version is running. It also says outdated documentation and a missing retirement plan make things worse.
A check you can run this week
- List every hostname that serves your API: production, staging, beta, regional, partner specific and legacy. Use DNS records, gateway configs, cloud load balancers and mobile app configuration.
- For each, record environment, owner, version and who may reach it.
- Run the same abuse test on each host: repeated reset attempts, repeated logins, large page sizes.
- Compare results. Any host where a control is missing is a finding.
- Check that non production hosts do not connect to production data. OWASP notes different versions are sometimes connected to the same database with real data.
- Close or fix: put the host behind the same controls, restrict network access, or retire it.
Put controls where they cannot be skipped
| Control | Weak place | Stronger place |
|---|---|---|
| Rate limit on sensitive flows | Edge component for one hostname | Also in the service, per account and per action |
| Authentication | Gateway only | Service verifies tokens itself |
| Network access | Obscurity of the hostname | Allow lists and private networking |
| Version retirement | Informal | Written date, owner and monitoring |
Defence in depth means a missed host is limited by the service's own checks.
Mobile angle
Mobile apps often contain hostnames for beta, regional and older backends in their configuration, which makes those hosts easy for an attacker to find. Treat the app's config as a public host list, and make sure each entry is protected.
You can try the demo below to see how an API scan reports findings by endpoint, and run a free scan of your own at gold.safeguard.sh/scan. Safeguard's asset discovery is aimed at the inventory part of this problem.
Try it yourself
Click through it at your own pace, or open it full screen.
Notice that each finding belongs to a specific endpoint, which is why scanning every host matters.
Quick check
Is it enough to rate limit at the gateway?
Not on its own. Any host that bypasses the gateway skips the control. Add limits in the service for sensitive flows.
How do I find hosts I have forgotten?
Combine DNS records, cloud load balancer lists, gateway configuration and the hostnames inside your mobile apps.
Sources
Last reviewed: 19 October 2026.
