3 months ago
For my app in [Southeast Asia region], does your edge proxy fully construct/overwrite the X-Forwarded-For header based on the real observed client connection, or does it append onto a client-supplied X-Forwarded-For value if one is already present in the incoming request? I need to know whether a client can prepend fake entries ahead of the real client IP for rate-limiting purposes.
I saw @phin's reply in the 'Security-Critical Questions on Edge Proxy Header Handling and Hop Count' thread confirming Railway strips X-Forwarded-For at the edge and clients can't overwrite it. Can you confirm this holds for my project specifically — / web / production, [Southeast Asia region]? I'm currently seeing exactly 2 entries in X-Forwarded-For (real client leftmost, one internal Railway hop after it) and want to confirm that's a stable, guaranteed shape for my setup before I rely on it for rate-limiting security, not just something that happened to hold today.
Pinned Solution
3 months ago
Hey! I believe you can confirm this yourself for your region without needing Railway to check any internals. Send a request manually with a header and log what your app receives:
curl -H "X-Forwarded-For: 9.9.9.9" https://your-app/whatever
If the app sees 9.9.9.9, <your real IP>, <railway hop>, the edge appends to what the client sent, so the leftmost entry is client-controlled and unsafe to key rate-limiting on.
If it sees only <your real IP>, <railway hop> with 9.9.9.9 stripped, the edge reconstructs the header and leftmost is safe (which matches what you said @phin described).
I think that test is definitive for your setup.
4 Replies
Status changed to Awaiting Railway Response Railway • 3 months ago
3 months ago
This thread has been opened as a public bounty so the community can help solve it. The thread and any further activity are now visible to everyone.
Status changed to Open Railway • 3 months ago
3 months ago
Hey! I believe you can confirm this yourself for your region without needing Railway to check any internals. Send a request manually with a header and log what your app receives:
curl -H "X-Forwarded-For: 9.9.9.9" https://your-app/whatever
If the app sees 9.9.9.9, <your real IP>, <railway hop>, the edge appends to what the client sent, so the leftmost entry is client-controlled and unsafe to key rate-limiting on.
If it sees only <your real IP>, <railway hop> with 9.9.9.9 stripped, the edge reconstructs the header and leftmost is safe (which matches what you said @phin described).
I think that test is definitive for your setup.
spjoes
Hey! I believe you can confirm this yourself for your region without needing Railway to check any internals. Send a request manually with a header and log what your app receives: `curl -H "X-Forwarded-For: 9.9.9.9" https://your-app/whatever` If the app sees `9.9.9.9, <your real IP>, <railway hop>`, the edge appends to what the client sent, so the leftmost entry is client-controlled and unsafe to key rate-limiting on. If it sees only `<your real IP>, <railway hop>` with 9.9.9.9 stripped, the edge reconstructs the header and leftmost is safe (which matches what you said @phin described). I think that test is definitive for your setup.
3 months ago
very solid advice spjoes. thank you!
tfenk
very solid advice spjoes. thank you!
3 months ago
No problem! If this solved your issue please make sure to mark my answer as the accepted solution so this thread can be properly closed!
spjoes
No problem! If this solved your issue please make sure to mark my answer as the accepted solution so this thread can be properly closed!
3 months ago
it solved my issue and I just marked your answer as accepetd
Status changed to Solved tfenk • 3 months ago