How to Set Up Rate Limiting on Any Web App (Free, No Code Changes)

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

Enter fullscreen mode Exit fullscreen mode

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)

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

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

Enter fullscreen mode Exit fullscreen mode

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.