<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title>Csp - Tag - arleo.eu</title><link>https://www.arleo.eu/en/tags/csp/</link><description>Csp - Tag - arleo.eu</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Fri, 29 May 2026 20:00:00 +0200</lastBuildDate><atom:link href="https://www.arleo.eu/en/tags/csp/" rel="self" type="application/rss+xml"/><item><title>Hugo: freezing Mermaid diagrams to static dark/light SVGs</title><link>https://www.arleo.eu/en/posts/debug-mermaid-svg-freeze/</link><pubDate>Fri, 29 May 2026 20:00:00 +0200</pubDate><author>Jmr</author><guid>https://www.arleo.eu/en/posts/debug-mermaid-svg-freeze/</guid><description><![CDATA[<div class="featured-image">
                <img src="/images/debug-mermaid-svg-freeze-featured.jpg" referrerpolicy="no-referrer">
            </div><h2 id="problem">Problem</h2>
<p>Mermaid diagrams on arleo.eu were rendering client-side via <code>cdn.jsdelivr.net</code>. Three concrete consequences:</p>
<ol>
<li><strong>CSP constraint</strong> — <code>script-src cdn.jsdelivr.net</code> and <code>worker-src cdn.jsdelivr.net</code> become mandatory (Mermaid v11 uses Web Workers for its parsers).</li>
<li><strong>Render flash</strong> — the diagram appears after JS execution, creating a visible delay.</li>
<li><strong>Dark theme ignored</strong> — Mermaid initialized the SVG in light mode even when the site theme was dark.</li>
</ol>
<p>The solution: generate SVGs <strong>at build time</strong> with <code>mmdc</code>, outside any browser context.</p>]]></description></item><item><title>CSP A+ on Hugo + Cloudflare: from hash-based to origin allowlist, auto-monitoring and hardening</title><link>https://www.arleo.eu/en/posts/csp-a-plus-hugo-cloudflare-origin-allowlist/</link><pubDate>Thu, 28 May 2026 23:45:41 +0200</pubDate><author>Jmr</author><guid>https://www.arleo.eu/en/posts/csp-a-plus-hugo-cloudflare-origin-allowlist/</guid><description><![CDATA[<div class="featured-image">
                <img src="/images/csp-a-plus-hugo-cloudflare-origin-allowlist-featured.jpg" referrerpolicy="no-referrer">
            </div><h2 id="context">Context</h2>
<p>arleo.eu runs on Hugo (KVM VM) → OpenResty (NUC) → Cloudflare (CDN/WAF). Goal: <strong>A+ score on Mozilla Observatory</strong> with a strict CSP that resists edge-side injections.</p>
<p>The journey went through three strategies over a few weeks — nonces, hashes, then origin allowlist — before landing on a stable, automated solution.</p>
<hr>
<h2 id="act-1-why-hash-based-failed">Act 1: why hash-based failed</h2>
<p>The initial idea seemed solid: Hugo Pipes externalizes all JS with SRI, we list the hashes in the CSP, clean result. In practice, two problems made the approach impossible.</p>]]></description></item><item><title>CSP Hash on Hugo: migrating from nonce to hash to preserve CDN cache</title><link>https://www.arleo.eu/en/posts/csp-hash-hugo/</link><pubDate>Sat, 16 May 2026 00:00:00 +0000</pubDate><author>Jmr</author><guid>https://www.arleo.eu/en/posts/csp-hash-hugo/</guid><description>&lt;div class="featured-image">
                &lt;img src="/images/csp-hash-hugo-featured.png" referrerpolicy="no-referrer">
            &lt;/div>CSP nonces and CDN caching are incompatible by design. On a Hugo static site, SHA-256 hashes are the native approach: computed at build time, stable across requests, and fully compatible with Cloudflare caching.</description></item></channel></rss>