Forwarded Without Question: How Web Frameworks Overtrust the Forwarded Header

6.8 relevance

Security-focused analysis of web framework behavior, directly relevant to infrastructure and platform engineering.

Languages lkoskela.fi

Answer the board on AI readiness

Arrive with evidence, not opinion. See how your foundation benchmarks against your peers, get a clear read, and leave with a ranked place to start.

Why It Matters

As a platform engineer managing proxy layers and app security, this is a silent trust boundary gap — your Envoy or nginx may handle X-Forwarded-* correctly while Forwarded headers sail through untouched, making your Rails/Spring apps vulnerable to spoofing without any alert.

Key Takeaways

Audit your proxy configs to drop all incoming Forwarded and X-Forwarded-* headers before they reach the app, then have the proxy re-add only the ones you explicitly trust.

Summary

Web frameworks including Rails, Spring, and Jetty trust the Forwarded header by default, but most reverse proxies like Envoy and CDNs do not strip or validate it, passing attacker-controlled values straight through to applications. This creates a client IP and hostname spoofing vector that bypasses IP restrictions, rate limits, and can enable password reset deception. Developers must configure proxies to drop untrusted Forwarded headers and align trusted header lists between proxies and apps.