Sécurité, séance 3 : failles courantes et durcissement

Par où entrent les attaques, et ce qui vous incombe ensuite

Pourquoi cette séance existe

Personne ne vous en voudra si votre site est attaqué. On vous en voudra de ne pas avoir su quoi faire ensuite.

C’est la seule manière juste de poser le sujet. Un site WordPress accessible publiquement est sondé en permanence par des systèmes automatisés qui ne savent pas ce qu’ils attaquent et ne s’y intéressent pas. Vous ne pouvez pas empêcher qu’on essaie. Vous pouvez décider ce qui se passe quand quelqu’un réussit.

Cette séance ne fera pas de vous des techniciens de sécurité. Elle vous rend capables de trois choses qu’aucun prestataire ne fera à votre place : évaluer le risque réel de votre site, arbitrer les mesures qui valent leur coût, et savoir ce que la loi vous impose si des données personnelles sont concernées.

Ce que vous saurez à la fin de cette séance

• Par où entrent réellement les attaques, chiffres à l’appui, et ce que cela implique pour vos décisions d’achat
• Les six mesures qui couvrent l’essentiel du risque, et ce qu’elles coûtent
• Pourquoi une sauvegarde non testée n’est pas une sauvegarde
• Ce que le RGPD impose en cas de violation de données, et dans quel délai

1. Par où entrent les attaques

1.1 Ce n’est pas contre vous

La première correction à apporter à l’intuition commune : les attaques sur un site d’entreprise ordinaire ne sont pas ciblées. Elles sont conduites par des programmes qui parcourent le web, testent des adresses au hasard, et essaient une liste de failles connues sur tout ce qu’ils trouvent.

Conséquence directe, et elle est contre-intuitive : la taille de votre entreprise ne vous protège pas. Un site vitrine de trois pages est sondé exactement comme un site à fort trafic. Il est même une cible plus intéressante, parce qu’il est moins surveillé et qu’un serveur compromis sert à autre chose : envoyer du courrier indésirable, héberger des pages frauduleuses, ou relayer d’autres attaques.

L’argument « nous sommes trop petits pour intéresser quelqu’un » est le plus répandu et le plus faux.

1.2 Où sont les failles, en chiffres

Un rapport annuel recense les vulnérabilités publiées sur l’écosystème WordPress. Les proportions sont stables d’une année sur l’autre et elles décident de tout votre raisonnement¹.

Plus de 11 000 vulnérabilités nouvelles sur une année, soit une trentaine par jour, en augmentation de 42 % sur l’année précédente. Toutes ne présentent pas le même danger : un peu plus d’un tiers appellent une protection, et 17 % sont de gravité élevée avec un risque d’exploitation massive.

Un chiffre à part, contre-intuitif, et c’est celui qui vous concerne comme acheteur : les composants payants ne sont pas plus sûrs. Ils représentent 29 % des vulnérabilités signalées, mais 76 % de celles-là se sont révélées réellement exploitables, et les composants payants comptent trois fois plus de vulnérabilités effectivement exploitées que les gratuits. La raison est documentée : leur code n’est pas public, donc beaucoup moins de chercheurs les examinent.

1.3 Ce que ces chiffres commandent

Trois conclusions de gestion, et aucune n’est technique.

Le cœur de WordPress n’est pas votre problème. Il est audité, corrigé vite, et il se met à jour tout seul pour les correctifs de sécurité. Le débat « WordPress est-il sûr » est mal posé : la question est « qu’avez-vous installé dessus ».

Chaque extension est une décision d’achat. Installer une extension, c’est faire entrer dans votre site du code écrit par un tiers, que vous n’auditerez jamais, et dont vous dépendez pour les correctifs. Le nombre d’extensions actives est le meilleur indicateur de surface d’exposition d’un site, et c’est un nombre que vous contrôlez.

Une extension abandonnée est une porte ouverte. Elle continue de fonctionner et cesse d’être corrigée. C’est la situation la plus dangereuse, parce qu’elle est invisible : rien ne casse, rien n’alerte.

À retenir. Le risque n’est presque jamais dans WordPress lui-même : il est dans ce que vous y ajoutez. Le nombre d’extensions actives, leur fraîcheur et la vitalité de leur éditeur sont des critères de gestion, pas des détails techniques. Une extension qui n’a pas été mise à jour depuis un an se désinstalle.

2. Les six mesures qui couvrent l’essentiel

Elles sont classées par rapport entre effort et effet. Les trois premières coûtent presque rien et couvrent la majorité du risque réel.

2.1 Les mises à jour, appliquées et surveillées

Une faille connue et corrigée par l’éditeur reste exploitable tant que vous n’avez pas appliqué le correctif. L’essentiel des sites compromis le sont par une faille publiée des mois plus tôt.

Ce qui manque presque toujours n’est pas la capacité technique de mettre à jour, c’est quelqu’un dont c’est la responsabilité et un moment prévu pour le faire. Les mises à jour automatiques traitent une partie du sujet, mais elles peuvent casser un site : sur un site qui compte, elles s’appliquent après vérification, et jamais un vendredi soir.

2.2 Les comptes et les rôles

WordPress distingue plusieurs rôles, du simple abonné à l’administrateur. Le principe est celui du moindre privilège : chacun reçoit le niveau nécessaire à son travail, et rien de plus.

Deux fautes très répandues, que vous rencontrerez dans presque toutes les structures.

Le compte partagé : un seul accès administrateur, dont le mot de passe circule dans l’entreprise, souvent par courriel. Il rend toute traçabilité impossible et survit indéfiniment aux départs.

Le compte fantôme : l’agence qui a créé le site il y a quatre ans conserve un accès administrateur, personne ne s’en souvient, et personne ne l’a jamais retiré. Le premier réflexe en reprenant un site est d’ouvrir la liste des comptes et de demander qui est qui.

2.3 L’authentification à deux facteurs

Un mot de passe volé ne suffit plus si un second élément est exigé à la connexion. C’est la mesure au meilleur rapport entre effort et effet sur toute la liste, et elle prend dix minutes à activer.

Elle se justifie d’abord sur les comptes administrateurs. Sur un site à plusieurs contributeurs, l’étendre à tous ceux qui publient est raisonnable.

2.4 La limitation des tentatives de connexion

Une attaque par force brute essaie des milliers de couples identifiant et mot de passe. Limiter le nombre d’essais par adresse la rend inopérante et allège au passage la charge du serveur, ce qui est un bénéfice secondaire non négligeable.

2.5 Les sauvegardes, traitées en section 3

C’est la mesure qui ne protège de rien et qui sauve tout. Elle a sa section.

2.6 La surveillance

Savoir qu’il s’est passé quelque chose, et quand. Un journal des connexions et des modifications de fichiers, une alerte en cas de changement inattendu.

Sans surveillance, une compromission est découverte par un tiers : un client qui signale une page étrange, un moteur de recherche qui affiche un avertissement, un hébergeur qui suspend le compte. Découvrir l’incident par son propre système et non par son client change entièrement la conversation qui suit.

Atelier 1, l’audit de sécurité

En binôme, sur le site de votre entreprise d’accueil ou sur un site que vous administrez. Si vous n’avez pas d’accès, travaillez sur votre site de première année ou sur celui de votre binôme.

1. Combien d’extensions sont actives ? Combien ont une mise à jour en attente ? Combien n’ont pas été mises à jour par leur éditeur depuis plus d’un an ?
2. Combien de comptes existent, avec quels rôles ? Combien d’administrateurs ? Reconnaissez-vous chaque nom ?
3. L’authentification à deux facteurs est-elle active sur les comptes administrateurs ?
4. Une sauvegarde existe-t-elle ? Où est-elle stockée ? Quand a-t-elle été restaurée pour la dernière fois ?
5. Qui, nommément, est responsable des mises à jour de ce site ?

Livrable : trois risques classés par gravité, formulés en une phrase chacune, avec l’action correspondante et son coût estimé en temps. Pas de liste exhaustive : trois, les plus graves.

3. La sauvegarde et le seul test qui compte

3.1 Ce qu’une sauvegarde doit contenir

Un site WordPress vit dans deux endroits. Les fichiers, qui contiennent le cœur, les extensions, les thèmes et la médiathèque. La base de données, qui contient tous vos contenus, vos réglages, vos comptes et vos commandes.

Une sauvegarde des seuls fichiers ne restaure rien d’utile : votre site reviendrait avec ses extensions et sans un seul de vos contenus. Une sauvegarde de la seule base ne restaure pas davantage : vos textes reviendraient sans aucune de vos images.

C’est l’erreur la plus fréquente et elle ne se découvre qu’au moment de restaurer.

3.2 La règle des trois exemplaires

Une règle de sauvegarde largement pratiquée tient en trois chiffres : trois copies des données, sur deux supports différents, dont une hors du site.

Le dernier point est celui qui compte le plus et celui qui manque le plus souvent. Une sauvegarde stockée sur le serveur qu’elle protège disparaît avec lui : elle ne couvre qu’une seule situation, la fausse manipulation. Elle ne couvre ni la compromission du serveur, ni la défaillance de l’hébergeur, ni le litige commercial qui vous coupe l’accès.

3.3 Le seul test qui compte

Une sauvegarde qui n’a jamais été restaurée n’est pas une sauvegarde : c’est une hypothèse.

Les sauvegardes qui échouent silencieusement sont un cas ordinaire : quota de stockage atteint, tâche planifiée arrêtée depuis six mois, archive incomplète parce que la base était trop volumineuse. Rien n’alerte, le fichier existe, il porte la bonne date, et il est inutilisable.

La restauration se teste sur un environnement séparé, jamais en écrasant la production. C’est un exercice d’une heure, à faire deux fois par an, et il répond à la seule question qui comptera le jour venu : combien de temps faut-il pour remettre le site en ligne ?

3.4 Les deux chiffres à donner à un dirigeant

Deux questions, en français simple, qui remplacent avantageusement tout vocabulaire technique.

Combien de données acceptons-nous de perdre ? Si la sauvegarde est quotidienne, la réponse est « jusqu’à une journée de contenus et de commandes ». Cette réponse est acceptable pour un site vitrine et intenable pour un site marchand.

Combien de temps acceptons-nous de rester hors ligne ? La réponse dépend de la sauvegarde, mais aussi de qui sait restaurer, et de sa disponibilité un dimanche.

Ces deux chiffres se décident avec la direction, pas avec le prestataire technique. Ils déterminent ensuite le dispositif et son budget, et non l’inverse.

3.5 Ce que la loi impose si des données personnelles sont concernées

Un site compromis contenant des données personnelles, ne serait-ce que les adresses électroniques d’un formulaire de contact ou d’une lettre d’information, relève d’une obligation légale.

Le responsable de traitement doit notifier la violation à l’autorité de contrôle, la CNIL en France, dans les meilleurs délais et au plus tard 72 heures après en avoir pris connaissance, dès lors que la violation présente un risque pour les droits et libertés des personnes. Un retard doit être motivé².

Si le risque est élevé, les personnes concernées doivent en outre être informées individuellement.

Trois actions, donc, et il ne faut pas les confondre. Documenter : toute violation, sans exception, se consigne en interne. Notifier la CNIL : seulement si la violation présente un risque pour les personnes. Informer les personnes : seulement si ce risque est élevé. Une extension compromise sur un site vitrine qui ne collecte rien se documente, et ne se notifie pas.

Deux conséquences pratiques pour vous.

La première est un délai : 72 heures se comptent à partir de la prise de connaissance, y compris un week-end. Découvrir un incident le samedi et attendre le lundi pour en parler consomme les deux tiers du délai.

La seconde est une exigence documentaire : vous devez pouvoir décrire ce qui s’est passé, quelles données étaient concernées et quelles mesures ont été prises. C’est impossible sans journalisation, ce qui fait de la surveillance de la section 2.6 une obligation de fait, et pas seulement une bonne pratique.

Le piège. La responsabilité de la notification à l’autorité pèse sur le responsable de traitement, c’est-à-dire sur l’entreprise, jamais sur son prestataire technique. Le sous-traitant, lui, a une obligation distincte et tout aussi légale : alerter le responsable sans délai indu après avoir eu connaissance de la violation, article 33.2. Ce n’est donc pas une simple clause de contrat. Un contrat d’infogérance organise le détail de cette alerte et l’assistance qui suit ; il ne transfère pas l’obligation de notifier. C’est un point à vérifier dans les contrats que vous signerez.

Atelier 2, le plan de reprise en une page

Individuellement. Rédigez le document que quelqu’un ouvrirait un dimanche matin en découvrant que le site de votre entreprise affiche une page qui n’est pas la vôtre.

Attendu, une page maximum, sans jargon :

1. Les trois premières actions, dans l’ordre, et pourquoi cet ordre.
2. Qui est prévenu, dans quel ordre, et par quel moyen si le site sert habituellement à communiquer.
3. Où se trouve la sauvegarde, et qui sait la restaurer. Nommez une fonction, pas une personne.
4. Le point de décision RGPD : quelles données pourraient être concernées, et qui décide de la notification.
5. Ce qu’on ne fait surtout pas dans la première heure.

Synthèse

L’attaque n’est pas ciblée. Elle est automatisée, et être petit ne protège pas. Un serveur compromis a une valeur indépendante de votre activité.

Neuf vulnérabilités sur dix viennent des extensions. Chaque extension installée est une décision d’achat et une surface d’exposition supplémentaire. Payer ne protège pas : les composants commerciaux sont proportionnellement plus exploités. Une extension abandonnée par son éditeur se désinstalle.

Six mesures. Mises à jour avec un responsable désigné, rôles au moindre privilège, double authentification, limitation des tentatives, sauvegardes, surveillance. Les trois premières ne coûtent presque rien.

Une sauvegarde non testée est une hypothèse. Fichiers et base, trois copies dont une hors du serveur, restauration testée deux fois par an sur un environnement séparé.

72 heures. Le délai de notification à la CNIL en cas de violation de données présentant un risque, à compter de la prise de connaissance. L’obligation pèse sur l’entreprise, pas sur son prestataire.

Pour la séance suivante

La séance suivante est consacrée à l’audit et à la production d’un rapport. Venez avec les résultats de l’atelier 1 : nous en ferons un document présentable à une direction.

Si vous avez accès à un site réel, relevez d’ici là deux éléments supplémentaires : la version de PHP utilisée par l’hébergement, et l’existence ou non d’un certificat de sécurité valide sur toutes les adresses du site.

Sources

Notes

• Rapport annuel sur l’état de la sécurité de l’écosystème WordPress, Patchstack, édition 2026 portant sur l’année 2025 : 11 334 vulnérabilités nouvelles, en hausse de 42 % sur 2024, dont 91 % dans les extensions, 9 % dans les thèmes et 6 dans le cœur, jugées de faible priorité. 36 % appellent une protection, 17 % sont de gravité élevée. Les composants payants ou freemium pèsent 29 % des signalements, dont 76 % se sont révélés exploitables. Source : patchstack.com/whitepaper/state-of-wordpress-security-in-2026/. Vérifié le 11 août 2026. Une édition paraît chaque année : relever les valeurs de l’édition courante avant la séance. Revenir au texte
• Règlement général sur la protection des données, article 33 pour la notification à l’autorité de contrôle dans les 72 heures, article 34 pour l’information des personnes concernées en cas de risque élevé. Source : cnil.fr/fr/notifier-une-violation-de-donnees-personnelles. Vérifié le 11 août 2026. Revenir au texte