Walking my dog earlier, I came across the sign on the right. Having just looked at yet another middleware/HTTP header issue (the Next.js problem that became public this weekend) [1], I figured I should write something about HTTP headers. We all know HTTP headers. But it appears some do not know them well enough. Just like this sign, proxies and other middleboxes hardly ever stop unsafe behaviors. 

Let's look at some (somewhat random) past vulnerabilities rooted in the misuse of HTTP headers:

1. AT&T used the "User-Agent" header to identify iPhones: yes, this didn't last long and can be justified as a temporary solution. However, a similar issue came back with iPads a few years later, causing the leakage of subscriber e-mail addresses. [2][3]
2. Google Cloud ESP v2 JWT bypass: Adding a "X-HTTP-Method-Override" header will bypass JWT authentication [4]
3. Authentik Identify Provider: Authentication bypass using an invalid X-Forwarded-For header [5]

These are three issues that I think exemplify some of the common problems. First of all, a user may send whatever header they like. The first rule of web application security is that users are evil. You MUST authenticate, access control, and validate each request. There are reasonable methods to use HTTP headers for authentication. Authorization headers and Cookies can play a valuable role if used responsibly.

But here are some of the common pitfalls:

1. Any authentication/authorization related header must ve verified on the server. For a JWT, the signature must be verified properly before using any of the data encoded in the JWT. Session cookies must be verified using some form of backend session logic and authentication credentials like passwords must be properly verified. Nothing else should be done before correct authentication is established.

2. Proxies may or may not modify headers. One basic "bad pattern" is to have the proxy add a header verifying that a request is authorized. This is not always a bad idea, but it must be done properly. Will an attacker be able to bypass the proxy (and add the header)? Proxies will modify some headers but not others. The rules for this are complex and not always implemented correctly. 

Here are some of the documents defining rules around proxies and what they should and should not do with requests and responses:

Guidelines for Web Content Transformation Proxies 1.0

In the past, RFCs have become more specific about what works/doesn't work with proxies (see, for example, RFC 9112), but there is no guarantee that your web server or proxy will follow these rules. Be ready for non-compliance. Some web servers still happily accept an HTTP 1.1 request without a "Host" header. Upper/lower case headers (or in some cases even methods) are accepted. This behavior has been quite fluent, and you must not trust that any component of your HTTP request handling bucket brigade obeys any specific standard.

When parsing headers, stay flexible but at the same time, enforce standards. For example, HTTP/2 headers are usually lowercase. HTTP/1.1 headers should be treated as case insensitive, but browsers usually use "Pascal Case" (e.g. Content-Type). 

Duplicate headers may show up, even if they are not allowed, and middleware may blindly "combine" them. 

As of June 2012, the "X-" prefix is no longer supposed to be used for non-standard headers [RFC 6648]. However, this RFC has been widely ignored. IANA maintains a list of HTTP headers: https://www.iana.org/assignments/http-fields/http-fields.xhtml. 

RFC7230 allows a client to send multiple copies of some headers, and the proxy may combine them in one header, eliminating the value of each header with a comma. But remember, standards are flexible. The "Referer" header is supposed to show up only once, but typically, multiple copies will happily be accepted and combined into a nonstandard compliant comma-separated list.

In short, Be VERY VERY careful using headers for anything authorization-related. JWTs are a good standard-based solution, but they must be implemented carefully, just like any authorization solution. Any non-standard header should be treated with suspicion, just like a nonstandard encryption or authentication algorithm.

[1] https://nextjs.org/blog/cve-2025-29927
[2] https://www.ghacks.net/2008/05/02/apple-and-att-will-learn-that-user-agents-are-no-good-for-access-control/
[3]https://www.fastcompany.com/1659772/att-defends-ipad-email-address-hack
[4] https://github.com/GoogleCloudPlatform/esp-v2/security/advisories/GHSA-6qmp-9p95-fc5f
[5] https://github.com/goauthentik/authentik/security/advisories/GHSA-7jxf-mmg9-9hg7

---
Johannes B. Ullrich, Ph.D. , Dean of Research, SANS.edu
Twitter|