<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Script-Src on CSP Guide</title>
    <link>https://csp-guide.com/tags/script-src/</link>
    <description>Recent content in Script-Src on CSP Guide</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Sat, 08 Aug 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://csp-guide.com/tags/script-src/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>CSP Mistakes with Unleash Feature Flags</title>
      <link>https://csp-guide.com/posts/csp-for-unleash-feature-flags/</link>
      <pubDate>Sat, 08 Aug 2026 00:00:00 +0000</pubDate>
      
      <guid>https://csp-guide.com/posts/csp-for-unleash-feature-flags/</guid>
      
      <description>&lt;p&gt;Feature flags look harmless until CSP starts blocking them in production.&lt;/p&gt;
&lt;p&gt;Unleash is a good example. The SDK itself is usually straightforward, but the moment you load a frontend client, bootstrap flags, poll an API, or stream updates over SSE or WebSockets, your CSP needs to be precise. Most breakages come from people treating Unleash like “just another script” when the real problem is usually &lt;code&gt;connect-src&lt;/code&gt;.&lt;/p&gt;
&lt;p&gt;I’ve seen teams waste hours tweaking &lt;code&gt;script-src&lt;/code&gt; while the browser was yelling about a blocked fetch the whole time.&lt;/p&gt;</description>
      
    </item>
    
  </channel>
</rss>
