Injected creatives + IAS brand-safety pixel carry the TS edge host instead of the publisher domain

[aram356]

Summary

On the SSAT inline-creative injection path, the server-side auction builds its OpenRTB Site from the raw incoming Host header (the Trusted Server edge domain, e.g. ts.example.com) instead of the configured publisher domain (www.example.com). As a result, every injected creative and the IAS brand-safety pixel carry the staging edge host, not the real publisher host.

The /auction endpoint path is unaffected — it already sources the host from config — which is why an /auction request capture looks correct while injected creatives do not.

Root cause

There are two AuctionRequest builders that populate publisher.domain / site.domain from opposite sources:

• Correct — convert_tsjs_to_auction_request (crates/trusted-server-core/src/auction/formats.rs:235 and :245) uses settings.publisher.domain (from [publisher] domain config). Used by the /auction endpoint.
• Wrong — build_auction_request (crates/trusted-server-core/src/publisher.rs:3037 and :3051) uses request_info.host, the raw incoming Host header. On the SSAT proxy model that is the TS edge domain.

The wrong builder is called on both navigation paths:

• AuctionSource::InitialNavigation — crates/trusted-server-core/src/publisher.rs:2626
• AuctionSource::SpaNavigation — crates/trusted-server-core/src/publisher.rs:3509

Downstream, PrebidAuctionProvider::request_bids builds the OpenRTB Site directly from these fields (crates/trusted-server-core/src/integrations/prebid.rs:1812-1818), so PBS and any IAS brand-safety integration keyed on site.domain / site.page receive the edge host and reflect it into creative markup and the pixel URL.

Relationship to PR #934

PR #934 ("Fix ext.trusted_server.request_host to use the publisher domain", commit 5d7f696c2) only changed ext.trusted_server.request_host inside the Prebid provider (crates/trusted-server-core/src/integrations/prebid.rs:2274) to read from request.publisher.domain. That does not fix this path, because:

• On the navigation path, request.publisher.domain is itself the poisoned edge host (set by build_auction_request).
• Fix ext.trusted_server.request_host to use the publisher domain #934 never touched site.domain / site.publisher.domain / site.page.

So the leak into injected creatives + the IAS pixel remains.

Note: PR #916 (optional creative rewriting) is unrelated — that rewriter only makes asset URLs relative and is not the source of the host.

Suggested fix

Make build_auction_request (crates/trusted-server-core/src/publisher.rs:3012) source publisher.domain, site.domain, and page_url from settings.publisher.domain — the way convert_tsjs_to_auction_request already does — rather than from request_info.host.

Affected branch

Found on the rc/july release-candidate branch (PR #919).

[jevansnyc]

Confirming this on the live production route, not just rc/july.

Reproduced today on www.prospect-a.com (TS v358, cookie-gated ts-tester=true + basic auth). Injected creatives carry url=https://ts.prospect-a.com/ and the IAS pixel carries custom2=ts.prospect-a.com, exactly as described. The auction itself is healthy (real winning CPMs across ix / msft / ozone / pubmatic / rise), so this is purely the page-context/host leak into creative markup + the IAS pixel. Raising priority since it is shipping in production, not only on the RC branch.

One thing worth pinning down for the fix: the browser request went to www.prospect-a.com (:authority: www.prospect-a.com), yet the creatives carry ts.prospect-a.com. That is consistent with the raw-Host root cause only if the production VCL route presents Host: ts.prospect-a.com to the Compute guest. If the guest instead sees Host: www.prospect-a.com, the ts.prospect-a.com value is coming from a stale settings.publisher.domain in the deployed config, and sourcing site.domain/page from settings.publisher.domain (the suggested fix) would not resolve it on its own.

Suggest verifying both before/with the fix: (1) the Host the Compute guest actually sees on the prod www route, and (2) that the deployed settings.publisher.domain is www.prospect-a.com, not ts.prospect-a.com.