Quel est le niveau de protection des sites les plus populaires de Pologne ? 1 000 domaines .pl mesurés (septembre 2026)

J'ai pris les 1 000 premiers domaines .pl du classement Tranco, une liste conçue pour la recherche, et, le matin du 24 septembre 2026, je les ai contrôlés de l'extérieur, comme les voit n'importe quel visiteur ou serveur de messagerie. La mesure était passive : des requêtes DNS, une visite de chaque page d'accueil et quelques connexions TLS par domaine, sans recherche de vulnérabilités ni tentative de connexion. Les résultats ont été comptés par les mêmes contrôles que ceux des outils gratuits de ShieldWave. Je ne nomme aucun des domaines.

Principaux constats

• Le 24 septembre 2026, 460 des 997 domaines .pl les plus populaires (46,1 %) avaient une politique DMARC qui demande aux serveurs de messagerie destinataires de rejeter ou de mettre en quarantaine les messages qui usurpent le domaine. Parmi les domaines qui reçoivent du courrier (avec des enregistrements MX), c'était 445 sur 927 (48,0 %).
• Dans la mesure du 24 septembre 2026, 406 des 882 pages d'accueil polonaises populaires servies en HTTPS (46,0 %) envoyaient un en-tête HSTS, et 217 sur 887 (24,5 %) appliquaient une Content-Security-Policy.
• En septembre 2026, 230 des 952 domaines .pl populaires (24,2 %) acceptaient encore les connexions TLS 1.0. Sur ces 230, 149 passent par Cloudflare, qui accepte TLS 1.0 tant que le propriétaire ne relève pas la version minimale.
• Il n'y a aucun enregistrement DMARC pour 274 domaines sur 997 (27,5 %), et 248 autres (24,9 %) en ont un réglé sur p=none, qui ne bloque rien.
• Dans le contrôle des en-têtes de sécurité, 20 pages d'accueil sur 887 (2,3 %) ont obtenu la meilleure note, A, et 290 (32,7 %) la plus basse, F.
• J'ai trouvé un fichier security.txt, qui indique aux chercheurs où signaler une vulnérabilité, sur au moins 78 sites sur 881 (8,9 %).
• Sur les 46 sites qui indiquent leur version de PHP dans un en-tête, 26 utilisent une version qui ne reçoit plus aucun correctif, dont 11 PHP 5.

E-mail : qui peut envoyer du courrier au nom de votre domaine

Un e-mail falsifié avec l'adresse de votre entreprise dans le champ « De » suffit à envoyer une fausse facture à un client. Trois enregistrements DNS en protègent : SPF, DKIM et DMARC, que j'explique dans SPF, DKIM et DMARC expliqués. C'est DMARC qui tranche : il indique au serveur destinataire que faire d'un message qui se dit de vous mais échoue aux contrôles.

SPF est presque partout : 915 domaines sur 999 l'ont (91,6 %). SPF seul ne vérifie cependant pas l'adresse que le destinataire voit dans le champ « De ». Seul DMARC le fait, et ici les chiffres sont plus bas.

• Pas d'enregistrement DMARC27,5%274 sur 997
• p=none : surveille, ne bloque rien24,9%248 sur 997
• quarantine ou reject, mais seulement pour une partie du courrier (pct inférieur à 100)1,5%15 sur 997
• quarantine ou reject pour tout le courrier46,1%460 sur 997

Domaines avec une réponse DNS définitive. Seul l'enregistrement propre au domaine compte.

Ainsi 460 domaines sur 997 (46,1 %) bloquent l'usurpation. Parmi les domaines avec des enregistrements MX, ceux qui reçoivent du courrier, c'est 445 sur 927 (48,0 %). Les autres n'ont pas de DMARC ou ont un enregistrement qui se contente de surveiller. Qu'un message falsifié arrive ensuite ou non dans la boîte de réception est laissé entièrement aux filtres du destinataire.

p=none n'est pas une erreur mais la première étape recommandée : le domaine collecte des rapports, et son propriétaire voit qui envoie du courrier en son nom. Sur les 723 enregistrements DMARC, 622 (86,0 %) contiennent une adresse pour les rapports agrégés (rua). La protection ne commence toutefois qu'avec quarantine ou reject. Parmi les domaines qui ont DMARC, les trois réglages sont presque aussi fréquents : p=none sur 248 sur 723 (34,3 %), quarantine sur 263 (36,4 %) et reject sur 212 (29,3 %).

Défauts SPF plus mineurs : 12 enregistrements sur 915 (1,3 %) exigent plus des 10 requêtes DNS que permet la norme, deux domaines publient deux enregistrements SPF au lieu d'un, et un termine son enregistrement par +all, ce qui autorise n'importe quel serveur à envoyer du courrier en son nom.

Je ne rapporte pas DKIM. Les sélecteurs sous lesquels les clés DKIM sont publiées ne peuvent pas être listés par le DNS : « introuvable » voudrait donc seulement dire « pas sous les noms courants ».

Chiffrement : HTTPS, HSTS et TLS

HTTPS lui-même est la norme. Les différences tiennent à ce qui l'accompagne : l'en-tête HSTS, les anciennes versions de TLS et l'enregistrement CAA.

Les dénominateurs diffèrent parce que chaque ligne ne compte que les domaines pour lesquels ce contrôle a obtenu une réponse. La section sur la méthode donne le détail.

HSTS est un en-tête qui indique au navigateur de n'utiliser que HTTPS pour le domaine pendant une durée donnée. Sans lui, chaque visite à une adresse tapée sans https:// commence par une connexion non chiffrée avant que le serveur ne la redirige, et sur le Wi-Fi de quelqu'un d'autre cette connexion peut être interceptée. HSTS est envoyé par 406 des 882 pages d'accueil en HTTPS (46,0 %), et par 268 (30,4 %) avec la durée recommandée d'au moins un an.

TLS 1.0 et 1.1 sont d'anciennes versions du protocole de chiffrement. Les navigateurs les ont désactivées en 2020, et l'IETF les a formellement dépréciées en 2021 (RFC 8996). TLS 1.0 est encore accepté par 230 domaines sur 952 (24,2 %). Un visiteur avec un navigateur récent se connecte de toute façon en TLS 1.2 ou 1.3 : ce n'est donc pas un moyen de prendre le contrôle d'un site. Cela signifie en revanche que le serveur accepte un chiffrement obsolète si on le lui demande, et les auditeurs ainsi que les questionnaires de sécurité des fournisseurs demandent la désactivation des anciennes versions.

Sur ces 230 domaines, 149 (64,8 %) passent par Cloudflare, qui accepte TLS 1.0 par défaut et ne s'arrête que quand le propriétaire relève la version minimale dans le tableau de bord. Les 81 autres acceptent TLS 1.0 sur leurs propres serveurs ou chez d'autres fournisseurs.

CAA est un enregistrement DNS qui liste les autorités de certification autorisées à émettre des certificats pour le domaine ; les autres doivent alors refuser. J'en ai trouvé un pour 192 domaines sur 999 (19,2 %).

En-têtes de sécurité

Les en-têtes de sécurité sont quelques lignes d'instructions que le serveur envoie au navigateur avec la page. Je les décris dans En-têtes de sécurité d'un site : ce qu'ils sont et quoi demander. Voici la fréquence à laquelle ils apparaissent sur les pages d'accueil (HSTS figure dans la section sur le chiffrement) :

26 autres pages d'accueil (2,9 %) n'ont la CSP qu'en mode Report-Only, dans lequel le navigateur ne bloque rien.

Le contrôle gratuit des en-têtes de sécurité (en anglais) les note de A à F. Chaque en-tête reçoit une lettre, HSTS et CSP comptent double, les autres simple, et la moyenne donne la note finale. L'étude a utilisé exactement cette échelle.

• A2,3%20 sur 887
• B21,8%193 sur 887
• C21,1%187 sur 887
• D22,2%197 sur 887
• F32,7%290 sur 887

L'échelle du contrôle gratuit des en-têtes de ShieldWave. HSTS et CSP comptent double, les autres en-têtes simple.

Un F ne veut pas dire qu'un site a une faille, et un A ne garantit pas qu'il n'en a pas. Les en-têtes sont une deuxième ligne de défense : ils limitent les dégâts quand autre chose échoue. Des en-têtes manquants signifient en général la configuration par défaut d'un serveur, qui ne les ajoute pas. Souvent, un CDN ou une extension les ajoute plus tard.

Le même jour et avec la même méthode, j'ai mesuré les 500 domaines .ae et les 500 domaines .sa les plus populaires (Émirats arabes unis et Arabie saoudite). Leurs pages d'accueil ont plus souvent une CSP (280 sur 656, 42,7 %) et HSTS (408 sur 652, 62,6 %). La comparaison est approximative : ces listes descendent plus bas dans le classement, et 344 des 1 000 pages d'accueil de là-bas n'ont pas pu être analysées depuis la Pologne. Le détail figure dans le compte rendu de cette mesure.

Plateformes et logiciels obsolètes

J'ai reconnu une plateforme sur une page d'accueil sur quatre. Sur 663 des 884 pages d'accueil (75,0 %), je n'ai trouvé aucune trace de plateforme connue : ce sont des sites sur mesure ou des sites qui ne révèlent pas ce sur quoi ils tournent. Les parts ci-dessous sont donc des minorants.

WordPress fait tourner 101 des 884 pages d'accueil (11,4 %). Viennent ensuite Drupal (25), Magento (21) et TYPO3 (13). Les plateformes de boutiques polonaises (IdoSell, Shoper, AtomStore et RedCart) en font tourner 12 à elles toutes.

La version de WordPress est visible sur 54 des 101. Ce sont de petits nombres, je ne donne donc que des effectifs :

• 28 des 54 ne sont pas sur la dernière version, 7.1.2,
• 22 sont sur une branche plus ancienne que 7.1,
• 18 ne sont pas sur la dernière version de leur propre branche, il leur manque donc des correctifs de sécurité déjà publiés pour elle,
• la plus ancienne version visible est WordPress 3.5.1, de 2013.

Seules 46 pages d'accueil sur 887 indiquent leur version de PHP dans un en-tête : ceci décrit donc ces 46, pas le web entier. Sur celles-ci, 26 utilisent des branches qui ne reçoivent plus aucun correctif (8.1 et plus anciennes), dont 11 PHP 5, dont la dernière branche a perdu son support fin 2018. 12 autres ne reçoivent que des correctifs de sécurité (8.2 et 8.3), et 8 sont entièrement prises en charge (8.4 et 8.5).

Un nom de serveur avec un numéro de version, comme Apache/2.4.41, apparaît dans les en-têtes de 74 pages d'accueil sur 887 (8,3 %). Divulguer la version n'est pas une faille en soi, mais cela restreint les bogues connus qui s'appliquent.

Je n'ai pas vérifié les extensions dans cette étude. Si votre site tourne sous WordPress, commencez par Extensions WordPress obsolètes : quoi mettre à jour en premier et quoi supprimer.

security.txt : où signaler une vulnérabilité

Le fichier /.well-known/security.txt (RFC 9116) donne l'adresse où un chercheur en sécurité peut signaler une vulnérabilité qu'il a trouvée. Sans lui, un signalement va à une adresse de contact générale, ou nulle part.

J'en ai trouvé un avec un champ Contact: sur 78 sites sur 881 (8,9 %). C'est un minorant : 41 autres sites ont répondu par une redirection vers un fichier security.txt à une autre adresse, et je n'ai pas suivi les redirections. Même si chacun menait à un fichier valide, on arriverait à 119 sur 881 (13,5 %). Sur les 78 fichiers, 55 ont le champ Expires que la norme exige.

Traceurs et plateformes de consentement

Cette partie est descriptive. Aucun JavaScript n'a été exécuté : je ne vois donc que les outils nommés dans le HTML de la page d'accueil. Je ne peux pas dire s'ils tournent ni quand : un script peut attendre le consentement du visiteur, et Google Tag Manager peut charger des outils qui ne figurent pas dans le code de la page.

• Google Tag Manager45,6%403 sur 884
• Google Analytics30,3%268 sur 884
• Gemius12,3%109 sur 884
• Meta Pixel10,2%90 sur 884
• Microsoft Clarity3,4%30 sur 884
• Hotjar2,5%22 sur 884
• Matomo2,0%18 sur 884

Sous quelque forme que ce soit : script, extrait d'installation ou simple appel. Figurer dans le code ne montre pas si l'outil tourne avant le consentement.

Google Analytics ou Google Tag Manager apparaît dans le code de 572 pages d'accueil sur 884 (64,7 %). Gemius, le système de mesure d'audience polonais, est présent sur 109 sur 884 (12,3 %). Google Consent Mode avec refus par défaut, dans lequel les outils de Google fonctionnent sans cookies jusqu'au consentement, apparaît sur 103 pages d'accueil sur 884 (11,7 %).

Une plateforme de consentement connue, comme Cookiebot, OneTrust, Didomi ou une utilisant le cadre IAB TCF, apparaît sur 293 pages d'accueil sur 884 (33,1 %). Cela ne veut pas dire que les autres n'ont pas de bandeau de consentement. Les bandeaux sur mesure, ceux intégrés aux plateformes de boutiques et les outils chargés via Google Tag Manager sont invisibles pour cette méthode, je ne tire donc de ces chiffres aucune conclusion sur la conformité juridique.

Ce que cela signifie pour votre entreprise

Si ces réglages manquent sur certains des sites les plus populaires du pays, ils sont faciles à oublier aussi sur un site plus petit. Chaque contrôle ci-dessous prend une minute et ne demande aucun accès à votre serveur.

1. E-mail. Lancez la vérification SPF, DKIM et DMARC (en anglais). Si vous n'avez pas de DMARC ou si vous êtes à p=none, passez à quarantine par étapes comme décrit dans SPF, DKIM et DMARC expliqués. Cela protège contre les fausses factures envoyées depuis votre domaine.
2. Chiffrement. La vérification du certificat SSL (en anglais) montre le certificat, la redirection HTTPS et les versions de TLS. Si votre site est derrière Cloudflare, changez le minimum dans le tableau de bord, sous SSL/TLS, Edge Certificates, Minimum TLS Version. Réglez TLS 1.2.
3. En-têtes. La vérification des en-têtes de sécurité (en anglais) montre ce qui manque. En-têtes de sécurité d'un site contient un descriptif prêt pour votre développeur : commencez par HSTS avec un max-age court et par une CSP en mode Report-Only.
4. security.txt. Publiez /.well-known/security.txt avec les champs Contact et Expires. Ce sont quelques lignes de texte.
5. Logiciels. Mettez à jour le CMS et les extensions, et retirez les numéros de version des en-têtes du serveur. Pour WordPress, voir Extensions WordPress obsolètes.
6. Traceurs et consentement. La vérification des cookies avant consentement (en anglais) montre si votre page d'accueil pose des cookies de suivi ou charge des outils d'analyse et de publicité avant l'accord du visiteur. Si vous êtes délégué à la protection des données, voir aussi Ce qu'un DPO peut vérifier sur le site d'un client sans service informatique.

Si vos clients relèvent de NIS2, leurs questionnaires pour fournisseurs portent sur les mêmes réglages. NIS2 et votre site explique comment vous préparer.

Méthode

Domaines. Liste Tranco L5PV4, générée le 23 septembre 2026 à 22 h 00 UTC à partir de 30 jours de données (du 25 août au 23 septembre 2026) de cinq fournisseurs : Chrome UX Report, Farsight, Majestic, Cloudflare Radar et Cisco Umbrella. Tranco est un classement conçu pour la recherche et durci contre la manipulation. J'ai pris les 1 000 premiers domaines finissant par .pl dans l'ordre du classement, domaines de deuxième niveau comme com.pl, gov.pl et edu.pl compris. Le million de tête contient 9 214 domaines .pl ; les 1 000 retenus se classent du rang 667 au rang 136 495. Tranco classe des domaines, pas des sites, la liste contient donc aussi des domaines techniques (CDN, hôtes de publicité et de mesure) sans page d'accueil.

Quand et d'où. Le 24 septembre 2026, de 07 h 39 à 07 h 43 UTC (de 09 h 39 à 09 h 43 heure polonaise), depuis une seule connexion réseau en Pologne. Les requêtes DNS sont allées aux résolveurs publics 1.1.1.1 et 8.8.8.8. Chaque requête HTTP s'identifiait comme ShieldWaveResearch/1.0 avec un lien vers shieldwave.io ; elle ne se faisait pas passer pour un navigateur.

Ce qui a été envoyé. Par domaine, seulement :

1. des requêtes DNS : adresses, MX, TXT (SPF et DMARC), CAA,
2. une visite de la page d'accueil (https://, ou http:// quand https ne répondait pas ; 5 redirections au plus),
3. une requête http:// simple pour voir si elle redirige vers https,
4. des poignées de main TLS sur le port 443 : une poignée de main complète et quatre sondes de version (1.0, 1.1, 1.2 et 1.3),
5. une requête vers /.well-known/security.txt.

Rien d'autre : aucune recherche de fichiers, de panneaux d'administration ou de sauvegardes, et aucun formulaire, connexion ou donnée de test.

Les mêmes contrôles que les outils gratuits. Les résultats ont été calculés par le même code que celui qui fait tourner les outils gratuits de ShieldWave (certificat, e-mail, en-têtes et cookies), à l'état du commit 8db196d. Chacun peut vérifier son propre domaine avec la même mesure.

Dénominateurs et exclusions. Chaque chiffre a son propre dénominateur, car tous les contrôles n'obtiennent pas de réponse de tous les domaines. Sur les 1 000 domaines, 887 pages d'accueil ont pu être analysées. Parmi les autres, 38 domaines n'ont donné aucune réponse HTTP (13 d'entre eux n'ont aucune adresse dans le DNS), 52 ont répondu par un mur anti-robots ou un blocage comme un 403, et 23 ont renvoyé une autre erreur. Ces 113 sont écartés des chiffres de pages d'accueil (en-têtes, HTML, security.txt, redirection) mais restent dans les chiffres DNS, e-mail et TLS, qui ne dépendent pas de la page. Les chiffres DNS ne comptent que les réponses définitives (pour DMARC, 997 sur 1 000).

Définitions. Une politique DMARC qui bloque l'usurpation est l'enregistrement propre au domaine avec p=quarantine ou p=reject et pct=100 ou sans pct. Un enregistrement hérité d'un domaine parent ne compte pas. HSTS n'est compté que sur les pages d'accueil qui finissent en HTTPS, et la CSP seulement quand elle est appliquée. security.txt compte quand la réponse est un 200 avec un champ Contact: ; une page HTML ne compte jamais.

Limites.

• Page d'accueil seulement, une visite, un jour. D'autres pages peuvent envoyer d'autres en-têtes.
• Pas de JavaScript : les traceurs et les outils de consentement sont lus dans le HTML. Je ne vois pas ce que charge Google Tag Manager ni ce que des scripts enregistrent plus tard.
• Beaucoup de résultats reflètent les réglages par défaut d'un CDN ou d'un hébergeur (TLS 1.0 chez Cloudflare, en-têtes ajoutés ou non en périphérie).
• Les sites qui ont bloqué la visite automatisée manquent dans les chiffres de pages d'accueil, et ils peuvent différer de ceux qui restent.
• security.txt est un minorant, car les redirections n'ont pas été suivies.
• La détection des plateformes est un minorant (75,0 % des pages d'accueil non reconnues).
• DKIM n'est pas rapporté.
• Mesure faite depuis la Pologne : les sites qui varient selon la localisation du visiteur peuvent paraître différents ailleurs.

Répétabilité et vérifications. Environ un quart d'heure plus tôt, j'ai fait un premier passage complet sur la même liste. Je ne le publie pas, parce que j'ai corrigé la détection de Gemius après coup. Hors chiffres Gemius, aucun des 250 indicateurs n'a différé entre les deux passages de plus de 0,9 point de pourcentage, et la différence médiane était de 0,0. Séparément, j'ai remesuré 36 domaines tirés au hasard, dont 20 de la liste polonaise, avec d'autres outils : DMARC et SPF par un autre résolveur (9.9.9.9), HSTS et l'en-tête Server avec curl, TLS 1.0 avec openssl, security.txt avec curl. Les 216 comparaisons concordaient.

Données. Je ne publie pas les données brutes, car elles nomment des sites précis. Tous les chiffres agrégés, chacun avec numérateur, dénominateur, pourcentage et population, sont téléchargeables librement sous licence CC BY 4.0 : pl-2026-09.csv et pl-2026-09.json (en anglais). La mesure peut être répétée : la liste Tranco est publique, et chaque contrôle tourne dans les outils gratuits de ShieldWave.

Comment citer

Version courte : Source : ShieldWave, mesure des 1 000 domaines .pl les plus populaires, 24 septembre 2026, https://shieldwave.io/blog/polish-websites-security-2026/

Version complète : Radosław Fedorczuk (ShieldWave, ENSOMEDIA), « Quel est le niveau de protection des sites les plus populaires de Pologne ? 1 000 domaines .pl mesurés (septembre 2026) », 24 septembre 2026, https://shieldwave.io/blog/polish-websites-security-2026/. Données agrégées sous licence CC BY 4.0.

Questions sur la méthode ou les données : support@shieldwave.io.