Imagine this scenario: your application makes an HTTP request to an API with an Authorization header. The API responds with a 301 redirect to a different domain. Your HTTP library follows the redirect automatically. Question: does the Authorization header get sent to the new domain as well?
If you answered "no, obviously it gets stripped" - you are right in theory. RFC 7235 is clear: credentials should not be sent to domains different from the original one. But in practice, many of the world's most used HTTP libraries do not implement this behavior correctly. And this is exactly the pattern I discovered in my vulnerability research campaign.
The anatomy of the bug
The problem is subtle. Most libraries handle the base case correctly - a cross-domain redirect strips sensitive headers. But what about a redirect from HTTPS to HTTP on the same domain? Or a redirect that goes through an intermediary? Or a redirect with a specifically crafted path? Edge cases are where bugs hide.
In some cases, I found that custom authentication headers (not the standard Authorization, but proprietary headers like X-API-Key or X-Auth-Token) were preserved across all redirects without any checks. A developer might think they are safe because they use a custom header, but the library does not know that header is sensitive.
The practical impact: if an attacker controls an endpoint that can respond with a redirect, they could collect credentials from any application using that library for authenticated requests. In cloud contexts, where redirects between services are common, this pattern becomes particularly dangerous.
If you want to dive deeper into this topic or need specialized consulting, let us talk.
Let's talk →