Reverse proxies and edge security

Reverse Proxy Core Functions

A reverse proxy is a web server that sits in front of internal services and gives the public one unified interface: it forwards each request to a server that can fulfill it and returns that server's response. Useful even in front of a single server, it provides:

• Security: Hides information about backend servers, can block IP addresses, and can limit connections per client.
• Scalability and flexibility: Clients see only the proxy's address, so you can add, remove or reconfigure servers behind it.
• TLS termination: Decrypts incoming requests and encrypts responses, so backend servers do not have to do this potentially expensive work. Whether traffic is re-encrypted on the way to the backends is a separate security decision.
• Compression of responses, caching of responses it has already seen, and serving static content directly.

NGINX and HAProxy can act as both a layer 7 reverse proxy and a load balancer.

Web Application Firewall (WAF)

A web application firewall applies a set of rules to HTTP traffic. Generally these rules cover common attacks such as:

• SQL injection (SQLi): e.g., ' OR 1=1--
• Cross-site scripting (XSS): e.g., <script>alert(1)</script>

Rate Limiting Algorithms

To protect backends from brute force and traffic surges, reverse proxies implement rate limiters:

Token bucket algorithm

A bucket holds up to $B$ tokens (the burst), and tokens are added at a steady rate of $r$ per second (the rate). Each request consumes $1$ token.

• Allowed: If tokens $\ge 1$, consume $1$ token and forward the request.
• Rejected: If tokens $< 1$, respond with HTTP 429 Too Many Requests, optionally with a Retry-After header telling the client how long to wait.
• Advantage: Allows bursts up to $B$ requests while holding the long-run average to $r$. AWS API Gateway, for example, throttles with a token bucket configured exactly this way.

Leaky bucket algorithm

Requests enter a queue and leave it at a constant rate $r$; when the queue is full, new requests are rejected. This smooths bursty traffic into a steady stream. NGINX's request-rate limiting uses the leaky bucket method (and by default rejects excess requests with 503 rather than 429).