<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Onetrust on CSP Guide</title>
    <link>https://csp-guide.com/tags/onetrust/</link>
    <description>Recent content in Onetrust on CSP Guide</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Fri, 03 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://csp-guide.com/tags/onetrust/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>CSP for OneTrust cookie consent: a real-world fix</title>
      <link>https://csp-guide.com/posts/csp-for-onetrust-cookie-consent/</link>
      <pubDate>Fri, 03 Jul 2026 00:00:00 +0000</pubDate>
      
      <guid>https://csp-guide.com/posts/csp-for-onetrust-cookie-consent/</guid>
      
      <description>&lt;p&gt;Cookie consent banners are one of the fastest ways to wreck an otherwise clean Content Security Policy.&lt;/p&gt;
&lt;p&gt;I’ve seen teams lock down &lt;code&gt;script-src&lt;/code&gt;, remove &lt;code&gt;unsafe-inline&lt;/code&gt;, pat themselves on the back, then ship OneTrust and immediately flood the console with CSP violations. The banner does not show, consent does not save, analytics gets weird, and somebody suggests adding &lt;code&gt;https:&lt;/code&gt; everywhere until the errors go away. That usually “works,” and also defeats half the reason you had a CSP in the first place.&lt;/p&gt;</description>
      
    </item>
    
  </channel>
</rss>
