---
title: "CSP Configuration for the OneTrust CMP"
canonical_url: https://ot.webclat.com/guides/content-security-policy-for-onetrust-cmp
description: "A strict Content-Security-Policy can silently block the OneTrust CMP itself unless its script, API, and asset domains are explicitly allowed - here's the checklist and how to verify it."
source: Webclat | OneTrust Solutions (OneTrust partner, independent consultancy)
---

# Content Security Policy configuration for the OneTrust CMP

**What it is:** OneTrust's CMP script calls a specific set of domains at runtime - the script origin itself, the API/logging origin that receives consent choices, and a CDN origin serving rule and consent-string data. Under a strict Content-Security-Policy, none of those calls are allowed by default, so the CMP either fails to load entirely (worst case: no banner, no consent gate, and other tags firing unconstrained) or throws CSP violations that mask the real problem underneath.

## When you need it

- Your security team is introducing or tightening a Content-Security-Policy on a site where OneTrust is already live, and hasn't yet accounted for the CMP's own domain requirements.
- You're standing up OneTrust for the first time on a site that already enforces a strict CSP.
- A CSP hardening pass is planned and needs a checklist item for the CMP specifically, since it's easy to overlook as "just another script" during a general audit.

## How to implement it

1. **Inventory every domain OneTrust's script actually calls at runtime** - The exact hostnames are tenant- and region-specific, so verify against current OneTrust docs or your own browser Network panel rather than assuming a fixed, universal list.

2. **Add each domain to the correct CSP directive** - script-src for the loader script itself, connect-src for its XHR/fetch calls to the API and logging origin, and frame-src / img-src if your configuration embeds a preference-center iframe or logo assets.

3. **Confirm the OneTrust script tag carries your CSP's nonce, if you're using one** - A nonce-based or strict-dynamic CSP blocks any script tag without the matching nonce, the OneTrust loader included - it isn't exempt just because it's a third-party consent tool.

4. **Roll out via Content-Security-Policy-Report-Only first, if your infrastructure supports it** - A report-only rollout surfaces a missed OneTrust domain through violation reports before it becomes a real, user-facing block.

5. **Re-check the allowance list after any OneTrust configuration change** - Adding a new vendor script, switching API regions, or enabling a new feature inside OneTrust can introduce a new domain the CSP hasn't accounted for - this isn't a one-time setup task.

## How to verify it worked

- With the CSP enforced (not report-only), open DevTools > Console and confirm there are zero CSP violation entries referencing a OneTrust domain.
- Open DevTools > Network and confirm the banner and its API calls all return normal responses rather than being silently blocked.
- If you rolled out report-only first, check the violation report endpoint across a full day of traffic before switching to enforcing, to catch a domain that's only called on a less common path, like opening the preference center specifically.

## Related

- [How do I load a CMP/consent banner without it becoming the slowest script on the page?](https://ot.webclat.com/qa/consent-banner-hurting-page-performance)
- [OneTrust JavaScript consent events: what to listen for and why](https://ot.webclat.com/guides/onetrust-javascript-consent-events)
- [Stop guessing which tags fire before consent](https://ot.webclat.com/use-cases/stop-guessing-which-tags-fire)

Contact: ot@webclat.com | (813) 694-4451 | https://ot.webclat.com/#contact