Cybersecurity glossary
What is X-Forwarded-Proto?
Learn what the X-Forwarded-Proto HTTP header does, how it records http vs https at the edge, why spoofing breaks HTTPS redirects without trusted proxy lists, and how to configure secure upstream behavior.
Definition
X-Forwarded-Proto is a de-facto standard HTTP request header set by reverse proxies and load balancers to indicate whether the client originally connected over HTTP or HTTPS, enabling backends that receive plain HTTP on private networks to generate correct absolute URLs, enforce TLS redirects, and apply secure cookie policies based on the external scheme.
Why X-Forwarded-Proto matters
TLS termination at the edge is standard practice. Backends often see unencrypted HTTP on trusted networks. X-Forwarded-Proto tells those backends whether the user-facing connection was http or https so redirects, cookies, and absolute URLs match reality.
Without trusted proto metadata, applications guess wrong: broken redirects, insecure session cookies, and mixed-content links. With blind trust, attackers spoof scheme and weaken those same controls.
How X-Forwarded-Proto flows through TLS termination
The edge observes the client's TLS handshake, sets proto to https or http, and forwards the request upstream—usually over plaintext HTTP on a private link.
Client connects with HTTPS
The browser negotiates TLS with the CDN, load balancer, or reverse proxy.
Edge records the scheme
The proxy sets X-Forwarded-Proto to https based on the inbound connection, not the upstream link.
Plain HTTP to origin
The proxy forwards to the app over an internal network; the direct request URL may still show http.
App enforces HTTPS policy
Middleware reads trusted proto metadata to redirect, set Secure cookies, and emit canonical https links.
User sees consistent TLS
Responses reference https even though the hop behind the proxy was plaintext.
HTTPS redirects and trust
| Where redirect runs | What it must read | Common pitfall |
|---|---|---|
| CDN / load balancer | Inbound client TLS state | Origin still unaware unless forwarding headers are set consistently |
| Application middleware | Trusted X-Forwarded-Proto from proxy peer | Redirect loop if edge and app both redirect with mismatched trust |
| Framework URL helpers | Forwarded proto + host for absolute URLs | Generated http links on pages served over https to users |
| Cookie Secure flag | Trusted proto == https before marking session cookies Secure | Session fixation over plaintext when proto is spoofed or ignored |
| HSTS and upgrade headers | Edge TLS termination plus correct downstream assumptions | HSTS at edge while app still emits http asset URLs |
Spoofing scenarios
Client sends X-Forwarded-Proto: https
On a direct connection, attackers claim TLS was used. Apps that trust it may skip legitimate redirects or mark cookies Secure incorrectly.
Forged http downgrade
Spoofed http values can weaken cookie policies or generate insecure links if scheme checks trust the header blindly.
Missing header
Apps behind proxies without proto forwarding never redirect to HTTPS because they only see plaintext upstream.
Conflicting Forwarded header
Mixed de-facto and RFC 7239 headers with different proto values confuse middleware.
Trusted proxy list gaps
New ingress IPs not on the allowlist cause apps to ignore legitimate proto metadata—or accept forged values from the wrong peers.
Redirect loops
Edge forces https while app thinks request is http and redirects again—or the reverse.
Security checklist
- Maintain a trusted proxy list; ignore X-Forwarded-Proto from connections outside that list.
- Have the edge strip client-supplied X-Forwarded-Proto before setting its own value.
- Perform HTTP→HTTPS redirects at the edge or in app middleware—but not both without coordinated rules.
- Enable framework trust-proxy settings so URL helpers and cookie Secure flags read forwarded proto correctly.
- Never mark session cookies Secure based on proto unless the header came from a trusted hop.
- Re-encrypt to origin when the path between proxy and app crosses untrusted networks.
- Standardize on X-Forwarded-Proto or RFC 7239 Forwarded proto=—document which is authoritative.
- Test by sending forged proto headers from outside the proxy path and confirm they are ignored.
Limits and pitfalls
X-Forwarded-Proto describes what the edge observed; it does not replace TLS on the upstream hop. Teams that terminate TLS only at the CDN but expose origins to broader networks still need encryption or strict network policy behind the proxy.
Redirect logic split across CDN, ingress, and application layers causes subtle loops. Pick one primary enforcement point, forward trusted metadata consistently, and integration-test the full path after every ingress change.
The practical takeaway
X-Forwarded-Proto lets backends treat user connections as HTTPS even when upstream links are plain HTTP—but only when trusted proxies set it and applications refuse spoofed values.
Configure trusted proxy lists, coordinate HTTPS redirects between edge and app, and never base cookie or URL security on scheme metadata you did not receive from infrastructure you control.
Related security terms
HTTPS
Transport security users expect when X-Forwarded-Proto reports https at the edge.
Reverse Proxy
Infrastructure that terminates TLS and sets forwarding headers toward origins.
X-Forwarded-Host
Companion header preserving the original public hostname for URL generation.
Load Balancer
Often performs TLS termination and injects proto metadata for backend pools.
Frequently asked questions
What is X-Forwarded-Proto in simple terms?
Your app might receive http:// on a private link from the load balancer even though the user used https:// in the browser. X-Forwarded-Proto tells the app the user-facing scheme was https so it can build correct links and security rules.
Why do HTTPS redirects depend on X-Forwarded-Proto?
Applications that redirect HTTP to HTTPS need to know the external scheme. Without a trusted X-Forwarded-Proto (or equivalent), code that inspects only the direct connection sees http and may skip redirects—or redirect incorrectly.
Can attackers spoof X-Forwarded-Proto to https?
Yes, if the application trusts the header from any client. Spoofing https can trick apps into generating https URLs on plaintext connections or bypass scheme checks. Only accept values appended by trusted proxies.
What happens if I trust a spoofed http value?
Attackers may force downgrade behavior: insecure cookies, mixed-content links, or disabled HSTS assumptions—depending on how the application branches on scheme.
How is X-Forwarded-Proto different from Forwarded?
The RFC 7239 Forwarded header can carry proto= as a structured parameter. X-Forwarded-Proto is the widely deployed single-value form. Configure proxies to set one consistently and parse it with the same trust rules.
Should the edge or the app perform HTTP to HTTPS redirects?
Either can work. Many teams redirect at the CDN or load balancer for efficiency. When the app redirects, it must read trusted proto metadata—not the plaintext upstream socket scheme alone.
References
Explore authoritative guidance and frameworks related to x-forwarded-proto.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.