Trusted Proxies Are an Authentication Boundary: Stop X-Forwarded-For Spoofing

A trusted-proxy setting is an authentication boundary. If an application trusts client-supplied forwarding headers from the wrong place, a remote request can appear to come from localhost, a Docker bridge, a VPN range, or a LAN subnet and inherit local-only behavior it should never receive.

Reader question: Can a bad proxy config make remote users look local? Practical answer: Yes. The fix is exact trusted proxy ranges, header replacement at the edge, direct-origin isolation, and negative tests from both remote and adjacent networks.

Client

Never trust X-Forwarded-For or similar headers directly from arbitrary clients.

Edge

The first trusted proxy should remove client-supplied identity headers and set its own.

App

Applications should trust only known proxy addresses or networks, not broad LAN or Docker ranges.

Origin

A bypass route to the origin defeats the proxy policy even when headers are correct.

The Short Version

• Do not add entire LAN, Docker, or VPN ranges as trusted proxies unless every host in that range is allowed to assert client identity.
• The edge proxy should strip incoming forwarding headers and write the canonical ones.
• The application origin should not be reachable directly from clients that are supposed to pass through SSO or proxy controls.
• A correct setup includes negative tests proving spoofed headers fail.

Decision Matrix

Area	What to Check	Operational Standard
Header source	Who can set X-Forwarded-For, X-Real-IP, Forwarded	Only controlled proxies write identity headers.
Trusted ranges	Exact proxy IPs, container networks, IPv6 paths	Trust the proxy, not the whole network.
Origin access	Direct port, Docker publish, firewall, VLAN rules	Clients cannot bypass the proxy to reach the app.
App behavior	Local auth exceptions, remote IP rules, known proxies	Remote requests stay remote in app logs and policy.

The Mistake: Trusting A Network Instead Of A Proxy

Trusted proxy settings are often filled with broad ranges because it makes the warning disappear. That is exactly the wrong instinct. If the application trusts every address in a Docker bridge, LAN, or VPN range, then any host in that range may be able to send identity headers that the application treats as truth.

The correct model is narrow: identify the specific reverse proxy address that connects to the application, trust only that address or tightly scoped proxy subnet, and make sure no ordinary client can reach the application port directly.

Configure The Edge To Own The Header

A reverse proxy should not pass through whatever forwarding headers the client supplied. It should overwrite or normalize them at the first trusted hop. The exact syntax differs between NGINX, Caddy, Traefik, Authelia integrations, and application-specific settings, but the principle is the same: client identity is asserted by controlled infrastructure, not the browser.

IPv6 and container networks make this easy to get wrong. If the proxy connects over IPv6, trust the IPv6 source used by the proxy. If the proxy and app sit on a Docker network, identify the proxy container address or network carefully instead of trusting every container by habit.

• Strip incoming forwarding headers from untrusted clients.
• Set canonical forwarding headers at the edge proxy.
• Configure the application to trust only the proxy source.
• Block direct app access from user VLANs and the internet.

Negative Tests Matter More Than A Green Dashboard

A working login only proves the happy path. The failure path is what protects you. Test from outside the LAN, from a guest VLAN, from another container, and from a VPN client that should not be able to assert local identity.

Send a harmless request with spoofed forwarding headers and confirm the application still records the real remote path or rejects the request. Do not test by bypassing authentication on production accounts; test whether the trust boundary rejects a fake client address.

Validation Checklist

• Application logs show the expected client IP when traffic arrives through the proxy.
• Spoofed forwarding headers from an untrusted client do not change authorization behavior.
• Direct requests to the application origin fail from public, guest, and ordinary LAN networks.
• Trusted proxy ranges are exact and include IPv6 where used.
• SSO, local-auth exceptions, and remote-streaming features still behave intentionally after tightening.

What This Does Not Prove

A trusted-proxy test does not prove the application is secure, the proxy has no bugs, or every upstream route is authenticated. It proves only that the tested forwarding-header trust path resists the specific spoofing and bypass cases tested.

Security, Privacy, Legal, And Recovery Boundaries

• Do not treat proxy authentication as a substitute for patching vulnerable applications.
• Do not expose origin ports for convenience after adding SSO.
• Do not publish real internal address maps if they identify private infrastructure.
• For media-stack examples, use lawful personal media services and private administrative access.

Publication-Day Rechecks

• Verify current NGINX, Caddy, Jellyfin, and Authelia trusted-header documentation before publication.
• Check whether the target applications changed known-proxy or local-network behavior.
• Retest the negative path after any proxy or container-network change.

Related TechGeeks Resources

• Nginx Proxy Manager vs Caddy vs Traefik
• Reverse Proxy Setup Without Security Mistakes
• Remote Access Without Opening Router Ports

References

• Jellyfin Reverse Proxy Documentation
• NGINX Real IP Module
• Caddy Reverse Proxy Directive
• Authelia Forwarded Headers

Final Operational Standard

The standard is narrow trust. Your proxy may speak for clients; ordinary clients, random containers, and the whole LAN may not.