La sécurité sur WordPress n’est pas une case à cocher. C’est un système en couches qui doit résister aux bots, aux attaquants opportunistes et aux tentatives ciblées occasionnelles — et le coût d’une erreur a augmenté. Un site d’entreprise compromis en 2026, c’est une exposition au RGPD, une perte de confiance, des semaines de nettoyage forensique et des dommages SEO qui peuvent prendre des mois à effacer.
Voici la liste de contrôle que j’applique lors de chaque audit que j’effectue. Pas une liste générique du type « installez Wordfence et basta » — mais les contrôles en couches qui comptent vraiment sur les sites WordPress et WooCommerce critiques.
1. Couche serveur et hébergement
Le durcissement WordPress le plus solide ne sert à rien si le serveur sous-jacent est partagé avec des centaines d’autres sites et que l’hébergeur ne les isole pas correctement. Commencez par là.
Version PHP et isolation
Utilisez une version PHP supportée (8.2 ou 8.3 en 2026). Chaque version de retard signifie des correctifs de sécurité manqués et des performances dégradées. Si votre hébergeur sert encore PHP 7.4 en 2026, vous payez pour de la négligence.
Pour les sites d’entreprise, insistez sur des pools PHP-FPM isolés par site, et non un pool partagé. Cela empêche un voisin compromis de pivoter vers votre code ou votre connexion à la base de données.
Pare-feu applicatif web
Un WAF placé devant WordPress filtre le bruit — abus XML-RPC, tentatives de force brute, signatures d’exploits courants — avant que les requêtes n’atteignent PHP. Le WAF gratuit de Cloudflare associé à la limitation de débit gère 90 % du volume ; pour les sites à risque élevé, le plan Pro ajoute la gestion des bots et des règles gérées adaptées à WordPress.
Les pare-feux basés sur des extensions (Wordfence, Solid Security) s’exécutent dans PHP, ce qui signifie qu’ils n’agissent qu’après le chargement de PHP. Ils ont leur place — règles au niveau applicatif, surveillance des connexions — mais ils ne remplacent pas un WAF en périphérie.
HTTPS et en-têtes
TLS 1.2 minimum, idéalement 1.3. En-tête HSTS avec un max-age d’au moins 1 an une fois que vous êtes sûr que le certificat est stable. Les autres en-têtes qui doivent figurer dans chaque réponse d’un site WordPress sérieux :
X-Content-Type-Options: nosniffX-Frame-Options: SAMEORIGIN(ou un CSPframe-ancestorsapproprié)Referrer-Policy: strict-origin-when-cross-originPermissions-Policylimité aux API réellement utilisées par le siteContent-Security-Policy— le plus difficile à paramétrer correctement, mais avec le plus fort impact
2. Cœur WordPress
Le cœur est la partie facile — mais c’est aussi là que commencent la plupart des histoires de « nous avons été piratés ». Presque toujours à cause de mises à jour retardées ou d’une constante mal configurée.
Mises à jour automatiques pour les versions mineures et de sécurité
Dans wp-config.php, définissez define( 'WP_AUTO_UPDATE_CORE', 'minor' );. Cela applique automatiquement les correctifs de sécurité sans risquer les changements cassants d’une version majeure. Les mises à niveau vers une version majeure restent manuelles et testées en environnement de staging.
Désactiver l’édition de fichiers depuis l’administration
Cette seule ligne dans wp-config.php bloque le pivot post-compromission le plus courant — l’upload de code malveillant via Apparence → Éditeur de fichiers du thème :
define( 'DISALLOW_FILE_EDIT', true );Associez-la à DISALLOW_FILE_MODS si vous n’avez pas besoin d’installer des plugins ou des thèmes via l’administration — les modifications de code passent de toute façon par Git.
Clés de sécurité et préfixe de base de données
Renouvelez les huit clés d’authentification et salts dans wp-config.php au moins une fois par an et immédiatement après toute compromission suspectée. Utilisez le générateur officiel de WordPress.org. Un préfixe de base de données personnalisé (autre que wp_) constitue un obstacle mineur aux tentatives d’injection SQL automatisées — définissez-le lors de l’installation ; le modifier sur un site en production présente plus de risques que d’avantages.
3. Extensions et thèmes
C’est là que réside la véritable surface d’attaque. Chaque extension est du code s’exécutant avec un accès complet au système de fichiers et à la base de données. Une extension négligée d’un éditeur disparu il y a deux ans est une faille en attente d’être exploitée.
Auditer et élaguer
Une fois par trimestre : listez toutes les extensions installées et posez trois questions pour chacune d’elles.
- Est-elle encore utilisée ? (Examinez l’utilisation réelle des fonctionnalités, pas « elle pourrait être utile un jour ».)
- A-t-elle été mise à jour par l’éditeur au cours des 12 derniers mois ?
- Dispose-t-elle d’une politique de divulgation des failles de sécurité publiée ?
Si la réponse à l’une de ces questions est non, l’extension est remplacée ou supprimée. La prolifération d’extensions est le principal facteur prédictif de compromission d’un site WordPress — plus que la version du cœur, plus que l’hébergement.
Éviter les extensions nulled / piratées
Je ne devrais pas avoir à le préciser en 2026, mais j’en trouve encore lors des audits. Les extensions premium nulled sont presque toujours accompagnées de portes dérobées. Les 99 € que vous « économisez » sur une année de WPML ou une extension WooCommerce premium se transforment en facture de réponse à incident à cinq chiffres.
Restreindre XML-RPC et l’API REST
XML-RPC est une interface héritée encore activée par défaut. Sauf si vous utilisez Jetpack ou un client de publication distant, désactivez-la entièrement au niveau du serveur (un simple bloc nginx location ou une règle .htaccess).
L’API REST est plus utile, mais son exposition par défaut de /wp-json/wp/v2/users divulgue les noms d’utilisateurs aux requêtes anonymes. Restreignez ce point de terminaison aux requêtes authentifiées à l’aide d’un petit filtre rest_authentication_errors.
4. Connexion et accès
La plupart des intrusions commencent au niveau du formulaire de connexion. Le renforcer n’est pas optionnel.
Authentification à deux facteurs pour chaque compte administrateur
La 2FA basée sur TOTP (via Wordfence Login Security, Two Factor, ou un fournisseur SSO) sur chaque compte disposant du rôle administrator ou editor. Sans exception, y compris le vôtre. Si vous externalisez le développement, votre prestataire dispose de son propre compte avec 2FA, et non d’un identifiant administrateur partagé.
Renommer ou limiter le débit de /wp-login.php
La sécurité par l’obscurité est faible, mais combinée à une limitation du débit, elle réduit significativement le trafic de bots. Déplacez soit wp-login.php vers un chemin personnalisé (WPS Hide Login le fait proprement), soit appliquez une limite de débit stricte au niveau du WAF — 5 tentatives par 15 minutes par adresse IP est raisonnable.
Politique de mots de passe forts appliquée
L’indicateur de robustesse intégré de WordPress est indicatif, pas contraignant. Utilisez une extension (Password Policy Manager, ou intégrée à votre suite de sécurité) qui bloque les mots de passe faibles. 12 caractères minimum, devant inclure les quatre classes de caractères, rejetés s’ils figurent dans une liste de mots de passe connus comme compromis.
5. Système de fichiers et permissions
Une installation WordPress correctement paramétrée en termes de permissions limite l’impact de toute compromission.
- Répertoires :
755 - Fichiers :
644 wp-config.php:600(lisible uniquement par l’utilisateur sous lequel s’exécute le serveur web)- Propriétaire : l’utilisateur de déploiement, et non l’utilisateur du serveur web
- Utilisateur du serveur web : lecture seule sur tout ce qui se trouve en dehors de
wp-content/uploads/et des quelques caches nécessitant un accès en écriture
Désactivez l’exécution PHP dans wp-content/uploads/ au niveau du serveur. Il s’agit du contrôle défensif le plus efficace contre le schéma d’attaque consistant à « uploader un fichier .php déguisé en .jpg ».
6. Base de données
La base de données est rarement le point d’entrée, mais c’est presque toujours là que les dommages sont causés — exfiltration de données, injection d’utilisateur administrateur, contenu de publication malveillant.
- Utilisateur DB dédié par site avec les privilèges minimum requis (pas de
GRANT, pas deDROP DATABASE) - Base de données et serveur web sur un réseau privé ; aucun port de base de données exposé publiquement
- Sauvegardes chiffrées stockées hors serveur, conservées pendant au moins 30 jours
- Restauration testée au moins deux fois par an — une sauvegarde que vous n’avez jamais restaurée est un espoir, pas une sauvegarde
7. Surveillance et réponse aux incidents
Vous serez compromis tôt ou tard. La différence entre un incident de 24 heures et un désastre de 6 semaines, c’est de savoir si vous l’apprenez par votre système de surveillance ou par un client.
Surveillance de l’intégrité des fichiers
Une analyse quotidienne qui compare le système de fichiers actuel à une référence saine connue. Tout fichier noyau modifié, tout nouveau fichier PHP dans wp-content/uploads/, toute modification de .htaccess génère une alerte. Wordfence le fait, tout comme des outils professionnels tels qu’OSSEC.
Surveillance de la disponibilité et du comportement
Les vérifications de disponibilité simples (UptimeRobot, BetterUptime) détectent les problèmes évidents. Plus utile encore : la détection des anomalies de temps de réponse — un site qui ralentit soudainement de 3× héberge souvent un cryptomineur dans wp-content/uploads/.
Plan de réponse documenté
Rédigé avant d’en avoir besoin : qui contacte qui, ce qui est mis hors ligne, où se trouve la dernière sauvegarde saine, à quoi ressemble la procédure de notification RGPD en cas d’exposition de données personnelles. Un document d’une page vaut mieux qu’un plan parfaitement architecturé que vous ne lirez jamais en situation de panique.
Ce que cela donne en pratique
La liste de contrôle complète compte plus de 30 mesures. La plupart des sites que j’audite en appliquent 5 à 10 — les moins coûteuses, ainsi que celles dont le développeur d’origine se souvenait. Les 20 restantes constituent le véritable gisement de réduction des risques.
La bonne nouvelle : vous n’avez pas besoin d’un projet sécurité de six mois pour atteindre un état défendable. La première moitié de cette liste — durcissement du serveur, constantes noyau, audit des extensions, authentification à deux facteurs, permissions de fichiers — se traite en deux ou trois journées de travail concentré. Le reste s’inscrit dans un rythme trimestriel.
Si vous préférez ne pas vous charger de tout cela vous-même, c’est précisément ce que couvre l’Audit d’ingénierie WordPress — la même revue de sécurité livrée sous forme de plan de remédiation priorisé.
