Le Guide Complet WordPress Sécurisé : la checklist ultime 2025 (100 points de contrôle)

1. Serveur et hébergement : bases d’une plateforme saine

Un WordPress sécurisé commence toujours par un serveur sain. Si la couche système ou PHP est vulnérable, aucun plugin ne pourra rattraper toutes les failles.

1.1 – Configuration PHP et modules

• 1. Utiliser une version supportée de PHP (8.1 ou 8.2, selon la compatibilité des extensions).
• 2. Activer OPcache pour améliorer les performances et limiter certaines attaques par déni de service applicatif.
• 3. Désactiver les fonctions dangereuses non utilisées (exec, shell_exec, passthru, system, proc_open…).
• 4. Désactiver expose_php pour ne pas afficher la version de PHP dans les headers.
• 5. Forcer display_errors = Off en production et utiliser un fichier de log dédié.
• 6. Limiter la taille d’upload et le temps d’exécution (upload_max_filesize, post_max_size, max_execution_time) pour éviter certains abus.
• 7. S’assurer que les modules inutiles (par exemple certaines extensions expérimentales) ne sont pas chargés.

1.2 – Sécurité système (Linux / OS)

• 8. Utiliser un utilisateur système dédié par site ou par groupe de sites (modèle multi-tenant).
• 9. Interdire la connexion SSH directe en root, utiliser sudo et des clés SSH.
• 10. Changer le port SSH par défaut et limiter les IP autorisées (firewall).
• 11. Mettre en place un pare-feu (UFW, nftables…) en mode “liste blanche” : seuls les ports nécessaires sont ouverts.
• 12. Installer un système de bannissement comme Fail2ban ou CrowdSec pour bloquer les IP agressives.
• 13. Mettre à jour régulièrement le système (sécurité) et automatiser si possible les mises à jour critiques.
• 14. Désactiver les services et démons inutiles pour réduire la surface d’attaque.
• 15. Surveiller l’espace disque pour éviter les incidents liés à un disque saturé (ce qui peut corrompre des bases ou backups).

1.3 – HTTPS, certificats et couche réseau

• 16. Forcer le HTTPS pour tout le site (redirection permanente HTTP → HTTPS).
• 17. Utiliser des certificats valides (Let’s Encrypt ou certificat payé) et vérifier qu’ils se renouvellent automatiquement.
• 18. Activer HSTS (HTTP Strict Transport Security) une fois le HTTPS stabilisé, pour obliger le navigateur à utiliser le protocole chiffré.
• 19. Configurer des suites de chiffrement modernes et désactiver les protocoles obsolètes (TLS 1.0, 1.1…).
• 20. Si vous êtes derrière Cloudflare, utiliser le mode Full (strict) et non un “Flexible” trompeur.

2. Installation WordPress propre et durcie

Une installation propre réduit fortement les risques d’attaque automatisée et facilite les audits ultérieurs.

2.1 – Paramètres de base

• 21. Choisir un préfixe de table différent de wp_ lors de l’installation.
• 22. Générer des clés de sécurité (salts) robustes dans wp-config.php (via l’API officielle de WordPress).
• 23. Supprimer les fichiers readme.html et license.txt de la racine si vous n’en avez pas besoin en public.
• 24. Configurer l’URL du site en HTTPS dès le départ.
• 25. Désactiver XML-RPC si vous ne l’utilisez pas, ou le filtrer très strictement.

2.2 – Durcissement de wp-config.php

• 26. Placer wp-config.php un niveau au-dessus de la racine web si l’hébergement le permet.
• 27. Définir DISALLOW_FILE_EDIT à true pour désactiver l’éditeur de fichiers dans l’admin.
• 28. Définir DISALLOW_FILE_MODS à true dans les cas où vous gérez les mises à jour via Git/CI (option avancée).
• 29. Forcer l’utilisation de HTTPS dans l’admin avec FORCE_SSL_ADMIN.
• 30. S’assurer que le fichier n’est pas accessible en lecture via le navigateur (test direct + règles serveur).

3. Comptes, rôles et authentification

Les comptes administrateurs sont souvent la première cible des attaques. Une politique de comptes claire réduit le risque d’accès non autorisé.

3.1 – Comptes et rôles

• 31. Ne jamais utiliser “admin” comme identifiant.
• 32. Limiter au maximum le nombre de comptes administrateurs.
• 33. Supprimer ou rétrograder les comptes inutilisés.
• 34. Vérifier régulièrement la liste des utilisateurs et les rôles attribués.
• 35. Utiliser des rôles personnalisés si les rôles par défaut sont trop permissifs.

3.2 – Authentification forte

• 36. Imposer des mots de passe forts (par un plugin ou via l’interface WordPress).
• 37. Activer la double authentification (2FA) au moins pour les administrateurs et éditeurs.
• 38. Limiter les tentatives de connexion (WP Cerber, autre plugin dédié ou Cloudflare).
• 39. Bloquer l’énumération des utilisateurs (accès ?author=1, REST, etc.).
• 40. Sur les sites critiques, filtrer l’accès au back-office par IP ou zone géographique (via Cloudflare ou firewall).

4. Fichiers sensibles, permissions et structure

Une grande partie des attaques tirent parti de fichiers mal protégés (uploads exécutables, logs exposés, backups dans le webroot, etc.).

4.1 – Permissions et structure

• 41. Appliquer des permissions 755 pour les dossiers et 644 pour les fichiers (sauf besoin spécifique).
• 42. Ne jamais utiliser 777, même “juste pour tester un plugin”.
• 43. Vérifier que les uploads sont dans wp-content/uploads et non dans des dossiers exécutables.
• 44. Désactiver l’exécution de PHP dans wp-content/uploads via un fichier .htaccess ou config Nginx.
• 45. Interdire le listing des répertoires (Options -Indexes / autoindex off).

4.2 – Protection des fichiers et endpoints clés

• 46. Protéger wp-config.php côté serveur (blocage direct si quelqu’un tente de l’ouvrir dans un navigateur).
• 47. Bloquer l’accès direct à xmlrpc.php si vous n’en avez pas l’usage.
• 48. Protéger wp-admin par mot de passe HTTP ou filtration IP si possible.
• 49. Empêcher l’accès aux fichiers de log, d’export, de backup ou d’outils (ex. .sql, .zip, .bak).
• 50. Supprimer les fichiers de test ou de démo laissés par certains thèmes ou plugins.

5. Extensions, thèmes et maintenance continue

Les deux principales sources de failles WordPress sont les extensions et les thèmes. La qualité et la maintenance du code sont donc essentielles.

5.1 – Gestion des extensions

• 51. Installer uniquement des extensions depuis des sources reconnues (répertoire officiel, éditeurs fiables).
• 52. Éviter les extensions qui ne sont plus mises à jour depuis longtemps.
• 53. Supprimer (et pas seulement désactiver) les plugins inutilisés.
• 54. Ne jamais utiliser de plugins “nulled” ou piratés.
• 55. Lire les changelogs de mises à jour critiques (sécurité) et planifier leur déploiement.
• 56. Limiter le nombre global d’extensions à ce qui est vraiment nécessaire.
• 57. Éviter d’installer plusieurs plugins qui font presque la même chose.

5.2 – Plugin de sécurité central

Plutôt que d’empiler 3 ou 4 plugins de sécurité, il est préférable d’en choisir un bon, de le configurer correctement et de l’intégrer dans votre routine de suivi.

• 58. Installer un plugin de sécurité complet (par exemple WP Cerber).
• 59. Activer la limitation de tentatives de connexion et les alertes d’IP bloquées.
• 60. Activer l’anti-spam sur les formulaires de base si possible.
• 61. Utiliser les outils de scan pour détecter les fichiers modifiés ou suspects.
• 62. Configurer les notifications par e-mail sur les événements importants (connexion admin, blocage massif, scan terminé, etc.).

5.3 – Thèmes

• 63. Utiliser un thème maintenu, à jour, et documenté.
• 64. Supprimer les thèmes inutilisés (sauf un thème par défaut en secours).
• 65. Créer un thème enfant pour les personnalisations, plutôt que de modifier directement le thème parent.
• 66. Vérifier régulièrement que le thème ne charge pas de scripts distants douteux.
• 67. Tester les mises à jour de thème sur une préproduction si le site est critique.

6. Sauvegardes, restauration et plan de reprise

On ne parle pas de sécurité sans parler de sauvegardes fiables. Un site parfaitement sécurisé n’existe pas ; un bon plan de reprise, si.

6.1 – Stratégie de sauvegarde

• 68. Sauvegarder la base de données au minimum une fois par jour pour un site actif.
• 69. Sauvegarder les fichiers au moins une fois par semaine (plus souvent pour les sites e-commerce ou très actifs).
• 70. Stocker les sauvegardes sur un stockage externe (S3, autre serveur, service dédié).
• 71. Ne pas laisser de fichiers de sauvegarde dans le répertoire accessible au public.
• 72. Chiffrer les sauvegardes contenant des données sensibles.

6.2 – Outils et tests de restauration

• 73. Utiliser un plugin fiable comme WPvivid pour orchestrer les sauvegardes WordPress.
• 74. Compléter les sauvegardes plugin par des sauvegardes serveur (dumps SQL + archives de dossiers).
• 75. Tester régulièrement au moins une restauration sur un environnement de préproduction.
• 76. Documenter la procédure de restauration (qui fait quoi, où cliquer, quelles infos utiles).
• 77. Garder un historique suffisant (rétention) pour pouvoir revenir avant une infection passée inaperçue.

7. Cloudflare, WAF et protection réseau

Cloudflare et les WAF permettent de filtrer une grande partie du trafic malveillant avant même que les requêtes n’atteignent votre serveur. Bien configurés, ils allègent la charge et augmentent la résilience.

• 78. Ajouter votre domaine sur Cloudflare et activer le proxy (nuage orange).
• 79. Utiliser le mode SSL Full (strict) pour un chiffrement de bout en bout.
• 80. Activer le WAF avec le jeu de règles WordPress / CMS.
• 81. Ajouter une règle spécifique pour protéger /wp-login.php (challenge, rate limiting ou filtrage).
• 82. Bloquer ou limiter l’accès à /xmlrpc.php.
• 83. Activer Bot Fight Mode ou un équivalent pour bloquer les bots connus.
• 84. Utiliser des règles de cache adaptées (pas de mise en cache du back-office ni des pages de compte/panier).
• 85. Surveiller régulièrement les logs Cloudflare pour identifier les attaques récurrentes.

8. Monitoring, journaux et réponse à incident

Même bien sécurisé, un site doit être surveillé. Le monitoring et les logs permettent de détecter plus tôt les problèmes et de comprendre ce qui s’est passé en cas d’incident.

8.1 – Monitoring technique

• 86. Mettre en place un monitoring d’uptime externe (ping régulier du site, alerte en cas d’erreur 5xx ou de lenteur).
• 87. Surveiller l’utilisation CPU, RAM et disque du serveur (Netdata, Grafana, outil hébergeur, etc.).
• 88. Activer les logs d’erreurs PHP et HTTP, avec rotation.
• 89. Vérifier régulièrement les logs de l’outil de sécurité (WP Cerber ou équivalent).

8.2 – Réponse à incident

• 90. Prévoir un petit plan de réponse : qui alerter, quelles étapes suivre en cas de suspicion de piratage.
• 91. En cas d’incident, mettre immédiatement le site en maintenance ou bloquer l’accès admin le temps de l’analyse.
• 92. Changer tous les mots de passe critiques (admin, FTP/SSH, base SQL).
• 93. Scanner le site avec un outil de sécurité et comparer les fichiers core à une version saine.
• 94. Une fois corrigé, vérifier Search Console pour s’assurer que Google ne signale plus de problème.
• 95. Documenter l’incident pour éviter qu’il ne se reproduise (origine, vecteur, correctifs appliqués).

Les 5 derniers points complètent la checklist :

• 96. Planifier au minimum un audit de sécurité global tous les 3 à 6 mois.
• 97. Former les personnes qui utilisent le back-office (mots de passe, pièces jointes, liens suspects).
• 98. Mettre en place un suivi de réputation (listes noires, e-mails, domaines).
• 99. Tester régulièrement l’expérience utilisateur après durcissement (ne pas sacrifier l’accès légitime).
• 100. Mettre à jour cette checklist en fonction des nouvelles menaces et des évolutions WordPress.

9. FAQ – Sécurité WordPress 2025

WordPress est-il encore “sécurisable” en 2025 ?

Oui. La majorité des compromissions viennent de sites non mis à jour, d’extensions douteuses ou de mots de passe faibles. En appliquant la majorité des points de cette checklist (mises à jour, plugin de sécurité, HTTPS, durcissement des fichiers, backups), un site WordPress devient beaucoup plus difficile à attaquer que la moyenne.

Quel est le minimum vital si je n’ai pas le temps pour les 100 points ?

Si vous devez aller à l’essentiel : (1) mettre à jour WordPress, thèmes et extensions, (2) forcer le HTTPS, (3) installer un plugin de sécurité (WP Cerber par exemple) avec limitation des tentatives et 2FA, (4) désactiver XML-RPC, (5) mettre en place des sauvegardes externes automatiques. Ce socle couvre déjà une grande partie des risques.

Un plugin de sécurité suffit-il si j’utilise Cloudflare ?

Non, et l’inverse non plus. Cloudflare protège la couche réseau (WAF, DDoS, filtrage IP), tandis que le plugin de sécurité agit au niveau de WordPress (authentification, fichiers, base, activité interne). Les deux se complètent et forment un ensemble cohérent.

Est-ce que WP Cerber est obligatoire pour suivre ce guide ?

Vous pouvez utiliser un autre plugin sérieux, mais WP Cerber couvre beaucoup de fonctionnalités utiles (limitation de login, blocage IP, scan, logs détaillés). L’important est d’en choisir un que vous comprenez et que vous surveillez, plutôt que d’empiler plusieurs outils mal configurés.

Un hébergement mutualisé peut-il être sécurisé ?

Oui, dans certaines limites. Vous avez moins de contrôle sur le serveur, mais vous pouvez tout de même appliquer les bonnes pratiques WordPress : mises à jour, HTTPS, plugin de sécurité, durcissement minimal des fichiers et sauvegardes externes. Pour les sites à fort enjeu ou à fort trafic, un VPS ou un serveur dédié bien géré reste préférable.

Comment savoir si mon site a déjà été piraté ?

Les signes fréquents sont : lenteurs soudaines, redirections étranges, nouveaux comptes administrateurs inconnus, pages ou liens que vous n’avez jamais créés, avertissements dans Google Search Console ou mails de spam envoyés depuis votre domaine. En cas de doute, effectuez un scan complet avec votre plugin de sécurité et analysez les journaux (logs) du serveur et de WordPress.

À quelle fréquence faut-il vérifier la sécurité d’un site ?

Pour un site vitrine classique, un check mensuel + un audit plus poussé deux ou trois fois par an est souvent suffisant. Pour un e-commerce ou un site métier critique, surveillez les logs et les alertes chaque semaine, voire chaque jour, et planifiez des audits plus fréquents.

Puis-je appliquer cette checklist à plusieurs sites WordPress sur un même serveur ?

Oui, mais certaines actions sont à dupliquer par site (comptes, thèmes, extensions) et d’autres se gèrent au niveau serveur (PHP, MySQL/MariaDB, firewall, Cloudflare). Pour un parc multi-sites, il est recommandé d’aller plus loin sur l’isolation (un utilisateur Linux par site, pools PHP-FPM séparés, bases distinctes).

10. Conclusion : comment utiliser cette checklist au quotidien

Cette checklist de 100 points n’est pas un examen à réussir une fois pour toutes, mais une feuille de route vivante. Elle vous aide à structurer votre démarche de sécurité WordPress en 2025, que vous gériez un seul site vitrine ou un petit parc de sites pour plusieurs clients.

Pour la rendre exploitable, vous pouvez :

• Commencer par les blocs critiques : mises à jour, HTTPS, plugin de sécurité, désactivation de XML-RPC, sauvegardes externes.
• Planifier ensuite un “sprint sécurité” dédié au durcissement des fichiers et des permissions.
• Bloquer un créneau récurrent (par exemple chaque trimestre) pour repasser la checklist, contrôler les logs et ajuster les règles Cloudflare ou WAF.
• Documenter ce que vous avez appliqué sur chaque site (notamment si vous gérez plusieurs WordPress pour des clients).

En combinant ce guide pilier avec les tutoriels spécialisés du Mag Web (WP Cerber, Cloudflare, sauvegardes WPvivid, durcissement Apache2 et optimisation serveur), vous construisez progressivement une défense en profondeur : plusieurs couches complémentaires plutôt qu’un “gros plugin miracle”. C’est cette approche, patiente mais structurée, qui fait la différence entre un site régulièrement compromis et un site qui résiste dans la durée.