<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Static-Sites on CSP Guide</title>
    <link>https://csp-guide.com/tags/static-sites/</link>
    <description>Recent content in Static-Sites on CSP Guide</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en-us</language>
    <lastBuildDate>Tue, 07 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://csp-guide.com/tags/static-sites/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>CSP for Static Sites and Jekyll</title>
      <link>https://csp-guide.com/posts/csp-for-static-sites-and-jekyll/</link>
      <pubDate>Tue, 07 Jul 2026 00:00:00 +0000</pubDate>
      
      <guid>https://csp-guide.com/posts/csp-for-static-sites-and-jekyll/</guid>
      
      <description>&lt;p&gt;Static sites have a nice security advantage: less moving parts, fewer server-side bugs, and usually a very predictable frontend. That predictability makes Content Security Policy a great fit.&lt;/p&gt;
&lt;p&gt;The catch is that CSP gets awkward fast when you mix a static build system like Jekyll with inline scripts, analytics tags, consent banners, and hosting platforms that don’t give you full control over headers. I’ve seen plenty of “we added CSP” rollouts that either broke production or quietly fell back to &lt;code&gt;&#39;unsafe-inline&#39;&lt;/code&gt;, which defeats half the point.&lt;/p&gt;</description>
      
    </item>
    
  </channel>
</rss>
