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
Want this scoped against your specific OneTrust tenant?
We scope every engagement in discovery, before implementation - no assumptions about your stack.