First-party integration URLs leak the routing host instead of being root-relative

[aram356]

Summary

Several integration attribute rewriters (GPT, DataDome, Permutive, Lockr, Sourcepoint) rewrite a publisher's <script src> / <link href> to an absolute first-party URL built from request_host:

format!("{}://{}/integrations/gpt/script", ctx.request_scheme, ctx.request_host)

When request_host is not the page's own host, the wrong host leaks into the rendered HTML. For example, behind a host-rewriting dev proxy the page renders https://ts.example.com/integrations/gpt/script while the address bar shows www.example.com.

Impact

• Integration assets (GPT, DataDome SDK, Permutive, Lockr, Sourcepoint) point at the routing host rather than the production/first-party host.
• Breaks first-party context whenever request_host != the page host — e.g. dev-proxy testing against a staging hostname, or any deployment where the program sees the routing host. X-Forwarded-Host does not reliably fix it (it can be dropped/overwritten at the edge).

Expected

These page-facing first-party URLs should be root-relative (/integrations/...) so the browser resolves them against the page's own host — matching what GTM, Didomi, Testlight, and these integrations' own inline-script rewriters already do.

Root cause

{scheme}://{request_host}/integrations/... in the attribute rewriters:

• gpt.rs (rewrite)
• datadome.rs (rewrite)
• permutive.rs (rewrite)
• lockr.rs (rewrite)
• sourcepoint.rs (build_first_party_url)

Scope

An audit of every integration's page-facing URL emission found these five were the only host leaks. NextJS RSC/flight payload rewriting is intentionally absolute and out of scope; the DataDome protection module's raw-Host read is server-side (validation API body), not page-facing.