FastCGI: 30 years old and still the better protocol for reverse proxies

April 29, 2026

FastCGI: 30 Years Old and Still the Better Protocol for Reverse Proxies

HTTP reverse proxying is a minefield. Just the other week, a researcher disclosed a desync vulnerability in Discord's media proxy that allowed spying on private attachments. This is not unusual; these vulnerabilities just keep coming.

The problem is the widespread use of HTTP as the protocol between reverse proxies and backends, even though it's unfit for the job. But we don't have to use HTTP here. There's a 30-year-old protocol for proxy-to-backend communication that avoids HTTP's pitfalls. It's called FastCGI, and its specification was released 30 years ago today.

FastCGI is a Wire Protocol, not a Process Model

It's true that some web servers can automatically spawn FastCGI processes to handle requests for files with the .fcgi extension, much like they would for .cgi files. But you don't have to use FastCGI this way - you can also use the FastCGI protocol just like HTTP, with requests sent over a TCP or UNIX socket to a long-running daemon that handles them as if they were HTTP requests.

For example, in Go all you have to do is import the net/http/fcgi standard library package and replace http.Serve with fcgi.Serve.

Everything else about your app stays the same - even your handler, which continues to use the standard http.ResponseWriter and http.Request types.

Popular proxies like Apache, Caddy, nginx, and HAProxy support FastCGI backends, and the configuration is simple.

Why HTTP Sucks for Reverse Proxies: Desync Attacks / Request Smuggling

HTTP/1.1 has the tragic property of looking simple on the surface but actually being a nightmare to parse robustly. There are so many different ways to format the same HTTP message, and there are too many edge cases and ambiguities for implementations to handle consistently.

The most serious problem is that there is no explicit framing of HTTP messages. Implementations can disagree about where a message ends, and consequently, where the next message begins. This is the foundation of HTTP desync attacks, also known as request smuggling.

HTTP/2, when consistently used between the proxy and backend, fixes desync by putting clear boundaries around messages, but FastCGI has been doing that since 1996 with a simpler protocol.

Why HTTP Sucks for Reverse Proxies: Untrusted Headers

HTTP has no robust way for the proxy to convey trusted information about the request, such as the real client IP address. The only option is to stick this information in HTTP headers, without a clear structural distinction between trusted headers from the proxy and untrusted headers from a potential attacker.

FastCGI completely avoids this class of problem by providing domain separation between headers from the client and information added by the proxy. HTTP header names are prefixed with the string "HTTP_", making it structurally impossible for clients to send a header that would be interpreted as trusted data.

Closing Thoughts

If FastCGI is the better protocol, why isn't it more popular? Maybe it's the name - CGI feels dated in 2026. There's also an enduring lack of awareness of the security problems with HTTP reverse proxying. FastCGI is very usable today, though using a vintage technology has some downsides like lack of WebSocket support and fewer modern tools.