<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0">
    <channel>
        <title>Csp - Balise - arleo.eu</title>
        <link>https://www.arleo.eu/tags/csp/</link>
        <description>Csp - Balise - arleo.eu</description>
        <generator>Hugo -- gohugo.io</generator><language>fr</language><lastBuildDate>Fri, 29 May 2026 20:00:00 &#43;0200</lastBuildDate><atom:link href="https://www.arleo.eu/tags/csp/" rel="self" type="application/rss+xml" /><item>
    <title>Hugo : gel des diagrammes Mermaid en SVG statiques dark/light</title>
    <link>https://www.arleo.eu/posts/debug-mermaid-svg-freeze/</link>
    <pubDate>Fri, 29 May 2026 20:00:00 &#43;0200</pubDate>
    <author>Jmr</author>
    <guid>https://www.arleo.eu/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="problème">Problème</h2>
<p>Les diagrammes Mermaid sur arleo.eu rendaient côté client via <code>cdn.jsdelivr.net</code>. Trois conséquences concrètes :</p>
<ol>
<li><strong>CSP contrainte</strong> — <code>script-src cdn.jsdelivr.net</code> et <code>worker-src cdn.jsdelivr.net</code> obligatoires (Mermaid v11 utilise des Web Workers pour ses parsers).</li>
<li><strong>Flash de rendu</strong> — le diagramme apparaît après l&rsquo;exécution JS, créant un décalage visible.</li>
<li><strong>Thème dark ignoré</strong> — Mermaid initialisait le SVG en mode clair même quand le thème du site était dark.</li>
</ol>
<p>La solution : générer les SVG <strong>au build</strong> avec <code>mmdc</code>, en dehors de tout contexte navigateur.</p>]]></description>
</item>
<item>
    <title>CSP A&#43; sur Hugo &#43; Cloudflare : de hash-based à origin allowlist, monitoring auto et durcissement</title>
    <link>https://www.arleo.eu/posts/csp-a-plus-hugo-cloudflare-origin-allowlist/</link>
    <pubDate>Thu, 28 May 2026 23:40:12 &#43;0200</pubDate>
    <author>Jmr</author>
    <guid>https://www.arleo.eu/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="contexte">Contexte</h2>
<p>arleo.eu tourne sur Hugo (VM KVM) → OpenResty (NUC) → Cloudflare (CDN/WAF). Objectif : score <strong>A+ sur Mozilla Observatory</strong> avec une CSP stricte qui résiste aux injections côté edge.</p>
<p>Le parcours a traversé trois stratégies en quelques semaines — nonces, hashes, puis origin allowlist — avant d&rsquo;aboutir à une solution stable et automatisée.</p>
<hr>
<h2 id="acte-1--pourquoi-hash-based-a-échoué">Acte 1 : pourquoi hash-based a échoué</h2>
<p>L&rsquo;idée de départ semblait solide : Hugo Pipes externalise tout le JS avec SRI, on liste les hashes dans la CSP, résultat propre. En pratique, deux problèmes ont rendu l&rsquo;approche impossible.</p>]]></description>
</item>
<item>
    <title>CSP Hash sur Hugo : migrer du nonce vers le hash pour préserver le cache CDN</title>
    <link>https://www.arleo.eu/posts/csp-hash-hugo/</link>
    <pubDate>Sat, 16 May 2026 00:00:00 &#43;0000</pubDate>
    <author>Jmr</author>
    <guid>https://www.arleo.eu/posts/csp-hash-hugo/</guid>
    <description><![CDATA[<div class="featured-image">
                <img src="/images/csp-hash-hugo-featured.png" referrerpolicy="no-referrer">
            </div>Le nonce CSP et le cache CDN sont incompatibles par design. Sur un site Hugo statique, le hash SHA-256 est l&rsquo;approche native : il est calculé au build, reste stable entre les requêtes, et laisse Cloudflare cacher le HTML.]]></description>
</item>
</channel>
</rss>
