Content Security Policies (CSPs) and Zync Tags

This page explains what a Content Security Policy (CSP) is, why it may impact Zeta tags (including Zync and enabled solutions), and how to plan and validate CSP changes for a successful deployment.

Summary

A Content Security Policy (CSP) restricts where a website can load resources from (scripts, pixels, network calls, frames, and more). If a CSP is too restrictive, Zeta tags may be blocked from loading or from making downstream calls required for measurement and functionality.

Most clients succeed with an allowlist-based CSP and, where needed, a nonce-based CSP. In most cases, SHA-256 hash–only CSP models are not compatible at scale with tag-container deployments such as Zync.

What is a Content Security Policy (CSP)?

A Content Security Policy (CSP) helps protect websites from threats such as cross-site scripting (XSS) and unauthorized content injection. CSP is enforced by the browser and defines which sources are allowed for different types of resources, including:

• Scripts (script-src)

• Network requests / APIs / beacons (connect-src)

• Images and pixels (img-src)

• Iframes (frame-src or child-src)

• Styles and fonts (style-src, font-src)

If the browser attempts to load a resource that isn’t permitted by the policy, it will block it and typically log a CSP violation in the browser console.

Why CSP can impact Zeta tag deployments

Zeta tags support common marketing and measurement workflows. Depending on your enabled Zeta products and configuration, a deployment may require the ability to:

• load one or more scripts,

• send data to approved endpoints,

• fire pixels,

• and (in some cases) load framed content.

Because CSP controls these resource types separately, it’s possible for a tag to load successfully but still fail downstream if a required destination is blocked under a different directive.

Recommended CSP approach for Zeta deployments

1) Allowlist-based CSP

Allowlist-based CSP is typically the best fit for Zeta deployments. With this model, you explicitly allow only the sources required for your configuration under the appropriate directives.

Best practice: apply least privilege, allow only what is required based on your enabled Zeta functionality and validation results.

2) Nonce-based CSP (when inline scripts are restricted)

Some sites use a nonce-based CSP, where inline scripts can run only if they include a server-generated nonce value. If your site uses nonces, your deployment mechanism (for example, a tag manager) must retrieve and apply that nonce consistently.

If you use nonces, plan for:

• how the nonce is generated server-side,

• how your tag manager retrieves it, and

• how it is applied to required scripts (including any dynamically created script elements where applicable).

3) SHA-256 hash–only CSP (often incompatible at scale)

A hash-based CSP model allows inline scripts only if their exact text matches a pre-approved SHA-256 hash value. In practice, this approach is highly restrictive and requires ongoing maintenance whenever scripts change (even minor formatting changes can invalidate the hash).

What we need from you to provide CSP guidance

Required sources vary depending on which Zeta products and features are enabled, so we do not publish a single universal domain list. To provide accurate recommendations for your deployment, please share:

Your CSP policy

• Content-Security-Policy header value

• Content-Security-Policy-Report-Only header value (if present)

• Whether CSP is delivered via response header and/or meta tag

Enforcement mode

• Is CSP enforced or report-only?

Deployment context

• Specify which Zeta products/features are enabled via Zync. If unsure, Zeta’s Digital Operations team can verify for you

• Whether you are using a tag manager, and which one

• Whether your CSP uses nonces or hashes for inline scripts

Validation evidence (preferred)

• Browser console CSP violation messages

• DevTools Network details for blocked requests (URL + resource type)

Suggested rollout process (recommended for clients implementing CSP)

Many organizations already have a CSP in place. If you do, the steps below can still help validate that your existing policy supports your Zeta deployment. If you are introducing CSP for the first time, we recommend the following approach to minimize disruption:

Step 1: Start in Report-Only mode (when possible)

If your security process allows it, enable CSP in Report-Only mode first. This logs violations without blocking resources and helps identify what sources must be added before enforcement.

Step 2: Validate in a non-production environment

Deploy Zeta tags in a staging environment and validate expected behavior (script loads, decisioning/data calls, pixels, and any iframe-based flows where applicable).

Step 3: Update CSP surgically based on evidence

When the browser reports a CSP violation, it typically includes the blocked URL and directive. Add only the necessary sources under the correct directive (for example, script-src vs connect-src vs img-src).

Step 4: Enforce CSP after validation

Once you have confirmed functionality in staging and reviewed violations, move to enforced CSP in production.

How to check whether CSP is blocking Zeta tags

If you suspect CSP is blocking tag execution:

1. Open browser DevTools → Console

• Look for messages containing “Content Security Policy” or “violates the following directive…”

2. Open DevTools → Network

• Look for blocked requests (often labeled as blocked by CSP)

• Confirm whether the blocked request is a script, network call, image/pixel, or frame

3. Map the blocked request to the CSP directive

• script blocked → script-src

• fetch/XHR/beacon blocked → connect-src

• pixel/image blocked → img-src

• iframe blocked → frame-src / child-src

Common CSP failure patterns (what clients typically see)

• Zync appears to load, but personalization/measurement is incomplete: often caused by connect-src (blocked network calls) and/or img-src (blocked pixels).

• Console mentions “nonce required” or “hash/nonce/unsafe-inline required”: your policy restricts inline execution. A nonce-based approach or externalizing scripts is typically required.

• Works on some pages but not others: CSP may differ by template/path, or be applied only on certain site sections (for example, checkout or quote flows).

• Framing/iframe errors: frame-src indicates your policy is blocking embedded content. frame-ancestors often indicates the embedded page is rejecting your site as a parent and may require vendor-side changes.

CSP gotchas (quick sanity checks)

• Origins must match exactly: https://example.com is different from https://www.example.com.

• Wildcard behavior can be surprising: *.example.com may not include example.com (root).

• Directive-specific allowlists: allowing a source in script-src does not allow API calls (connect-src) or pixels (img-src).

• Header vs meta CSP: if CSP is set both as a response header and a meta tag, the combined behavior can be stricter than expected.

Optional: Strict-dynamic CSP (for security teams)

Some organizations use 'strict-dynamic' in script-src with nonces to simplify script loading in modern browsers. This can help with dynamic script loaders, but it does not replace the need to configure connect-src, img-src, or frame-src for data collection, pixels, or frames.

Keep expectations aligned
Even with strict-dynamic, clients still need to allow required destinations for network calls and pixels.

Validation checklist (what “complete” looks like)

Before enforcing CSP changes in production, confirm:

• Zeta tags load on the intended pages

• Required downstream network calls succeed (connect-src)

• Required pixels fire (img-src)

• Any required frames load (frame-src / child-src)

• No CSP console violations for required Zeta functionality during key site flows

Recommended testing scope
Validate on high-traffic pages, and conversion flows (quote/checkout/lead forms), since CSP often differs by template/path.

Support

If you are deploying Zeta tags on a CSP-restricted site, contact your Zeta account team with the information in the “What we need from you to provide CSP guidance” section above. We will provide CSP recommendations tailored to your configuration and enabled capabilities.