Stop forwarding Authorization header to third-party integration APIs#833
Merged
Conversation
The integration API proxies forwarded the publisher site's `Authorization`
header (e.g. a staging basic-auth credential) to the third-party upstream.
The Lockr API rejects any request carrying an unexpected `Authorization`
with `{"success":false,"error":{"code":400,"message":"Invalid request"}}`,
which short-circuits the SDK's `getAIMSettings()` init — no settings data,
no page-view, no identity tokens — on any deployment behind site auth.
Forwarding it also leaks the publisher credential to the third party.
Auditing the other integrations found the same copy-paste in permutive and
didomi; sourcepoint already omits it intentionally; datadome, prebid, and
gpt never forwarded it. Stop forwarding `Authorization` in lockr, permutive,
and didomi to match sourcepoint.
Add a regression test asserting the Lockr proxy forwards the POST body and
content-type but strips `Authorization`, and record outgoing request bodies
in the stub HTTP client so the test can assert on them.
aram356
force-pushed
the
test-lockr-proxy-forwards-post-body
branch
from
7866e22 to
663caf2
Compare
aram356
changed the title
ChristianPavilonis
approved these changes
Jul 1, 2026
ChristianPavilonis
left a comment
ChristianPavilonis
left a comment
Collaborator
There was a problem hiding this comment.
Summary
Reviewed the Trusted Server PR that strips Authorization from Lockr, Permutive, and Didomi integration proxies. The direction looks correct and CI is green. I am approving as requested, with inline notes for a remaining Lockr cookie-forwarding credential-leak risk and follow-up test coverage/test-infrastructure hardening.
…, surface stub body-capture errors - Lockr: stop forwarding the publisher `Cookie` header to the upstream. Under the first-party proxy the browser attaches publisher session/auth cookies to `/integrations/lockr/api/...`; forwarding them (minus only consent names) is the same credential-leak class as `Authorization`. The SDK already sends the identity cookie data it needs in the request body, so no `Cookie` is required. Removes the now-unused `copy_cookie_header` (which also forwarded unparseable cookie headers verbatim). - Add Permutive and Didomi regression tests asserting `Authorization` is not forwarded upstream, so a future allowlist edit can't silently reintroduce the leak. - Extend the Lockr test to assert the `Cookie` header is stripped too. - StubHttpClient: propagate request-body capture failures instead of recording an empty body, so tests can't mistake a capture failure for an empty body.
prk-Jr
approved these changes
Jul 1, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Root cause (verified with a local
fastly compute servereproduction)The integration API proxies forward the publisher site's
Authorizationheader (e.g. a staging basic-auth credential) to the third-party upstream. The Lockr API rejects any request carrying an unexpectedAuthorization:{"success":false,"error":{"code":400,"message":"Invalid request"}}This short-circuits the SDK's
getAIMSettings()init (which gates onsuccess && data) — no settings data, nopvStatus, nopage-view, no identity tokens — on any deployment served behind site auth. It also leaks the publisher credential to the third party.How it was confirmed
success; adding only anAuthorizationheader flips it to the exact400 Invalid request. Missing Origin returns500, missing body/content-type returns400from a different cause — both ruled out.fastly compute serve(legacy path, lockr enabled) reproduced the400; debug logging showed the proxy puttingauthorizationon the outbound wire. Removing it → upstream no longer returns the400.This corrects two earlier misdiagnoses (Origin — PR #831, closed; POST body — the original framing of this PR). The body and content-type were always forwarded correctly.
Fix
Stop forwarding
Authorizationin lockr, permutive, and didomi.Audit of all integration proxies:
Authorization?Tests
lockr_proxy_forwards_body_and_strips_authorization: asserts the proxy forwards the POST body + content-type but stripsAuthorization. Extends the stub HTTP client to record outgoing request bodies.cargo test -p trusted-server-core— 1455 passed;fmt+clippyclean.Fixes #832