Depuis Catégorie B à Catégorie A:
Comment nous avons corrigé la conformité NIS2 en 30 minutes

Nous avons analysé nos propres sites Web avec KENSAI et découvert des lacunes critiques en matière de conformité NIS2. Les en-têtes de sécurité HTTP manquants ont amené deux de nos trois domaines au grade B (0,786). Voici exactement ce qui n'allait pas, quels articles NIS2 étaient menacés et comment 30 minutes de configuration de Caddy ont tout résolu.

La vérité inconfortable

Nous construisons une plateforme d'analyse de sécurité. Nous prêchons la conformité NIS2 à nos clients. Nous avons ensuite exécuté KENSAI sur nos propres domaines et constaté que deux sur trois n'étaient pas conformes.

Aucune vulnérabilité, aucune violation. Il manque juste les en-têtes de sécurité HTTP – le genre de faille silencieuse que les régulateurs vérifient en premier et que les attaquants exploitent en second. En vertu de la directive NIS2 (Art. 21, §2), ces en-têtes ne sont pas facultatifs pour les entités réglementées. Il s’agit d’une exigence d’hygiène de base.

Voici ce que nous avons trouvé et à quelle vitesse nous l'avons corrigé.

Les résultats de l'analyse

Nous avons effectué l'analyse automatisée de conformité NIS2 de KENSAI sur les trois domaines du portefeuille le 15 mars 2026 :

kensai.app a obtenu un score presque parfait à 0,997 car il exécutait déjà la configuration correcte de l'en-tête Caddy. Les deux autres domaines — brnz.ai et codeforceai.com – étaient tous deux à 0,786, chacun manquant les mêmes six en-têtes de sécurité critiques.

Ce qui manquait – et pourquoi c'est important pour NIS2

Six en-têtes de réponse HTTP étaient absents des deux domaines défaillants. Chacun correspond directement aux exigences de la directive NIS2 :

Le correctif : configuration de l'en-tête Caddy

Nous utilisons Caddie comme notre proxy inverse. Le correctif était un seul et réutilisable en-tête bloc que nous pourrions appliquer à tous les domaines. Voici exactement ce que nous avons ajouté :

# Extrait d'en-tête global – ajouter à tous les sites de production
(sécurité_headers) {
  en-tête {
    # Forcer HTTPS — NIS2 Art. 21(2)(h) : communications sécurisées
    Sécurité stricte des transports "max-age=31536000 ; includeSubDomains ; préchargement"

    # Blocage XSS & injection — NIS2 Art. 21(2)(d) : sécurité de la chaîne d’approvisionnement
    Politique de sécurité du contenu "default-src 'self'; script-src 'self' 'unsafe-inline' https://fonts.googleapis.com; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data: https:; connect-src 'self' https:; frame-ancestors 'aucun'"

    # Empêcher le détournement de clics — NIS2 Art. 21(2)(b)
    Options du cadre X "REFUSER"

    # Arrêtez le reniflage MIME — NIS2 Art. 21(2)(b)
    Options de type de contenu X "nosniff"

    # Limiter les fuites de référents — NIS2 Art. 21(2)(e)
    Politique de référence "origine stricte quand origine croisée"

    # Restreindre les API du navigateur — NIS2 Art. 25 : la sécurité dès la conception
    Politique d'autorisations "camera=(), microphone=(), geolocation=(), payment=(), usb=(), Interest-cohort=()"

    # Supprimer les empreintes digitales du serveur
    -Serveur
    -X-Powered-By
  }
}

Ensuite, nous avons importé l'extrait dans chaque bloc du site :

# brnz.ai
brnz.ai, www.brnz.ai {
  importer sécurité_headers
  proxy_inverse hôte local : 3001
}

# codeforceai.com
codeforceai.com, www.codeforceai.com {
  importer sécurité_headers
  proxy_inverse hôte local : 3002
}

Rechargez Caddy, vérifiez les en-têtes dans les DevTools du navigateur, c'est fait :

caddie recharger --config /etc/caddy/Caddyfile

La chronologie : 30 minutes du début à la fin

Avant vs Après

Leçons clés

1. Les en-têtes de sécurité sont des éléments de conformité NIS2, et non des extras facultatifs

Chaque entité réglementée par NIS2 doit disposer d'en-têtes de sécurité HTTP de base. Les régulateurs effectuent de plus en plus d’analyses automatisées lors des audits. Un disparu Sécurité stricte des transports l'en-tête n'est pas une omission mineure — c'est la preuve d'une gestion des risques inadéquate au sens de l'art. 21(2).

2. Même les entreprises de sécurité ont des lacunes

Nous construisons des outils de conformité et disposions toujours de deux sites de niveau B. Ce n'est pas embarrassant, c'est un rappel qu'une dérive de configuration se produit. Un domaine lancé rapidement, un Caddyfile qui n'a pas été synchronisé, un import manquant. L'analyse automatisée détecte ce qui manque aux audits manuels.

3. La solution est presque toujours simple

Six en-têtes manquants. Trente lignes de configuration Caddy. Trente minutes de travail. L'écart entre les niveaux B et A n'est pas un projet d'un mois, c'est un après-midi. Le plus difficile est de savoir que l’écart existe en premier lieu.

4. Les extraits réutilisables empêchent toute dérive future

En extrayant les en-têtes dans un (sécurité_headers) extrait, tout nouveau domaine que nous ajoutons obtient automatiquement une couverture complète de l'en-tête NIS2 en incluant un seul importer doubler. La conformité devient une valeur par défaut et non une réflexion après coup.

Ce que cela signifie pour votre organisation

Si vous êtes sous NIS2 – ou si vous vous préparez à un audit – vos en-têtes de sécurité HTTP sont l'une des premières choses que les régulateurs vérifient. Ils sont rapides à analyser, sans ambiguïté à évaluer et simples à corriger. Il n'y a aucune excuse pour un grade B quand un grade A prend 30 minutes.

Exécutez l'analyse. Lisez le rapport. Corrigez ce qui est signalé. Re-scanner pour confirmer.