Skip to content

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

Closed

Description

@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:

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).

Activity

  1. added theissue type on Jul 20, 2026
  2. self-assigned this
    on Jul 20, 2026
  3. jevansnyc commented on Jul 20, 2026

    @jevansnyc
    Collaborator

    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.

  4. added a commit that references this issue on Jul 30, 2026
    67b89e9
  5. added this to the 202607 milestone on Aug 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

Projects

No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions