The Problem
Your login page, search endpoint, or contact form is getting hammered. Rate limiting is the fix — but implementing it in application code means finding every endpoint, writing middleware, choosing a storage backend, and deploying changes. On a WAF, you set it once and it applies everywhere.
Why WAF-Level Rate Limiting Is Better
| Approach | Code-Level | WAF-Level |
|---|
| Setup time | Hours to days | 5 minutes |
| Code changes | Required | None |
| Applies to | One endpoint at a time | All routes with one rule |
| Storage | Redis/Memcached needed | Built into WAF |
| Performance impact | Hits your app server | Blocked at proxy |
| Updates | Deploy new code | Change a rule in dashboard |
Step-by-Step: Rate Limit Setup
1. Log into SafeLine Dashboard
Go to https://<your-ip>:9443. Navigate to Rules -> Add Rule -> Rate Limiting.
2. Create Your First Rule — Login Protection
Name: Login brute force protection
Match: URL contains /login OR /wp-login.php OR /auth
Limit: 5 requests per minute per IP
Action: Block (return 429 Too Many Requests)
Block duration: 15 minutes
This stops credential stuffing cold. An attacker who tries 5 wrong passwords in 60 seconds gets blocked for 15 minutes. That's a maximum of 480 attempts per day — vs unlimited without rate limiting.
3. Search Endpoint Protection
Name: Search rate limit
Match: URL contains /search OR /query
Limit: 30 requests per minute per IP
Action: Challenge (JS captcha)
Search endpoints are expensive. A single user running a script can do 1,000+ queries per minute and degrade performance for everyone. 30/min is generous for humans but stops scripts.
4. Global Baseline
Name: Global request limit
Match: /*
Limit: 300 requests per minute per IP
Action: Throttle
Catches anything that slips through specific rules. 300/min = 5/sec, which is more than any human needs.
What Happens When a Limit Is Hit
SafeLine logs every rate limit trigger to the Attack Log. You'll see:
- Which IP triggered it
- Which endpoint they were hitting
- Time of the trigger
- Whether they got blocked, challenged, or throttled
Watch the Attack Log for the first 24 hours. You might discover endpoints you didn't know were getting hammered.
Adjusting Limits — What I Learned
From running a WAF for 30 days on a production site:
- Login: 5/min was right. Zero legitimate users complained.
- Search: 30/min was too strict. Bumped to 60/min after a user reported captcha fatigue.
- API: 100/min per API key was the sweet spot. Power users never hit it; scrapers got blocked.
- Global: 300/min per IP was generous. Never triggered by real traffic, only by vulnerability scanners.
FAQ
Will legitimate users get blocked?
Rarely. Set generous limits (60-300/min) for read endpoints. Only use strict limits (5-10/min) for login, password reset, and registration. Monitor for false positives in the first week.
What if I'm behind Cloudflare or another proxy?
SafeLine reads X-Forwarded-For headers automatically. Rate limiting works correctly behind proxies — it rate-limits the real client IP, not the proxy IP.
Can I set different limits for different users?
Create separate rules for authenticated vs unauthenticated paths. For API key-based limiting, you can match on the Authorization header or specific URL path prefixes.
Try SafeLine Community Edition — free, self-hosted, and takes 5 minutes to deploy:
bash -c "$(curl -fsSLk https://waf.chaitin.com/release/latest/manager.sh)" -- --en
Dashboard: https://<your-server-ip>:9443 | Docs
What's the one endpoint on your site that's getting hit the hardest right now? Start there.