Content Security Policy Configuration

A Content Security Policy can affect your Rokt Ads integration in two independent ways. The first is outbound: your CSP determines whether your pages can load the Rokt SDK and send events to Rokt. The second is inbound: your CSP determines which sites are allowed to load your page inside an iframe, which applies when your offer runs as an embedded experience on a partner site. The two use different directives, are often owned by different teams, and are configured independently. Allowing one does not allow the other.

Direction	What it controls	CSP directive	When you need it
Outbound	Whether your page can load the Rokt SDK and send events to Rokt	script-src, connect-src	Any Web SDK integration, if your CSP restricts these directives
Inbound	Whether Rokt can present your page inside an iframe on a partner site	frame-ancestors	Embedded experiences, where the customer completes your funnel inside a Rokt placement

This page walks through both.

remarque

The changes below are usually made by the team that owns your web server or CDN configuration rather than the team integrating the SDK. If you need further assistance, please contact your Rokt account manager.

remarque

This page is for advertisers. If you are a partner hosting Rokt placements on your own site, see Web SDK security for the directives that apply to your page.

Allowing the Rokt SDK to load and send data

If your CSP defines script-src, the browser refuses to load the Rokt SDK script unless Rokt's domains are on the list. If it defines connect-src (or a default-src that connect-src falls back to), the SDK may load but its event and identity calls are blocked. In both cases the browser console reports what happened, with Refused to load or Refused to connect errors that name the directive responsible.

To resolve this, add the Rokt domains to the directives you already define:

script-src https://apps.rokt.com https://apps.rokt-api.com https://apps.roktecommerce.com;
connect-src https://apps.rokt.com https://apps.rokt-api.com https://apps.roktecommerce.com;

apps.rokt-api.com is the primary domain the SDK loads from and talks to. apps.roktecommerce.com is the fallback it tries when the primary is unreachable. Include both, even though you will rarely see the fallback in use.

remarque

Only modify the directives your policy already defines. If your CSP has no script-src, connect-src, or default-src, nothing is being blocked and there is nothing to change here.

If you use a first-party domain

If you route the SDK through your own subdomain using the first-party domain configuration, the SDK loads from and sends events to that subdomain instead. Add your custom subdomain to script-src and connect-src, and keep the Rokt domains listed too, since the SDK falls back to them if your subdomain stops responding.

If your CSP cannot allow third-party scripts at all

Some advertisers, particularly in regulated industries, run a CSP that blocks third-party JavaScript entirely but still allows image requests. If that applies to you, the Pixel Service is designed for this situation.

Allowing Rokt to embed your page

What an embedded experience is

With an embedded experience, your sign-up, application, or account-opening page is presented directly inside a Rokt placement on a partner site, usually at a high-intent moment like the payment or order confirmation page. Instead of clicking your offer and being redirected to your site, the customer completes your existing flow right there, without leaving the partner's page.

Mechanically, your page URL is configured in the Rokt platform, and the placement renders it in a sandboxed cross-origin iframe inside the placement container on the partner's page. Your page keeps its own origin and runs unchanged. You keep full control over the form, the branched flows, and the decision states, exactly as in your redirect flow. The sandbox enforces isolation in both directions: the partner's page cannot reach into your content, and your content cannot reach into theirs.

Your page should render responsively within the placement container dimensions:

• Desktop: width min(1024px, calc(100% - 128px)), height min(900px, calc(100% - 128px))
• Mobile (768px screen width and smaller): width 99%, height 90%, anchored to the bottom of the viewport

The CSP change described in this section is one of four pieces that make an embedded experience work:

#	Requirement	Summary
1	iframe-renderable URL	Your page loads in a cross-origin iframe and renders responsively within the container dimensions above.
2	CSP frame-ancestors	Your page allows the Rokt and partner origins to frame it. This is the subject of this section.
3	Rokt Web SDK	Your page runs the standard Web SDK integration. The page views and conversion events you already log give the placement everything it needs to track progress and decision states, including instant reward fulfilment on approval where an incentive is enabled. No additional integration code is required.
4	Conversion tracking	Real-time conversions are tracked through the Web SDK conversion event. Delayed decisions are reported through your existing close-the-loop integration, such as the Event API.

Your Rokt account manager will provide the full integration specification for the rest, along with the complete, current list of origins for your frame-ancestors directive, and will keep that list up to date as partner sites are added.

How browsers control framing

When one page loads another inside an iframe, the browser checks the response headers of the page being framed to decide whether framing is allowed. Two headers can carry that permission:

• Content-Security-Policy: frame-ancestors ... is the modern mechanism. It takes a list of origins that are allowed to frame the page, so it can allow specific partners while continuing to block everyone else. This is what Rokt integrations use.
• X-Frame-Options is the legacy mechanism. It supports only all-or-nothing values (DENY, SAMEORIGIN), so it cannot allow a specific partner like Rokt. If your page sends this header, it needs to be replaced with a frame-ancestors directive before an embedded experience can render.

If your page sends neither header, any site can frame it today, and there is nothing you need to change to launch.

remarque

frame-ancestors does not inherit from default-src. If your CSP defines default-src but no frame-ancestors, framing is unrestricted. Adding frame-ancestors is an addition to your existing policy, not a change to any directive you already have.

Why every origin in the chain matters

Your page does not sit directly inside the partner's page. It sits inside the Rokt placement, which sits inside the partner's page, and the browser checks your frame-ancestors list against every origin in that chain, not just the immediate parent. If any origin in the chain is missing from the list, the browser refuses to render your page.

In practice the list has three groups of entries:

1. Your own origin. Include 'self' and your sign-up domain, for example https://*.yourdomain.com. Your page needs this even without a Rokt integration.
2. Rokt domains. These are stable and the same for every integration (see below).
3. Partner sites where your offer runs. These are the publisher domains that host the placement. Rokt provides this list and keeps it current for you.

Rokt domains

The simplest form uses wildcards:

https://*.rokt.com
https://*.rokt-api.com
https://roktdemo.com

Make sure https://*.rokt-api.com is included. It is used by the current Rokt SDK, and policies written against earlier guidance sometimes leave it out. Without it, the latest SDK is blocked.

If your security team does not allow wildcards

Some teams prefer not to permit wildcard subdomains. If that applies to you, drop the wildcard entries and use the explicit Rokt domains instead:

https://wsdk.rokt.com
https://apps.rokt.com
https://apps.rokt-api.com
https://playground.rokt.com
https://apps.stage.rokt.com
https://apps.stage.rokt-api.com
https://playground.stage.rokt.com
https://apps-demo.rokt.com
https://roktdemo.com

The partner entries are still needed, and your account manager can provide those in an explicit, non-wildcard form as well.

Partner domains

The publisher domains that host your offer are specific to your campaign and change as Rokt adds partners, so we do not publish them here. Your account manager will send you the complete frame-ancestors value, ready to deploy, and updated entries whenever the partner list changes.

For each partner you will usually see both the bare domain and a wildcard form. Both are included so the policy holds whether or not a given site serves traffic from www. You can keep both, or ask your account manager to confirm the exact form each partner uses and trim the list down.

Checking your current policy

Before changing anything, look at what your page actually sends today. Check the real funnel page (the sign-up or application URL itself), not the homepage, because policies often differ by path.

1. Open your funnel page in a browser.
2. Open the developer tools panel and select the Network tab.
3. Reload the page and select the first request (type document).
4. Under Response Headers, look for x-frame-options and content-security-policy.

For the SDK direction, check whether script-src, connect-src, or default-src appear in the policy and whether the Rokt domains are in them. The Console tab makes this easy: if the SDK is being blocked, you will see Refused to load or Refused to connect errors spelling out which directive is responsible.

For framing, what you find maps directly onto what to do next:

What your page sends	What it means	What to do
No X-Frame-Options, no frame-ancestors	Framing is unrestricted	Nothing required to launch. You can optionally add frame-ancestors with the Rokt and partner entries for tighter control.
frame-ancestors with an allowlist	Only the listed origins can frame your page	Add the Rokt and partner entries to your existing list.
frame-ancestors 'none'	All framing is blocked	Replace 'none' with the allowlist of origins from your account manager.
X-Frame-Options: SAMEORIGIN or DENY	Legacy header, all-or-nothing	Remove the header and use a frame-ancestors allowlist instead. All modern browsers support frame-ancestors, and it takes precedence when both are present.

remarque

Command-line tools such as curl sometimes return a bot-protection challenge rather than your application's real headers, because the protection layer answers before your application does. The browser method above always reflects what a real user receives.

Deploying the change

Where the header is set depends on your stack. It might be your CDN or edge configuration (CloudFront, Cloudflare, Akamai), your web server (nginx, Apache), or the application framework itself. Wherever it is, only add the Rokt entries to the directives discussed on this page and leave everything else in your policy unchanged.

If your CSP is set in a <meta http-equiv> tag, note that frame-ancestors is silently ignored there. Browsers only honor it as an HTTP response header.

Quick checklist

SDK loading and data collection (all Web SDK integrations):

• If your CSP defines script-src, the Rokt domains are present
• If your CSP defines connect-src or default-src, the Rokt domains are present
• If you use a first-party domain, your custom subdomain is present in both
• No Refused to load or Refused to connect errors in the browser console on your funnel pages

Embedding (embedded experiences only):

• 'self' and your own sign-up domain are present in frame-ancestors
• https://*.rokt.com is present (or the explicit Rokt domains listed above)
• https://*.rokt-api.com is present (required by the current SDK)
• https://roktdemo.com is present
• The partner domains provided by your account manager are present
• Any X-Frame-Options header has been removed from the funnel pages
• The change is verified on the funnel URL itself, not just the homepage