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.

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.

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.

⚡ En bref

Un audit de la stack sécurité du NUC révèle une double inspection WAF redondante : ModSecurity + OWASP CRS chargent 11 872 règles en mémoire malgré SecRuleEngine Off, en parallèle d’un CrowdSec AppSec déjà actif et couvrant le même périmètre. Après suppression du module nginx ModSecurity et 5 autres correctifs ciblés, nginx passe de ~520 MB à ~27 MB PSS. Sécurité identique, empreinte divisée par 20.

🏗️ Architecture avant audit

La stack sécurité reposait sur six couches empilées :

TL;DR

Le 9 mai 2026, j’ai livré en une session marathon les 10 chantiers du sprint sécurité MCP que j’avais annoncé en début de journée. hugo-mcp est désormais en v1.9.0 (GitHub Release), commit 1404f83 GPG-signé.

Voici le recap haute-volée + un zoom pédagogique sur 2 chantiers qui ont une vraie valeur en dehors de mon contexte précis : C2 token rotation et C6 TLS interne.

Recap des 10 chantiers

Détails complets dans le CHANGELOG v1.9.0 et le commit 1404f83.

Statut : ✅ LIVRÉ — sprint clos le 9 mai 2026

Mise à jour 9 mai 2026 (fin de session) : les 10 chantiers sont livrés en une session marathon, et les 3 releases coordonnées sont publiées (hugo-mcp v1.9.0, mcp-oauth-proxy v2.1.0, mcp-installer v1.3.0). Tout l’écosystème MCP est durci dans la même journée. Recap technique complet : Sprint sécurité MCP livré : v1.9.0, 10 chantiers, écosystème durci.

Cette page reste publiée à fins d’archive — pour montrer la trajectoire d’un sprint annoncé puis tenu. Tout le contenu original ci-dessous est préservé.

Statut original (avant livraison)

Cette page documentait publiquement un sprint de hardening en cours sur l’infrastructure MCP d’arleo.eu. Pour des raisons de sécurité, les détails précis des chantiers n’étaient pas exposés tant que les correctifs n’étaient pas livrés (philosophie “sec-first” : ne pas publier de roadmap d’attaque).

Pourquoi cette transparence

J’ai débattu de publier ou non cette page. Arguments pour la transparence :

• Engagement public = pression saine sur soi-même pour livrer
• Documentation d’un homelab dont l’objectif est apprendre et partager
• Honnêteté vis-à-vis des lecteurs qui consomment les autres articles techniques

Arguments contre :

• Roadmap d’attaque : si je liste précisément ce qui n’est pas encore protégé, je donne des indices à un attaquant patient
• Pression artificielle : annoncer un sprint puis ne pas livrer = pire que ne rien annoncer

Compromis adopté : publier la direction et les domaines de hardening sans préciser ce qui est faible aujourd’hui. Détail technique précis publié à la livraison.

Domaines couverts par le sprint

Le sprint couvrait 10 chantiers regroupés en 4 domaines :

1. Hardening applicatif (FastAPI + Pydantic)

Renforcement des couches d’entrée du MCP : validation stricte des inputs, gestion d’erreurs unifiée, pas de leak d’information dans les responses (stack traces, paths internes, versions de libs).

2. Authentification et tokens

Refonte de la gestion des tokens d’accès au MCP : durée de vie, rotation, révocation, hashing en stockage. Permettre de couper l’accès d’un client compromis sans redéployer le service.

3. Observabilité et audit

Intégration de logs structurés JSON ingérés dans BetterStack via Vector. Chaque appel MCP doit produire un événement traçable : qui, quoi, quand, durée, statut. Permet la détection d’anomalies en quasi-temps réel.

4. Infrastructure et résilience

TLS pour le trafic interne entre le NUC et la VM, règles ModSec dédiées au path /mcp, runbook de récupération en cas de désastre (vol de tokens, compromise serveur, perte de données).

Ce qui était déjà en place avant le sprint

Pour ne pas créer de fausse impression, voici les couches déjà en place sur l’infrastructure avant le sprint (donc hors scope) :

• nginx + TLS 1.3 obligatoire (Mozilla Modern config)
• Cloudflare WAF + Bot Management + IP whitelist
• ModSecurity + OWASP CRS 4.x sur tous les vhosts
• CrowdSec en mode WAF + bouncer Cloudflare
• systemd hardening niveau 1.7 (cf. hardening systemd)
• HMAC validation sur les webhooks
• Frontmatter validation Pydantic (1 chantier sur 4 dans la catégorie validation)

Le sprint visait à compléter cette base, pas à la remplacer.

Méthode

Pour chaque chantier :

1. Implémenté en local + tests unitaires
2. Validé sur mcp-test-vm (VM de pré-prod)
3. Déployé sur prod uniquement après tests réussis
4. Audit log structuré JSON pour traçabilité du déploiement
5. Article post-mortem ou write-up technique publié après livraison

Aucun déploiement direct prod sans étape pré-prod.

Releases publiées

TL;DR

systemd-analyze security est un outil sous-utilisé. Il scanne tes unit files et calcule un score d’exposition de 0.0 (UNSAFE) à 10.0 (PERFECT). Les services Python custom sortent souvent autour de 9.6 par défaut — c’est mauvais.

J’ai fait passer mon service hugo-mcp (FastAPI exposant 7 tools MCP) de 9.6 → 1.7 sans casser la moindre fonctionnalité. Voici les directives qui comptent vraiment, et celles qui sont des pièges.

Le score initial

$ sudo systemd-analyze security hugo-mcp
→ Overall exposure level for hugo-mcp.service: 9.6 UNSAFE 😨

9.6 sur 10. Le service tourne en root équivalent, peut faire setuid(), peut allouer de la mémoire RWX, voit tous les processus du système, peut écrire partout, peut faire des syscalls arbitraires.

Pour un MCP qui édite du contenu Markdown et déclenche un build Hugo, c’est démesuré.

⚡ En bref

La CSP initiale listait 46 hashes SHA-256 pour couvrir les scripts et styles inline — ingérable, fragile, et à la limite des 4 096 caractères de Cloudflare. Cette migration vers des nonces dynamiques réduit la CSP à ~600 caractères, supprime toute maintenance manuelle des hashes, et ajoute un reporting structuré des violations dans BetterStack.

Le plugin Grav utilisé est disponible sur GitHub : 🔌 Plugin : jmrGrav/grav-plugin-csp-nonce