fix: strip provider response headers

[TejasGhatte]

Summary

Fixes a security vulnerability where provider API key headers injected by Bifrost upstream were being echoed back to clients in response headers. This was identified as a regression in the /genai_passthrough endpoint where x-goog-api-key values were leaking to clients (e.g., via Google's file-download 302 redirects).

fixes #3954

Changes

• Added x-goog-api-key, x-api-key, and api-key to the providerResponseFilterHeaders blocklist so they are stripped from upstream responses before being forwarded to clients.
• Added a regression test TestExtractProviderResponseHeaders_StripsProviderSecrets that verifies all four sensitive headers (x-goog-api-key, x-api-key, api-key, authorization) are stripped while benign headers like x-request-id are preserved.

Type of change

• Bug fix
• Feature
• Refactor
• Documentation
• Chore/CI

Affected areas

• Core (Go)
• Transports (HTTP)
• Providers/Integrations
• Plugins
• UI (React)
• Docs

How to test

go test ./core/providers/utils/... -run TestExtractProviderResponseHeaders_StripsProviderSecrets -v

Expected output: the test passes, confirming that x-goog-api-key, x-api-key, api-key, and authorization are absent from the extracted response headers map, and that x-request-id is preserved.

Screenshots/Recordings

N/A

Breaking changes

• Yes
• No

Related issues

Regression fix for x-goog-api-key leak via /genai_passthrough.

Security considerations

This patch closes a credential leak where provider API keys (x-goog-api-key, x-api-key, api-key) injected into upstream requests could be reflected back to end clients in HTTP response headers. Any client receiving these responses prior to this fix may have been exposed to the upstream provider credentials. No new secrets or auth mechanisms are introduced.

Checklist

• I read docs/contributing/README.md and followed the guidelines
• I added/updated tests where appropriate
• I updated documentation where needed
• I verified builds succeed (Go and UI)
• I verified the CI pipeline passes locally if applicable

Summary by CodeRabbit

• Bug Fixes

  • API key and authentication headers (case-insensitive) are now filtered from provider responses to prevent exposure of sensitive credentials to clients.
  • Legitimate non-sensitive response headers are preserved to maintain request tracing and debugging.

• Tests

  • Added a test that verifies sensitive provider headers are stripped while ensuring benign headers remain intact.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro

Run ID: 2eb39506-fb19-46c4-9a15-4658147d5039

📥 Commits

Reviewing files that changed from the base of the PR and between d9fe7d0 and 5d788af.

📒 Files selected for processing (2)

• core/providers/utils/utils.go
• core/providers/utils/utils_test.go

---

📝 Walkthrough

Walkthrough

Adds x-goog-api-key, x-api-key, and api-key to the provider response header filter so ExtractProviderResponseHeaders (fasthttp/net/http) omits them when building client-facing headers. A new test verifies case-insensitive removal of those secret headers while preserving benign headers like x-request-id.

Changes

API Key Header Filtering

Layer / File(s)	Summary
Filter provider API key headers core/providers/utils/utils.go, core/providers/utils/utils_test.go	providerResponseFilterHeaders extended to include x-goog-api-key, x-api-key, and api-key. Test TestExtractProviderResponseHeaders_StripsProviderSecrets verifies these and other secret headers (e.g., authorization) are removed case-insensitively while x-request-id remains.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Suggested reviewers

• akshaydeo
• danpiths

Poem

🐰 I nibble through headers late at night,
I hide the keys from prying sight,
Filters hum, secrets cease to peep,
The harmless tags I gently keep,
Hooray — no tokens hop away tonight!

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 50.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely summarizes the main change: stripping provider response headers that contain sensitive API keys to fix a security vulnerability.
Description check	✅ Passed	The PR description comprehensively covers all required template sections including summary, changes, type, affected areas, testing instructions, security considerations, and a completed checklist.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch 06-01-fix_strip_provider_response_headers

Warning

There were issues while running some tools. Please review the errors and either fix the tool's configuration or disable the tool if it's a critical failure.

🔧 golangci-lint (2.12.2)

level=error msg="[linters_context] typechecking error: pattern ./...: directory prefix . does not contain main module or its selected dependencies"

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

---

tejas ghatte seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[TejasGhatte]

• fix: strip provider response headers #3955 👈 (View in Graphite)
• dev

This stack of pull requests is managed by Graphite. Learn more about stacking.

[greptile-apps]

Confidence Score: 5/5

Safe to merge — the change is a targeted, additive blocklist update that closes a real credential-leak path with no behavioral side effects on the normal request flow.

The diff is minimal: three new entries added to an existing filter map used by both response-header extraction paths. The logic is straightforward (map lookup on lower-cased key), the existing authorization entry confirms the pattern is already established, and the new regression test confirms the fasthttp path strips all four secret headers as intended. No concurrency concerns, no pooled-object changes, no new external dependencies.

No files require special attention.

Important Files Changed

Filename	Overview
core/providers/utils/utils.go	Adds x-goog-api-key, x-api-key, and api-key to the providerResponseFilterHeaders blocklist; both ExtractProviderResponseHeaders and ExtractProviderResponseHeadersFromHTTP now strip these headers via the shared map.
core/providers/utils/utils_test.go	Adds TestExtractProviderResponseHeaders_StripsProviderSecrets covering the fasthttp path; verifies all four secret headers are stripped and benign headers are preserved.

_{Reviews (2): Last reviewed commit: "fix: strip provider response headers" | Re-trigger Greptile}

[akshaydeo]

Merge activity

• Jun 2, 7:04 AM UTC: A user started a stack merge that includes this pull request via Graphite.
• Jun 2, 7:04 AM UTC: @akshaydeo merged this pull request with Graphite.