---
title: "Discussion on \"Forwarded Headers Are Not Trusted Input: X-Forwarded-For, Proto and Host Behind a Tunnel\" | Hashnode"
description: "Discussion on \"Forwarded Headers Are Not Trusted Input: X-Forwarded-For, Proto and Host Behind a Tunnel\". Behind a tunnel, X-Forwarded-For, Proto and Host are untrusted input. Learn the right trustProxy settings for Express, Fastify, Django and Rails."
url: "https://hashnode.com/posts/forwarded-headers-are-not-trusted-input-x-forwarded-for-proto-and-host-behind-a-tunnel/6af2940f54f4bcba4e4c1d28"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [Forwarded Headers Are Not Trusted Input: X-Forwarded-For, Proto and Host Behind a Tunnel](https://instatunnel.hashnode.dev/forwarded-headers-are-not-trusted-input-x-forwarded-for-proto-and-host-behind-a-tunnel?utm_source=hashnode&utm_medium=feed)

Behind a tunnel, X-Forwarded-For, Proto and Host are untrusted input. Learn the right trustProxy settings for Express, Fastify, Django and Rails.

2d ago · 11 min read · instatunnel.hashnode.dev  
Read the article

-   [#networking](https://hashnode.com/tag/networking)
-   [#devops](https://hashnode.com/tag/devops)
-   [#security](https://hashnode.com/tag/security)
-   [#webdev](https://hashnode.com/tag/webdev)

## Written by

[InstaTunnel](https://hashnode.com/@instatunnel)

@instatunnel

  
[View profile](https://hashnode.com/@instatunnel)

InstaTunnel - The Professional ngrok Alternative That's 40% Cheaper

## Responses 1

Markdown supported · ⌘↵ to post

[Edge Ops](https://hashnode.com/@edgecacheops)

[2d ago](https://hashnode.com/posts/forwarded-headers-are-not-trusted-input-x-forwarded-for-proto-and-host-behind-a-tunnel/6af2940f54f4bcba4e4c1d28/comment/6af2a64191e5634f8cc11796)

Forwarded headers behind a tunnel are only safe when the first hop you operate overwrites client-supplied X-Forwarded-For, Proto, and Host, and the application trusts a hop list that matches those addresses. Prefer a tight trustProxy (or equivalent) that names the tunnel or edge CIDR, drop or replace inbound forwarded fields from untrusted clients, and pin the expected Host so a spoofed authority cannot change routing, cookies, or generated absolute paths. Treat Proto as an operator-set scheme bit, not as a client-editable flag.

Ops prove-out after tightening trust: send a request with forged X-Forwarded-For, Proto, and Host from outside the trusted hop list and confirm the app still logs the real connecting address and the pinned Host, then repeat from the trusted tunnel and confirm the client address and scheme are the ones the edge injected. Watch access logs, rate-limit identity, and redirect targets for one change window — a mismatch usually means the app still appends client-supplied hops or trusts a hop count that the tunnel does not consume. Keep the hop list versioned with the tunnel or edge change so a new egress address cannot silently widen trust.