Reverse proxy security checklist

A reverse proxy is the only component that sees every request before your application does, which makes it the best place to enforce security properties and the worst place to get them wrong. This checklist is organised by category; each item states what to check, why it matters, and how to verify it from outside the box rather than by reading the configuration file. Configuration describes intent, and the gap between intent and behaviour is where the findings are.

Work through it in order. The categories are sequenced by blast radius: a trust boundary error invalidates every authorisation decision downstream, while a missing rate limit degrades availability. If you only have an afternoon, do the first three.

1. Trust boundary and forwarded headers#

The edge proxy is the only hop that knows the true client address, because it is the only hop with an unforgeable TCP peer. Every hop after it works from an assertion. The entire discipline is deciding where assertions start being trustworthy and enforcing that boundary exactly once.

2. Request handling#

3. TLS configuration#

4. Upstream#

5. Rate limiting and abuse#

6. Exposure#

Every proxy ships an operational surface that is a control plane rather than a status page. These are among the most reliably productive findings in an internal audit.

7. Logging and detection#

8. Process#

Worked example: an edge server block implementing sections 1 to 4#

# Trusted edge devices only. Exact CIDRs, never a whole VPC.
set_real_ip_from 203.0.113.0/24;
set_real_ip_from 198.51.100.0/24;
real_ip_header   X-Forwarded-For;
real_ip_recursive on;

log_format edge '$realip_remote_addr $remote_addr $host "$request" '
                '$status $body_bytes_sent $request_time '
                '$upstream_addr $upstream_status $upstream_response_time '
                '$ssl_protocol/$ssl_cipher';

limit_req_zone  $binary_remote_addr zone=auth:10m rate=5r/s;
limit_conn_zone $binary_remote_addr zone=perip:10m;

server {
    listen 443 ssl default_server;
    server_name _;
    ssl_reject_handshake on;      # nginx 1.19.4 and later
    return 444;
}

server {
    listen 443 ssl;
    http2 on;                      # nginx 1.25.1 and later
    server_name app.example.com;
    access_log /var/log/nginx/edge.log edge;

    ssl_protocols TLSv1.2 TLSv1.3;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

    client_header_timeout 12s;     # slowloris; default is 60s
    client_body_timeout   12s;     # default is 60s
    client_max_body_size  20m;     # default is 1m
    limit_conn perip 40;
    limit_req_status 429;          # default is 503

    if ($request_method !~ ^(GET|HEAD|POST|PUT|PATCH|DELETE)$) { return 405; }

    location / {
        # Overwrite the trust boundary. Never append at the edge.
        proxy_set_header X-Forwarded-For   $remote_addr;
        proxy_set_header X-Real-IP         $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header X-Forwarded-Host  $host;
        proxy_set_header Forwarded         "";
        proxy_set_header X-Auth-Assertion  "";

        proxy_pass                    https://app_backend;
        proxy_ssl_verify              on;    # default is off
        proxy_ssl_server_name         on;    # default is off
        proxy_ssl_name                app.internal;
        proxy_ssl_trusted_certificate /etc/nginx/internal-ca.pem;

        proxy_connect_timeout 3s;
        proxy_send_timeout    20s;
        proxy_read_timeout    20s;
    }

    location /login { limit_req zone=auth burst=10 nodelay; proxy_pass https://app_backend; }
}

Two details do the heavy lifting. proxy_set_header X-Forwarded-For $remote_addr; overwrites rather than appending, which is what $proxy_add_x_forwarded_for would do; appending at the outermost hop is the single most common trust-boundary defect, and the X-Forwarded-For page covers why. Setting a header to the empty string is nginx's way of not passing it upstream at all, which is how inbound Forwarded and any internal assertion header are neutralised.

Failure modes this checklist prevents#

Every request appears to come from the load balancer. set_real_ip_from does not cover the actual load balancer subnet, or real_ip_header names a header the load balancer does not set. Rate limits keyed on the address then apply globally rather than per client, and one abusive user throttles everyone.

Users behind a corporate NAT are throttled as one client. limit_req keyed on the derived address is working exactly as configured. Key on a session or account identifier for authenticated endpoints and reserve address-keyed limits for unauthenticated ones.

502 Bad Gateway after tightening upstream TLS. proxy_ssl_verify on is now doing its job and the upstream certificate does not validate against proxy_ssl_trusted_certificate, or proxy_ssl_name does not match its subject. This is a finding, not a regression: the connection was previously unauthenticated.

400 Bad Request from the edge after enabling strict framing. A legacy client relied on lenient parsing. Identify it by source address from the logs and fix the client; relaxing the edge reopens the desync path.

A working change breaks on reload but not on nginx -t. Syntax checking validates the file, not the runtime: missing certificate files, unresolvable upstream names and permission errors surface only on reload. Stage the rollout.

Frequently asked questions#

Should the reverse proxy append to or overwrite X-Forwarded-For?#

The outermost proxy, the one terminating the client connection, must overwrite it with the socket peer address. Internal hops behind that boundary may append. Appending at the edge means the leftmost entry is whatever the client sent, so any code reading the first element is reading attacker-controlled data.

What is the most commonly missed reverse proxy security setting?#

Upstream certificate verification. nginx defaults proxy_ssl_verify to off and proxy_ssl_server_name to off, so an https:// upstream is authenticated against nothing and sends no SNI. Teams see https in proxy_pass, assume the connection is verified, and get an encrypted channel to an unauthenticated peer.

How do I stop slowloris attacks at the proxy?#

Shorten client_header_timeout and client_body_timeout from their 60 second defaults to roughly 10 to 15 seconds, cap concurrent connections per source with limit_conn, and keep request body buffering enabled so the proxy rather than the origin absorbs slow senders. The attack depends on a connection being held cheaply for a long time, so bounding the hold time removes it.

Is exposing the Envoy admin interface actually dangerous?#

Yes. It is a control plane, not a status page: it exposes the full effective configuration, allows runtime modification, and includes /quitquitquit, which terminates the process. Bind it to loopback or a UNIX domain socket, never to 0.0.0.0, and reach it through a bastion or a sidecar rather than the network.

What should a reverse proxy access log contain for security purposes?#

At minimum the socket peer address and the derived client address as separate fields, the Host, the full request line, the status, the upstream address, upstream status and upstream response time, plus the negotiated TLS version and cipher. The two address fields matter most: with only one, a spoofing report cannot be investigated at all.

How often should this checklist be re-run?#

At least after every network topology change, since bind addresses and origin lock-down assumptions are invalidated by new subnets, new load balancers and newly published container ports. Sections 1 and 6, the trust boundary and the exposed admin surfaces, are the ones that silently regress; the rest are stable once set.

Does a WAF replace any of these items?#

No, and it adds an item. A WAF is another HTTP parser in the chain, so it introduces another opportunity for framing divergence, as described in HTTP request smuggling and proxy desync. It inspects the request as it parsed it, which is not necessarily what the origin will parse. Treat it as an additional hop subject to sections 2 and 6 of this checklist.