<rss xmlns:atom="http://www.w3.org/2005/Atom" version="2.0">
    <channel>
        <title>Sécurité - Catégorie - arleo.eu</title>
        <link>https://www.arleo.eu/categories/s%C3%A9curit%C3%A9/</link>
        <description>Sécurité - Catégorie - arleo.eu</description>
        <generator>Hugo -- gohugo.io</generator><language>fr</language><lastBuildDate>Thu, 28 May 2026 23:40:12 &#43;0200</lastBuildDate><atom:link href="https://www.arleo.eu/categories/s%C3%A9curit%C3%A9/" rel="self" type="application/rss+xml" /><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>SRI sur Hugo : hashes automatiques, auto-update et alerting BetterStack</title>
    <link>https://www.arleo.eu/posts/sri-cdn-hugo-automate/</link>
    <pubDate>Sun, 17 May 2026 00:00:00 &#43;0000</pubDate>
    <author>Jmr</author>
    <guid>https://www.arleo.eu/posts/sri-cdn-hugo-automate/</guid>
    <description><![CDATA[<div class="featured-image">
                <img src="/images/sri-cdn-hugo-automate-featured.jpg" referrerpolicy="no-referrer">
            </div><h2 id="pourquoi-le-sri-">Pourquoi le SRI ?</h2>
<p>Quand votre site charge des ressources depuis un CDN tiers — FontAwesome, Mermaid, Animate.css — vous faites confiance à un tiers sur lequel vous n&rsquo;avez aucun contrôle. Si jsdelivr.net est compromis ou si une version « immuable » est mutée silencieusement, votre site peut devenir vecteur d&rsquo;attaque.</p>
<p>Le <strong>Subresource Integrity</strong> (SRI) résout ça simplement : chaque balise <code>&lt;link&gt;</code> ou <code>&lt;script&gt;</code> porte un attribut <code>integrity=&quot;sha256-…&quot;</code> que le navigateur vérifie avant d&rsquo;exécuter la ressource. Si le hash ne correspond pas, le navigateur bloque le chargement.</p>]]></description>
</item>
</channel>
</rss>
