SaaSFort Une base de sécurité externe qui ne change jamais est soit parfaite, soit à l’abandon. La nôtre a changé en 2026, et voici le relevé de ce qui a bougé et sur quel raisonnement.
Six contrôles ont été ajoutés. Tous traitent des sujets qui, il y a deux ans, n’étaient ni déployables ni demandés.
La règle que nous avons appliquée
Un contrôle gagne sa place dans la base quand trois conditions sont réunies.
Il est observable de l’extérieur, sans identifiants ni coopération. S’il ne se mesure pas depuis l’extérieur, il relève d’un questionnaire et non d’un scan.
Il est actionnable, c’est-à-dire qu’une équipe peut le changer. Rapporter une condition que personne ne peut corriger produit du bruit, et le bruit apprend aux gens à ignorer le rapport.
Il est décidable à partir d’une preuve, pas déduit d’une bannière ni d’un numéro de version. Un verdict que nous ne pouvons pas étayer par une observation brute est une supposition, et les suppositions sont ce qui rend les scanners peu fiables.
La dernière condition explique pourquoi deux des six sont rapportés en information plutôt qu’en échec.
1. Politique MTA-STS
Ce qu’il mesure. Si le domaine publie une politique MTA-STS (RFC 8461), et surtout quel mode la politique déclare.
Pourquoi. SPF, DKIM et DMARC authentifient l’expéditeur. Aucun n’empêche un attaquant en coupure de retirer STARTTLS et de forcer une remise en clair. C’était le plus grand trou non mesuré de la base.
Notation. enforce passe. testing est un constat Low, car il signale les échecs et délivre quand même. none, ou une politique annoncée en DNS mais injoignable en HTTPS, est Medium. L’absence est Low.
Rapporter le mode plutôt que la présence d’un enregistrement est la distinction qui compte : un domaine garé en testing a l’apparence du contrôle et aucun de ses effets.
Non applicable aux domaines sans enregistrement MX. Un domaine qui ne reçoit pas de courrier n’échoue pas à un contrôle de courrier, et le rapporter placerait un constat incorrigible devant chaque client dont le domaine marketing n’accepte pas de courrier.
2. Remontée TLS-RPT
Ce qu’il mesure. Un enregistrement v=TLSRPTv1 sur _smtp._tls.<domaine> (RFC 8460).
Pourquoi. TLS-RPT est ce qui rend MTA-STS sûr à appliquer et ce qui révèle un hôte MX défaillant avant qu’un client ne le remarque. Sans lui, les échecs de remise en TLS sont invisibles.
Notation. Information en cas d’absence, car c’est de la télémétrie et non un contrôle protecteur. Présent vaut réussite.
3. Accord de clés post-quantique
Ce qu’il mesure. Si le serveur négocie le groupe hybride X25519MLKEM768, point de code IANA 0x11ec.
Comment il est mesuré. Un vrai handshake TLS restreint au groupe hybride. Pas une bannière, pas une déduction de version. En cas d’échec, un second handshake non restreint confirme que l’hôte répond bien en TLS avant toute conclusion, car un handshake échoué contre un hôte injoignable ne prouve rien.
Notation. Information en cas d’absence. Ne pas proposer d’accord de clés post-quantique en 2026 est une exposition à effet différé, pas une erreur de configuration présente, et le noter comme un échec représenterait mal le risque. Le raisonnement complet.
4. Durée de vie du certificat
Ce qu’il mesure. Pour combien de temps le certificat a été émis, comparé au plafond du CA/Browser Forum en vigueur à sa date d’émission.
Pourquoi. Distinct de l’expiration, qui demande quand le certificat s’épuise. La durée de vie demande comment fonctionne le renouvellement, et avec le plafond passant à 100 jours en mars 2027, un certificat à longue durée prédit une panne.
La subtilité qui compte. Le plafond est évalué contre notBefore, pas contre aujourd’hui. Un certificat de 398 jours émis en 2025 respectait la règle en vigueur au moment de sa frappe et reste valide. Un vérificateur comparant chaque certificat au plafond du jour produit un faux constat sur chaque certificat hérité légitimement émis, ce qui est précisément la manière dont un outil apprend aux gens à l’ignorer.
Notation. Au-dessus du plafond applicable : Medium. Dans le plafond mais au-dessus de l’étape suivante : information, signalant que la cadence de renouvellement doit changer avant cette étape. Sinon réussite. Le calendrier complet.
5. Trusted Types
Ce qu’il mesure. Si la CSP porte require-trusted-types-for 'script' et une liste blanche de politiques trusted-types.
Pourquoi. Toutes les autres directives CSP régissent l’origine des scripts. Le DOM XSS ne charge aucun script, donc aucune ne s’applique. Trusted Types est le seul mécanisme CSP qui traite le point d’injection.
Notation. Trois états, car ce sont réellement des postures différentes : les deux directives présentes valent réussite ; l’application sans liste blanche vaut Low, puisque n’importe quel code peut alors fabriquer des politiques et la traçabilité est perdue ; aucune des deux vaut Low. Le chemin de déploiement.
6. Integrity-Policy
Ce qu’il mesure. Les en-têtes de réponse Integrity-Policy et Integrity-Policy-Report-Only de SRI niveau 2.
Pourquoi. Le contrôle SRI existant rapporte si les scripts portent individuellement des attributs d’intégrité. Integrity-Policy est la couche d’application qui empêche la couverture de se dégrader quand quelqu’un ajoute un script et oublie l’attribut.
Notation. Appliqué vaut réussite. Report-only vaut information, puisque les violations sont signalées mais les scripts s’exécutent. Absent vaut information. Le support navigateur reste partiel, notamment dans Safari, donc une sévérité plus dure ne serait pas défendable aujourd’hui. Pourquoi cela compte malgré tout.
Mappage des référentiels
Chaque nouveau contrôle se mappe dans les trois référentiels du reste de la base, car un constat non mappé est invisible dans le rapport de preuve que les clients utilisent réellement.
| Contrôle | NIS2 | ISO 27001:2022 | DORA |
|---|---|---|---|
| Politique MTA-STS | 21(2)(h), 21(2)(e) | A.8.24, A.5.14 | Art.9, Art.7 |
| Remontée TLS-RPT | 21(2)(b), 21(2)(h) | A.8.16, A.5.14 | Art.10, Art.9 |
| Accord de clés post-quantique | 21(2)(h) | A.8.24 | Art.9 |
| Durée de vie du certificat | 21(2)(h) | A.8.24 | Art.9 |
| Trusted Types | 21(2)(g), 21(2)(e) | A.8.28, A.8.26 | Art.9 |
| Integrity-Policy | 21(2)(d), 21(2)(g) | A.5.21, A.8.28 | Art.28, Art.6 |
Ce qui n’a pas changé
Le chiffre publié de 66 contrôles sur 25 catégories reste tel quel. Il a toujours été un nombre conservateur situé à l’intérieur de la plage implémentée plutôt qu’un décompte de tout ce que le moteur peut émettre, et ajouter des contrôles le rend plus conservateur, pas moins.
Nous préférons sous-annoncer un nombre vérifiable que gonfler un nombre qui ne l’est pas. Ce qu’un scan externe peut et ne peut pas prouver.
En résumé
Six contrôles ajoutés : deux pour le transport du courrier, un pour l’accord de clés, un pour le processus de certificat, deux pour l’intégrité côté navigateur.
Deux sont notés en information à dessein, car rapporter une exposition prospective comme un échec serait inexact, et l’exactitude est la seule chose qui rend une note digne d’être citée.
Passez de la lecture à l'action
Scannez votre domaine gratuitement. Premiers résultats en moins de 10 secondes — sans inscription.