Un résultat de sécurité tient en un mot – « Solide », « Partiel », « À renforcer » – et cette page explique comment ce mot est obtenu. Chaque contrôle porte deux attributs : un poids, qui dit ce qu’il coûte dans le total, et une gravité, qui dit si son échec plafonne le résultat quoi qu’il arrive. Rien d’autre n’entre dans le calcul.
Le barème vit dans le code, pas dans un réglage : il est le même pour toutes les entités d’un périmètre, et il change par versions numérotées dont l’historique figure en bas de cette page. Cet historique compte autant que le barème lui-même – sans lui, une variation due à un contrôle ajouté se lirait comme une dégradation de l’entité mesurée.
Les quatre niveaux
Le calcul, étape par étape
- Les points d’une famille de contrôles sont additionnés : un contrôle réussi rapporte son poids entier, un contrôle partiellement satisfait la moitié, un contrôle en échec rien. Le total est ramené en pourcentage des points applicables.
- Un contrôle qui n’a pas pu être mesuré sort du calcul : il ne compte ni comme réussite, ni comme échec, et son poids quitte le total applicable. Un site injoignable ne récolte donc pas une mauvaise note, mais l’absence de note.
- Deux plafonds s’appliquent ensuite au niveau obtenu, et ne peuvent que le faire baisser : un contrôle critique en échec ramène à « À renforcer », quel que soit le pourcentage ; un contrôle critique partiellement satisfait, ou un contrôle majeur en échec, interdit de dépasser « Partiel ».
- Le score global d’une entité est la moyenne des familles ayant produit un résultat, ramenée aux mêmes niveaux. Une famille « non évalué » n’entre pas dans cette moyenne.
Les trois gravités
La gravité ne décide pas de ce que coûte un contrôle – c’est le rôle du poids – mais du plafond appliqué au résultat quand ce contrôle échoue.
Un échec ramène le résultat de la famille à « À renforcer », quel que soit le score par ailleurs.
- Fichier security.txt publié security.txt
- Connexion chiffrée disponible (HTTPS) Entêtes de sécurité
- Expéditeurs de courrier autorisés (SPF) Sécurité e-mail
- Politique appliquée aux courriels frauduleux (DMARC) Sécurité e-mail
Un échec interdit « Solide » : le résultat ne peut pas dépasser « Partiel ».
- Adresse de contact valide (champ Contact) security.txt
- Date de validité renseignée (champ Expires) security.txt
- Redirection automatique vers HTTPS Entêtes de sécurité
- Navigateur forcé à rester en HTTPS (HSTS) Entêtes de sécurité
- Réponses DNS signées et vérifiables (DNSSEC) Sécurité e-mail
- Chiffrement SMTP forcé en transit (MTA-STS) Sécurité e-mail
Aucun plafond : le contrôle pèse seulement dans le score, à hauteur de son poids.
- Fichier accessible avec et sans www security.txt
- Clé de chiffrement publiée (champ Encryption) security.txt facultatif
- Langues de contact indiquées (champ Preferred-Languages) security.txt facultatif
- Liste des scripts et ressources autorisés (CSP) Entêtes de sécurité
- Type de fichier non réinterprété par le navigateur (nosniff) Entêtes de sécurité
- Protection contre l’affichage dans un cadre invisible (anti-clickjacking) Entêtes de sécurité
- Informations limitées vers les liens sortants (Referrer-Policy) Entêtes de sécurité
- Accès aux fonctions du navigateur limité (Permissions-Policy) Entêtes de sécurité
- Numéro de version du logiciel non divulgué Entêtes de sécurité
- Cookies protégés (Secure, HttpOnly, SameSite) Entêtes de sécurité
- Autorités de certification restreintes (CAA) Sécurité e-mail
- Rapports d’échec de chiffrement SMTP (TLS-RPT) Sécurité e-mail
Le barème, famille par famille
security.txt
| Code | Contrôle | Poids | Gravité |
|---|---|---|---|
STXT-PRESENT | Fichier security.txt publié | 4 | Critique |
STXT-CONTACT | Adresse de contact valide (champ Contact) | 3 | Majeur |
STXT-EXPIRES | Date de validité renseignée (champ Expires) | 2 | Majeur |
STXT-BOTH-VARIANTS | Fichier accessible avec et sans www | 1 | Mineur |
STXT-ENCRYPTION | Clé de chiffrement publiée (champ Encryption) facultatif | 1 | Mineur |
STXT-LANGUAGES | Langues de contact indiquées (champ Preferred-Languages) facultatif | 1 | Mineur |
Entêtes de sécurité
| Code | Contrôle | Poids | Gravité |
|---|---|---|---|
HEAD-HTTPS | Connexion chiffrée disponible (HTTPS) | 5 | Critique |
HEAD-REDIRECT | Redirection automatique vers HTTPS | 3 | Majeur |
HEAD-HSTS | Navigateur forcé à rester en HTTPS (HSTS) | 3 | Majeur |
HEAD-CSP | Liste des scripts et ressources autorisés (CSP) | 3 | Mineur |
HEAD-NOSNIFF | Type de fichier non réinterprété par le navigateur (nosniff) | 2 | Mineur |
HEAD-FRAME | Protection contre l’affichage dans un cadre invisible (anti-clickjacking) | 2 | Mineur |
HEAD-REFERRER | Informations limitées vers les liens sortants (Referrer-Policy) | 1 | Mineur |
HEAD-PERMISSIONS | Accès aux fonctions du navigateur limité (Permissions-Policy) | 1 | Mineur |
HEAD-VERSION | Numéro de version du logiciel non divulgué | 1 | Mineur |
HEAD-COOKIES | Cookies protégés (Secure, HttpOnly, SameSite) | 2 | Mineur |
Sécurité e-mail
| Code | Contrôle | Poids | Gravité |
|---|---|---|---|
EMAIL-SPF | Expéditeurs de courrier autorisés (SPF) | 3 | Critique |
EMAIL-DMARC | Politique appliquée aux courriels frauduleux (DMARC) | 3 | Critique |
EMAIL-DNSSEC | Réponses DNS signées et vérifiables (DNSSEC) | 2 | Majeur |
EMAIL-CAA | Autorités de certification restreintes (CAA) | 1 | Mineur |
EMAIL-MTA-STS | Chiffrement SMTP forcé en transit (MTA-STS) | 3 | Majeur |
EMAIL-TLSRPT | Rapports d’échec de chiffrement SMTP (TLS-RPT) | 1 | Mineur |
Un contrôle marqué « facultatif » est mesuré et compte dans le score, mais n’est jamais présenté comme un défaut à corriger : renseigné c’est mieux, pas grave sinon.
Historique du barème
Chaque résultat archivé porte la version du barème sous laquelle il a été calculé. C’est ce qui permet de lire une variation sans la prendre pour une évolution réelle du site mesuré : la ligne « effet » dit dans quel sens chaque version déplace les entités déjà mesurées. Les entrées ci-dessous emploient le vocabulaire technique du calcul : une « sonde » y désigne une famille de contrôles, un « verdict » le niveau qui en résulte.
Quand le certificat est refusé, une seconde requête sans vérification du certificat mesure tout de même les en-têtes (HSTS, CSP…) et la redirection, au lieu de tout marquer « non évalué ». Le contrôle HTTPS porte la cause précise : chaîne de certificats incomplète = partiel (les navigateurs de bureau complètent la chaîne), certificat expiré, pour un autre nom ou auto-signé = échec. Seconde tentative plus patiente sur délai dépassé ou connexion coupée.
Effet sur les entités déjà mesurées : Les sites au certificat refusé voient leurs en-têtes notés pour la première fois : leur sonde en-têtes peut monter (chaîne incomplète : de « à renforcer » à « partiel ») ou rester basse selon leurs en-têtes réels. Quelques sites jusque-là « non évalués » par un délai dépassé passager sont désormais mesurés. Aucun site correctement servi en HTTPS n’est touché.
CSP (sonde en-têtes) passe de majeur à mineur. Son poids ne change pas (3, autant que HSTS) : l’absence de politique coûte toujours autant dans le score, elle ne plafonne simplement plus le verdict de la sonde à « partiel ». Motif : c’est le seul contrôle du barème qui demande un travail d’intégration au site plutôt qu’une ligne de configuration.
Effet sur les entités déjà mesurées : Un site sans CSP mais conforme par ailleurs peut passer de « partiel » à « solide » sur la sonde en-têtes sans avoir bougé, et remonter dans les classements. Aucun site ne redescend. Cette gravité était jusqu’ici surchargée depuis l’administration : la porter dans le code a permis de retirer le mécanisme de surcharge.
Le contrôle « présent » rendait « non applicable » – donc rien du tout – quand aucun fichier n’était trouvé. Il rend désormais « échec » sur un site JOIGNABLE : l’emplacement attendu a été interrogé, et l’absence constatée est un résultat. Un site INJOIGNABLE reste « non applicable » : on ne reproche pas une panne réseau.
Effet sur les entités déjà mesurées : La sonde security.txt d’un site sans fichier vaut désormais « à renforcer » et entre dans la moyenne du score global au lieu d’en sortir : la quasi-totalité des entités qui ne publient rien recule d’une bande, sans avoir bougé. C’est le prix d’une correction voulue – publier un fichier imparfait ne peut plus classer une entité DERRIÈRE une entité qui n’en publie aucun, une contre-incitation à publier dans un observatoire qui existe pour encourager la publication.
Encryption et Preferred-Languages ajoutés (poids 1, gravité mineure chacun : renseigné c’est mieux, pas grave sinon, jamais de plafond). Mêmes données que celles déjà collectées. Poids maximal de la sonde : 10 puis 12.
Effet sur les entités déjà mesurées : Un fichier conforme sans ces deux champs reste « solide » (10 sur 12), mais un fichier qui manque aussi l’autre variante www (9 sur 12) peut passer de « solide » à « partiel » sans avoir bougé. Les résultats déjà enregistrés portent leur version et marquent ces deux contrôles « non mesurés », jamais supposés conformes.
CAA (poids 1, mineur), MTA-STS (poids 3, majeur – un échec plafonne donc le verdict de sonde à partiel) et TLS-RPT (poids 1, mineur). Mêmes requêtes DNS-over-HTTPS déjà mutualisées, aucune requête supplémentaire.
Effet sur les entités déjà mesurées : Poids maximal de la sonde e-mail / DNS change (8 puis 13). Un site sans MTA-STS jusque-là « solide » peut redescendre à « partiel » sans avoir bougé : la mesure devient plus exigeante, pas le site.
DMARC bascule en partiel si « pct= » est inférieur à 100 (rejet appliqué à une fraction seulement des courriels frauduleux) ou si « sp= » est plus faible que « p= » (sous-domaines moins protégés que le domaine principal). Les deux tags absents restent neutres : comportement par défaut RFC 7489 inchangé.
Effet sur les entités déjà mesurées : Baisse possible des seuls domaines dont la politique était déjà affaiblie de cette façon.
SPF « ~all » (soft fail) et DMARC « p=quarantine » passent de conforme à partiel : ni l’un ni l’autre ne produit d’effet contraignant réel, un serveur destinataire pouvant délivrer le courriel frauduleux quand même. Seuls « -all » et « p=reject » bloquent effectivement.
Effet sur les entités déjà mesurées : Un site peut baisser sans avoir bougé : la mesure devient plus exigeante. A nécessité un re-scan complet, le texte source de l’enregistrement n’étant pas conservé pour les contrôles déjà notés conformes avant cette version.
Contrôle ajouté à la sonde en-têtes (poids 3, gravité majeure). Seul contrôle du barème à requérir une requête DÉDIÉE : ce qu’un visiteur reçoit en clair sur le port 80 n’est observable par aucune autre requête déjà mutualisée.
Effet sur les entités déjà mesurées : Poids maximal de la sonde en-têtes à nouveau modifié (20 puis 23) : même incomparabilité qu’à la version 4.
Divulgation de numéro de version (Server, X-Powered-By) et marquage des cookies (Secure, HttpOnly, SameSite). Aucune requête supplémentaire : même réponse racine, déjà récupérée.
Effet sur les entités déjà mesurées : Le poids maximal de la sonde en-têtes change : le score de tous les sites portant cette sonde n’est plus comparable à une mesure antérieure, même sans régression réelle de leur part.
SPF « +all » passe de partiel à échec. Plusieurs enregistrements DMARC sur un même domaine passent de conforme à échec (permerror, RFC 7489). DNSSEC cesse de produire de faux négatifs sur les domaines sans adresse à l’apex.
Effet sur les entités déjà mesurées : Les deux premiers font baisser certains sites, le troisième en fait remonter d’autres. Dans les deux sens, c’est la mesure qui a changé, pas eux.
Chaque contrôle reçoit une gravité (critique, majeur, mineur). Un échec critique plafonne le verdict de la sonde à « à renforcer », un échec majeur à « partiel ».
Effet sur les entités déjà mesurées : Le score seul ne décide plus du verdict : une entité bien notée par ailleurs peut désormais être plafonnée par un seul contrôle grave.