DEV Community: Bhavy Yadav

Fixed Window, Leaky Bucket, Sliding Window: I Used All Three in a Production WAF. Here's Where Each One Broke.

Bhavy Yadav — Tue, 02 Jun 2026 15:56:42 +0000

I was scrolling through access logs at 2 AM — not because an alert fired, but because something about the traffic shape I'd glanced at before bed felt wrong. The WAF was running. All counters looked healthy. Then I filtered by endpoint, and the login route told a different story: 4,300 credential stuffing attempts in the past hour, spread across 58 source IPs, every single one of them under my per-IP fixed window threshold. The attack had been running for hours. My rate limiter had never once fired.

That was the night I stopped thinking about rate limiting as a solved problem.

I built this WAF from scratch — started with NGINX and ModSecurity as the backbone, then migrated the core request pipeline to Go when the rule evaluation latency from ModSecurity became unacceptable. At peak, the system handles around 8,000 requests per second across the sites it protects. Not hyperscale, but enough that naive algorithm choices will hurt you in very specific and instructive ways.

I've run fixed window, sliding window, and leaky bucket in production. Each one failed differently. None of them failed the way I expected from reading about them.

Rate Limiting Is Not the Problem It Looks Like

The interview version: "Increment a counter. If it exceeds N, return 429." Two Redis calls. Done.

The production version: your WAF runs on multiple nodes behind a load balancer. Rate limit state is either local — in which case your effective limit per identity is N × node_count, and an attacker who hits all nodes gets 3x or 5x the throttle you intended — or it's centralized in Redis, in which case you've just made Redis a mandatory dependency on every single request. Under active attack, when you need rate limiting most, Redis is also under the highest load it will ever see.

The latency constraint bites immediately. My self-imposed budget for the entire WAF pipeline — IP reputation check, rate limit, header inspection, rule engine — was 5ms added latency. Redis round trips run 0.4-0.8ms under normal load. Under attack, with key contention, I've seen them hit 6ms on their own. The rate limiter alone can blow the entire latency budget the moment traffic spikes.

Then there's the false positive problem, which nobody talks about enough because it's not exciting. A false positive in a WAF doesn't generate a security incident. It generates a legitimate user getting a 429 they don't understand, giving up, and not coming back. False negatives get you breached. False positives just quietly erode whatever you're protecting. You will have both, and the people who care about each one have zero overlap.

That's the context. Now here's what actually broke.

Fixed Window: Fast, Debuggable, and Exploitable by Anyone Who Can Read a Clock

I started with fixed window because the implementation is essentially free:

func (fw *FixedWindowLimiter) Allow(ctx context.Context, key string, limit int64, window time.Duration) (bool, error) {
    windowSize := int64(window.Seconds())
    bucketKey := fmt.Sprintf("%s:%d", key, time.Now().Unix()/windowSize)

    pipe := fw.redis.Pipeline()
    incr := pipe.Incr(ctx, bucketKey)
    pipe.Expire(ctx, bucketKey, window+time.Second)
    if _, err := pipe.Exec(ctx); err != nil {
        return true, err // fail open — debatable, but my threat model allowed it
    }

    return incr.Val() <= limit, nil
}

Two pipelined Redis calls. O(1) storage per identity per window. The counter is a plain integer — you can inspect it with redis-cli GET at any time without understanding anything about the system. I liked how debuggable it was.

The problem is the boundary. A fixed window resets on a schedule — top of the minute, top of the hour, whatever you pick. That reset time is observable. Any attacker watching X-RateLimit-Reset headers knows exactly when it happens.

Here's the 58-IP attack that ran through my WAF undetected:

Window: 60 seconds
Limit:  100 req/min per IP

T=58.2s  →  35 requests from IP A  (window 1 total: 35)
T=59.1s  →  65 requests from IP A  (window 1 total: 100) ← at limit
             ────────── WINDOW RESETS ──────────
T=60.0s  →  80 requests from IP A  (window 2 total: 80)  ← fresh counter
T=60.4s  →  20 requests from IP A  (window 2 total: 100) ← at limit again

200 requests in 2.2 seconds.
Intended limit: 100 per 60 seconds.

Each window looks correct in isolation. 100 in window 1, 100 in window 2. My monitoring was alerting on sustained violations — counters that stayed pegged at the limit across multiple consecutive windows. This attack never triggered that alert because each window had a gap. The burst was entirely invisible.

Across 58 IPs all doing the same thing, that's 11,600 credential stuffing attempts in a 2-second window. The backend database handled 200 bcrypt comparisons that second. That's what woke it up in the logs.

I added a parallel 5-second burst counter after this. <your_ip>:burst:<epoch/5>. It fires a separate alert if any IP exceeds 30 requests in a 5-second window, regardless of what the per-minute window says. The fix was not replacing fixed window — it was accepting that fixed window alone is incomplete and adding what it's missing.

Fixed window is fine for coarse limits where boundary bursts don't create exploitable gaps: ingress byte caps, background job throttling, anything where 2x the intended rate for 2 seconds doesn't matter. On an authentication endpoint, it's the wrong tool.

Sliding Window: The Right Algorithm With a Memory Problem I Should Have Calculated First

After the fixed window incident, I switched login and payment endpoints to sliding window log. Store every request timestamp in a Redis sorted set, prune entries older than the window on each check, count what's left.

func (sw *SlidingWindowLog) Allow(ctx context.Context, key string, limit int64, window time.Duration) (bool, error) {
    now := time.Now()
    cutoff := strconv.FormatInt(now.Add(-window).UnixMicro(), 10)
    nowScore := float64(now.UnixMicro())

    pipe := sw.redis.Pipeline()
    pipe.ZRemRangeByScore(ctx, key, "0", cutoff)
    count := pipe.ZCard(ctx, key)
    pipe.ZAdd(ctx, key, redis.Z{Score: nowScore, Member: now.UnixNano()})
    pipe.Expire(ctx, key, window+time.Second)

    if _, err := pipe.Exec(ctx); err != nil {
        return true, err
    }
    return count.Val() < limit, nil
}

No boundary exploits. Accurate count at any point in time. I felt good about this.

Then a scrapers' botnet hit one of the news sites I was protecting, and I did the memory math I should have done before deploying:

Active unique IPs during the attack: ~180,000
Max timestamps stored per IP:        600  (the req/min limit)
Redis sorted set overhead per entry: ~128 bytes

180,000 × 600 × 128 bytes = ~13.8 GB

My Redis instance had 4GB. At around 60% capacity Redis started making eviction decisions I had not planned for. When a rate limit key gets evicted, the counter resets. An attacker whose key gets evicted effectively gets a clean slate. The scraper was generating enough distinct source IPs that key eviction was happening continuously — their effective rate limit was functionally nonexistent during peak attack traffic, which was the exact moment I most needed it to work.

ZREMRANGEBYSCORE + ZCARD + ZADD is also three operations per request, versus one INCR for fixed window. Under attack, three operations per request across hundreds of thousands of concurrent IPs is a non-trivial Redis throughput multiplier.

The version I ended up running is the sliding window counter — an approximation that uses two adjacent fixed window buckets:

func (sw *SlidingWindowCounter) Allow(ctx context.Context, key string, limit int64, window time.Duration) (bool, error) {
    windowSecs := int64(window.Seconds())
    now := time.Now().Unix()
    currentSlot := now / windowSecs
    prevSlot := currentSlot - 1

    // How far through the current window are we? 0.0 at start, 1.0 at end
    position := float64(now%windowSecs) / float64(windowSecs)

    currentKey := fmt.Sprintf("%s:%d", key, currentSlot)
    prevKey := fmt.Sprintf("%s:%d", key, prevSlot)

    pipe := sw.redis.Pipeline()
    getCurrent := pipe.Get(ctx, currentKey)
    getPrev := pipe.Get(ctx, prevKey)
    pipe.Exec(ctx)

    current, _ := getCurrent.Int64()
    prev, _ := getPrev.Int64()

    // Weight the previous window based on how much of it falls in our sliding window
    weighted := float64(prev)*(1.0-position) + float64(current)
    if weighted >= float64(limit) {
        return false, nil
    }

    pipe2 := sw.redis.Pipeline()
    pipe2.Incr(ctx, currentKey)
    pipe2.Expire(ctx, currentKey, window*2)
    _, err := pipe2.Exec(ctx)
    return err == nil, err
}

Two integer keys per identity, regardless of traffic volume. Error rate is around 0.4% at window boundaries — there's a small zone where the interpolation overestimates or underestimates the true count. For a security rate limiter, I accepted that tradeoff. For something financial, you probably can't.

The sliding window log is the right algorithm when you have a small number of identities and need exact counts. If you're running it on raw source IPs during any kind of bot traffic, do the memory math before you deploy it.

Leaky Bucket: Where I Blocked Legitimate Users and Didn't Immediately Know Why

Before I rewrote the WAF in Go, I was running NGINX with ngx_limit_req. NGINX's rate limiting is leaky bucket. I didn't choose it — it was the only option the module gave me.

Leaky bucket models a queue with a drain rate. Traffic enters at any rate, leaves at a constant rate. If the queue fills, excess is either delayed or dropped. For protecting a fragile backend from traffic spikes, it genuinely works well.

The failure case is what legitimate traffic looks like.

One of the sites I was protecting had a mobile app with decent usage — maybe 30,000 active users. Mobile users lose connectivity constantly. Subway, elevator, spotty 4G in a rural area. When they reconnect, the app retries whatever it was trying to send. If they lost connectivity for 30 seconds while the app was making periodic API calls, reconnection triggers three or four requests in under a second.

From the leaky bucket's perspective: burst of 4 requests with 200ms spacing from an IP that was quiet for 30 seconds. No burst credit for the quiet period. If the queue is already at capacity from other traffic, these 4 requests get dropped.

The users weren't sending error reports because the app silently retried. I noticed it because app engagement metrics were lower than expected for certain times of day — specifically peak commute hours, when users were moving in and out of underground transit. The "drop rate" I was seeing was legitimate mobile reconnects getting shed by the queue.

Leaky bucket optimizes for smooth output at the cost of bursty-but-legitimate input. It doesn't model how real users behave — people don't make API calls at a metronomic rate. A well-tuned attacker running a slow crawl has smoother traffic than a real mobile user. The algorithm punishes the user and rewards the patient attacker.

I kept NGINX's ngx_limit_req for one specific purpose: coarse traffic shaping before requests reach the Go process. A 2,000 req/s per-IP hard cap with a generous burst parameter (burst=500, nodelay). This protects the Go process from single-source floods without doing any policy enforcement. The policy — who actually gets blocked and why — lives in the Go middleware with sliding window counter.

Searching for the Best Algorithm Is the Wrong Question

Every few months I see a blog post that compares these algorithms and concludes one of them is best. The conclusion is always wrong, because the algorithm that's right depends on what you're trying to stop, at what traffic volume, with what latency budget, and what your false positive tolerance is.

Credential stuffing is patient and distributed. Attackers stay well under per-IP limits intentionally. No single-identity rate limiter catches it — you need cross-IP correlation, behavioral signals, per-endpoint limits that make even sub-limit sustained attempts expensive. A leaky bucket set up to smooth traffic does nothing against this.

A volumetric DDoS doesn't care about your per-minute limits. You need to shed traffic at the kernel level before it touches application code. eBPF at the XDP hook drops packets at line rate before the TCP stack processes them. Sliding window counter accuracy is irrelevant here — you need throughput, not precision.

API abuse from residential proxies — a competitor scraping your pricing, a research firm harvesting your public data — operates at a few requests per minute per IP. Per-identity rate limiting sees nothing. You need aggregate behavior analysis: same user-agent across thousands of IPs, consistent URL patterns, request timing that's too regular to be human.

Algorithm	Boundary Safety	Memory	Redis Ops/req	Best use	Breaks on
Fixed Window	✗ exploitable	O(1)	1	Coarse ingress caps	Auth/payment endpoints
Sliding Window Log	✓ exact	O(limit × IDs)	3	Low-volume sensitive endpoints	Bot traffic with many IPs
Sliding Window Counter	✓ ~99.6%	O(IDs)	2 + 2	General API rate limiting	Hard financial accuracy
Leaky Bucket	N/A (shaping)	O(queue)	N/A	Backend protection	Bursty legitimate users
Token Bucket	✓	O(IDs)	2	APIs with burst allowance	DDoS mitigation

The mistake is picking one and calling it done.

What I Actually Run

Four layers. Each one independently simple. Complexity in the composition.

┌─────────────────────────────────────────────┐
│               INTERNET                      │
└──────────────────┬──────────────────────────┘
                   │
┌──────────────────▼──────────────────────────┐
│  LAYER 1 — eBPF/XDP                         │
│  Fixed window: 10K req/s hard cap per IP    │
│  Drops at NIC before kernel TCP stack       │
│  Blocklist from Kafka consumer (30s lag)    │
└──────────────────┬──────────────────────────┘
                   │
┌──────────────────▼──────────────────────────┐
│  LAYER 2 — NGINX ngx_limit_req              │
│  Leaky bucket: 500 req/s per IP, burst=200  │
│  Traffic shaping only — no policy           │
│  Node-local state, zero Redis dependency    │
└──────────────────┬──────────────────────────┘
                   │
┌──────────────────▼──────────────────────────┐
│  LAYER 3 — Go WAF middleware                │
│  Sliding window counter (Redis-backed)      │
│  Per-IP + per-session + per-API-key         │
│  Auth endpoints: 5 req/min, no exceptions   │
│  In-process cache for hot keys, 100ms sync  │
└──────────────────┬──────────────────────────┘
                   │
┌──────────────────▼──────────────────────────┐
│  LAYER 4 — Kafka telemetry (off hot path)   │
│  Every decision emitted as event            │
│  Consumer correlates across IPs/sessions    │
│  Pushes back to Layer 1 blocklist           │
└─────────────────────────────────────────────┘

Layer 1 handles volumetric attacks. eBPF at XDP processes packets before the kernel network stack — a tight fixed window at 10,000 req/s per IP, which no legitimate source ever hits, implemented as a BPF hash map. Packets matching the blocklist or exceeding the cap get XDP_DROP returned before a single socket buffer is allocated. The performance difference versus application-layer dropping is significant: XDP runs at ~2M pps on modest hardware; getting the same traffic to the Go process would saturate it.

Layer 2 is NGINX doing traffic shaping. I'm not trying to make policy decisions here — just preventing a single source from landing 8,000 req/s on the Go process. The burst parameter is generous (200) specifically because I burned legitimate mobile users with a tight leaky bucket before. NGINX handles this without touching Redis.

Layer 3 is where rate limit policy actually happens. Sliding window counter in Go, Redis-backed. Every identity type gets its own key namespace: rl:ip:, rl:user:, rl:session:, rl:apikey:. Different limits per endpoint class — a public API endpoint gets 600 req/min, a login endpoint gets 5 req/min with no burst, a password reset endpoint gets 3 per hour per user. The tiering exists because "rate limiting" is not one policy, it's many policies layered on the same infrastructure.

One practical problem: some API keys are legitimate high-volume clients generating thousands of requests per minute. All their requests map to the same Redis key. At volume, that single key can saturate the Redis CPU for its shard — Redis is single-threaded per core per shard, and a hot key is a ceiling you'll hit before memory becomes an issue. My fix was local counter caching in the Go process: maintain an in-memory counter, sync to Redis every 100ms. This reduces Redis ops by roughly 50-100x for hot keys. The accuracy cost is ±100ms on the limit enforcement, which is acceptable for API key throttling and completely unacceptable for authentication endpoints where I need exact counts.

Layer 4 is Kafka. Every rate limit decision — allowed, warned, blocked — gets emitted as a structured event asynchronously. It does not touch the request path. A Go consumer reads the stream and looks for patterns individual layers can't see: IPs clustering near the limit without hitting it (scanning), identical user-agents across thousands of distinct source IPs (coordinated botnet), session tokens that seem to travel geographically faster than physics allows. When confidence is high enough, it pushes the offending identities to a Redis set that Layer 1 reads every 30 seconds and translates into XDP blocklist entries.

The 30-second lag between detection and enforcement is real and intentional. I'd rather have 30 seconds of exposure with high-confidence blocks than 0 seconds of exposure with an aggressive heuristic that starts blocking legitimate traffic. The eBPF layer catches volumetric attacks immediately. The Kafka consumer catches the slow, distributed, low-signal attacks. They cover different threat models.

This architecture evolved over about a year and a half of the WAF running against real traffic. It was not designed this way. I started with just fixed window in Go, added sliding window counter after the credential stuffing incident, added the eBPF layer after a volumetric attack saturated the Go process, added Kafka telemetry after noticing slow distributed scraping that none of the per-identity limiters caught.

Each layer was added reactively, after something broke. I'd design it this way from the start now, but I wouldn't have known to without having run the earlier, simpler versions until they failed.

What to Actually Build and When

If you're starting from zero: sliding window counter in Redis, applied to authentication endpoints with a tight limit and everything else with a loose one. Do not start with leaky bucket unless traffic shaping is your actual goal. Do not start with fixed window on anything where a boundary burst creates a security gap. The sliding window counter implementation above is around 50 lines of Go and handles most cases correctly.

When Redis starts hurting: the signal is rate limit check latency climbing at p99, or Redis CPU staying above 60% under normal load. Before redesigning, add local counter caching with Redis sync. Cheap to implement, handles hot key scenarios, keeps the rest of the architecture unchanged. This buys significant headroom.

On eBPF: don't reach for XDP until you have a clear volumetric problem and you're comfortable debugging kernel-space code. An eBPF bug that passes the verifier but has a logic error can do things you cannot recover from without a reboot. The performance gain is real — moving packet drops from the Go process to the NIC makes a measurable difference once you're getting hit with hundreds of thousands of packets per second. The operational cost is also real.

On authentication endpoints: they deserve their own rate limit config, separate from everything else, with limits 10x tighter than your general API. A 600 req/min API limit that you accidentally apply to your login endpoint lets an attacker run 36,000 credential stuffing attempts per hour per IP. Five requests per minute on login makes credential stuffing economically unviable. Three requests per minute is better. The number of legitimate users who need to attempt login more than 5 times per minute is zero.

On 429 responses: they need a Retry-After header, a request ID the user can reference, and a message that doesn't say "rate limit exceeded" to an end user who has no idea what that means. This sounds like product work and not worth engineering time. It is worth engineering time. Unexplained 429s generate support tickets that take longer to resolve than writing the Retry-After header would have taken.

What Still Breaks

The hybrid setup catches the attacks it's been designed to catch. It does not catch everything.

Six months ago, an actor was rotating API session tokens every 300-400 requests — specifically tuned to stay under per-session limits while exceeding the per-endpoint total rate I actually cared about. The rotation was fast enough that no individual token triggered a block. The Kafka consumer eventually flagged the pattern: thousands of short-lived tokens all following the same URL sequence, all from the same three ASNs. By the time the block deployed, the actor had been running for 11 days.

The lesson from that isn't "build a better heuristic." It's that any fixed rule set has a bypass if the attacker has enough signal about your rules. The adaptive detection layer — Kafka consumer plus behavioral analysis — is the part that closes unknown-unknown attack patterns. It needs to be running before you need it.

Rate limiting is not a problem you solve. It's a system you tune against an adversary who is also tuning against you. Every algorithm I've described has a bypass. The goal is making the bypass expensive enough that the attacker moves on.

Backend engineer. Go, security infrastructure, distributed systems. WAF project on GitHub: bhavyyadav25. Portfolio: bhavyyadav25.github.io. Email: yadavbhavy25@gmail.com

What Happens in 2 Milliseconds: Anatomy of a Single HTTP Request Through a Production WAF

Bhavy Yadav — Sun, 31 May 2026 00:14:29 +0000

The rule engine is not the hard part. Everyone builds a rule engine. The hard part is deciding what order the checks run in — because the difference between a hash map lookup and a regex match is two orders of magnitude, and you're doing this on every single request.

Six-stage pipeline. Production. 50+ client websites, 100K+ daily requests. I'll trace one request through all of it.

http
POST /api/login HTTP/1.1
Host: client-website.com
User-Agent: python-requests/2.28.0
Content-Type: application/json
X-Forwarded-For: 185.220.101.45
{"username":"admin' OR '1'='1' --","password":"anything"}

Four problems: Tor exit node IP, automation library User-Agent, no Accept header, SQL injection payload. It gets blocked at stage 4. But all six stages matter.

The Pipeline

func (waf *WAF) Handle(next http.Handler) http.Handler {
    return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        ctx := &RequestContext{
            IP:    extractIP(r),
            Start: time.Now(),
        }

        // Stage 1: IP reputation — cheapest check, runs first
        ipScore := waf.reputation.Score(ctx.IP)
        ctx.Score += ipScore
        if ctx.Score >= 100 {
            waf.block(w, r, ctx, Decision{Code: 403, Reason: "blocklist"})
            return
        }

        // Stage 2: Rate limiting
        if allowed := waf.limiter.Allow(ctx.IP); !allowed {
            ctx.Score += 25
            ctx.RateLimited = true
        }

        // Stage 3: Header inspection
        headerScore, hardBlock := waf.inspectHeaders(r)
        ctx.Score += headerScore
        if hardBlock != "" {
            waf.block(w, r, ctx, Decision{Code: 400, Reason: hardBlock})
            return
        }

        // Stage 4: Rule engine — most expensive, runs last
        body, _ := io.ReadAll(r.Body)
        r.Body = io.NopCloser(bytes.NewReader(body))
        ctx.Matches = waf.rules.Evaluate(r, body)

        // Stage 5: Decision
        if d := waf.decide(ctx); d.Block {
            waf.block(w, r, ctx, d)
            return
        }

        next.ServeHTTP(w, r)
    })
}

Cheap checks first, expensive last. If IP reputation kills the request, the rule engine never runs. At 100K req/day that ordering shows up measurably in CPU.

Stage 1: IP Reputation [0ms → 0.2ms]

Three data structures, all in memory, all O(1):

Hard blocklist — permanently banned IPs. Hash map, no expiry.
Tor exit nodes — refreshed every 15 minutes via Onionoo. ~1,500 active exit IPs at any given time.
Threat score map — IPs we've observed before, with accumulated scores that decay over time.

type IPReputation struct {
    mu        sync.RWMutex
    blocklist  map[string]struct{}
    torExits   map[string]struct{}
    cidrs      []*net.IPNet // datacenter/hosting ranges
    scores     map[string]scoredIP
}

type scoredIP struct {
    score    int
    lastSeen time.Time
}

func (ipr *IPReputation) Score(ip string) int {
    ipr.mu.RLock()
    defer ipr.mu.RUnlock()

    if _, ok := ipr.blocklist[ip]; ok {
        return 100
    }
    if _, ok := ipr.torExits[ip]; ok {
        return 70
    }

    parsed := net.ParseIP(ip)
    for _, cidr := range ipr.cidrs {
        if cidr.Contains(parsed) {
            return 55 // datacenter origin — not necessarily malicious, but not a browser
        }
    }

    if entry, ok := ipr.scores[ip]; ok {
        days := time.Since(entry.lastSeen).Hours() / 24
        // Score halves every 24h
        return int(float64(entry.score) * math.Pow(0.5, days))
    }

    return 0
}

Score decays at a 24-hour half-life. IPs rotate. Cloud provider ranges get reassigned. Treating a month-old signal the same as a current one tanks precision — false positives climb until the system is more noise than signal.

We should have used MaxMind GeoLite from day one instead of maintaining a CIDR list manually. We added hosting ranges reactively — after seeing attacks rather than before — and missed several in the first few months. Proper ASN lookups would have caught those automatically. That gap cost us a few weeks of noisier detection early on.

The scores map has an unbounded growth problem. A background goroutine evicts entries with decayed scores below 5, running every hour. In production the map stabilized around 40-50k entries.

185.220.101.45 matches the Tor exit list. Score: 70. Continue.

Stage 2: Rate Limiter [0.2ms → 0.5ms]

Sliding window, not fixed. Fixed windows have a boundary exploit: 59 requests at :59, 59 more at :00 — 118 requests through a 60-request limit. The sliding window always covers the last N seconds. There's no boundary to game.

type SlidingWindow struct {
    mu      sync.Mutex
    entries map[string]*ipWindow
    limit   int
    window  time.Duration
}

type ipWindow struct {
    timestamps []int64 // nanoseconds — 8 bytes vs 24 for time.Time
}

func (sw *SlidingWindow) Allow(ip string) bool {
    sw.mu.Lock()
    defer sw.mu.Unlock()

    now := time.Now().UnixNano()
    cutoff := now - sw.window.Nanoseconds()

    w := sw.entries[ip]
    if w == nil {
        w = &ipWindow{}
        sw.entries[ip] = w
    }

    // Prune in-place — avoids allocating a new slice on every call
    n := 0
    for _, t := range w.timestamps {
        if t > cutoff {
            w.timestamps[n] = t
            n++
        }
    }
    w.timestamps = w.timestamps[:n]

    if len(w.timestamps) >= sw.limit {
        return false
    }

    w.timestamps = append(w.timestamps, now)
    return true
}

Threshold: 60 requests per 10-second window. This attacker sent 847.

Rate limit alone doesn't block. +25 to score, continue. A misconfigured load balancer looks identical to a rate violation — same IP, high request count. The system needs the full picture before making a hard call. Rate limit plus anything else usually crosses the block threshold.

Score: 70 + 25 = 95. Continue.

Stage 3: Header Inspection [0.5ms → 0.8ms]

Real browsers are consistent. They send Accept, Accept-Language, Accept-Encoding. Their User-Agent follows recognizable patterns. Automation libraries don't replicate this — not because attackers are careless, but because python-requests, httpx, go-http-client don't send browser headers by default, and most attackers don't bother faking them.

var automationSignatures = []string{
    "python-requests", "python-urllib", "go-http-client",
    "libwww-perl", "java/", "curl/", "wget/",
    "sqlmap", "nikto", "masscan", "zgrab", "scrapy",
    "aiohttp", "httpx", "mechanize",
}

func (waf *WAF) inspectHeaders(r *http.Request) (score int, hardBlock string) {
    ua := r.Header.Get("User-Agent")
    if ua == "" {
        return 40, ""
    }

    uaLow := strings.ToLower(ua)
    for _, sig := range automationSignatures {
        if strings.Contains(uaLow, sig) {
            score += 30
            break
        }
    }

    if r.Header.Get("Accept") == "" {
        score += 15
    }

    // POST from a browser almost always carries a Referer
    if r.Method == http.MethodPost && r.Header.Get("Referer") == "" {
        score += 10
    }

    // Header injection is a hard block regardless of score
    for _, values := range r.Header {
        for _, v := range values {
            if strings.ContainsAny(v, "\r\n") {
                return 0, "header injection"
            }
        }
    }

    return score, ""
}

Header injection is the only hard block at this stage. \r\n in a header value is never legitimate — it can split HTTP responses and poison downstream caches. Everything else is scored and accumulated.

We evaluated TLS fingerprinting (JA3) — comparing cipher suite and extension order from the TLS handshake, which browsers expose consistently and scripts don't. Decided against it. It requires TLS termination at the WAF layer or integration with nginx's ssl_fingerprint module, and it's brittle across library versions. The coupling cost wasn't worth it at our traffic volume. Worth revisiting at scale.

python-requests/2.28.0: +30. No Accept: +15. No Referer on POST: +10. Score: 95 + 55 = 100 (capped). Continue.

Stage 4: Rule Engine [0.8ms → 1.5ms]

Most expensive stage. Runs last.

Pre-compile at startup. regexp.MustCompile is not free. Calling it per request at 100K req/day is burning CPU for no reason. All patterns compile once on server start, stored as *regexp.Regexp struct fields, reused across every request.

Normalize before matching. Attackers don't send raw OR '1'='1'. They URL-encode it, double-encode it, or split it across fields. A rule engine that only looks at the raw payload misses most real attacks.

func normalize(input []byte) []byte {
    // First pass
    s, err := url.QueryUnescape(string(input))
    if err != nil {
        s = string(input)
    }
    // Second pass — catches double-encoding
    s2, err := url.QueryUnescape(s)
    if err != nil {
        s2 = s
    }
    return []byte(strings.ToLower(s2))
}

Then the rules:

type Rule struct {
    ID       string
    Pattern  *regexp.Regexp
    Severity int    // 1–4; severity 4 = block unconditionally regardless of score
    Target   Target // Body, URL, or both
}

// Compiled at init() — never at request time
var coreRules = []*Rule{
    {
        ID:       "SQLI-001",
        Pattern:  regexp.MustCompile(`\bor\b\s+['"]?\w+['"]?\s*=\s*['"]?\w+['"]?`),
        Severity: 4,
        Target:   TargetBody,
    },
    {
        ID:       "SQLI-002",
        Pattern:  regexp.MustCompile(`(--|#|/\*)`),
        Severity: 3,
        Target:   TargetBody,
    },
    {
        ID:       "SQLI-003",
        Pattern:  regexp.MustCompile(`\bunion\b.{0,30}\bselect\b`),
        Severity: 4,
        Target:   TargetBody | TargetURL,
    },
    {
        ID:       "XSS-001",
        Pattern:  regexp.MustCompile(`<script[\s/>]|javascript\s*:`),
        Severity: 4,
        Target:   TargetBody | TargetURL,
    },
    {
        ID:       "PATH-001",
        Pattern:  regexp.MustCompile(`(\.\.[\\/]){2,}`),
        Severity: 3,
        Target:   TargetURL,
    },
    {
        ID:       "CMD-001",
        Pattern:  regexp.MustCompile(`[;|&]\s*(cat|ls|whoami|id|wget|curl)\b`),
        Severity: 4,
        Target:   TargetBody | TargetURL,
    },
}

func (e *RuleEngine) Evaluate(r *http.Request, body []byte) []*Match {
    normBody := normalize(body)
    normURL := normalize([]byte(r.URL.RawQuery + r.URL.Path))

    var matches []*Match
    for _, rule := range e.rules {
        var target []byte
        if rule.Target&TargetBody != 0 {
            target = normBody
        } else {
            target = normURL
        }
        if loc := rule.Pattern.Find(target); loc != nil {
            matches = append(matches, &Match{Rule: rule, At: loc})
        }
    }
    return matches
}

After normalization, the body reads as: {"username":"admin' or '1'='1' --","password":"anything"}.

SQLI-001 fires on or '1'='1'. SQLI-002 fires on --. Two matches. SQLI-001 is severity 4. Score is irrelevant — block unconditionally.

Stage 5: Decision [1.5ms → 1.8ms]

Thin layer. Accumulated context in, decision out. Complexity here is where subtle edge cases live and where probing exploits get found.

func (waf *WAF) decide(ctx *RequestContext) Decision {
    // Severity-4 match: score doesn't matter
    for _, m := range ctx.Matches {
        if m.Rule.Severity == 4 {
            return Decision{Block: true, Code: 403, Reason: m.Rule.ID}
        }
    }

    // High score + any rule match: block
    if ctx.Score >= 80 && len(ctx.Matches) > 0 {
        return Decision{Block: true, Code: 403, Reason: "score+rules"}
    }

    // Rate limited, no rule match: 429, not 403
    if ctx.RateLimited && len(ctx.Matches) == 0 {
        return Decision{Block: true, Code: 429, Reason: "rate-limit"}
    }

    return Decision{Block: false}
}

The 403 vs 429 distinction is operational. Repeated 429s from the same IP often turn out to be misconfigured clients or internal tooling; 403s with rule matches are almost always actual attacks. The alerting pipeline treats them differently, which matters at 2am when you're deciding whether to page someone.

Verdict: Block, 403, SQLI-001.

Stage 6: Logging [1.8ms → 2ms]

Response goes out before logging. Logging is I/O. I/O is slow. Those two facts mean the log write cannot touch the response path.

type WAF struct {
    logCh chan IncidentLog // buffered
}

func NewWAF(cfg Config) *WAF {
    w := &WAF{
        logCh: make(chan IncidentLog, 4096),
    }
    go w.logWorker()
    return w
}

func (waf *WAF) logWorker() {
    for entry := range waf.logCh {
        waf.sink.Write(entry) // JSON to disk + forward to alert pipeline
    }
}

func (waf *WAF) block(w http.ResponseWriter, r *http.Request, ctx *RequestContext, d Decision) {
    // Response first
    w.Header().Set("Content-Type", "application/json")
    w.WriteHeader(d.Code)
    w.Write([]byte(`{"error":"Forbidden"}`))

    // Log asynchronously — non-blocking send
    select {
    case waf.logCh <- IncidentLog{
        Timestamp:   time.Now().UTC(),
        IP:          ctx.IP,
        Method:      r.Method,
        Path:        r.URL.Path,
        Score:       ctx.Score,
        Matches:     ctx.Matches,
        RateLimited: ctx.RateLimited,
        Decision:    d,
        LatencyMs:   float64(time.Since(ctx.Start).Microseconds()) / 1000,
    }:
    default:
        // Channel full — drop the entry, track the drop count separately
        waf.metrics.LogDropped.Inc()
    }

    go waf.reputation.Increment(ctx.IP, 20)
}

The select with default is intentional. If the log channel fills — writer goroutine falling behind, usually disk I/O saturation during a large attack — drop the log entry rather than stall HTTP responses. Track the drop counter as a separate metric and alert on it. In 8 months of production this happened once, during a coordinated multi-client attack that was also saturating the disk writer. Logging should never affect response latency, even under that load.

The attacker gets:

HTTP/1.1 403 Forbidden
Content-Type: application/json
{"error":"Forbidden"}

No indication of which rule fired. Nothing actionable. The less information a 403 carries, the harder the system is to probe.

Production Numbers

At peak (~180 req/s across all clients), the WAF added a median 0.8ms latency to allowed requests. p99: 3.2ms. Blocked requests averaged 1.9ms — they exit earlier in the pipeline. Memory at steady state: ~90MB for the reputation map, rate limiter state, and rule engine combined.

Over 8 months: 25% reduction in breach incidents across client websites, 35% faster detection from attack onset to alert. The detection improvement came almost entirely from centralized structured logging — correlating patterns across 50+ clients simultaneously instead of treating each site's logs as a separate silo.

Two things I'd rebuild differently. First: MaxMind GeoLite for ASN-level blocking from the start. Maintaining a CIDR list manually is reactive by nature and you're always a step behind. Second: weight rule matches by position in the payload. A pattern found deep inside a multi-part encoded body is more likely to be deliberate evasion than one sitting in a raw field — that distinction should influence severity scoring, and currently it doesn't.

Want more deep-dive backend stories?
I regularly write about:

Go internals and performance
backend system design
building open-source tools
real-world optimization stories
Check out my personal site: https://bhavyyadav25.github.io

You can also find me on:

GitHub: https://github.com/Bhavyyadav25
LinkedIn: https://linkedin.com/in/yadavbhavy

Backend engineer. Go, distributed systems, security infrastructure.