WAF, CDN and Edge Security

Edge security controls — WAFs, CDNs, and rate limiters — are the first line of defence for internet-facing applications. They cannot replace application-level security, but they reduce attack surface, absorb volumetric attacks, and buy time when zero-days drop. This lesson covers what they do, how to configure them, and where they fail.

Web Application Firewalls (WAFs)

A WAF inspects HTTP requests and responses against a set of rules, blocking requests that match known attack patterns.

How WAFs work

Client → CDN/Edge → WAF → Load Balancer → Application
                     ↓
              Block / Allow / Log

WAFs operate in two modes:

Always deploy in detection mode first. Blocking legitimate traffic is worse than missing an attack.

Rule types

Managed rules (vendor-provided):

Pre-built rule sets maintained by the WAF vendor:

Custom rules:

Rules you write for your specific application:

# Block requests to admin endpoints from outside the corporate network
IF path STARTS WITH /admin
AND source_ip NOT IN 10.0.0.0/8
THEN BLOCK

# Block excessively large request bodies (file upload abuse)
IF request_body_size > 10MB
AND path != /api/upload
THEN BLOCK

WAF configuration by platform

AWS WAF:

{
  "Name": "BlockSQLi",
  "Priority": 1,
  "Statement": {
    "SqliMatchStatement": {
      "FieldToMatch": {
        "Body": {}
      },
      "TextTransformations": [
        { "Priority": 0, "Type": "URL_DECODE" },
        { "Priority": 1, "Type": "HTML_ENTITY_DECODE" }
      ]
    }
  },
  "Action": { "Block": {} }
}

Cloudflare WAF:

Cloudflare provides managed rulesets you enable per zone, plus custom firewall rules using their expression language:

# Block requests with SQL injection patterns in query string
(http.request.uri.query contains "UNION SELECT" and not ip.src in {10.0.0.0/8})

WAF limitations

WAFs are not a substitute for secure code:

Think of a WAF as a seatbelt, not a crash-avoidance system.

Virtual patching

When a zero-day drops and you cannot patch the application immediately, deploy a WAF rule to block the specific exploit pattern:

# Virtual patch for CVE-2025-xxxxx (hypothetical SSRF via redirect parameter)
IF query_param "redirect" MATCHES "^https?://(169\.254|10\.|172\.(1[6-9]|2[0-9]|3[01])\.|192\.168\.)"
THEN BLOCK

This buys time to develop and deploy the real fix. Remove virtual patches once the application is patched — they add complexity and latency.

Rate limiting

Rate limiting prevents abuse by capping the number of requests a client can make in a time window.

What to rate limit

Rate limiting strategies

Fixed window: Count requests in fixed time buckets (e.g., 0:00–0:01, 0:01–0:02). Simple but allows bursts at window boundaries.

Sliding window: Count requests in a rolling window. Smoother but more resource-intensive.

Token bucket: Clients have a "bucket" of tokens that refills at a constant rate. Each request consumes a token. Allows short bursts while enforcing average rate.

Implementation

At the edge (recommended for public endpoints):

# Cloudflare rate limiting rule
When: URI path equals "/api/auth/login"
Rate: 10 requests per minute per IP
Action: Block for 60 seconds
Response: 429 Too Many Requests

In the application (for business logic limits):

import rateLimit from 'express-rate-limit';

const loginLimiter = rateLimit({
  windowMs: 60 * 1000,
  max: 10,
  keyGenerator: (req) => req.ip,
  handler: (req, res) => {
    res.status(429).json({ error: 'Too many login attempts. Try again in 1 minute.' });
  }
});

app.post('/api/auth/login', loginLimiter, loginHandler);

Rate limit headers

Return rate limit information in response headers so legitimate clients can back off:

HTTP/1.1 200 OK
X-RateLimit-Limit: 100
X-RateLimit-Remaining: 73
X-RateLimit-Reset: 1710504000
Retry-After: 42

CDN security

CDNs cache and serve content from edge locations close to users. Beyond performance, they provide several security benefits.

DDoS absorption

CDNs distribute traffic across a global network, absorbing volumetric DDoS attacks before they reach your origin:

• Network-layer (L3/L4): SYN floods, UDP amplification — absorbed by CDN infrastructure
• Application-layer (L7): HTTP floods — mitigated by rate limiting and bot detection at the edge

Origin shielding

Hide your origin server's IP address behind the CDN:

1. All DNS records point to CDN edge nodes
2. Origin server only accepts traffic from CDN IP ranges
3. Origin IP is not exposed in any public record

# Example: restrict origin security group to CDN IPs only
aws ec2 authorize-security-group-ingress \
  --group-id sg-12345 \
  --protocol tcp \
  --port 443 \
  --cidr 104.16.0.0/12  # Cloudflare IP range

If an attacker discovers your origin IP (through DNS history, email headers, or error messages), they can bypass the CDN and attack the origin directly. Keep the origin IP private.

TLS at the edge

Always use "Full (strict)" SSL mode. "Flexible" mode means the CDN terminates TLS but connects to your origin over plain HTTP — an attacker on the same network as your origin can intercept traffic.

Bot management

Automated bots account for a significant percentage of web traffic. Not all bots are malicious, but you need to distinguish:

Bot detection techniques

Managed bot solutions

Cloudflare Bot Management, AWS WAF Bot Control, Akamai Bot Manager, and similar products combine multiple detection techniques. They are more effective than custom rules for large-scale bot problems.

Putting it together

A typical edge security stack:

Client → CDN (DDoS absorption, caching, TLS)
          → WAF (managed rules, custom rules, virtual patches)
            → Rate Limiter (per-endpoint limits)
              → Bot Management (challenges, fingerprinting)
                → Origin (your application)

Configuration checklist

• CDN in front of all public endpoints
• Origin IP hidden, security group restricted to CDN IPs
• TLS 1.2+ with Full (strict) SSL mode
• OWASP CRS managed rules enabled in detection mode → tuned → switched to prevention
• Custom WAF rules for application-specific patterns
• Rate limiting on authentication, registration, and sensitive API endpoints
• Bot management enabled with appropriate challenge levels
• Rate limit headers returned to clients
• Logging enabled for all blocked and challenged requests
• Monthly review of WAF false positives and rule effectiveness

Summary

Edge security controls — WAFs, CDNs, and rate limiters — reduce attack surface and absorb automated abuse, but they cannot replace secure application code. Deploy WAF rules in detection mode first, tune for false positives, then switch to blocking. Rate limit authentication and sensitive endpoints at the edge. Hide your origin behind the CDN and enforce strict TLS. Review and tune edge rules regularly — an untuned WAF either blocks legitimate users or misses real attacks.