Let's Talk About HTTP Headers

Let's Talk About HTTP Headers

Walking my dog earlier, I came across a sign on the right that caught my attention. 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 people do not know them well enough. Just like this sign, proxies and other middleboxes hardly ever stop unsafe behaviors. In this article, let's explore some past vulnerabilities rooted in the misuse of HTTP headers that exemplify common problems.

These are three issues that I think highlight some of the common pitfalls when it comes to using HTTP headers correctly. First and foremost, a user may send whatever header they like without proper authentication, access control, or validation. The first rule of web application security is that users are evil [2]. You MUST authenticate, access control, and validate each request. There are reasonable methods to use HTTP headers for authentication, such as authorization headers and cookies. However, there are common pitfalls that can lead to vulnerabilities like those mentioned below.

1. Verification of Authentication/Authorization Headers

Any authentication or authorization-related header must be verified on the server. For a JWT (JSON Web Token), the signature must be verified properly before using any of the data encoded in the JWT [5]. 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. This is crucial to prevent unauthorized access to sensitive data.

2. Proxies and HTTP Headers

Proxies may or may not modify headers, which can lead to security vulnerabilities if not implemented correctly. One basic "bad pattern" is to have the proxy add a header verifying that a request is authorized [4]. While this can be useful, it must be done properly to prevent an attacker from bypassing the proxy and adding their own malicious headers. Proxies will modify some headers but not others, making it essential to understand the rules for modifying requests and responses.

According to RFCs and guidelines, such as Guidelines for Web Content Transformation Proxies 1.0 [6], there are specific rules around proxies and what they should and should not do with requests and responses. However, compliance is not always guaranteed, and web servers may still accept non-standard headers or methods without proper validation.

For example, some web servers may happily accept an HTTP 1.1 request without a "Host" header [6]. 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.

Common Pitfalls and Best Practices

Some common pitfalls when using HTTP headers include:

  • Duplicate headers may show up, even if they are not allowed, and middleware may blindly "combine" them [6]. As of June 2012, the "X-" prefix is no longer supposed to be used for non-standard headers [7], but this RFC has been widely ignored.
  • 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 [8].
  • Non-standard headers should be treated with suspicion, just like a nonstandard encryption or authentication algorithm [9].

In conclusion, HTTP headers can be a powerful tool for web application security, but they must be used correctly to prevent vulnerabilities. It's essential to understand the rules and guidelines around proxies and HTTP headers and to enforce standards when parsing headers.

References:

  • [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-7gfn-jvyj-nb4t
  • [6] RFC 2617, Section 9.1 [10]
  • [7] https://tools.ietf.org/html/draft-joe-wg-headers-rfc2616-bis
  • [8] https://www.w3.org/Protocols/rfc2616.html#SEC_5.1
  • [9] https://owasp.org/www-pedia/OWASP_Cheat_Sheet

Stay safe online and keep learning about web application security!

Author's note: This article is a summary of common pitfalls and best practices when it comes to using HTTP headers. It's essential to stay up-to-date with the latest guidelines and best practices in web application security.