WordPress fait tourner une part considérable du web, ce qui en fait une cible industrielle. Les attaques ne visent pas votre entreprise en particulier : des robots parcourent les adresses, testent des versions connues d'extensions et exploitent ce qui répond. Sécuriser un site WordPress, c'est donc d'abord réduire la surface qui répond.
Par où passent réellement les attaques
Le coeur de WordPress est plutôt bien tenu et corrigé rapidement. Les compromissions viennent presque toujours d'ailleurs.
Les extensions et thèmes arrivent largement en tête. Une extension abandonnée par son auteur ne recevra jamais de correctif, et sa faille reste exploitable indéfiniment. Viennent ensuite les identifiants faibles ou réutilisés, puis les accès techniques : un compte FTP resté actif, une base de données ouverte sur l'extérieur, un fichier de sauvegarde laissé à la racine et accessible en téléchargement.
Enfin, l'hébergement mutualisé mal cloisonné : un site voisin compromis sur le même compte peut contaminer le vôtre par les fichiers partagés.
La liste de contrôle en douze points
- Inventorier les extensions et supprimer, pas seulement désactiver, celles qui ne servent plus.
- Vérifier la date de dernière mise à jour de chaque extension restante ; au-delà d'un an sans publication, chercher un remplacement.
- Supprimer les thèmes inutilisés, y compris les thèmes par défaut superflus.
- Bloquer l'édition de fichiers depuis l'administration.
- Interdire l'exécution de code dans le répertoire des médias.
- Masquer ou renommer la page de connexion et limiter les tentatives.
- Imposer un second facteur sur tous les comptes administrateurs.
- Vérifier que le site force le chiffrement sur toutes les pages, pas uniquement le formulaire de contact.
- Déplacer les sauvegardes hors de la racine web.
- Tenir la version de PHP à une branche encore maintenue.
- Activer une journalisation des actions d'administration.
- Tester une restauration complète au moins une fois par an.
Le point 12 est celui qu'on saute. Une sauvegarde jamais restaurée n'est pas une sauvegarde, c'est un fichier dont on espère qu'il fonctionne.
Comptes et accès : le maillon le plus négligé
Ouvrez la liste des utilisateurs de votre site. Vous y trouverez souvent un ancien prestataire, un stagiaire parti l'été dernier et un compte nommé « admin » créé à l'installation.
Appliquez trois principes. Un compte par personne, jamais de compte partagé entre l'agence et l'entreprise. Le rôle minimal : un rédacteur n'a pas besoin des droits d'administration, un responsable marketing non plus. Et une revue trimestrielle, inscrite au calendrier, pour désactiver ce qui ne sert plus.
Côté technique, les accès SFTP et base de données méritent le même traitement. Un mot de passe de base de données inchangé depuis la création du site, présent dans le fichier de configuration lisible par toute extension, est un risque permanent.
| Accès | Fréquence de revue | Action par défaut si inactif |
|---|---|---|
| Comptes d'administration | trimestrielle | suppression |
| Comptes éditeurs et auteurs | semestrielle | rétrogradation |
| Accès SFTP et SSH | trimestrielle | révocation de la clé |
| Clés d'API et jetons | semestrielle | rotation |
Mises à jour : trouver un rythme tenable
Deux mauvaises stratégies s'opposent. La mise à jour automatique de tout, qui casse un site de production un vendredi soir. Et l'immobilisme total, justifié par la peur de casser, qui accumule les failles.
Le compromis raisonnable : mises à jour de sécurité du coeur appliquées automatiquement, extensions mises à jour manuellement toutes les deux à quatre semaines sur un environnement de préproduction, avec une sauvegarde immédiatement avant et une vérification des pages critiques après. Pour une boutique, cette vérification inclut obligatoirement le tunnel de commande complet, du panier au paiement.
Gardez une trace écrite : date, extensions mises à jour, anomalies constatées. Ce journal vaut de l'or le jour où un comportement bizarre apparaît trois semaines plus tard. C'est précisément l'objet de notre prestation de maintenance de site, qui industrialise ce cycle à distance.
Filtrage, détection et surveillance
Un pare-feu applicatif web filtre en amont les requêtes malveillantes : injections, tentatives d'exploitation de failles connues, balayages automatisés. Il ne remplace pas les correctifs, mais il achète du temps entre la publication d'une faille et son application, période où la majorité des sites se font toucher. Voyez à ce sujet nos prestations de pare-feu applicatif web.
En parallèle, surveillez quelques signaux simples : apparition de fichiers PHP dans le répertoire des téléversements, modification d'un fichier du coeur, création d'un compte administrateur hors procédure, pic de trafic sortant, apparition de pages inconnues dans les résultats de recherche.
Un site marchand mérite en plus une surveillance de performance, car une compromission se manifeste souvent par un ralentissement avant de se manifester par une page défigurée. La préparation d'une boutique aux pics de trafic, abordée dans notre article sur les tests de charge avant Black Friday, donne aussi la référence de comportement normal qui permet de repérer l'anomalie.
Si le site est déjà compromis
Ne commencez pas par nettoyer. Commencez par constater : copiez l'intégralité des fichiers et de la base dans un endroit sûr, notez l'heure, relevez les journaux du serveur. Cette copie sert à comprendre le point d'entrée et, le cas échéant, à documenter l'incident.
Ensuite seulement : mettre le site en maintenance, changer tous les mots de passe et clés, restaurer depuis une sauvegarde antérieure à l'intrusion, appliquer les correctifs, puis remettre en ligne. Restaurer sans corriger la faille d'origine garantit une seconde compromission dans la semaine.
Si des données personnelles ont pu être consultées, la question de la notification à la CNIL se pose dans les 72 heures. Et si le site est inutilisable, notre prestation de récupération de site après incident prend le relais, entièrement à distance.
Rédaction Apply
Sécurité des applications web