⚙️ All In One WP Security : configuration de la sécurité WordPress étape par étape en 16 étapes
Chaque jour, un site WordPress moyen reçoit entre 200 et 500 requêtes illégitimes sur wp-login.php. Il ne s’agit pas de pirates à capuche, mais de scripts. Ils parcourent Internet, trouvent la page de connexion standard et lancent une attaque par force brute: admin/123456, admin/qwerty, admin/mot_de_passe_issu_d_une_base_de_donnees_fuitee. Tôt ou tard, ils percent.
L’hébergement ne protège pas contre cela. Le pare-feu du serveur voit une requête POST légitime vers wp-login.php et la laisse passer, il ne peut pas distinguer si c’est vous qui saisissez un mot de passe ou un robot. La protection WordPress et la protection serveur sont deux couches différentes, et vous êtes responsable de la première.
All-In-One Security (AIOS) de l’équipe UpdraftPlus couvre entièrement cette couche. Un seul plugin au lieu d’un ensemble: pare-feu, protection de la connexion, audit des fichiers, blocage des robots et sauvegardes. Un million d’installations, note de 4,7 sur WordPress.org. La version gratuite suffit pour protéger un site standard. Voici une configuration étape par étape, des bases jusqu’à l’export de la configuration.
💡 Aperçu rapide:
- Nous allons masquer la page de connexion derrière une URL personnalisée et activer l’authentification à deux facteurs. Les attaques par force brute échoueront immédiatement.
- Nous allons configurer trois couches de pare-feu: règles htaccess, règles PHP et liste noire 6G. Un filtrage des requêtes par couches superposées.
- Nous allons bloquer l’accès aux fichiers de service, désactiver l’éditeur PHP depuis le panneau d’administration et vérifier les permissions des dossiers.
- Nous allons activer la détection par pot de miel et par erreur 404. Les robots seront filtrés avant d’atterrir, sans captcha pour les utilisateurs.
- Nous allons sauvegarder la configuration prête dans un fichier pour la transférer entre sites en une minute.
Étape 1. Supprimer les métadonnées du générateur WP
La première chose qui divulgue votre version de WordPress est la balise <meta name="generator" content="WordPress X.X.X"> dans le <head> de chaque page. Un attaquant obtient le numéro de version exact et sélectionne des exploits pour celle-ci en quelques secondes. AIOS supprime cette balise d’un simple clic.
Chemin: WP Security → Settings → General Settings. Activez Remove WP Generator Meta Info et sauvegardez. Vérifiez le code source de votre page d’accueil (Ctrl+U), la ligne avec generator doit disparaître. Dans cette même section, désactivez également Enable Info Comments, AIOS ajoute par défaut des commentaires HTML avec des informations de service, mieux vaut les supprimer aussi.
Étape 2. Bloquer les tentatives de connexion
L’attaque par force brute sur wp-login.php est l’attaque numéro un en termes de fréquence. Les robots essaient des centaines de mots de passe par minute, ce qui génère une charge sur le serveur et la base de données. Tôt ou tard, un mot de passe faible est percé, surtout si un utilisateur admin ou éditeur utilise qwerty123.
Chemin: WP Security → User Login → Login Lockdown. Activez Enable Login Lockdown et définissez: maximum 5 tentatives, blocage IP pendant 60 minutes, réinitialisation du compteur après 24 heures. Pour les sites avec plusieurs administrateurs, activez Notify by Email, la notification de blocage arrive instantanément. Si vous voyez des notifications fréquentes, changez le slug de la page de connexion (étape 14).
Étape 3. Approbation manuelle pour les nouvelles inscriptions
Si l’inscription est ouverte sur votre site, sans ce paramètre, n’importe quel robot créera un compte en quelques secondes. Les comptes indésirables s’accumulent par milliers, encombrant la base de données et créant une surface d’attaque via l’escalade de privilèges.
Chemin: WP Security → User Registration → Manual Approval. Activez Enable Manual Approval. Désormais, chaque nouveau compte attend la confirmation de l’administrateur avant d’être activé. Dans cette même section, configurez un captcha pour les formulaires d’inscription, une barrière supplémentaire que les robots ne peuvent pas franchir.
Étape 4. Modifier le préfixe des tables de la base de données
Le préfixe wp_ est standard pour toutes les installations WordPress. Les injections SQL et les scripts de compromission massive le ciblent spécifiquement: quand un exploit connaît les noms des tables (wp_users, wp_options), l’attaque devient ciblée plutôt qu’aveugle.
Chemin: WP Security → Database → DB Prefix. Vous voyez le préfixe actuel. S’il s’agit de wp_, cliquez sur Change DB Table Prefix. Le plugin proposera une chaîne aléatoire ou vous laissera saisir la vôtre (4 à 6 caractères, uniquement des lettres latines et des tirets bas). Avant de lancer l’opération, faites impérativement une sauvegarde de la base de données (étape 5). Le processus prend 5 à 10 secondes sur un site moyen, mais un retour en arrière sans sauvegarde est impossible.
Étape 5. Sauvegarde de la base de données
Avant toute modification structurelle, changement de préfixe, nettoyage des révisions, mise à jour du cœur, la sauvegarde est obligatoire. AIOS est intégré à UpdraftPlus, la sauvegarde se lance depuis la même interface.
Chemin: WP Security → Database → Database Backup. Cliquez sur Create Database Backup, le fichier est sauvegardé localement. Configurez le téléchargement automatique vers le cloud via UpdraftPlus (Google Drive, Dropbox, S3) et une planification quotidienne. Restaurer un site après une compromission sans sauvegarde est pratiquement impossible, et avec AIOS + UpdraftPlus, cela se fait en un clic.
Étape 6. Vérifier les permissions des répertoires et des fichiers
Des permissions d’accès incorrectes, 777 sur wp-config.php, 666 sur le dossier uploads, un accès en écriture ouvert sur wp-content, ouvrent une voie directe pour l’écriture de code malveillant. Si un attaquant obtient l’accès à un thème via une vulnérabilité, des permissions incorrectes lui permettent de modifier les fichiers système.
Chemin: WP Security → Filesystem Security → File Permissions. Lancez l’analyse. Toutes les lignes doivent être vertes. Ligne rouge ou jaune, cliquez sur Set Recommended Permissions à côté du fichier ou dossier problématique. Après correction, relancez l’analyse, elle doit être propre.
Étape 7. Désactiver l’édition PHP depuis l’administration
L’éditeur intégré de thèmes et d’extensions, wp-admin/theme-editor.php et wp-admin/plugin-editor.php, constitue une voie directe vers l’exécution de code arbitraire. Si un attaquant obtient l’accès à l’administration, cet éditeur permet d’ajouter un shell PHP dans functions.php et de prendre le contrôle du serveur. Un développeur légitime n’a pas besoin de cet éditeur: les modifications se font via FTP/SFTP ou par déploiement.
Chemin: WP Security → Filesystem Security → PHP File Editing. Activez Disable PHP File Editing. Après la sauvegarde, les entrées «Theme Editor» et «Plugin Editor» disparaîtront des menus «Appearance» et «Plugins». Si vous devez effectuer des modifications, passez uniquement par le gestionnaire de fichiers de l’hébergement ou par SSH.
Étape 8. Bloquer l’accès aux fichiers de service WordPress
readme.html, license.txt, wp-config-sample.php et debug.log révèlent la version du CMS, la structure d’installation et les chemins internes. debug.log est particulièrement dangereux: en mode WP_DEBUG, il écrit les chemins absolus du serveur et les traces de pile d’erreurs avec les noms des extensions.
Chemin: WP Security → Filesystem Security → WP Info Files. Cochez les quatre éléments: readme.html, license.txt, wp-config-sample.php, debug.log. Sauvegardez. Désormais, lors d’une requête directe sur yoursite.com/readme.html, le serveur renverra une erreur 403 Forbidden. Il s’agit de règles .htaccess qui agissent au niveau Apache/Nginx avant le démarrage de PHP.
Étape 9. Fonctions de base du pare-feu
Le pare-feu AIOS propose trois niveaux de protection. Les règles .htaccess bloquent les requêtes avant leur transmission à PHP (la couche la plus rapide). Les règles PHP filtrent les vecteurs XSS, désactivent XML-RPC et les flux RSS. La troisième couche écarte les faux robots Google en se basant sur le user-agent.
Chemin: WP Security → Firewall → Basic Firewall. Activez:
- Enable Basic Firewall Protection, activation générale;
- Block Fake Googlebots, les robots avec un faux
user-agentGooglebot sont filtrés; - Disable RSS and Atom Feeds, si le site n’utilise pas les flux RSS, désactivez-les (aspiration de contenu);
- Disable Directory Listing, empêche Apache d’afficher le contenu des dossiers sans
index.php.
Désactivez également ici XML-RPC si vous n’utilisez pas l’application mobile WordPress, Jetpack ou les trackbacks. Pour la plupart des sites de type blog en 2026, XML-RPC n’est pas nécessaire.
Étape 10. Règles de pare-feu supplémentaires
Des règles .htaccess étendues ferment plusieurs autres vecteurs d’attaque: l’accès direct par navigateur à wp-config.php et .htaccess, la limite de taille des fichiers téléversés, la désactivation de la signature serveur.
Chemin: WP Security → Firewall → Additional Firewall. Activez:
- Deny Access to wp-config.php, la configuration clé est inaccessible via HTTP;
- Deny Access to.htaccess, le fichier de règles serveur est protégé en lecture;
- Disable Server Signature, Apache cesse de signaler sa version dans les en-têtes
Server; - Limit File Upload Size, réglez sur 10 Mo (suffisant pour des images, insuffisant pour téléverser une archive contenant un shell).
Les règles sont écrites directement dans .htaccess. Après avoir sauvegardé, ouvrez le site dans une fenêtre de navigation privée et vérifiez que tout fonctionne.
Étape 11. Liste noire du pare-feu 6G
6G Firewall de Perishable Press est un ensemble strict de règles .htaccess qui bloquent les motifs malveillants dans les URL et les chaînes de requête: injections SQL, tentatives d’inclusion de fichier (../../wp-config.php), vecteurs XSS et signatures de scanners de vulnérabilités. Les règles sont statiques, ne nécessitent aucune mise à jour, les schémas d’attaque n’ayant pas changé depuis des années.
Chemin: WP Security → Firewall → 6G Blacklist. Activez Enable 6G Firewall Protection et sauvegardez. Si après activation un plugin légitime cesse de fonctionner (rare, mais cela arrive avec des plugins ayant des motifs d’URL non standard), ajoutez-le à la liste blanche: Firewall → Whitelist.
Étape 12. Empêcher le hotlinking des images
Le hotlinking se produit lorsqu’un autre site intègre votre image via une URL directe (<img src="https://yoursite.com/uploads/photo.jpg">). Votre serveur fournit consciencieusement l’image, consommant bande passante et ressources CPU, tandis que le visiteur voit le contenu sur le site de quelqu’un d’autre. Pour les sites proposant des captures d’écran et des photos originales, cela se remarque.
Chemin: WP Security → Firewall → Prevent Hotlinks. Activez Prevent Hotlinking. Ajoutez des domaines d’exception (google.com, facebook.com, twitter.com) pour que les aperçus sur les réseaux sociaux et les moteurs de recherche continuent de fonctionner. AIOS écrit des règles dans .htaccess, interdisant les requêtes directes d’images avec un en-tête Referer provenant d’un autre domaine.
Étape 13. Détection des erreurs 404
Les erreurs 404 en masse sont le signe d’un scan de vulnérabilités. Un robot essaie /wp-admin/, /admin/, /backup.zip, /phpmyadmin/ et des centaines d’autres chemins typiques, pour évaluer la surface d’attaque. AIOS suit ces requêtes, les associe à des adresses IP et bloque la source.
Chemin: WP Security → Scanner → 404 Detection. Activez Enable 404 Detection. Seuil: 20 erreurs en 15 minutes → bannissement temporaire de 30 minutes; 50 erreurs en 15 minutes → bannissement permanent. L’onglet Logged 404 Events affichera une liste en direct des requêtes suspectes, utile pour comprendre ce qui est précisément scanné sur votre site.
Étape 14. Modifier l’adresse de la page de connexion
/wp-admin et /wp-login.php sont des points d’entrée standard, connus de tous les robots. Sans cette étape, la protection anti-force brute (étape 2) fonctionne, mais les attaques arrivent encore par milliers, les robots frappent à une porte connue. Renommer la page de connexion supprime la cible elle-même.
Chemin: WP Security → Brute Force → Rename Login Page. Saisissez un slug personnalisé: au moins 4 caractères, ni admin, ni login, ni wp-*. Une bonne option: manage- suivi de 6 lettres aléatoires, par exemple manage-xk7qpd. Après avoir sauvegardé, vérifiez immédiatement la nouvelle URL et mettez-la en favori. Le wp-login.php standard sera désactivé; si vous oubliez le slug, vous devrez le restaurer via FTP (en supprimant ou en renommant le plugin).
Étape 15. Piège honeypot pour les robots
Le honeypot est un champ caché dans le formulaire de connexion. Un humain ne le voit pas (règle CSS display:none ou positionnement hors écran), mais un robot le trouve en analysant le balisage HTML et le remplit. AIOS détecte le champ caché rempli et bloque la tentative comme non humaine. Pas de captcha, l’utilisateur n’a même pas connaissance de ce contrôle.
Chemin: WP Security → Brute Force → Honeypot. Activez Enable Honeypot Protection. Le champ est ajouté automatiquement au formulaire wp-login.php et fonctionne silencieusement en arrière-plan. Selon Team Updraft, le honeypot filtre l’écrasante majorité des robots automatisés: ils n’ont pas besoin spécifiquement de votre panneau d’administration, ils cherchent simplement le formulaire standard et remplissent tous les champs dans l’ordre.
Étape 16. Empêcher l’intégration du site dans des frames
Le clickjacking est une attaque où votre site se charge dans une <iframe> transparente superposée au site de l’attaquant. L’utilisateur pense cliquer sur l’interface, mais interagit en réalité avec le formulaire d’un autre site. L’en-tête X-Frame-Options: SAMEORIGIN empêche cette intégration.
Chemin: WP Security → Firewall → Prevent Framing. Activez Prevent Your Site From Being Displayed in a Frame. AIOS ajoute l’en-tête HTTP X-Frame-Options: SAMEORIGIN à toutes les réponses du serveur. Vérification: curl -I https://yoursite.com, l’en-tête doit apparaître dans la réponse. Pour les sites comportant un formulaire de connexion, un panier ou un panneau d’administration, cette étape est critique.
Exporter une configuration prête à l’emploi pour d’autres sites
Si vous gérez plusieurs sites, l’import-export fait gagner des heures. AIOS sauvegarde l’intégralité de la configuration dans un fichier texte qui se charge sur un autre site en un clic.
Chemin: WP Security → Settings → Import/Export. Cliquez sur Export Settings, vous obtenez un fichier .txt avec toutes les options activées et leurs valeurs. Le fichier peut être modifié avant import sur un autre site: remplacez l’email pour les notifications de sécurité et le slug de la page de connexion par ceux correspondant au site cible.
Import: WP Security → Settings → Import/Export → Import Settings → sélectionnez le fichier. Les 16 étapes s’appliqueront automatiquement en quelques secondes, sans avoir à parcourir chaque écran de nouveau.
⁉️🤔 Questions fréquentes
AIOS est-il nécessaire si mon hébergement promet une «protection complète»?
L’hébergement protège le serveur: niveau système d’exploitation, pare-feu réseau, filtrage anti-DDoS. AIOS protège l’application WordPress: force brute sur le panneau d’administration, injections via les extensions, vulnérabilités des thèmes obsolètes. Le pare-feu du serveur ne voit pas qu’un robot teste des mots de passe sur
wp-login.php, il voit des requêtes POST légitimes. Les couches ne se chevauchent pas, vous avez besoin des deux. Un site sur un hébergement «protégé» sans extension de sécurité reste vulnérable au niveau du CMS.
AIOS entre-t-il en conflit avec Cloudflare ou un autre WAF?
Non, ils travaillent à des niveaux différents. Cloudflare intervient au niveau de la couche 7 (proxy HTTP), il filtre le trafic avant qu’il n’atteigne le serveur. AIOS agit au niveau applicatif (PHP,
.htaccess), une fois la requête arrivée dans WordPress. La seule subtilité: si vous utilisez Cloudflare, activez l’option Activer la détection d’IP dans AIOS, afin que l’extension voie l’IP réelle du visiteur depuis l’en-têteX-Forwarded-For, et non l’IP du proxy.
Puis-je supprimer AIOS après la configuration, les règles restent de toute façon dans le.htaccess?
Non. Les règles
.htaccessresteront physiquement dans le fichier, mais sans surveillance ni mises à jour, elles deviendront obsolètes. Pire: le pot de miel, le renommage de la page de connexion, le blocage de l’éditeur PHP et l’authentification à deux facteurs ne fonctionnent que si l’extension est active, il s’agit de logique PHP, pas de règles statiques. Supprimez l’extension, vous rouvrez lewp-login.phpstandard et désactivez toute la protection de la connexion.
Le site risque-t-il de casser si j’active les 16 étapes d’un coup?
Sur la très grande majorité des sites, non. Mais la recommandation pour la production: activez par blocs de trois à quatre étapes, en vérifiant le fonctionnement du site après chaque bloc. Soyez particulièrement prudent avec le pare-feu 6G (étape 11) et le changement du préfixe de table (étape 4, la sauvegarde est obligatoire). Au fil des années et sur un million d’installations, aucun conflit critique avec des thèmes et extensions populaires n’a été enregistré.
Qu’apporte la version premium d’AIOS par rapport à la version gratuite?
Trois ajouts clés: l’authentification à deux facteurs avec des politiques flexibles (A2F obligatoire pour les administrateurs après N jours, configuration de la fréquence de redemande), un scanner de malwares avec alertes Google blacklist, et un bloqueur de pays (interdiction d’accès par géolocalisation IP). La version gratuite suffit pour protéger un blog ou un site vitrine. Une boutique en ligne avec des données clients confidentielles devrait opter pour la version Premium.
Que faire si j’oublie l’URL personnalisée de la page de connexion?
Connectez-vous au serveur via FTP/SFTP, allez dans
/wp-content/plugins/all-in-one-wp-security-and-firewall/et renommez temporairement le dossier de l’extension. Cela désactivera AIOS et rétablira lewp-login.phpstandard. Connectez-vous au panneau d’administration, redonnez son nom d’origine au dossier, activez l’extension et définissez un nouveau slug. Pour ne pas oublier, enregistrez l’URL dans votre gestionnaire de mots de passe dès sa création.
Vaut-il la peine de configurer AIOS en 2026 ou existe-t-il de meilleures alternatives?
Des années plus tard, AIOS reste l’extension de sécurité gratuite pour WordPress la plus équilibrée: un million d’installations, un développement actif, des mises à jour régulières pour les nouvelles versions du cœur. Des alternatives comme Wordfence ou Solid Security sont également solides, mais plus lourdes.
Les 16 étapes ci-dessus prennent 15 à 20 minutes. Résultat: une page de connexion cachée, trois couches de pare-feu, un pot de miel invisible et une configuration prête à être clonée sur le prochain site.
Le minimum sans lequel la protection ne peut pas être considérée comme constituée:
- Base: étapes 1, 2, 9, 14, masquage de version, protection anti-force brute, pare-feu de base et page de connexion cachée;
- Niveau serveur: étapes 7, 8, 10, 11, interdiction de l’éditeur PHP, blocage des fichiers de service, règles additionnelles et 6G;
- Protection avancée: étapes 4, 6, 12, 15, préfixe de table, permissions d’accès, anti-hotlink, pot de miel;
- Périmètre: étapes 3, 5, 13, 16, modération des inscriptions, sauvegardes, détection 404, protection anti-clickjacking.
Configurez un site, exportez la configuration et importez-la sur les autres en une minute. Une fois par trimestre, vérifiez AIOS → Tableau de bord: le compteur de sécurité indiquera si un paramètre est «tombé» après une mise à jour du cœur.
Une équipe professionnelle de rédacteurs et d'éditeurs spécialisés dans la création de contenu de qualité.