gate forwarded host/proto headers on proxy trust model - #390
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3e1a88cd28
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| return ( | ||
| normalizedIpSource === "x-forwarded-for" || | ||
| normalizedIpSource === "forwarded" | ||
| ); |
There was a problem hiding this comment.
For deployments behind a trusted CDN/proxy that use a documented custom WBO_IP_SOURCE such as CF-Connecting-IP (README.md lines 43 and 186), this returns false, so the new callers in templating and cookie generation ignore X-Forwarded-Proto/X-Forwarded-Host. In that configuration HTTPS board pages will emit a non-Secure user-secret cookie and generate http/internal-host base and canonical URLs even though the deployment is explicitly configured to trust the proxy-provided client IP.
Useful? React with 👍 / 👎.
A custom WBO_IP_SOURCE such as CF-Connecting-IP is a trusted-proxy deployment too, so HTTPS pages must keep emitting Secure cookies and https canonical URLs. Trust forwarded headers whenever IP_SOURCE is not the default remoteAddress.
1 participant
Fixes #373. HTTP code trusted
x-forwarded-host/x-forwarded-proto/forwardedunconditionally, while socket client-IP resolution already gates forwarded headers behindWBO_IP_SOURCE. Direct deployments could be fed spoofed canonical URLs, an attacker-controlled cookieSecureflag, and high-cardinality fakeserver.addressmetrics.One shared helper now drives both surfaces:
trustsForwardedHeaders(config)returns true only whenIP_SOURCEisX-Forwarded-FororForwarded(the same sources that imply a trusted proxy for IP resolution). The three header-reading spots (findBaseUrl,requestScheme/requestAuthority, cookieSecure) call it and fall back toreq.socket.encrypted/req.headers.hoston direct deploys.Proof, forwarded headers ignored on a direct deployment:
New tests assert the gate directly:
templating.test.js: spoofedx-forwarded-host/protoignored, base URL falls back to realhost.server_routes.test.js: cookie is NOTSecurefrom spoofedx-forwarded-protoon a direct deploy; stillSecurebehind a configured proxy.socket_policy.test.js:trustsForwardedHeaderstruth table.npm run lintandnpm run typecheckpass. Net +129 LOC, mostly tests.