Your Rate Limiter Is Not A Security Control
A bot pulled all the data for one passport from my API in minutes.
My rate limiter did not stop it.
The limit was 3,000 calls per month. A full passport scan only takes 195 calls. The bot stayed under my limit and stole everything.
Rate limiting protects your infrastructure costs. It does not protect your data.
If you mix these two ideas, you will leak your data.
Rate limiters ask one question: Is this client costing me too much money right now?
Scrapers stay under that line on purpose. My scraper ran at 25 requests per minute. That is a tiny load. It would only need 40,000 calls to copy my entire dataset. If a hacker uses many free accounts, no volume cap will catch them.
Stop looking at volume. Look at identity, coverage, and pattern.
I made two mistakes. First, I did not log the source IP. A hacker could just sign up again for free.
Fix your logs first. Add IP and country columns to your database. Use the real client IP from Cloudflare instead of the remote address. This lets you block attackers at the network layer.
Second, change your limits.
Do not just limit requests per month. Limit how many different destinations one passport can check per day. A real user checks a few destinations. A scraper tries to check them all.
A data sweep has a specific signature:
- It is dense.
- It is sequential.
- It covers everything for one source.
You can detect this pattern by looking at a sliding window of activity. If one passport hits too many destinations in a short time, flag it. Throttle that key or block it immediately.
Now you react to behavior instead of just counting numbers.
Split your strategy into two jobs:
- Rate Limiter: Protect your money. Use per-key volume caps.
- Extraction Defense: Protect your data. Use identity, coverage, and cadence.
If you only have a rate limiter, you have a billing guardrail. You do not have security.
Source: https://dev.to/mathis_higuinen_6db9b244c/your-rate-limiter-is-not-a-security-control-4b3f