fix: sanitize forwarded headers on websocket connections and strip x-real-ip by ameistad · Pull Request #14 · haloydev/haloy

ameistad · 2026-06-10T08:34:55Z

Summary

The regular HTTP proxy path already handles forwarded headers securely: the Rewrite-based httputil.ReverseProxy strips client-supplied Forwarded and X-Forwarded-For/Host/Proto headers and sets fresh values via SetXForwarded(). This PR closes two gaps found while auditing that behavior:

WebSocket connections bypassed all forwarded-header handling.handleWebSocket hijacks the connection and forwards the client's handshake verbatim to the backend, so backends received no X-Forwarded-* headers at all, and client-spoofed ones passed through untouched. A new setForwardedHeaders function now strips Forwarded, X-Forwarded-For/Host/Proto, and X-Real-IP, then sets trusted values (client IP from the direct connection, proto from TLS state, original host) before the handshake is written to the backend.
X-Real-IP was never stripped on any path. Go's stdlib only strips the four standard forwarded headers, so a client could spoof X-Real-IP to backends that trust nginx-style conventions. It is now deleted in both Rewrite funcs (backend proxy and ACME challenge proxy).

Tests

New internal/proxy/forwarded_test.go:

HTTP path: spoofed X-Forwarded-*, X-Real-IP, and Forwarded headers never reach the backend; fresh values are correct.
WebSocket path: drives a real hijacked tunnel through handleWebSocket to a raw TCP backend and verifies the sanitized handshake.
Unit coverage for the https/http proto derivation in setForwardedHeaders.

…real-ip

ameistad · 2026-06-10T08:34:55Z

Summary

The regular HTTP proxy path already handles forwarded headers securely: the Rewrite-based httputil.ReverseProxy strips client-supplied Forwarded and X-Forwarded-For/Host/Proto headers and sets fresh values via SetXForwarded(). This PR closes two gaps found while auditing that behavior:

WebSocket connections bypassed all forwarded-header handling.handleWebSocket hijacks the connection and forwards the client's handshake verbatim to the backend, so backends received no X-Forwarded-* headers at all, and client-spoofed ones passed through untouched. A new setForwardedHeaders function now strips Forwarded, X-Forwarded-For/Host/Proto, and X-Real-IP, then sets trusted values (client IP from the direct connection, proto from TLS state, original host) before the handshake is written to the backend.
X-Real-IP was never stripped on any path. Go's stdlib only strips the four standard forwarded headers, so a client could spoof X-Real-IP to backends that trust nginx-style conventions. It is now deleted in both Rewrite funcs (backend proxy and ACME challenge proxy).

Tests

New internal/proxy/forwarded_test.go:

HTTP path: spoofed X-Forwarded-*, X-Real-IP, and Forwarded headers never reach the backend; fresh values are correct.
WebSocket path: drives a real hijacked tunnel through handleWebSocket to a raw TCP backend and verifies the sanitized handshake.
Unit coverage for the https/http proto derivation in setForwardedHeaders.

…real-ip

ameistad · 2026-06-10T08:34:55Z

Summary

The regular HTTP proxy path already handles forwarded headers securely: the Rewrite-based httputil.ReverseProxy strips client-supplied Forwarded and X-Forwarded-For/Host/Proto headers and sets fresh values via SetXForwarded(). This PR closes two gaps found while auditing that behavior:

WebSocket connections bypassed all forwarded-header handling.handleWebSocket hijacks the connection and forwards the client's handshake verbatim to the backend, so backends received no X-Forwarded-* headers at all, and client-spoofed ones passed through untouched. A new setForwardedHeaders function now strips Forwarded, X-Forwarded-For/Host/Proto, and X-Real-IP, then sets trusted values (client IP from the direct connection, proto from TLS state, original host) before the handshake is written to the backend.
X-Real-IP was never stripped on any path. Go's stdlib only strips the four standard forwarded headers, so a client could spoof X-Real-IP to backends that trust nginx-style conventions. It is now deleted in both Rewrite funcs (backend proxy and ACME challenge proxy).

Tests

New internal/proxy/forwarded_test.go:

HTTP path: spoofed X-Forwarded-*, X-Real-IP, and Forwarded headers never reach the backend; fresh values are correct.
WebSocket path: drives a real hijacked tunnel through handleWebSocket to a raw TCP backend and verifies the sanitized handshake.
Unit coverage for the https/http proto derivation in setForwardedHeaders.

…real-ip

ameistad · 2026-06-10T08:34:55Z

Summary

The regular HTTP proxy path already handles forwarded headers securely: the Rewrite-based httputil.ReverseProxy strips client-supplied Forwarded and X-Forwarded-For/Host/Proto headers and sets fresh values via SetXForwarded(). This PR closes two gaps found while auditing that behavior:

WebSocket connections bypassed all forwarded-header handling.handleWebSocket hijacks the connection and forwards the client's handshake verbatim to the backend, so backends received no X-Forwarded-* headers at all, and client-spoofed ones passed through untouched. A new setForwardedHeaders function now strips Forwarded, X-Forwarded-For/Host/Proto, and X-Real-IP, then sets trusted values (client IP from the direct connection, proto from TLS state, original host) before the handshake is written to the backend.
X-Real-IP was never stripped on any path. Go's stdlib only strips the four standard forwarded headers, so a client could spoof X-Real-IP to backends that trust nginx-style conventions. It is now deleted in both Rewrite funcs (backend proxy and ACME challenge proxy).

Tests

New internal/proxy/forwarded_test.go:

HTTP path: spoofed X-Forwarded-*, X-Real-IP, and Forwarded headers never reach the backend; fresh values are correct.
WebSocket path: drives a real hijacked tunnel through handleWebSocket to a raw TCP backend and verifies the sanitized handshake.
Unit coverage for the https/http proto derivation in setForwardedHeaders.

…real-ip

ameistad · 2026-06-10T08:34:55Z

Summary

The regular HTTP proxy path already handles forwarded headers securely: the Rewrite-based httputil.ReverseProxy strips client-supplied Forwarded and X-Forwarded-For/Host/Proto headers and sets fresh values via SetXForwarded(). This PR closes two gaps found while auditing that behavior:

WebSocket connections bypassed all forwarded-header handling.handleWebSocket hijacks the connection and forwards the client's handshake verbatim to the backend, so backends received no X-Forwarded-* headers at all, and client-spoofed ones passed through untouched. A new setForwardedHeaders function now strips Forwarded, X-Forwarded-For/Host/Proto, and X-Real-IP, then sets trusted values (client IP from the direct connection, proto from TLS state, original host) before the handshake is written to the backend.
X-Real-IP was never stripped on any path. Go's stdlib only strips the four standard forwarded headers, so a client could spoof X-Real-IP to backends that trust nginx-style conventions. It is now deleted in both Rewrite funcs (backend proxy and ACME challenge proxy).

Tests

New internal/proxy/forwarded_test.go:

HTTP path: spoofed X-Forwarded-*, X-Real-IP, and Forwarded headers never reach the backend; fresh values are correct.
WebSocket path: drives a real hijacked tunnel through handleWebSocket to a raw TCP backend and verifies the sanitized handshake.
Unit coverage for the https/http proto derivation in setForwardedHeaders.

…real-ip

ameistad · 2026-06-10T08:34:55Z

Summary

The regular HTTP proxy path already handles forwarded headers securely: the Rewrite-based httputil.ReverseProxy strips client-supplied Forwarded and X-Forwarded-For/Host/Proto headers and sets fresh values via SetXForwarded(). This PR closes two gaps found while auditing that behavior:

WebSocket connections bypassed all forwarded-header handling.handleWebSocket hijacks the connection and forwards the client's handshake verbatim to the backend, so backends received no X-Forwarded-* headers at all, and client-spoofed ones passed through untouched. A new setForwardedHeaders function now strips Forwarded, X-Forwarded-For/Host/Proto, and X-Real-IP, then sets trusted values (client IP from the direct connection, proto from TLS state, original host) before the handshake is written to the backend.
X-Real-IP was never stripped on any path. Go's stdlib only strips the four standard forwarded headers, so a client could spoof X-Real-IP to backends that trust nginx-style conventions. It is now deleted in both Rewrite funcs (backend proxy and ACME challenge proxy).

Tests

New internal/proxy/forwarded_test.go:

HTTP path: spoofed X-Forwarded-*, X-Real-IP, and Forwarded headers never reach the backend; fresh values are correct.
WebSocket path: drives a real hijacked tunnel through handleWebSocket to a raw TCP backend and verifies the sanitized handshake.
Unit coverage for the https/http proto derivation in setForwardedHeaders.

…real-ip

ameistad · 2026-06-10T08:34:55Z

Summary

The regular HTTP proxy path already handles forwarded headers securely: the Rewrite-based httputil.ReverseProxy strips client-supplied Forwarded and X-Forwarded-For/Host/Proto headers and sets fresh values via SetXForwarded(). This PR closes two gaps found while auditing that behavior:

WebSocket connections bypassed all forwarded-header handling.handleWebSocket hijacks the connection and forwards the client's handshake verbatim to the backend, so backends received no X-Forwarded-* headers at all, and client-spoofed ones passed through untouched. A new setForwardedHeaders function now strips Forwarded, X-Forwarded-For/Host/Proto, and X-Real-IP, then sets trusted values (client IP from the direct connection, proto from TLS state, original host) before the handshake is written to the backend.
X-Real-IP was never stripped on any path. Go's stdlib only strips the four standard forwarded headers, so a client could spoof X-Real-IP to backends that trust nginx-style conventions. It is now deleted in both Rewrite funcs (backend proxy and ACME challenge proxy).

Tests

New internal/proxy/forwarded_test.go:

HTTP path: spoofed X-Forwarded-*, X-Real-IP, and Forwarded headers never reach the backend; fresh values are correct.
WebSocket path: drives a real hijacked tunnel through handleWebSocket to a raw TCP backend and verifies the sanitized handshake.
Unit coverage for the https/http proto derivation in setForwardedHeaders.

…real-ip

ameistad · 2026-06-10T08:34:55Z

Summary

The regular HTTP proxy path already handles forwarded headers securely: the Rewrite-based httputil.ReverseProxy strips client-supplied Forwarded and X-Forwarded-For/Host/Proto headers and sets fresh values via SetXForwarded(). This PR closes two gaps found while auditing that behavior:

WebSocket connections bypassed all forwarded-header handling.handleWebSocket hijacks the connection and forwards the client's handshake verbatim to the backend, so backends received no X-Forwarded-* headers at all, and client-spoofed ones passed through untouched. A new setForwardedHeaders function now strips Forwarded, X-Forwarded-For/Host/Proto, and X-Real-IP, then sets trusted values (client IP from the direct connection, proto from TLS state, original host) before the handshake is written to the backend.
X-Real-IP was never stripped on any path. Go's stdlib only strips the four standard forwarded headers, so a client could spoof X-Real-IP to backends that trust nginx-style conventions. It is now deleted in both Rewrite funcs (backend proxy and ACME challenge proxy).