Security: Custom auth headers via SetHeaderAuthorizationKey leak on cross-domain redirect by the underlying Go net/http

[Den-Sec]

Summary

When SetHeaderAuthorizationKey() is used to configure a custom HTTP header name for authentication tokens (e.g., X-API-Key, X-Auth-Token), the credential is leaked to cross-domain redirect targets.

Go's net/http only strips standard sensitive headers (Authorization, Cookie, Proxy-Authorization) on cross-domain redirects. Custom header names configured via resty's SetHeaderAuthorizationKey() are NOT recognized as sensitive and are forwarded verbatim.

Root Cause

• client.go:597 - SetHeaderAuthorizationKey() allows changing the header name
• middleware.go:288 - addCredentials() places auth token in user-configurable header
• redirect.go:97-105 - checkHostAndAddHeaders() copies ALL headers without credential check
• Go's net/http/client.go:814-815 only strips hardcoded headers: Authorization, Cookie, etc.

PoC

Standard 'Authorization' at attacker after redirect: ""              (SECURE - Go strips it)
Custom 'X-API-Key' at attacker after redirect:       "Bearer SECRET" (LEAKED!)

Tested with Go test servers on 127.0.0.1 -> 127.0.0.2 cross-domain redirect. All four custom header names tested (X-API-Key, X-Auth-Token, X-Custom-Authorization, Api-Key) leak credentials.

Comparison

• Python requests: Strips Authorization on domain change
• curl 7.58+: Strips credentials on cross-domain redirect
• Go net/http: Only strips standard headers (same limitation)

Suggested Fix

In SetRedirectPolicy or default CheckRedirect, strip the custom auth header when redirect crosses domain boundaries.

Severity

CWE-200/CWE-522 | CVSS 7.4 High

AI-assisted source code review, manually verified with working PoC.

[jeevatkm]

@Den-Sec, thanks for reaching out.

I reviewed the code. Resty redirect only adds headers when the request hostname matches the previous one; otherwise, it doesn’t add them.

Here’s the relevant section:

resty/redirect.go

Line 100 in 12468ab

if strings.EqualFold(curHostname, preHostname) {

I believe all headers are added by the underlying Go net/http library. In that case, I’m unsure if this is a bug or an enhancement to Resty.

However, adding this functionality would be beneficial for the Resty consumer. I’ll consider the appropriate implementation.

I think the appropriate solution is adding a new Redirect policy, something like RedirectHeaderStripSensitivePolicy.

[Den-Sec]

@jeevatkm Thank you for the detailed review.

You're correct that Go's net/http strips the standard Authorization header on cross-domain redirects (stripSensitiveHeaders in client.go). However, this protection only covers the standard header - it does not cover custom authentication headers set via SetHeaderAuthorizationKey() or SetHeader() with custom key names (e.g., X-API-Key, X-Auth-Token).

This is the exact gap: when users rely on Resty's SetHeaderAuthorizationKey("X-Custom-Auth"), they expect the same redirect safety as SetAuthToken(), but the custom header silently leaks to any domain the server redirects to.

This same vulnerability class has been accepted as a security issue in several other HTTP libraries:

• follow-redirects (GHSA-r4q5-vmmm-2653) - same pattern, accepted
• got (GHSA-xf2q-jg8c-6473) - same pattern, accepted
• dghubble/sling (GHSA-wrhp-qrc7-wmqx) - same pattern in Go, accepted

I'd be happy to submit a PR implementing the RedirectHeaderStripSensitivePolicy you mentioned. A clean approach would be:

1. Track headers set via SetHeaderAuthorizationKey() and SetAuthScheme()
2. Strip those headers on cross-domain redirects (same logic as net/http uses for Authorization)
3. The new policy could be opt-in to avoid breaking changes, or default-on with an escape hatch

Would you prefer this as a security advisory (via GitHub Security Advisory / GHSA) so a CVE can be assigned for proper tracking? This would follow the same process the libraries above used. I'm happy to help draft the advisory as well.

Let me know how you'd like to proceed and I'll have the PR ready.

Best regards,
Dennis Sepede - Securitix Solutions