An SDK should not forward the Authorization header or cookies when a redirect sends the request to a different origin. Strip credentials at the origin boundary, cap the number of redirects, and let callers opt in to anything broader. Forwarding by default hands your customers' keys to whoever the redirect points at.
Why this matters
APIs redirect for ordinary reasons: a moved resource, a download served from object storage, a regional endpoint. The danger appears when the target host is not the one the caller authenticated to. If your SDK copies the Authorization header onto the next request, the new host receives a working credential.
Mature command line tools already draw this line. The curl manual says Authorization and Cookie headers are explicitly not passed on in HTTP requests when following redirects to other origins, unless the user passes the option named location-trusted. Its documentation for the plain follow option adds that when credentials are given on the command line, curl sends them only to the initial host. That is the behavior to copy: safe by default, with a loudly named switch for the rare case that needs more.
Defining "origin" for your SDK
Use scheme, host and port together, the same triple browsers use. A change in any of them is a different origin. An http to https upgrade on the same host is the one case many teams allow, but if you allow it, decide deliberately and test it, because a downgrade in the other direction must never carry a credential.
Steps to implement safe redirect handling
- Turn off automatic redirect following for authenticated requests, or follow redirects in your own code so you control each hop.
- On each hop, compare the origin of the new location with the origin of the original request.
- If the origin differs, remove Authorization, Cookie, and any custom header that carries a credential, such as an API key header.
- Refuse redirects to a different scheme that lowers security, for example https to http.
- Set a maximum number of redirects and fail with a clear error when it is exceeded.
- For file downloads that redirect to storage, expect that the storage URL carries its own short lived signature, and call it without your API credential.
- Write tests with a local server that redirects to a second port, and assert the second request has no credential headers.
What a regression looks like
Teams often get this right in one HTTP client and wrong in another. An SDK that wraps two transports, or that swaps its HTTP library in a major release, can quietly change redirect behavior. Pin the behavior with the test in step 7 so a dependency update cannot undo it unnoticed. Record the rule in your changelog when you tighten it, because some customers may rely on the old behavior through a vanity domain or proxy.
What to tell customers
Document that the SDK drops credentials on cross origin redirects, and show how to opt in if they run their own gateway on a second domain. Make the opt in name explicit, something like trust redirects to these hosts, and take an allowlist rather than a boolean. An allowlist limits the blast radius if the option is set carelessly.
Quick check
Is an http to https redirect on the same host a different origin?
Yes, by the usual definition the scheme is part of the origin. Many clients still allow the upgrade; decide on purpose and test it.
Should the redirect limit be unlimited for convenience?
No. A cap prevents redirect loops and gives attackers less room. Fail with a clear error when it is hit.
Safeguard's dependency scanning and SBOM inventory can show which HTTP client libraries sit under your SDK and which versions customers run, which helps when one of them changes redirect behavior. You can start with the free scan.
Sources
Last reviewed: 19 October 2026.
