Building a Tunnel Proxy That's Actually Secure: Allow-Lists, Fail-Closed, JWT Stripping

Any time you expose a local process (a dev server, an agent's terminal, a customer-run instance) to the internet through a tunnel or reverse proxy, you're building a specific and well-understood security surface, and it's worth building it deliberately rather than incrementally. A production HTTP-over-tunnel proxy was built with these specific controls, added together rather than bolted on individually over time: an explicit allow-list of permitted paths and methods that fails closed (anything not explicitly allowed is denied, not the reverse), a deny rule enforced on the runner side as a second layer rather than trusting the proxy alone, a request body size cap to prevent resource exhaustion, a guard against CRLF injection in headers (a classic technique for smuggling additional headers or requests), host-rewrite handling so internal hostnames don't leak to the client, and explicit stripping of JWTs before they cross the tunnel boundary. Each of these addresses a distinct attack: the allow-list plus fail-closed default prevents accidental exposure of unintended endpoints. The runner-side deny is defense in depth in case the proxy layer has a bug. The body cap prevents a trivial denial-of-service via oversized requests. The CRLF guard prevents header injection. Host-rewrite prevents internal topology leakage. JWT stripping prevents credentials meant for internal use from crossing into a context where they could be logged or intercepted externally. If you're building anything that tunnels a local process to the internet, whether for remote access to your own tools or as a feature you're shipping to customers, treat this as the baseline checklist, not an aspirational one.