WAFs, CDNs, and rate limiters sit at the edge, in front of your application, and they're the first thing an attacker's traffic hits. Used well, they reduce your exposed surface and buy you time. Used as a substitute for secure code, they get you breached with a false sense of safety. So hold this in mind throughout: the edge is a seatbelt, not a reason to drive into walls. It improves the odds when something goes wrong; it doesn't make your application safe on its own.
Web Application Firewalls
A WAF inspects HTTP traffic against a set of rules and blocks what looks like an attack. The first rule of running one is to start in detection mode, never straight into blocking, because blocking legitimate customers is a worse outcome than missing a few attacks while you tune.
- Managed rule sets give you a sensible baseline: OWASP Core Rule Set, bot rules, IP reputation.
- Virtual patching is the WAF's best trick. A zero-day drops and you can't ship a real fix today, so you deploy a WAF rule that blocks the exploit pattern as a stopgap, then remove it once the code is fixed.
- Know its limits. A WAF can be bypassed with creative encoding, and it has no idea about your business logic. It catches generic attacks, not the flaw in how you calculate refunds.
Rate limiting
Rate limits turn brute force and abuse from cheap into expensive. Apply them per endpoint, tightest on the sensitive ones:
| Endpoint | Limit |
|---|---|
| Login | 10/min per IP |
| Password reset | 3/min per account |
| Registration | 5/min per IP |
Apply them at the edge where you can, so the traffic never reaches your origin, and return rate-limit headers so well-behaved clients back off on their own.
CDN security
A CDN does more than make things fast. It absorbs DDoS by spreading traffic across a global network, so a flood that would flatten your origin gets diluted.
The control people miss is origin shielding. Point all DNS at the CDN, configure your origin to accept connections only from the CDN's IP ranges, and keep the origin's real IP private. Otherwise an attacker just finds the origin and walks around the CDN entirely. And set TLS to full (strict) mode, because "flexible" leaves the CDN-to-origin hop unencrypted, which quietly defeats the point.
Bot management
Telling bots from humans is its own problem, tackled with JavaScript challenges, CAPTCHAs, TLS fingerprinting, and behavioural analysis. For anything beyond the basics, a managed solution (Cloudflare Bot Management, AWS WAF Bot Control) will outperform rules you write yourself, because they see traffic patterns across far more sites than you do.
The way to run the edge: WAF in detection first then block, rate limits on your auth endpoints, origin hidden behind the CDN, strict TLS, and a regular pass to tune it all. Then go and fix the actual code, because that's still where the real defence lives.