fix(fetch): reject unsupported sensitiveHeaders configurations - #11425

Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At PRE_RELEASE_DOCS.md, line 29:

<comment>Qualify this rejection rule as applying to an own `sensitiveHeaders` property and document that inherited properties are ignored. Otherwise the release documentation can claim rejection for configurations the adapter intentionally treats as absent.</comment>

<file context>
@@ -20,6 +20,16 @@ Do not store raw diffs or line-number-only instructions here; prefer stable sect
+- **Source:** The Fetch `sensitiveHeaders` entry in `PRE_RELEASE_CHANGELOG.md`.
+- **Status:** Pending.
+- **Docs targets:** `README.md` Request config and custom secret-bearing header example; `docs/pages/advanced/request-config.md`, `docs/pages/advanced/fetch-adapter.md`, and `docs/pages/advanced/security.md`, with their Spanish, French, and Chinese translations; `THREATMODEL.md` T-R2.
+- **Required content:** Clarify that custom redirect-header stripping is supported only by the Node HTTP adapter, rather than by every adapter running in Node. A non-empty array with `adapter: 'fetch'` rejects with `AxiosError.ERR_NOT_SUPPORT`, including with custom `env.fetch` implementations. Omitted, `null`, and empty arrays remain no-ops. Fetch delegates redirects to the runtime and cannot strip caller-selected headers between hops. Callers requiring this protection should explicitly select `adapter: 'http'` where available or avoid sending the custom secret header; do not recommend removing `sensitiveHeaders` while retaining the secret header.
+- **Examples:** Add `adapter: 'http'` to the existing `X-API-Key`/`sensitiveHeaders` example. Show checking `axios.isAxiosError(error)` and `error.code === 'ERR_NOT_SUPPORT'` when handling an unsupported configuration.
+- **Notes:** No declaration shape or runtime export changes are required. Document the intentional compatibility change: previously accepted fetch requests with this option now reject rather than proceeding without the requested protection.
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At PRE_RELEASE_DOCS.md, line 28:

<comment>The security documentation target points to a nonexistent section, so release preparation will miss the existing security page. Replace `advanced/security.md` with `misc/security.md` and use the corresponding translated paths.</comment>

<file context>
@@ -20,6 +20,16 @@ Do not store raw diffs or line-number-only instructions here; prefer stable sect
+- **Change:** The fetch adapter rejects non-empty `sensitiveHeaders` arrays before sending a request instead of silently ignoring them.
+- **Source:** The Fetch `sensitiveHeaders` entry in `PRE_RELEASE_CHANGELOG.md`.
+- **Status:** Pending.
+- **Docs targets:** `README.md` Request config and custom secret-bearing header example; `docs/pages/advanced/request-config.md`, `docs/pages/advanced/fetch-adapter.md`, and `docs/pages/advanced/security.md`, with their Spanish, French, and Chinese translations; `THREATMODEL.md` T-R2.
+- **Required content:** Clarify that custom redirect-header stripping is supported only by the Node HTTP adapter, rather than by every adapter running in Node. A non-empty array with `adapter: 'fetch'` rejects with `AxiosError.ERR_NOT_SUPPORT`, including with custom `env.fetch` implementations. Omitted, `null`, and empty arrays remain no-ops. Fetch delegates redirects to the runtime and cannot strip caller-selected headers between hops. Callers requiring this protection should explicitly select `adapter: 'http'` where available or avoid sending the custom secret header; do not recommend removing `sensitiveHeaders` while retaining the secret header.
+- **Examples:** Add `adapter: 'http'` to the existing `X-API-Key`/`sensitiveHeaders` example. Show checking `axios.isAxiosError(error)` and `error.code === 'ERR_NOT_SUPPORT'` when handling an unsupported configuration.
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At lib/adapters/fetch.js, line 239:

<comment>A non-null invalid value such as `sensitiveHeaders: 'X-API-Key'` bypasses this check, so fetch silently sends the secret through redirects without protection. Reject malformed values here, as the HTTP adapter does.</comment>

<file context>
@@ -234,6 +234,16 @@ const factory = (env) => {
 
+    // Native fetch handles redirects without exposing each hop to strip custom headers.
+    const sensitiveHeaders = own('sensitiveHeaders');
+    if (utils.isArray(sensitiveHeaders) && sensitiveHeaders.length > 0) {
+      throw new AxiosError(
+        'sensitiveHeaders is not supported by the fetch adapter; it is only honored by the http adapter',
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. When an issue isn't valid or won't be fixed in this PR, reply in its thread with the reason and then resolve the thread. At tests/unit/adapters/fetch.test.js, line 58:

<comment>The test leaks `target` when the second server cannot start because acquisition happens before `try`. Start both servers inside the protected setup or add an outer cleanup path so setup failures cannot leave a listening server behind.</comment>

<file context>
@@ -52,6 +52,103 @@ const createBrokenDOMExceptionLikeError = () =>
+  describe('sensitiveHeaders', () => {
+    it('rejects before sending a secret to a cross-origin redirect', async () => {
+      const received = [];
+      const target = await startHTTPServer((req, res) => {
+        received.push(req.headers['x-api-key']);
+        res.end('ok');
</file context>