Security at the edge: WAF, DDoS and bot management
Managed and custom WAF rules, rate limiting at the edge, how DDoS absorption works, bot scoring and challenges, and avoiding rules that block real customers.
WAF rules that help
| Rule type | Catches | Deploy as |
|---|---|---|
| Managed ruleset | Known exploit signatures for common platforms | On, in log mode first |
| Custom rule on a path | Abuse of one endpoint | Block after a threshold |
| Rate limit on a route | Credential stuffing, scraping | Throttle, then block |
| Geo rule | Traffic from regions you do not serve | Challenge, not block |
| Bot score | Automated traffic with a reputation | Challenge the low scores |
| Payload inspection | SQL injection and XSS attempts | Managed rules plus your own validation |
| IP reputation | Known abusive networks | Block, and review the false positives |
A rollout order that does not break the site
1. enable managed rules in log-only mode for a week
2. read the log: what would have been blocked, and was any of it real?
3. enable the rules with no false positives, in block mode
4. add rate limits on login, signup, search and any expensive endpoint
5. add a challenge for low bot scores on those endpoints only
6. keep an allow list for your own monitors and your payment provider's
webhooks - a blocked webhook looks like a payment failure- Rate limit by IP plus route. Limiting by IP alone blocks an entire office; limiting by route alone blocks everybody.
- Challenge before you block. A challenge is reversible by a real user; a block produces a support ticket.
- Never block the payment provider's webhook addresses. Check the documented ranges and add them explicitly.
DDoS absorption
- Volumetric attacks are absorbed by the CDN's network capacity, which is why the site is in front of it in the first place.
- Application-layer attacks look like ordinary requests. They are stopped by caching, rate limiting and challenges - not by bandwidth.
- An attack on an uncacheable endpoint is the expensive case. Make the endpoint cheap: cache what can be cached and reject what fails a cheap check early.
- Watch origin egress during an attack. If the CDN is passing everything through, you are paying for the attack.
- Test the failover: what happens if the CDN itself is degraded? A direct-to-origin fallback must exist, and it must not be publicly reachable.
Origin protection that survives an attack
allow only the CDN address ranges, not the whole internet
require a shared secret header that the CDN adds and the origin verifies
set a low connection limit per source at the firewall
cache aggressively at the edge so a flood of reads never reaches the origin
alarm on origin request rate, not only on error rateTuning without collateral damage
| Symptom | Likely rule | Adjust |
|---|---|---|
| Customers blocked from one country | Geo block | Change to a challenge or remove |
| Login fails for some users | Rate limit too tight | Raise the burst allowance |
| API clients get 403 | Bot score rule | Allow known user agents, or use a token |
| Search console errors | Crawler blocked | Verify the crawler by reverse DNS, then allow |
| Webhook failures | Rate limit on a callback path | Allow the provider ranges |
| Legitimate file uploads fail | Payload inspection | Exclude the upload path from body inspection |
| Monitoring reports the site down | Monitor blocked | Allow the monitor's addresses or token |
# a crawler must be verified by reverse DNS, never by user agent string
dig -x 66.249.66.1 +short # reverse lookup the claimed crawler address
dig +short googlebot.example.com # forward confirm it resolves back to the same range
# and a synthetic check that a real user path still works after a rule change
curl -s -o /dev/null -w "%{http_code}\n" https://example.com/login
curl -s -o /dev/null -w "%{http_code}\n" -H "User-Agent: $UA" https://example.com/⚠️
Every WAF rule has a false positive you have not met yet. Keep a documented allow list, log the rule id on every block, and make it possible to disable a single rule in one action without a deploy - otherwise your first reaction to an incident will be to turn the whole WAF off.
FAQ
Does a WAF replace fixing my application?
No. A WAF buys time on known patterns; an unvalidated input or a missing authorisation check is still the vulnerability. Treat the WAF as defence in depth, not as the fix.
How do I handle an attack on a login endpoint?
Rate limit by IP and account, add a challenge with a low bot score, consider a proof-of-work or CAPTCHA on repeat failures, and alert on the failure rate. Blocking by IP alone rarely helps against a distributed attempt.
Related
Signed URLs, token authentication and hotlink protection Multi-CDN, failover and cost optimisation
Last refreshed 2026-09-18.