Every API endpoint you expose without rate limiting is a backdoor waiting for a bored teenager with curl and a script
You spent weeks building that API. You secured the endpoints. You added authentication. You validated inputs. You feel good about it.
But you forgot one thing: rate limiting.
And somewhere out there, a bored teenager with a laptop, a bag of chips, and too much time on their hands just found your API.
They don’t need to hack you. They don’t need to find a vulnerability. They just need to run a script. And your API will take itself down.
The curl command that started it all
Imagine this: a teenager finds your API endpoint. No rate limiting. They open a terminal and type:
#!/bin/bash
while true; do
curl -X POST https://yourapi.com/endpoint -d '{"data":"lol"}'
done
That’s it. No sophisticated exploit. No zero-day. Just a loop.
Within minutes:
- Your database is under load
- Your server CPU is spiking
- Your cloud bill is climbing
- Your legitimate users are getting timeout errors
- You’re getting paged at 2 AM
The many ways an unrate-limited API can be abused
Attackers don’t need fancy exploits. They just need volume. Here’s what they can do:
- Denial of Service (DoS): Exhaust your compute, memory, or database connections. Your API becomes unavailable to real users.
- Credential stuffing: Try millions of username/password combinations using stolen credentials from other breaches.
- Inventory denial: Place thousands of fake orders. Hold items in carts without checking out. Disrupt your business.
- OTP bombing: Trigger thousands of SMS or email messages to a target. Annoying at best. Costly at worst.
- Data scraping: Download your entire database one request at a time. Competitors love this.
- Cloud cost attack: Exploit pay-per-request pricing. Make your bill explode.
The “bored teenager” is not a joke — it’s a threat profile
We laugh about “bored teenagers” because it sounds harmless. But bored teenagers have:
- Time — unlimited amounts of it
- Internet access — usually very fast
- Scripting skills — basic Bash/Python is enough
- Community — they share targets on Discord and Telegram
- Zero budget — so they attack things that cost you money, not them
Your API is not too small for them to notice. There are automated scanners that crawl the entire IPv4 address space. They will find you. It’s not a matter of if. It’s when.
Why developers skip rate limiting (and why that’s expensive)
Common excuses I hear:
- “We’ll add it later.” Later becomes never. Attackers don’t wait.
- “We trust our users.” You don’t know all your users. And some of them are not who they say they are.
- “Our authentication is strong.” Rate limiting isn’t about authentication. It’s about volume. A valid authenticated user can still DoS you.
- “We have a CDN.” CDNs help with distributed attacks. They don’t stop a single determined attacker with a script.
- “We’ll handle it if it happens.” You will. At 2 AM. While your phone explodes with alerts.
What proper rate limiting looks like
Don’t overcomplicate it. Start with these basics:
# Simple rate limiting in Express with express-rate-limit
import rateLimit from 'express-rate-limit';
const limiter = rateLimit({
windowMs: 15 * 60 * 1000, // 15 minutes
max: 100, // limit each IP to 100 requests per windowMs
message: 'Too many requests from this IP',
standardHeaders: true,
legacyHeaders: false,
});
app.use('/api/', limiter);
That’s it. Five minutes of work. Protects against 90% of abuse.
For more sophisticated protection:
- Per-endpoint limits: Login endpoints need stricter limits than public read endpoints.
- Per-user limits: Authenticated users have different quotas than anonymous visitors.
- Graduated responses: First slow down, then block, then require CAPTCHA.
- Retry-After headers: Tell clients when they can try again. Well-behaved clients will respect this.
- Distributed rate limiting: Use Redis or similar for serverless/load-balanced environments.
Rate limiting won’t save you from everything — but it’s step zero
Rate limiting is not a complete security strategy. It won’t stop:
- Sophisticated distributed attacks (thousands of IPs)
- Application logic vulnerabilities
- Authentication bypasses
- SQL injection or XSS
But rate limiting will stop the most common, cheapest, and most annoying attacks. It will save your cloud bill. It will keep your API online during accidental traffic spikes. It will make you a harder target.
And in security, being a harder target is often enough. Attackers move on to the next API — the one without rate limiting.
What to do this week
- Audit your APIs. Make a list of every public endpoint. Which ones have rate limiting?
- Add basic rate limiting. Start with global limits. 100 requests per 15 minutes per IP is better than nothing.
- Add stricter limits to sensitive endpoints. Login, registration, password reset, OTP verification — these need lower limits.
- Monitor your rate limit hits. If you’re seeing rate limit exceeded errors, investigate. Someone is trying to abuse you.
- Consider a WAF or API gateway. For larger deployments, tools like Cloudflare, AWS WAF, or Kong can provide advanced rate limiting.
The bottom line
You don’t need a nation-state actor to ruin your day. You don’t need a zero-day exploit. You don’t need a sophisticated hacker.
You just need one bored teenager with curl and a script.
Rate limiting is not exciting. It’s not glamorous. It won’t win you a security award.
But it will keep your API online. It will protect your cloud budget. It will prevent your phone from ringing at 2 AM.
Go add rate limiting to your APIs. It takes 10 minutes. Future you will thank present you.
🦞 Want to know if your APIs are vulnerable to abuse?
I test APIs for rate limiting gaps, authentication bypass, and business logic flaws. DM me first. Quick chat. Then we book a call if we’re a fit.
No Calendly. Just a human who breaks APIs (with permission). Based in The Netherlands 🇳🇱
Leave a Reply