What Is Reverse Proxy?

A reverse proxy accepts inbound requests on behalf of backend servers, forwarding them and returning responses. Clients see only the proxy; the servers behind it are not directly exposed.

It is the inbound counterpart to a forward proxy, and it is where a substantial share of inbound security controls are most practically applied.

What the position provides

Backend systems are not directly reachable, so their addresses, software versions and topology are not exposed. TLS terminates in one place, which centralises certificate management rather than distributing it across every backend.

It is also the natural home for request filtering, rate limiting and authentication enforcement, and it is where a web application firewall typically sits. Applying those centrally means backend applications need not each implement them correctly.

Header handling is where it goes wrong

Because the proxy makes the connection to the backend, the backend sees the proxy's address rather than the client's. Forwarded-for headers carry the original address, and backends frequently trust them.

If the backend accepts that header from any source, a client can forge it — defeating address-based access controls, rate limiting and audit logging in one step. The header should be trusted only when it arrives from the known proxy, and the proxy should overwrite rather than append any value the client supplied.

Request smuggling and parsing differences

Where a proxy and a backend interpret an ambiguous request differently, an attacker can construct traffic that the proxy reads as one request and the backend reads as two — smuggling a second request past whatever controls the proxy applies.

The defences are keeping both components current, avoiding unnecessary chains of proxies with differing implementations, and rejecting ambiguous requests rather than normalising them.

Caching and the data you did not mean to store

Reverse proxies frequently cache responses for performance, and cached content is stored content. Where responses contain personalised or sensitive data, a misconfigured cache can serve one user’s content to another — a class of incident that is both serious and difficult to detect.

The controls are ordinary once considered: respect cache-control headers from the application, never cache authenticated responses by default, and ensure cache keys include whatever distinguishes one user’s view from another’s.

It is worth testing explicitly, because the failure only appears under conditions — concurrent users, specific paths — that ordinary functional testing does not produce.

Error handling is a small detail with disproportionate effect. Default error pages frequently disclose the proxy software, its version and sometimes backend detail — information that shortens an attacker’s reconnaissance considerably. Replacing them with generic responses is a few minutes of configuration.

A common mistake worth avoiding

Whatever else is on the list, the answer worth establishing first is whether backends accept connections that did not come through it. It is a question that can be settled in a day, it requires no procurement, and the answer determines whether the rest of the programme is addressing the largest exposure or a smaller one that happened to be easier to see.

Where to start

Confirm your backends reject connections that did not come via the proxy, and check how they handle forwarded-for headers from arbitrary sources.

See web application firewalls. GuardsArm delivers application penetration testing.