DEV Community: Aniket Bhatia

Rate Limiting: The Sliding Window Approach

Aniket Bhatia — Sun, 09 Aug 2026 11:51:01 +0000

Every web application faces a fundamental challenge: how do you let legitimate users interact freely while preventing abuse? Without rate limiting, your endpoints are open to brute force attacks, denial-of-service flooding, scraping bots, and resource exhaustion that drives up infrastructure costs.

Rate limiting is the gatekeeper. Here's how to build one that actually works.

Common approaches

1. Fixed window counter

The simplest approach. Divide time into fixed intervals (e.g., every calendar minute) and count requests in each. It's easy to implement, but it has a critical flaw: the boundary exploit.

2. Sliding log (precise but expensive)

Store the timestamp of every request. On each new request, count how many timestamps fall within the last N seconds. Perfectly accurate, but storing every timestamp is memory-intensive at scale.

3. Sliding window (best of both worlds)

Uses a sorted set to track request timestamps, continuously sliding the window forward. Old entries are pruned on every check. No boundary exploits, and memory stays bounded. This is the approach worth building.

How the sliding window works

Instead of resetting a counter at fixed intervals, maintain a sorted set where each member is a unique request ID and its score is the Unix timestamp. On every incoming request:

Prune — remove all entries older than now - window_size
Count — count remaining entries
Decide — if count ≥ limit, deny; otherwise add the new request and allow

Implementation: Redis + Lua

Redis sorted sets are ideal for this pattern. A Lua script ensures atomicity — no race conditions when multiple requests arrive simultaneously. Without atomicity, two concurrent requests could both see count=59 and both be allowed past a limit of 60.

-- Step 1: Prune expired entries from the main window
redis.call('ZREMRANGEBYSCORE', key, 0, now - window)

-- Step 2: Count remaining requests
local current = redis.call('ZCARD', key)
if current >= limit then
    return {0, current, limit}  -- DENIED
end

-- Step 3: Check burst window
redis.call('ZREMRANGEBYSCORE', burst_key, 0, now - burst_window)
local burst_current = redis.call('ZCARD', burst_key)
if burst_current >= burst_limit then
    return {-1, burst_current, burst_limit}  -- DENIED: burst
end

-- Step 4: Record the request in both windows
local member = tostring(now) .. ':' .. tostring(math.random(1000000))
redis.call('ZADD', key, now, member)
redis.call('EXPIRE', key, window + 1)
redis.call('ZADD', burst_key, now, member)
redis.call('EXPIRE', burst_key, burst_window + 1)

return {1, current + 1, limit}  -- ALLOWED

Why a random suffix on members? Sorted sets require unique members. Two requests arriving at the exact same millisecond would overwrite each other without it, causing undercounting.

Dual-layer protection

A single window limit has a blind spot: a client could exhaust all 60 requests in the first 2 seconds and go silent for 58. The average rate looks fine, but the spike hammers your server. The solution is two checks that must both pass.

Layer	Window	Limit	Prevents
Window	60 seconds	60 requests	Sustained abuse across time boundaries
Burst	5 seconds	10 requests	Rapid-fire spikes (bots hammering in 1s)

FastAPI middleware integration

The rate limiter works best as middleware — intercepting every request before it reaches application logic.

@app.middleware('http')
async def rateLimitMiddleware(request, call_next):
    # Skip bypass paths (health checks, login)
    if request.url.path in bypass_paths:
        return await call_next(request)

    # Key by user (authenticated) or IP (anonymous)
    user = get_authenticated_user(request)
    rate_key = f"ratelimit:user:{user}" if user else f"ratelimit:ip:{ip}"

    result = await redis.eval(LUA_SCRIPT, keys=[rate_key, burst_key], args=[...])

    if result[0] == 0:
        return JSONResponse({"error": "Rate limit exceeded."},
            status_code=429, headers={"Retry-After": "60"})
    if result[0] == -1:
        return JSONResponse({"error": "Too many requests. Slow down."},
            status_code=429, headers={"Retry-After": "5"})

    response = await call_next(request)
    response.headers["X-RateLimit-Remaining"] = str(limit - result[1])
    return response

Decision	Rationale
Per-user key (authenticated)	Prevents one user from affecting others
Per-IP fallback (unauthenticated)	Protects public endpoints from anonymous abuse
Fail-open on Redis errors	Avoids blocking legitimate traffic if Redis goes down
HTTP 429 + `Retry-After`	Standard; well-handled by clients and load balancers
`X-RateLimit-*` headers	Gives clients visibility into their remaining quota

Testing

A quick smoke test to verify your burst limit fires correctly:

# Send 15 rapid requests — expect 429 after the 10th
for i in $(seq 1 15); do
  STATUS=$(curl -s -o /dev/null -w "%{http_code}" \
    -H "Cookie: session=YOUR_COOKIE" https://your-app/api/me)
  echo "Request $i: HTTP $STATUS"
done

# Inspect the sorted set directly
redis-cli ZCARD ratelimit:user:alice@example.com
redis-cli ZRANGE ratelimit:user:alice@example.com 0 -1 WITHSCORES

Summary

Fixed window

Simple but vulnerable to boundary exploits. Low memory, approximate accuracy.

Sliding log

Exact accuracy, no boundary issues. High memory cost at scale.

Sliding window ✓

Exact accuracy, no boundary exploits, moderate memory. The right choice.

Rate limiting isn't just about counting requests — it's about counting them in the right window.

Mitigating HTTP Request Smuggling

Aniket Bhatia — Sun, 09 Aug 2026 11:17:04 +0000

The Problem

When malformed or abnormal HTTP requests are interpreted by one or more entities in the data flow between the user and the web server, such as a proxy or firewall, they can be interpreted inconsistently, allowing the attacker to "smuggle" a request to one device without the other device being aware of it.

HTTP Request Smuggling

HTTP Request Smuggling exploits discrepancies in how front-end (proxy/load balancer/WAF) and back-end servers parse HTTP requests, specifically around where one request ends and the next begins.

How It Works

HTTP/1.1 uses two headers to indicate body length:

Content-Length (CL): specifies body size in bytes
Transfer-Encoding (TE): uses chunked encoding

When a request contains both headers (or malformed variants), different servers may prioritize differently:

Variant	Front-end uses	Back-end uses	Result
CL.TE	Content-Length	Transfer-Encoding	Front-end forwards extra data that back-end treats as a new request
TE.CL	Transfer-Encoding	Content-Length	Back-end stops reading early; leftover bytes become the next request
TE.TE	Transfer-Encoding	Transfer-Encoding	One server is tricked by an obfuscated TE header (e.g., `Transfer-Encoding: chunked\r\n Transfer-Encoding: x`)

Example (CL.TE)

Variant	Front-end uses	Back-end uses	Result
CL.TE	Content-Length	Transfer-Encoding	Front-end forwards extra data that back-end treats as a new request
TE.CL	Transfer-Encoding	Content-Length	Back-end stops reading early; leftover bytes become the next request
TE.TE	Transfer-Encoding	Transfer-Encoding	One server is tricked by an obfuscated TE header (e.g., `Transfer-Encoding: chunked\r\n Transfer-Encoding: x`)

Example (CL.TE)

POST / HTTP/1.1
Host: example.com
Content-Length: 13
Transfer-Encoding: chunked

0\r\n
\r\n
SMUGGLED

The front-end reads 13 bytes (the full body). The back-end processes chunked encoding, sees 0 (end of chunks), and treats SMUGGLED as the start of the next request — which could be crafted to bypass access controls, poison caches, or hijack other users' requests.

Impact

Bypass security controls (WAF, authentication)
Cache poisoning — serve malicious content to other users
Session hijacking — prepend attacker-controlled headers to another user's request
Credential theft via request redirection

Mitigations & Solutions

Infrastructure level:

Use HTTP/2 end-to-end — HTTP/2 has a binary framing layer that eliminates ambiguity in request boundaries
Normalize requests at the front-end — ensure the proxy resolves ambiguous requests before forwarding
Disable connection reuse between front-end and back-end (performance trade-off but eliminates the attack surface)
Use the same web server software on all layers to ensure consistent parsing

Configuration level:

5. Reject ambiguous requests — configure proxies/servers to return 400 Bad Request when both Content-Length and Transfer-Encoding are present

6. Disable Transfer-Encoding: chunked if not needed

7. Configure WAF rules to detect and block requests with conflicting length indicators

Application level:

8. Validate incoming requests — reject requests with duplicate or conflicting Content-Length/Transfer-Encoding headers

9. Use strict HTTP parsing in your web framework (e.g., Gunicorn's --strip-header-spaces, Nginx's ignore_invalid_headers off)

10. Set timeouts on back-end connections to limit the window for smuggled requests to persist

Detection:

11. Monitor for anomalies — unusual 400/405 errors, mismatched access logs between front-end and back-end

12. Use tools like Burp Suite's HTTP Request Smuggler extension for testing

The most effective fix is upgrading to HTTP/2 between all hops and rejecting ambiguous requests at the edge.

Why Both Headers = Smuggling Risk

The HTTP/1.1 spec (RFC 7230) says: if both Transfer-Encoding and Content-Length are present, Transfer-Encoding must take priority and Content-Length must be ignored. The problem is not all servers follow this rule the same way.

The Core Issue: Disagreement on Request Boundaries

When a proxy sits in front of a backend server, both need to agree on where each request starts and ends. These two headers are the only way to determine that:

Content-Length: 50 → "the body is exactly 50 bytes"
Transfer-Encoding: chunked → "the body is split into chunks, ending with a 0\r\n chunk"

When both are present, one server might use Content-Length and the other might use Transfer-Encoding — so they see different request boundaries.

Concrete Example

POST / HTTP/1.1
Host: example.com
Content-Length: 6
Transfer-Encoding: chunked

0\r\n
\r\n
X

What the proxy sees (if it trusts Content-Length: 6):

Body = "0\r\n\r\nX" (6 bytes — one complete request, forwards everything)

What the backend sees (if it trusts Transfer-Encoding: chunked):

Chunk: "0" → end of chunks → request is done Leftover: "X" → this must be the START of a NEW request!

That X is now smuggled. The attacker controls it, and it gets prepended to the next legitimate user's request. In practice, X would be a full malicious request like:

GET /admin HTTP/1.1 Host: example.com

Why This is Dangerous

Attack	How
Bypass WAF/auth	The proxy checks the outer request (looks safe), but the backend executes the hidden inner request
Session hijacking	The smuggled fragment merges with the next user's request, so the attacker's headers (e.g., a redirect) get applied to that user
Cache poisoning	The smuggled request causes the cache to store attacker-controlled content under a legitimate URL

Why Rejecting Both Headers Fixes It

If neither server ever processes a request containing both headers (returns 400 immediately), there's no ambiguity to exploit — both sides always agree on how to parse the body length. That's exactly what the Nginx rule we added does:

# If Transfer-Encoding AND Content-Length are both present → reject
if ($smuggle_check = "TECL") {
    return 400;
}

No ambiguity = no smuggling.

Testing HTTP Request Smuggling Protection

Validate Nginx Config Syntax

sudo nginx -t

Should output: syntax is ok and test is successful. Then reload:

sudo systemctl reload nginx

Test That Ambiguous Requests Are Rejected (400)

Send a request with both headers using curl:

# This should return HTTP 400
curl -i -X POST https://your-domain.com/ \
  -H "Transfer-Encoding: chunked" \
  -H "Content-Length: 6" \
  -d "0\r\n\r\nX"

Expected: HTTP/1.1 400 Bad Request

Test with a normal request (should still work):

# Content-Length only — should return 200/normal response
curl -i -X POST https://your-domain.com/api/some-endpoint \
  -H "Content-Type: application/json" \
  -d '{"key": "value"}

## Transfer-Encoding only — should also work
curl -i -X POST https://your-domain.com/api/some-endpoint \
  -H "Transfer-Encoding: chunked" \
  -H "Content-Type: application/json" \
  -d '{"key": "value"}'

Expected: Normal responses (not 400).

Test with Python Script

import socket
import ssl

host = "your-domain.com"
port = 443

## Craft an ambiguous request with both headers
smuggle_request = (
    "POST / HTTP/1.1\r\n"
    "Host: {}\r\n"
    "Content-Length: 6\r\n"
    "Transfer-Encoding: chunked\r\n"
    "\r\n"
    "0\r\n"
    "\r\n"
    "X"
).format(host)

ctx = ssl.create_default_context()
sock = socket.create_connection((host, port))
sock = ctx.wrap_socket(sock, server_hostname=host)
sock.send(smuggle_request.encode())
response = sock.recv(4096).decode()
print(response)
sock.close()

## Should print "400 Bad Request" in the response

Check Nginx Logs for Blocked Attempts

# Watch for 400 errors from smuggling attempts
tail -f /var/log/nginx/access.log | grep " 400 "

Summary Checklist

Test	Expected Result
`nginx -t`	syntax ok
Request with both `CL` + `TE`	400 Bad Request
Request with only `Content-Length`	Normal response
Request with only `Transfer-Encoding`	Normal response
Burp Suite smuggling scan	No vulnerabilities