🚦 Rate Limiting and DDOS Protection

Availability Is Security

Information security rests on the CIA triad: Confidentiality, Integrity, and Availability. The first two lessons this week guarded confidentiality and integrity — keeping data private and unaltered. This one guards availability: keeping the service reachable. A login form that's impenetrable but permanently overloaded protects nobody.

Downtime is expensive in ways that compound: lost revenue, eroded user trust, damaged SEO, and breached SLAs. And crucially, an outage doesn't require a malicious attacker — a viral post or an accidental retry loop can flood you just as effectively as a botnet.

Traffic Challenges

Not all heavy traffic is hostile. Sorting it into three buckets helps you choose the right response:

Rate-Limiting Algorithms

Rate limiting caps how many requests a client may make in a time window. Before reaching for a library, it helps to understand the three algorithms behind them — they differ in accuracy, memory, and how they handle bursts.

Fixed window

Count requests per clock interval (e.g. per minute). Simple, but a client can send a full window's worth at 10:00:59 and another full window at 10:01:00 — double the limit across the boundary.

class FixedWindowLimiter {
    constructor(maxRequests, windowMs) {
        this.max = maxRequests;
        this.windowMs = windowMs;
        this.clients = new Map();   // clientId -> { windowStart, count }
    }
    isAllowed(clientId) {
        const now = Date.now();
        const windowStart = Math.floor(now / this.windowMs) * this.windowMs;
        const entry = this.clients.get(clientId);

        if (!entry || entry.windowStart !== windowStart) {
            this.clients.set(clientId, { windowStart, count: 1 });
            return true;
        }
        if (entry.count < this.max) { entry.count++; return true; }
        return false;   // limit exceeded
    }
}

Sliding window log

Store a timestamp per request and count only those inside the trailing window. Precise and no edge bursts, but uses more memory.

class SlidingWindowLimiter {
    constructor(maxRequests, windowMs) {
        this.max = maxRequests;
        this.windowMs = windowMs;
        this.clients = new Map();   // clientId -> number[] of timestamps
    }
    isAllowed(clientId) {
        const now = Date.now();
        const cutoff = now - this.windowMs;
        const times = this.clients.get(clientId) || [];

        // Drop timestamps that have aged out of the window
        while (times.length && times[0] <= cutoff) times.shift();

        if (times.length < this.max) {
            times.push(now);
            this.clients.set(clientId, times);
            return true;
        }
        return false;
    }
}

Token bucket

A bucket refills tokens at a steady rate; each request spends one. It permits short bursts (spend the accumulated tokens) while enforcing a long-term average — which is why it's the most popular choice for APIs.

class TokenBucketLimiter {
    constructor(bucketSize, refillPerMs) {
        this.size = bucketSize;
        this.refillPerMs = refillPerMs;   // tokens added per millisecond
        this.clients = new Map();
    }
    isAllowed(clientId, cost = 1) {
        const now = Date.now();
        let b = this.clients.get(clientId);
        if (!b) { b = { tokens: this.size, last: now }; this.clients.set(clientId, b); }

        // Refill based on elapsed time, capped at bucket size
        b.tokens = Math.min(this.size, b.tokens + (now - b.last) * this.refillPerMs);
        b.last = now;

        if (b.tokens >= cost) { b.tokens -= cost; return true; }
        return false;   // not enough tokens
    }
}

Rate Limiting in Express

The express-rate-limit middleware handles the mechanics — counting, headers, and the 429 Too Many Requests response — in a few lines.

const rateLimit = require('express-rate-limit');

// Global limit: 100 requests per IP per 15 minutes
const limiter = rateLimit({
    windowMs: 15 * 60 * 1000,
    max: 100,
    standardHeaders: true,   // send RateLimit-* headers (the modern standard)
    legacyHeaders: false,    // drop the old X-RateLimit-* headers
    message: 'Too many requests, please try again later.'
});
app.use(limiter);

Apply stricter limits to sensitive or expensive routes — this is your front-line defense against credential-stuffing and brute-force login attacks:

// Only 5 login attempts per IP per hour — blunts brute force
const loginLimiter = rateLimit({
    windowMs: 60 * 60 * 1000,
    max: 5,
    message: 'Too many login attempts, please try again in an hour.'
});
app.post('/login', loginLimiter, handleLogin);

// A separate, looser budget for the general API
const apiLimiter = rateLimit({ windowMs: 15 * 60 * 1000, max: 100 });
app.use('/api/', apiLimiter);

Instead of a hard cutoff, express-slow-down adds latency as a client approaches the limit — a gentler nudge that's less likely to break legitimate bursts:

const slowDown = require('express-slow-down');

const speedLimiter = slowDown({
    windowMs: 15 * 60 * 1000,
    delayAfter: 50,                 // first 50 requests are full speed
    delayMs: (hits) => hits * 100   // then add 100ms per extra request
});
app.use('/api/', speedLimiter);

HTTP/1.1 429 Too Many Requests
RateLimit-Limit: 100
RateLimit-Remaining: 0
RateLimit-Reset: 840
Retry-After: 840

Distributed & Dynamic Limits

An in-memory limiter breaks the moment you run more than one server instance — each process keeps its own count, so the real limit multiplies by the number of instances. The fix is a shared store like Redis.

const { RateLimiterRedis } = require('rate-limiter-flexible');
const Redis = require('ioredis');
const redis = new Redis(process.env.REDIS_URL);

const limiter = new RateLimiterRedis({
    storeClient: redis,
    keyPrefix: 'api',
    points: 10,       // 10 requests
    duration: 1       // per second, shared across ALL instances
});

app.use(async (req, res, next) => {
    try {
        await limiter.consume(req.ip);   // spend 1 point
        next();
    } catch (err) {
        res.set('Retry-After', String(Math.ceil((err.msBeforeNext || 1000) / 1000)));
        res.status(429).json({ error: 'Too Many Requests' });
    }
});

You can also vary the limit by who the client is — key on the user id when authenticated (fairer than IP, which lumps everyone behind a NAT together), and give paying tiers a bigger budget:

const tieredLimiter = rateLimit({
    windowMs: 15 * 60 * 1000,
    max: (req) => (req.user?.tier === 'premium' ? 1000 : 100),
    keyGenerator: (req) => req.user?.id || req.ip   // user id beats raw IP
});

DDoS Defense in Depth

A Distributed Denial of Service attack comes from many machines at once, so no single control stops it. You need layers, each catching what the previous one missed — and ideally most of the traffic is absorbed before it ever reaches your origin server.

Edge and network layer

The most effective DDoS defense usually isn't your code at all — it's a CDN/WAF (Cloudflare, AWS Shield + WAF, Fastly, Akamai) sitting in front of your origin. Their globally distributed networks absorb volumetric floods and scrub malicious packets long before they reach you.

Server layer (example: Nginx)

http {
    # Cap connections and request rate per IP
    limit_conn_zone $binary_remote_addr zone=perip:10m;
    limit_req_zone  $binary_remote_addr zone=reqs:10m rate=5r/s;

    # Starve slow-loris style attacks of patience
    client_body_timeout   10s;
    client_header_timeout 10s;
    reset_timedout_connection on;

    server {
        location /login {
            limit_req  zone=reqs burst=5 nodelay;
            limit_conn perip 10;
        }
    }
}

Application layer

Inside Express, combine helmet, tight body limits, rate limiting, slow-down, and timeouts so one expensive endpoint can't be weaponised:

const helmet = require('helmet');
const rateLimit = require('express-rate-limit');

app.use(helmet());
app.use(express.json({ limit: '100kb' }));           // reject oversized bodies
app.use(express.urlencoded({ extended: true, limit: '100kb' }));
app.use('/api/', rateLimit({ windowMs: 15 * 60 * 1000, max: 100 }));

// Bound expensive operations so they can't pile up
app.get('/search', (req, res) => {
    const timer = setTimeout(() => res.status(503).send('Search timed out'), 5000);
    performSearch(req.query)
        .then((r) => { clearTimeout(timer); res.json(r); })
        .catch(() => { clearTimeout(timer); res.status(500).send('Search error'); });
});

Monitoring & Response

Prevention is never perfect, so you also need to see attacks and have a plan ready. You can't detect an anomaly without first knowing your normal baseline.

What to monitor

• Request rate per endpoint and per client
• Resource use — CPU, memory, network, database load
• Error rates — a spike in 4xx/5xx often precedes an outage
• Geographic and fingerprint anomalies — sudden traffic from unusual sources

An incident response plan

Emergency mitigations you can pre-build: temporary IP/geo blocks, tighter rate limits, feature degradation (turn off expensive endpoints), circuit breakers, and a CDN "under attack" mode. Wiring load-adaptive limits ahead of time means the response is a config flip, not a scramble:

const os = require('os');

// Tighten limits automatically as server load climbs
function currentMax() {
    const loadPerCpu = os.loadavg()[0] / os.cpus().length;
    if (loadPerCpu > 0.85) return 20;   // aggressive
    if (loadPerCpu > 0.70) return 50;   // moderate
    return 100;                         // normal
}

app.use((req, res, next) => {
    rateLimit({ windowMs: 60 * 1000, max: currentMax() })(req, res, next);
});

Practice & Quiz

const rateLimit = require('express-rate-limit');

const globalLimiter = rateLimit({
    windowMs: 60 * 1000, max: 100,
    standardHeaders: true, legacyHeaders: false,
    message: 'Too many requests, slow down.'
});
app.use(globalLimiter);

const loginLimiter = rateLimit({
    windowMs: 60 * 60 * 1000, max: 5,
    standardHeaders: true, legacyHeaders: false,
    message: 'Too many login attempts, try again in an hour.'
});
app.post('/login', loginLimiter, handleLogin);

const limiter = rateLimit({
    windowMs: 15 * 60 * 1000,
    max: 100,
    keyGenerator: (req) => req.user?.id ?? req.ip
});
// Fairer because many users can share one IP (NAT/proxy), so keying on
// the user id avoids penalising everyone behind a shared address.

Best Practices & Pitfalls

✅ Do

• Set tighter limits on sensitive routes (login, password reset, search)
• Return 429 with Retry-After and rate-limit headers so clients can back off
• Use a shared store (Redis) once you run more than one instance
• Prefer progressive throttling (slow-down) over hard cutoffs where possible
• Put a CDN/WAF in front for volumetric attacks; layer your defenses
• Know your baseline, monitor for anomalies, and rehearse your response plan

❌ Don't

• Rely on IP-only limits — they punish shared networks and miss distributed attacks
• Keep counters in memory across multiple instances (each undercounts)
• Forget body-size limits and timeouts — cheap, high-value DoS mitigations
• Treat rate limiting alone as full DDoS protection
• Wait until an attack to design your response — build it in advance

Summary

📚 Additional Resources

• express-rate-limit — official docs
• rate-limiter-flexible — Redis-backed limiting
• OWASP — blocking brute-force attacks
• Cloudflare — what is a DDoS attack?
• MDN — 429 Too Many Requests

🚀 What's Next?

You've now covered the whole security toolkit for Week 9 — vulnerabilities, CORS and CSP, and availability. Time to put it all together: the next lesson is a capstone where you build a secure authentication system with multiple strategies, applying hashing, sessions, rate limiting, and secure headers in one real project.