Trust Proxy Identity Headers Safely

A reverse proxy can authenticate a user and pass identity to an application through headers. This works only when the application can distinguish proxy-set values from client-set values. A direct route to the origin, a preview deployment, or a second proxy can break that assumption. The OWASP Authorization Cheat Sheet requires a reliable subject before any grant decision.

Header trust boundary

Draw each hop from the browser to the handler. Include public edge, authentication proxy, origin ingress, app middleware, and any worker handoff.

Record the exact header names, who sets them, and how the next hop verifies them. An internal IP address alone may not be enough if multiple services can reach the origin. If the proxy sends a signed assertion, validate issuer, audience, expiry, and key ownership. If it depends on network isolation, verify the firewall and ingress paths.

Verify the failure case

Use synthetic identities in staging. First, make a normal allowed request through the proxy. Then send the same apparent identity headers without a valid authenticated session through every owned ingress path. No path should grant access. Change the tenant header while keeping the user identity and confirm the handler checks current membership. Check that denial logs record the source hop without echoing credentials.

The OWASP REST Security Cheat Sheet provides transport context. This hop map is the artifact. Update it when a new CDN, load balancer, internal route, or preview host is added. Do not probe a third-party origin without exact written scope. A successful proxy login does not prove the direct path is closed.