Tout ce qui suit est observable de l’extérieur, sans identifiants et sans votre coopération. C’est la propriété déterminante : un acheteur entreprise, un auditeur et un attaquant voient la même chose, et aucun n’a besoin de votre permission pour regarder.
Classé par ce qui vous coûte un contrat ou fait échouer un audit en premier.
Palier 1 : disqualifiant
Un échec ici met fin à une revue fournisseur. Corrigez avant tout le reste de cette page.
[ ] TLS 1.0 et 1.1 refusés, pas seulement dépriorisés
[ ] TLS 1.2 minimum, TLS 1.3 pris en charge
[ ] Certificat valide, non expiré, SAN corrects pour chaque hôte servi
[ ] Chaîne de certification complète (aucun intermédiaire manquant)
[ ] HTTP redirige vers HTTPS
[ ] HSTS présent avec un max-age long
[ ] Aucun répertoire .git, fichier .env ou archive de sauvegarde exposé
[ ] Aucun listing de répertoire à la racine web
[ ] DMARC publié en p=quarantine ou p=reject
Un .env ou un .git exposé mérite sa place ici malgré son apparente banalité. Ils fuitent directement des identifiants, et ils restent trouvables sur des domaines de production en 2026.
Une remarque sur la façon de mesurer : un chemin qui renvoie HTTP 200 ne prouve pas une exposition. Les applications monopages répondent 200 avec leur coquille pour n’importe quel chemin, donc un vérificateur qui rapporte chaque 200 comme fichier exposé génère des faux positifs qui apprennent aux équipes à l’ignorer. La confirmation par signature de contenu est le correctif.
Palier 2 : attendu par tout acheteur sérieux
Une absence ici ne met pas fin à la revue, mais génère des questions et du travail de suivi.
[ ] Content-Security-Policy sans 'unsafe-inline' dans script-src
[ ] CSP utilisant nonce + strict-dynamic plutôt qu'une liste blanche d'origines
[ ] object-src 'none' et base-uri 'self'
[ ] frame-ancestors 'none' (ou une liste blanche explicite)
[ ] X-Content-Type-Options: nosniff
[ ] Referrer-Policy défini
[ ] Permissions-Policy désactivant les fonctions puissantes inutilisées
[ ] Uniquement des suites à confidentialité persistante
[ ] Agrafage OCSP activé
[ ] SPF et DKIM publiés et alignés avec DMARC
[ ] DNSSEC sur la zone (ou une décision documentée de s'en passer)
[ ] security.txt publié (RFC 9116)
[ ] Aucune source map servie en production
[ ] Aucune version de bibliothèque JavaScript vulnérable connue
unsafe-inline dans script-src est le constat le plus fréquent de ce palier, et il réduit une politique longue et impressionnante à aucune protection. L’échelle de maturité complète.
Palier 3 : les ajouts 2026
Ceux-ci sont nouveaux. La plupart des éditeurs n’en ont aucun, et c’est précisément pourquoi ils différencient.
[ ] MTA-STS publié en mode enforce (pas testing)
[ ] TLS-RPT publié et rapports réellement lus
[ ] Durée de vie émise du certificat dans le plafond en vigueur à l'émission
[ ] Durée de vie <= 100 jours, ou renouvellement automatisé avant le 15/03/2027
[ ] Accord de clés hybride X25519MLKEM768 proposé
[ ] Groupe hybride activé à l'origine, pas seulement en périphérie CDN
[ ] require-trusted-types-for 'script' dans la CSP
[ ] Liste blanche de politiques trusted-types déclarée
[ ] Integrity-Policy appliqué (ou report-only, comme première étape)
[ ] Empreintes SRI sur chaque script tiers
Quatre d’entre eux coûtent environ un après-midi chacun. Ce que chacun mesure et comment il est noté.
Palier 4 : surface d’attaque
Moins une affaire de configuration, davantage de ce qui existe et que vous avez oublié.
[ ] Inventaire des sous-domaines réconcilié avec les journaux de transparence des certificats
[ ] Aucun enregistrement DNS orphelin pointant vers un service déprovisionné
[ ] Aucun panneau d'administration ou interface de gestion exposé
[ ] Aucun équipement de périphérie exposé (VPN, passerelle de messagerie)
[ ] Hôtes de staging et de développement non joignables publiquement, ou authentifiés
[ ] Transfert de zone DNS refusé
[ ] Aucune page d'erreur verbeuse fuitant traces ou versions de framework
La transparence des certificats est l’élément le plus rentable. Chaque certificat jamais émis pour votre domaine est public, donc vos sous-domaines oubliés le sont aussi. Réconcilier cette liste avec ce que vous croyez exploiter fait régulièrement apparaître des hôtes que personne n’a corrigés depuis deux ans.
Le DNS orphelin est celui qui se transforme en incident réel, car un CNAME pointant vers une ressource cloud déprovisionnée peut être revendiqué par quelqu’un d’autre.
Comment l’utiliser
Ne partez pas du haut en descendant. Commencez par tout mesurer, puis corrigez dans l’ordre des paliers. L’échec courant est une équipe qui passe un sprint sur le palier 3 pendant qu’un point du palier 1 reste ouvert sur un sous-domaine oublié.
Vérifiez votre sous-domaine applicatif séparément du site marketing. Ils diffèrent souvent, et celui qui détient les données clients est fréquemment le plus faible.
Mesurez de façon répétée, pas une fois. Un résultat propre unique prouve un moment. Les auditeurs sous NIS2 interrogent la détection de dérive, et le constat récurrent des évaluations 2026 est la preuve manquante plutôt que la sécurité manquante. Une série datée est l’artefact qui y répond.
Soyez précis sur le périmètre. Rien de ce qui précède ne couvre le chiffrement au repos, le trafic entre services internes, la garde des clés, le contrôle d’accès ni la logique métier. Présenter une mesure externe comme si elle couvrait un contrôle entier appelle une correction de l’auditeur. Où se situe la limite.
Mappage des référentiels
| Palier | NIS2 | ISO/IEC 27001:2022 | DORA |
|---|---|---|---|
| TLS et certificats | 21(2)(h) | A.8.24 | Art.9 |
| En-têtes et CSP | 21(2)(g), 21(2)(e) | A.8.26, A.8.28 | Art.9 |
| Transport du courrier | 21(2)(h), 21(2)(e) | A.8.24, A.5.14 | Art.9, Art.7 |
| Intégrité des scripts tiers | 21(2)(d) | A.5.21 | Art.28 |
| Surface d’attaque | 21(2)(a), 21(2)(e) | A.8.8, A.5.7 | Art.8 |
Une mesure, trois mappages. Pour les équipes répondant à plus d’un référentiel, produire la preuve externe une fois et la mapper demande nettement moins de travail que des exercices séparés. Comment NIS2 et ISO 27001 s’articulent.
En résumé
Le palier 1 fait perdre des contrats. Le palier 2 crée des frictions. Le palier 3 différencie, et coûte peu aujourd’hui parce que presque personne ne l’a fait. Le palier 4 est d’où vient l’incident.
Mesurez d’abord, corrigez dans l’ordre, et conservez les résultats datés.
Passez de la lecture à l'action
Scannez votre domaine gratuitement. Premiers résultats en moins de 10 secondes — sans inscription.