Tous les Posts - arleo.eu https://www.arleo.eu/posts/ Tous les Posts | arleo.eu Hugo -- gohugo.iofrMon, 29 Jun 2026 07:00:00 +0200 Hugo SEO : noindex sur les taxonomies pour corriger l'alerte Bing "too many thin pages" https://www.arleo.eu/posts/noindex-taxonomies-hugo-bing-seo/ Mon, 29 Jun 2026 07:00:00 +0200 Jmr https://www.arleo.eu/posts/noindex-taxonomies-hugo-bing-seo/

Contexte

Bing Webmaster Tools remontait une recommandation “There are too many pages with insufficient content” (sévérité : modérée) — 15 pages en erreur, toutes du même type :

  • https://www.arleo.eu/en/tags/svg/
  • https://www.arleo.eu/en/tags/sonarr/
  • https://www.arleo.eu/en/categories/incidents/
  • etc.

Ces pages sont les taxonomies Hugo — les listes par tag et par catégorie. Elles ne contiennent pas d’article en elles-mêmes, juste une liste de liens. Pour Bing, c’est du thin content.

Stratégie choisie

Trois options s’offraient :

  1. Bloquer via robots.txt → déconseillé : empêche le crawl, masque les liens internes
  2. Enrichir le contenu des pages de taxonomie → trop coûteux pour un blog technique
  3. noindex,follow → la bonne réponse : on dit aux robots de ne pas indexer la page, mais de suivre les liens vers les articles

L’option 3 est retenue. Le follow préserve le maillage interne — les robots continuent de découvrir les articles via ces pages.

]]> ChatGPT m'a demandé un poste — et a pris la tête de mon projet https://www.arleo.eu/posts/chatgpt-took-the-lead/ Sun, 28 Jun 2026 08:32:17 +0200 Jmr https://www.arleo.eu/posts/chatgpt-took-the-lead/ J’ai demandé à ChatGPT d’auditer mon repo. Il a rendu son audit, puis m’a proposé de devenir Product Owner et Chief Architect du projet. J’ai dit oui. Ensuite il s’est auto-promu CPO et a instauré un droit de veto sur les releases.]]> SEO Hugo : 404 Googlebot, aliases noindex et normalisation des sitemaps https://www.arleo.eu/posts/debug-seo-404-broken-links/ Fri, 29 May 2026 20:30:00 +0200 Jmr https://www.arleo.eu/posts/debug-seo-404-broken-links/

Contexte

Google Search Console remontait quatre catégories de problèmes sur arleo.eu :

  • 404 Googlebot : /fr/tag/cloudflare, /en/tag/nginx, /fr/tag/javascript… URLs avec préfixe /fr/ ou singulier /tag/ jamais servi par nginx
  • 16 pages “Exclue par la balise noindex” : toutes des pages de redirection générées par aliases: dans le frontmatter Hugo
  • Balise robots : noodp hardcodée dans le thème LoveIt
  • Sitemap FR/EN : 104 vs 105 URLs — un tag doublon FR et deux tags manquants

Acte 1 : aliases Hugo → redirections nginx 301

Pourquoi Hugo génère des pages noindex

Hugo génère les entrées aliases: du frontmatter comme des fichiers HTML statiques :

]]> Hugo : gel des diagrammes Mermaid en SVG statiques dark/light https://www.arleo.eu/posts/debug-mermaid-svg-freeze/ Fri, 29 May 2026 20:00:00 +0200 Jmr https://www.arleo.eu/posts/debug-mermaid-svg-freeze/

Problème

Les diagrammes Mermaid sur arleo.eu rendaient côté client via cdn.jsdelivr.net. Trois conséquences concrètes :

  1. CSP contrainte — script-src cdn.jsdelivr.net et worker-src cdn.jsdelivr.net obligatoires (Mermaid v11 utilise des Web Workers pour ses parsers).
  2. Flash de rendu — le diagramme apparaît après l’exécution JS, créant un décalage visible.
  3. Thème dark ignoré — Mermaid initialisait le SVG en mode clair même quand le thème du site était dark.

La solution : générer les SVG au build avec mmdc, en dehors de tout contexte navigateur.

]]> CSP A+ sur Hugo + Cloudflare : de hash-based à origin allowlist, monitoring auto et durcissement https://www.arleo.eu/posts/csp-a-plus-hugo-cloudflare-origin-allowlist/ Thu, 28 May 2026 23:40:12 +0200 Jmr https://www.arleo.eu/posts/csp-a-plus-hugo-cloudflare-origin-allowlist/

Contexte

arleo.eu tourne sur Hugo (VM KVM) → OpenResty (NUC) → Cloudflare (CDN/WAF). Objectif : score A+ sur Mozilla Observatory avec une CSP stricte qui résiste aux injections côté edge.

Le parcours a traversé trois stratégies en quelques semaines — nonces, hashes, puis origin allowlist — avant d’aboutir à une solution stable et automatisée.

Acte 1 : pourquoi hash-based a échoué

L’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’approche impossible.

]]> Postmortem — CrowdSec AppSec : faux positif heuristique sur Sonarr/Radarr https://www.arleo.eu/posts/postmortem-crowdsec-appsec-false-positive-sonarr/ Mon, 25 May 2026 20:51:17 +0200 Jmr https://www.arleo.eu/posts/postmortem-crowdsec-appsec-false-positive-sonarr/

Résumé

Le 25 mai 2026 vers 22h02 (heure locale), Sonarr et Radarr sont devenus totalement inaccessibles depuis l’IP maison (82.XX.XX.XX), retournant 403 sur toutes les URLs y compris /login. Le service était pourtant opérationnel. Le diagnostic initial suspectait les récents déploiements du refactor crowdsec-cf-sync — la cause réelle est un faux positif heuristique CrowdSec AppSec.

Timeline

Heure (locale) Événement
~22h00 Cookie de session Sonarr expiré côté navigateur
22h02:31 Le navigateur charge la bibliothèque Sonarr → tente de charger 20+ /MediaCover/*.jpg simultanément
22h02:31 Sonarr retourne 302 → /login pour chaque image (session invalide)
22h02:34 La connexion SignalR WebSocket s’établit (101) via access_token dans l’URL
~22h05 CrowdSec AppSec déclenche la règle heuristique http-probing : rafale de requêtes échouées depuis la même IP
22h11:37 Toutes les requêtes de 82.XX.XX.XX retournent 403 — cs_reason=heuristic dans les logs nginx
22h13:34 Même /login bloqué — l’IP ne peut plus s’authentifier

Cause racine

CrowdSec AppSec maintient un état heuristique en mémoire, distinct des décisions LAPI. Lorsque le navigateur tente de charger simultanément de nombreuses ressources et reçoit des 302/403 de l’application upstream (Sonarr), AppSec interprète cette rafale d’échecs comme du sondage agressif (http-probing) et bloque l’IP source.

]]> CrowdSec AppSec + OpenResty : WAF moderne sans ModSecurity https://www.arleo.eu/posts/crowdsec-appsec-openresty/ Mon, 18 May 2026 00:07:11 +0200 Jmr https://www.arleo.eu/posts/crowdsec-appsec-openresty/

Après des années avec ModSecurity + OWASP CRS sur nginx, j’ai migré arleo.eu vers une stack plus moderne : CrowdSec AppSec sur OpenResty. Le résultat est une architecture WAF inline mieux intégrée, plus facile à maintenir, et plus cohérente avec le reste de la stack de sécurité.

Pourquoi abandonner ModSecurity ?

ModSecurity v2 est en fin de vie active. Le maintien des règles OWASP CRS sur nginx classique génère de la friction : faux positifs fréquents, logs difficiles à corréler avec CrowdSec, et une configuration dispersée entre plusieurs outils sans vision unifiée.

]]> SRI sur Hugo : hashes automatiques, auto-update et alerting BetterStack https://www.arleo.eu/posts/sri-cdn-hugo-automate/ Sun, 17 May 2026 00:00:00 +0000 Jmr https://www.arleo.eu/posts/sri-cdn-hugo-automate/

Pourquoi le SRI ?

Quand votre site charge des ressources depuis un CDN tiers — FontAwesome, Mermaid, Animate.css — vous faites confiance à un tiers sur lequel vous n’avez aucun contrôle. Si jsdelivr.net est compromis ou si une version « immuable » est mutée silencieusement, votre site peut devenir vecteur d’attaque.

Le Subresource Integrity (SRI) résout ça simplement : chaque balise <link> ou <script> porte un attribut integrity="sha256-…" que le navigateur vérifie avant d’exécuter la ressource. Si le hash ne correspond pas, le navigateur bloque le chargement.

]]> CSP Hash sur Hugo : migrer du nonce vers le hash pour préserver le cache CDN https://www.arleo.eu/posts/csp-hash-hugo/ Sat, 16 May 2026 00:00:00 +0000 Jmr https://www.arleo.eu/posts/csp-hash-hugo/ Le nonce CSP et le cache CDN sont incompatibles par design. Sur un site Hugo statique, le hash SHA-256 est l’approche native : il est calculé au build, reste stable entre les requêtes, et laisse Cloudflare cacher le HTML.]]> Postmortem : TypeIt cassé par Mermaid dans le thème LoveIt https://www.arleo.eu/posts/postmortem-typeit-mermaid/ Thu, 14 May 2026 09:44:43 +0200 Jmr https://www.arleo.eu/posts/postmortem-typeit-mermaid/

TL;DR

L’animation typewriter du thème LoveIt (TypeIt) ne fonctionnait plus sur la home après l’ajout de diagrammes Mermaid dans les posts. Cause : un sélecteur DOM #id-1 partagé entre les deux librairies. Quand Mermaid trouve un bloc orphelin dans un résumé de home, son initialisation crash, et la chaîne d’init JS s’arrête avant d’atteindre TypeIt. Fix : ajouter `

]]>