Niveau de sécurité des sites : ce que révèlent 884 audits Smart Audit

Un site qui s’ouvre n’est pas forcément un site protégé. Le propriétaire voit la page d’accueil, le formulaire de commande et le catalogue, et en conclut que tout va bien. Mais une partie de ce qui se passe sur un site n’est visible que de l’extérieur, aux yeux de la personne qui le vérifie.

Nous avons lancé le service Smart Audit, qui regarde justement les sites des autres de cette manière : de façon passive, uniquement les pages publiques. Il ne modifie rien, ne devine aucun mot de passe et ne s’introduit pas à l’intérieur. Au moment de préparer cet article, nous disposions des résultats de 884 sites d’entreprises uniques — pour chacun, on retient la dernière vérification réussie. Nous n’avons pas trié les « bons » et les « mauvais » : l’échantillon comprend des boutiques en ligne, des sites institutionnels, des médias et des sites de grandes organisations. Nous ne citons aucun nom : c’est le tableau d’ensemble qui nous intéresse, pas des adresses précises.

Voici ce que nous avons observé, ce que cela implique pour le propriétaire et par où commencer les corrections.

Vue d’ensemble : 22 points sur 100

La note globale moyenne sur l’ensemble des 884 sites est de 22 sur 100. Par domaine : sécurité — 19, rapidité — 18, visibilité dans les moteurs de recherche — 17.

• 480 sites (54 %) ont obtenu moins de 20 points sur 100 ;
• 286 (32 %) — entre 20 et 39 ;
• 96 (11 %) — entre 40 et 59 ;
• seulement 22 sites (2,5 %) atteignent 60 et plus.

Pour la note de sécurité seule, le tableau est le suivant : pour 466 sites (53 %), elle est inférieure à 10 points, pour 652 (74 %) elle est inférieure à 30, et seuls 75 sites (8,5 %) obtiennent 60 et plus.

Une précision tout de suite, pour que ces chiffres ne soient pas mal compris. « 22 sur 100 » ne signifie pas qu’un site est protégé à 22 %, et encore moins qu’il a été piraté. C’est l’écart par rapport à un socle de vérifications de base : le site active-t-il les protections qui sont depuis longtemps considérées comme la norme ? La plupart des points se perdent sur des éléments qui se corrigent vite et à peu de frais. C’est précisément pour cela que ces chiffres méritent qu’on s’y arrête.

Premier niveau : des portes sans verrou

Chaque page que le serveur envoie au navigateur s’accompagne de « consignes » techniques : ce que cette page a le droit de faire et ce qui lui est interdit. Ce sont les en-têtes de sécurité. Ils ne rendent pas un site imprenable, mais ils amortissent le choc lorsqu’une autre faille apparaît. Or leur absence est quasi générale :

• La politique de sécurité du contenu (CSP) est absente sur 90 % des sites. Elle définit quels scripts le navigateur est autorisé à exécuter sur la page. Sans elle, n’importe quel code injecté s’exécute au même titre que le code « maison ». C’est ainsi que des skimmers apparaissent sur les pages de validation de commande : des scripts qui copient discrètement les données des cartes bancaires. Pour une boutique en ligne (il y en a 130 dans l’échantillon), c’est le « verrou » manquant le plus coûteux.
• La politique d’autorisations (Permissions-Policy) manque sur 93 % des sites. Elle limite ce que les widgets intégrés au site peuvent demander au visiteur : caméra, microphone, géolocalisation.
• La politique de transmission de l’adresse (Referrer-Policy) manque sur 88 % des sites. Sans elle, les adresses complètes de vos pages — avec les numéros de commande internes ou les jetons présents dans les liens — partent vers des compteurs et des services publicitaires tiers.
• La protection contre l’intégration dans des cadres étrangers manque sur 73 % des sites. Un individu malveillant peut afficher votre site dans un cadre transparent sur sa propre page et pousser une personne à cliquer sur un « bouton » qui se trouve en réalité sur votre site. Cette technique s’appelle le clickjacking.
• L’interdiction de « deviner » le type d’un fichier manque sur 71 % des sites (nosniff).
• HSTS n’est pas activé sur 62 % des sites. Sans lui, la première visite d’une personne peut passer par un canal non chiffré — et sur un réseau Wi-Fi public, cela ouvre la porte à la substitution de la page.

Soyons honnêtes : l’absence d’un en-tête ne signifie pas qu’un site est piraté. C’est un niveau de protection qui manque. Mais il se corrige en quelques lignes dans la configuration du serveur, et son absence dit presque toujours la même chose : personne ne s’est occupé des réglages de sécurité.

Deuxième niveau : ce qui traîne à la vue de tous

Cette partie est plus sérieuse. Sur 172 sites sur 884 (19 %) — près d’un sur cinq — des adresses techniques qui n’auraient jamais dû être publiques sont accessibles de l’extérieur. Certains sites en cumulent plusieurs à la fois. Répartition par type :

• Liste des comptes WordPress — 103 sites (12 %). L’adresse standard renvoie les identifiants des utilisateurs, y compris des administrateurs. La moitié du travail de l’attaquant est faite : l’identifiant est connu, il ne reste plus qu’à trouver le mot de passe.
• Dossier technique Git — 45 sites (5 %). On peut en reconstituer le code source du site, et l’historique des modifications contient parfois des mots de passe et des clés qu’on a un jour inscrits « temporairement » dans le code.
• Page phpinfo — 43 sites (5 %). Elle affiche les versions de PHP, les modules, les chemins sur le serveur, les variables d’environnement. Pour un attaquant, c’est une carte du terrain toute prête.
• Page technique d’état du serveur — 34 sites (4 %). On y voit quelles adresses les visiteurs ouvrent en ce moment et depuis quelles IP.
• Fichier de configuration .env — 33 sites (4 %). Un tel fichier contient en général les mots de passe de la base de données, les clés de la messagerie et des services de paiement.
• Copie de la base de données — 28 sites (3 %). Un fichier que quelqu’un a laissé à la racine du site « juste une minute » : clients, commandes, téléphones, adresses.

Il est important de comprendre qu’ici il n’y a rien à pirater. Il suffit d’ouvrir l’adresse dans un navigateur. Smart Audit n’accède pas au contenu de ces fichiers : il constate seulement qu’une réponse existe à cette adresse, et le contenu n’est ni lu ni conservé. Mais ce que nous ne faisons pas, n’importe qui d’autre peut le faire — et des scanners automatiques passent en revue ce genre d’adresses jour et nuit, partout sur Internet.

Troisième niveau : des logiciels obsolètes

Parmi les sites vérifiés, la plateforme la plus répandue est WordPress — 222 sites (25 %), suivie d’OpenCart — 88 (10 %). Pour les autres, la plateforme n’a pas pu être déterminée, ou le site a été développé sur mesure.

154 sites (17 %) indiquent eux-mêmes la version de leur système. On le voit dans des balises techniques de la page. Prises isolément, elles ne font pas de mal : c’est leur association avec une version ancienne qui pose problème. Parmi ceux qui affichent leur version de WordPress, 22 sites fonctionnent sur les branches 4 et 5, publiées il y a de nombreuses années. Pour de telles versions, mieux vaut ne pas compter sur le fait que quelqu’un corrigera les nouvelles vulnérabilités.

Autre sujet : la version du serveur lui-même. Chez 247 sites (28 %), les en-têtes de réponse indiquent les versions exactes des logiciels serveur. L’attaquant n’a pas à deviner : il voit la version et applique aussitôt la méthode connue pour elle. L’exemple des vulnérabilités critiques de PHP montre l’importance du sujet : la seule défense est une mise à jour faite à temps. Quant au revers de la médaille — ce qui se passe quand une mise à jour est faite sans préparation —, nous l’avons raconté dans l’analyse de la mise à jour automatique d’un plugin.

Quatrième niveau : formulaires et connexions, là où les données de vos clients entrent dans le site

C’est par les formulaires qu’une personne vous transmet son nom, son téléphone, son adresse, parfois son paiement. Leur conception compte donc plus que tout. Voici ce que nous avons trouvé :

• 489 sites (55 %) — des formulaires sans protection contre la falsification de requête (CSRF). Concrètement, une page tierce peut forcer le navigateur de votre visiteur ou de votre administrateur à envoyer un formulaire en son nom, sans lui demander son avis.
• 543 (61 %) — des formulaires qui collectent des données personnelles sans consentement à leur traitement. Ce n’est pas seulement une question de sécurité : c’est aussi une question de conformité à la législation sur les données personnelles.
• 532 (60 %) — des formulaires sans protection contre les robots. La conséquence est connue de tous ceux qui ont vu leur messagerie saturée de spam venant de « demandes ».
• 76 sites (9 %) — des formulaires qui transmettent des données personnelles dans l’adresse de la page (méthode GET). Le téléphone et le nom restent dans l’historique du navigateur, dans les journaux du serveur, et se retrouvent chez des services tiers avec l’adresse.
• 321 (36 %) — des cookie sans attributs de protection. Ils sont plus faciles à intercepter ou à lire par un script.

Et quelques bases qui, pourrait-on croire, auraient dû être en place partout depuis longtemps : 35 sites (4 %) s’ouvrent sans aucun chiffrement (le navigateur y affiche l’avertissement « Non sécurisé »), chez 43 le certificat arrive bientôt à expiration, et sur 36 sites une partie du contenu d’une page sécurisée est chargée par un canal non protégé — ce qui fait que le chiffrement n’est pas pleinement effectif.

Ce que cela risque pour le propriétaire

Si l’on met le jargon de côté, il n’y a que quelques risques pour l’entreprise.

1. Fuite des données clients. Une copie de la base ou un fichier de configuration accessible n’est pas un « détail technique » : c’est la possibilité de repartir avec la liste de vos clients sans rien pirater. S’ensuivent une atteinte à la réputation et la responsabilité de la protection des données personnelles.
2. Du code étranger sur votre site. Des mises à jour non installées, plus l’absence de CSP — et des publicités pour des casinos, des redirections vers des sites tiers ou un skimmer sur la page de paiement apparaissent. Vous risquez de l’apprendre par un client plutôt que par vous-même.
3. La mention « site dangereux » et la chute dans les résultats de recherche. Les navigateurs et les moteurs de recherche ne prennent pas de risques avec les visiteurs. Un site piraté peut reculer dans les résultats pendant des semaines, et le retour prendra plus de temps que la chute.
4. L’arrêt d’activité et le coût de la remise en état. Se relever d’un piratage coûte en général bien plus cher que la prévention. Et tant que le site est hors service, il n’y a pas de commandes.
5. La perte de confiance des partenaires. De plus en plus souvent, les grands clients et les appels d’offres demandent de montrer où vous en êtes en matière de sécurité. La réponse « nous ne savons pas » ne fait pas gagner de points.

Par où commencer : un ordre qui fonctionne

1. Fermer l’accès aux fichiers techniques exposés. Ce sont les failles les plus coûteuses, et ce sont les plus rapides à corriger : une heure de travail suffit en général. Les fichiers contenant des mots de passe doivent être retirés de l’accès public, puis les mots de passe eux-mêmes doivent être changés, car on ne peut pas les considérer comme non compromis.
2. Mettre à jour le système et les plugins et retirer des réponses du serveur les versions exactes. Mettre à jour sur une copie du site, pas à l’aveugle sur le site en production.
3. Ajouter les en-têtes de sécurité. Commencer par HSTS, la protection contre l’intégration, nosniff et Referrer-Policy : ils ne cassent presque jamais rien. Introduire CSP progressivement, d’abord en mode observation.
4. Remettre HTTPS en ordre : renouvellement automatique du certificat, redirection depuis http, aucun contenu non sécurisé.
5. Vérifier les formulaires : jeton contre la falsification de requête, protection contre les robots, transmission uniquement par la méthode POST, consentement clair au traitement des données.
6. Mettre en place des sauvegardes hors du site et une surveillance. Une copie qui se trouve à côté du site disparaît avec lui en cas de piratage. Et la disponibilité du site ne doit pas être vérifiée par un client.

Comment nous vous aidons

Smart Audit répond à la question « qu’est-ce qui ne va pas, exactement » dans le langage des priorités : le rapport sépare les constats visibles tout de suite de ceux qui tiennent à la plateforme même du site. Les premiers, nous les corrigeons sur votre site actuel. Les seconds — versions anciennes, limites du système, impossibilité de configurer correctement la protection — se règlent en général par une migration vers notre système Smart CMS, où les en-têtes de sécurité, la protection des formulaires et les mises à jour sont déjà intégrés au socle. La migration, nous la réalisons nous-mêmes : nous transférons les pages et les adresses, conservons les réglages de visibilité dans les moteurs de recherche et vous accompagnons à chaque étape, pour que vous ne perdiez ni trafic ni commandes.

Quelle que soit la manière dont vous choisirez de commencer, il vaut d’abord la peine de voir votre propre situation.

---

Vous pouvez vérifier votre site gratuitement, sans inscription, en trois minutes, sur audit.sgt.com.ua. Et si vous souhaitez que nous examinions le résultat avec vous et vous disions franchement ce qu’il faut corriger en premier, écrivez-nous.