Integration proxies forward publisher Authorization header to third-party APIs (breaks Lockr)

[aram356]

Summary

The integration API proxies (lockr, permutive, didomi) forward the publisher site's Authorization header — e.g. a staging basic-auth credential — to the third-party upstream. This both leaks the publisher credential and breaks the Lockr API, which rejects any request carrying an unexpected Authorization.

Impact (Lockr)

The settings call returns HTTP 200 with a failure body:

{"success":false,"error":{"code":400,"message":"Invalid request"}}

The SDK's getAIMSettings() only proceeds on success === true && data, so init short-circuits: no settings data, no pvStatus, no page-view, and no identity tokens. This only manifests on deployments served behind site basic-auth (so the browser sends Authorization to the trusted server, which forwards it onward); a direct (no-auth) page works.

Diagnosis (verified)

• Direct upstream replay: a fully-correct request (Origin + content-type + body) succeeds; adding only an Authorization header reproduces the exact 400 Invalid request.
• Local fastly compute serve reproduction (legacy path, lockr enabled) reproduced the 400; the proxy placed authorization on the outbound wire. Removing it cleared the 400.

Earlier hypotheses (missing Origin, dropped POST body) were ruled out — both were forwarded correctly.

Fix

Stop forwarding Authorization to the upstream in lockr, permutive, and didomi (matching sourcepoint, which already omits it intentionally). datadome, prebid, and gpt never forwarded it.

Fixed by #833.