Données du SiteGuardian EU Web Security Benchmark — avril 2026, 704 044 sites web évalués dans 30 pays.
94,8% échouent
Nous avons analysé 704 044 sites web européens de manière automatisée — selon six dimensions : en-têtes de sécurité HTTP, configuration TLS, sécurité DNS, authentification des e-mails, accessibilité et conformité des cookies.
Les résultats :
| Note | Part |
|---|---|
| A | 0,0% (16 sites web) |
| B | 0,2% |
| C | 5,0% |
| D | 52,5% |
| F | 42,3% |
Il ne s'agit pas de sites marginaux. Le benchmark inclut des entreprises, des organismes gouvernementaux, des hôpitaux, des banques et des plateformes de commerce en ligne de toute l'UE — des organisations soumises à NIS2, DORA ou au RGPD qui traitent des données personnelles au quotidien.
Le cadre réglementaire : ce que l'UE exige
Au cours des trois dernières années, l'UE a construit un cadre réglementaire qui transforme la sécurité web d'un simple atout en une obligation légale. Trois règlements se distinguent :
NIS2 (Directive 2022/2555) — transposition nationale prévue depuis octobre 2024. L'article 21(2) exige des entités essentielles et importantes la mise en œuvre de mesures concrètes : cryptographie, réponse aux incidents, sécurité de la chaîne d'approvisionnement et — à l'alinéa (e) — gestion et divulgation des vulnérabilités. Les secteurs couverts incluent l'énergie, les transports, la santé, l'infrastructure numérique, l'industrie manufacturière, l'agroalimentaire, les services postaux et les fournisseurs numériques. Sanctions : jusqu'à 10 millions d'euros ou 2% du chiffre d'affaires annuel mondial.
DORA (Règlement 2022/2554) — en vigueur depuis janvier 2025 pour le secteur financier. Les articles 6-8 imposent une gestion des risques TIC incluant l'identification et la remédiation des vulnérabilités. Les entités concernées incluent les banques, les assureurs, les sociétés d'investissement, les prestataires de services sur crypto-actifs et leurs fournisseurs TIC critiques.
Cyber Resilience Act (Règlement 2024/2847) — signalement obligatoire des vulnérabilités activement exploitées à partir de septembre 2026 (Art. 11), divulgation coordonnée des vulnérabilités à partir de décembre 2027 (Art. 14). S'applique aux fabricants, importateurs et distributeurs de produits numériques. Sanctions : jusqu'à 15 millions d'euros ou 2,5% du chiffre d'affaires.
Les exigences sont en place. Qu'en est-il de la réalité ?
En-têtes de sécurité HTTP : la première ligne de défense est absente
Les en-têtes de sécurité sont des instructions côté serveur qui protègent le navigateur contre le cross-site scripting, le clickjacking, la confusion MIME et les attaques par dégradation. Ils ne coûtent rien, nécessitent généralement une seule ligne de configuration, et pourtant restent à peine adoptés :
| En-tête | Adoption | Protection |
|---|---|---|
| Strict-Transport-Security (HSTS) | 27,6% | Empêche la dégradation vers HTTP |
| X-Content-Type-Options | 27,7% | Bloque le MIME sniffing |
| X-Frame-Options | 19,2% | Empêche le clickjacking |
| Referrer-Policy | 13,1% | Contrôle les fuites de referrer |
| Content-Security-Policy (CSP) | 10,8% | Atténue les XSS et les injections |
| Permissions-Policy | 6,4% | Restreint les API du navigateur |
Trois sites web sur quatre autorisent les connexions non chiffrées, même s'ils disposent d'un certificat TLS — HSTS est absent. 24,3% ne redirigent même pas vers HTTPS automatiquement.
Content Security Policy — la défense la plus efficace contre les attaques XSS — est absente sur 89% des sites web.
Sécurité des e-mails : le phishing en toute simplicité
Le phishing et le Business Email Compromise sont les vecteurs d'attaque les plus courants en Europe. Les contre-mesures techniques existent depuis des années — et restent non déployées :
| Standard | Adoption | Fonction |
|---|---|---|
| SPF | 75,7% | Vérification de l'expéditeur |
| STARTTLS | 56,3% | Chiffrement du transport |
| DMARC | 46,8% | Application des politiques |
| DKIM | 31,1% | Intégrité du message |
| MTA-STS | 0,5% | Chiffrement du transport obligatoire |
SPF seul ne suffit pas. Sans DMARC configuré en reject ou quarantine, n'importe qui peut envoyer des e-mails au nom de votre domaine. Parmi les 46,8% qui ont DMARC, 63% définissent la politique à none — c'est-à-dire sans application. Le domaine reste usurpable.
Les erreurs de configuration que nous trouvons sont particulièrement révélatrices. Nous voyons des politiques DMARC comme quarantaine, rejet, keiner, brak (polonais pour « manquant »), beleidsnaam (néerlandais pour « nom de politique ») — et un site web qui a collé sa clé RSA entière dans le champ de politique. Ces erreurs de configuration sont difficiles à détecter : l'enregistrement existe, la case de conformité est cochée, mais la protection ne fonctionne pas. C'est exactement l'écart entre « configuré » et « efficace » que SiteGuardian a été conçu pour combler : des vérifications automatisées qui vérifient non seulement la présence, mais le bon fonctionnement de chaque mesure.
DNS : les fondations ne sont pas sécurisées
| Standard | Adoption | Fonction |
|---|---|---|
| DNSSEC | 15,8% | Protection contre le DNS spoofing |
| CAA | 3,0% | Contrôle de l'émission de certificats |
| MTA-STS | 0,5% | Chiffrement obligatoire des e-mails |
| DANE/TLSA | <1% | Épinglage de certificats pour SMTP |
84% des domaines européens n'ont aucune protection DNSSEC. Un attaquant capable de manipuler les réponses DNS peut rediriger les utilisateurs vers des sites frauduleux — avec un certificat TLS valide, si aucun enregistrement CAA ne restreint l'émission. 97% n'en ont aucun.
L'indicateur security.txt
Le RFC 9116 définit un simple fichier texte à /.well-known/security.txt qui fournit aux chercheurs en sécurité un canal de signalement standardisé. L'ANSSI et l'ENISA le recommandent comme bonne pratique, NIS2 exige la divulgation des vulnérabilités, et le Cyber Resilience Act rend la divulgation coordonnée obligatoire.
Taux d'adoption dans l'UE : 2,8%.
Le constat intéressant : security.txt corrèle fortement avec la maturité globale du site web.
| Métrique | AVEC security.txt | SANS | Facteur |
|---|---|---|---|
| Score composite | 55 | 42 | +31% |
| HSTS | 72% | 26% | 2,8x |
| Content Security Policy | 47% | 10% | 4,7x |
| Note F | 6% | 44% | 7x moins |
security.txt n'est pas une solution miracle. Ceux qui prennent le temps de le configurer se sont généralement occupés de tout le reste aussi. C'est un indicateur de maturité en sécurité — s'il manque, tout le reste manque généralement aussi.
Où en est l'Europe : le classement par pays
| Rang | Pays | Score | Nombre |
|---|---|---|---|
| 1 | Malte | 46 | 640 |
| 2 | Islande | 45 | 928 |
| 3 | Allemagne | 45 | 203 075 |
| 4 | Royaume-Uni | 44 | 73 769 |
| 5 | Luxembourg | 44 | 1 303 |
| 6 | Suisse | 43 | 26 248 |
| 7 | Norvège | 43 | 8 814 |
| 8 | Pays-Bas | 43 | 37 893 |
| ... | |||
| 26 | Espagne | 39 | 26 214 |
| 27 | Autriche | 39 | 30 804 |
| 28 | Hongrie | 38 | 6 886 |
| 29 | Lituanie | 38 | 3 539 |
| 30 | Pologne | 37 | 30 694 |
L'Allemagne est en tête parmi les grands États membres de l'UE — mais avec 45 points sur 100. Le meilleur d'un mauvais lot. L'écart entre le rang 1 et le rang 30 n'est que de 9 points. L'Europe n'a pas de leader qui fixe le standard. Elle a un déficit continental.
Ce que les RSSI doivent faire maintenant
1. Mesurez votre point de départ. On ne peut pas gérer ce qu'on ne mesure pas. Analysez vos domaines — de manière automatisée, régulière, sur les six dimensions.
2. Activez les en-têtes de sécurité. HSTS, CSP, X-Content-Type-Options — trois en-têtes qui atténuent la majorité des attaques web courantes. La plupart des frameworks web peuvent les ajouter avec une seule ligne de configuration.
3. Configurez DMARC en reject. Commencez par quarantine et pct=10, surveillez les rapports, puis passez à reject. policy=none ne protège personne.
4. Activez DNSSEC. Contactez votre fournisseur DNS. La plupart des grands fournisseurs le supportent — il suffit de l'activer.
5. Configurez security.txt. Cinq minutes d'effort, RFC 9116. Deux champs obligatoires : Contact et Expires. L'ENISA le considère comme une bonne pratique, et l'Art. 21(2)(e) de NIS2 exige la divulgation des vulnérabilités.
6. N'analysez pas que la page d'accueil. Sous-domaines, API, serveurs de messagerie — la surface d'attaque est plus grande que la page d'accueil. Un benchmark automatisé découvre systématiquement ce que les audits manuels manquent.
Méthodologie
Cet article est basé sur le SiteGuardian EU Web Security Benchmark couvrant 704 044 sites web dans 30 pays européens (données d'avril 2026). Le benchmark évalue six dimensions : en-têtes de sécurité HTTP, certificats TLS, sécurité DNS (DNSSEC, CAA, DANE, MTA-STS), authentification des e-mails (SPF, DKIM, DMARC, STARTTLS), accessibilité (WCAG 2.2 AA) et conformité des cookies. Toutes les analyses sont exécutées de manière automatisée et continue, sans sélection manuelle ni sponsoring.
Le benchmark est accessible gratuitement sur siteguardian.io/benchmark.
SiteGuardian est un outil de conformité et de surveillance de la sécurité web basé dans l'UE, développé en Allemagne.