<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Unsafe-Inline on CSP Guide</title>
    <link>https://csp-guide.com/tags/unsafe-inline/</link>
    <description>Recent content in Unsafe-Inline on CSP Guide</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Thu, 06 Aug 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://csp-guide.com/tags/unsafe-inline/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Migrate from unsafe-inline to nonce-based CSP</title>
      <link>https://csp-guide.com/posts/how-to-migrate-from-unsafe-inline-to-nonce-based-csp/</link>
      <pubDate>Thu, 06 Aug 2026 00:00:00 +0000</pubDate>
      
      <guid>https://csp-guide.com/posts/how-to-migrate-from-unsafe-inline-to-nonce-based-csp/</guid>
      
      <description>&lt;p&gt;If your CSP still depends on &lt;code&gt;&#39;unsafe-inline&#39;&lt;/code&gt;, you’re carrying a security exception that attackers love.&lt;/p&gt;
&lt;p&gt;I get why teams keep it around. Inline scripts are everywhere: templating fragments, analytics snippets, consent tools, framework hydration blobs, old event handlers, quick fixes nobody wants to touch. Removing &lt;code&gt;&#39;unsafe-inline&#39;&lt;/code&gt; sounds simple until you open the codebase and realize half the frontend was assembled by three generations of developers and two marketing vendors.&lt;/p&gt;
&lt;p&gt;Nonce-based CSP is usually the cleanest migration path when you can’t immediately externalize every script. It lets you keep some inline scripts, but only the ones you explicitly bless per request. That’s a huge improvement over allowing all inline JavaScript.&lt;/p&gt;</description>
      
    </item>
    
  </channel>
</rss>
