Reverse Proxy

Cybersecurity / 20 Sep 2026 / 7 min read

Trust Forwarded Headers Only from Known Proxies

Trust Forwarded Headers Only from Known Proxies A reverse proxy often knows facts that an application server cannot observe directly. It may terminate TLS, accept the public hostname, and receive the client connection before opening a separate connection to the backend. Forwarding fields carry those facts across the second hop. That arrangement is safe only when the backend can distinguish proxy-supplied metadata from client-supplied HTTP fields. A header name does not create trust. The trust comes from the network path, the proxy configuration, and a rule that defines which hop may set or replace each field.

Cybersecurity Reverse Proxy

Cybersecurity / 17 Sep 2026 / 10 min read

Mutual TLS Identity Can Disappear at a Terminating Proxy

Mutual TLS Identity Can Disappear at a Terminating Proxy A service can require a client certificate at its public endpoint, accept only certificates chained to an approved authority, and still deliver an unauthenticated request to the application behind it. The TLS check may be completely correct. The gap appears when a reverse proxy terminates that TLS connection and opens a different connection to the backend. Mutual TLS authenticates endpoints of a particular TLS connection. It does not automatically attach the authenticated client identity to HTTP requests after that connection ends, and it does not cause a second TLS connection to inherit the first connection’s peer. Once a proxy becomes the TLS server for the external client, the proxy is the component that possesses the verified client-certificate result. Any backend identity derived from that result crosses a new trust boundary.

Cybersecurity TLS

Cybersecurity / 17 Sep 2026 / 8 min read

HTTP Request Smuggling Begins at a Message-Framing Disagreement

HTTP Request Smuggling Begins at a Message-Framing Disagreement A reverse proxy can validate an HTTP request, route it to an approved application, and still deliver a different request sequence from the one it believed it accepted. The failure does not require the proxy to ignore authentication or the origin to execute malformed syntax. It can arise when the two HTTP processors disagree about the byte at which one request ends and the next begins.

Cybersecurity HTTP

Cybersecurity / 16 Sep 2026 / 8 min read

HTTP Request Framing Desynchronization Turns Parser Differences Into a Proxy Boundary Failure

HTTP Request Framing Desynchronization Turns Parser Differences Into a Proxy Boundary Failure A reverse proxy can validate an HTTP request, forward it to an origin, and still leave the origin processing a different request sequence from the one the proxy approved. The failure is not caused by encryption loss or a missing authorization check. It appears when two recipients consume the same connection bytes with different rules for deciding where one message ends and the next begins.

Cybersecurity HTTP

Cybersecurity / 16 Sep 2026 / 9 min read

Client Certificate Headers Move mTLS Identity Into the Proxy Trust Boundary

A service can require mutual TLS at its public edge and still have no TLS client certificate at the application server. The client proves possession of its private key to the TLS-terminating reverse proxy; the proxy then opens a separate connection to the origin. Unless certificate information is carried across that second hop, the origin cannot directly inspect the credential authenticated on the first connection. Forwarding the certificate in an HTTP field solves the transport problem but changes the security boundary. The origin is no longer consuming identity evidence directly from its own TLS handshake. It is consuming a statement made by an intermediary about a different handshake.

Cybersecurity TLS

Cybersecurity / 15 Sep 2026 / 7 min read

HTTP Request Smuggling Starts at Message-Boundary Disagreement

HTTP Request Smuggling Starts at Message-Boundary Disagreement A reverse proxy can validate an HTTP request, forward it to an application server, and still leave both systems with different views of where that request ends. The bytes do not need to change in transit. The security failure appears when two parsers assign different boundaries to the same stream. That disagreement is the core of HTTP request smuggling. One component consumes a prefix as a complete request while another treats additional bytes as part of that request, or as the beginning of a following one. On a reused backend connection, the leftover bytes can alter the interpretation of traffic that arrives later.

Cybersecurity HTTP

Cybersecurity / 13 Sep 2026 / 8 min read

HTTP Request Smuggling Begins With Parser Disagreement

HTTP Request Smuggling Begins With Parser Disagreement A reverse proxy can reject malicious paths, normalize headers, enforce authentication, and still pass an ambiguous HTTP message to a backend that interprets the same bytes differently. At that point, the security boundary is no longer defined by either component in isolation. It is defined by the gap between their parsers. HTTP request smuggling exploits that gap. The attacker is not primarily defeating TLS or guessing a credential. The useful primitive is message-boundary disagreement: one system decides that a request ends at one byte, while the next system decides that it ends somewhere else. Bytes treated as a body by the front end can become the start of another request at the origin, or the reverse can occur.

Cybersecurity Web Security

Cybersecurity / 13 Sep 2026 / 7 min read

HTTP Request Boundaries Fail When Intermediaries Disagree

A front-end proxy can accept a byte stream as one HTTP request while the server behind it interprets part of the same stream as the beginning of another. At that point, the disagreement is no longer a parsing curiosity. Bytes supplied by one connection can change how a later request is framed, creating a route around controls that assumed every component agreed on request boundaries. HTTP request smuggling sits in this gap between parsers. The vulnerable condition is not simply the presence of a Content-Length or Transfer-Encoding header. It is a chain in which two adjacent HTTP implementations assign different structure to the same traffic, then reuse a connection or otherwise preserve enough state for the disagreement to affect subsequent processing.

Cybersecurity HTTP

Cybersecurity / 13 Sep 2026 / 8 min read

Cache Keys Define a Security Boundary at Shared Proxies

A reverse proxy can receive two HTTP requests that look equivalent to its cache while the application behind it treats them as different. That disagreement is more than a performance bug. If an attacker can place a response generated from one request variant into a shared cache entry used by other clients, a request that originally affected one connection can acquire a much larger audience. This is the core security tension in web cache poisoning. The cache key defines which requests are considered interchangeable. The origin application defines which request properties can alter a response. Security depends on those two models staying aligned across proxies, frameworks, routing rules, and application code.

Cybersecurity HTTP Caching

Cloud Computing / Updated 02 Sep 2025 / 2 min read

Using Nginx as a Reverse Proxy for a Go Application

A Go web application often listens directly on an application port such as :8080. If you want users to access it through a normal domain on port 80 or 443, you can place Nginx in front of it as a reverse proxy. Using Nginx in front of a Go service provides several benefits: Client requests reach Nginx before being forwarded to the Go application. TLS termination can be handled at the proxy layer. Multiple application instances can be load balanced. Static assets can be served separately when that architecture makes sense. This guide shows a basic setup.

DevOps Golang