Sécurité WordPress : la checklist agence en 12 points

011. Mises à jour : noyau, plugins, thèmes

Le vecteur d'attaque #1 sur WordPress, c'est un plugin obsolète avec faille connue. La majorité des compromissions exploite des vulnérabilités publiées depuis plus de 6 mois — donc patchées, mais sur des sites qui n'ont pas mis à jour. Stratégie : activer les mises à jour automatiques pour les versions mineures (WP, plugins, thèmes), valider manuellement les versions majeures (qui peuvent casser des choses). Outils de monitoring : ManageWP ou MainWP centralisent les MAJ sur plusieurs sites. Plugin recommandé : Easy Updates Manager pour le contrôle fin par type.

// wp-config.php — activer auto-update du core
define('WP_AUTO_UPDATE_CORE', true);

// Pour les plugins (avec précaution)
add_filter('auto_update_plugin', '__return_true');

// Mais idéalement : centraliser avec ManageWP
// et tester avant les majeures

022. Authentification : 2FA et mots de passe forts

Tous les comptes administrateurs doivent : avoir un mot de passe complexe (16+ caractères, gestionnaire type 1Password/Bitwarden), avoir la 2FA activée (TOTP via Google Authenticator/Authy), ne PAS s'appeler `admin` (changer le username défaut). Plugin recommandé : Two Factor Authentication (Plugin Vault) ou WP 2FA. Pour les rôles : limiter les comptes admin au strict nécessaire. Un rédacteur n'a pas besoin du rôle Administrator, juste Editor ou Author. Auditer régulièrement la liste des utilisateurs et supprimer les comptes inactifs.

033. Limiter les tentatives de login

Les attaques par brute-force sur `/wp-login.php` représentent l'essentiel du trafic malveillant sur un WordPress non protégé. Plugins recommandés : Limit Login Attempts Reloaded (gratuit) ou Wordfence (qui inclut cette fonction). Configuration typique : 4 tentatives échouées = blocage IP 20 minutes, 10 échecs = blocage 24h. Variante : whitelister les IPs admin si vous travaillez depuis IPs fixes. Pour aller plus loin : ajouter un reCAPTCHA v3 sur le formulaire de login.

044. Cacher /wp-admin et /wp-login.php

Tous les bots ciblent `/wp-admin/` et `/wp-login.php`. Changer ces URLs est une protection par obscurité — pas une vraie sécurité, mais ça élimine 95% des attaques automatisées. Plugin recommandé : WPS Hide Login (renomme en `/secret-login-url`). Important : ne pas perdre l'URL custom (la stocker dans le gestionnaire de mots de passe), et garder une redirection ou une page d'erreur 404 sur l'ancienne URL. Combiné avec la 2FA, ça réduit drastiquement la surface d'attaque.

055. Permissions fichiers et durcissement wp-config

Les permissions Unix doivent être correctes : 644 pour les fichiers, 755 pour les dossiers, 600 ou 640 pour `wp-config.php` (le plus sensible). Désactiver l'édition de fichiers depuis l'admin WP (impossible pour un attaquant qui obtient un accès admin de modifier du code via l'interface) :

// wp-config.php — durcissement standard

// Empêcher l'édition de fichiers depuis l'admin
define('DISALLOW_FILE_EDIT', true);

// Empêcher l'installation/màj de plugins via l'admin
// (à activer seulement si CI/CD ou déploiement Git)
define('DISALLOW_FILE_MODS', false);

// Changer les clés et sels d'authentification
// Générer via https://api.wordpress.org/secret-key/1.1/salt/
define('AUTH_KEY', '...');
define('SECURE_AUTH_KEY', '...');
// ... et les 6 autres clés

066. Désactivation XML-RPC et REST API publique

XML-RPC est une vieille API WordPress utilisée pour les pingbacks, l'application mobile WordPress, etc. Si vous ne l'utilisez pas (cas le plus courant), désactivez-la : c'est un vecteur d'attaque récurrent (amplification DDoS, brute-force via xmlrpc.php). Plugin Disable XML-RPC ou règle .htaccess. La REST API WordPress (`/wp-json/`) est utile mais expose par défaut la liste des utilisateurs (`/wp-json/wp/v2/users`) — utile pour un attaquant pour trouver les usernames. Restreindre via plugin Disable REST API ou code custom pour ne laisser passer que les endpoints nécessaires.

077. WAF : Cloudflare, Sucuri, Wordfence

Un Web Application Firewall filtre les requêtes malveillantes AVANT qu'elles n'atteignent WordPress. Trois options crédibles : Cloudflare (gratuit en version basic, WAF avancé en payant ~20$/mois), Sucuri (~200$/an, spécialisé WP), Wordfence (gratuit + payant ~99$/an pour le WAF avancé). Cloudflare en frontal est notre recommandation #1 — il offre CDN + DDoS protection + WAF + analytics. Configurer les règles : bloquer les bots malveillants connus, geo-blocking si vous ne servez qu'un marché (FR/EU), rate limiting agressif sur `/wp-login.php`.

088. Sauvegardes : fréquence, lieu, restauration testée

Sauvegarde = la dernière ligne de défense. Critères : fréquence adaptée (quotidienne pour un site actif, hebdomadaire pour un site vitrine), stockage offsite (Amazon S3, Backblaze, Google Drive — PAS sur le même serveur), rétention 30+ jours, restauration TESTÉE régulièrement (un backup non testé n'est pas un backup). Plugins recommandés : UpdraftPlus (gratuit + Premium 70$/an), BackWPup (open-source), BlogVault (payant mais excellent). Tester la restauration au moins une fois par trimestre sur un staging.

099. Monitoring et alerting

Détecter une compromission rapidement = limiter les dégâts. Outils : Wordfence (alerte si fichiers core modifiés, nouveaux plugins suspects, comptes admin créés), Sucuri SiteCheck (scan quotidien), ManageWP (monitoring uptime + sécurité). Configurer alertes par email/Slack sur événements critiques : nouveau compte admin créé, fichier core modifié, plugin ajouté, downtime > 5 min. Plus tôt vous détectez, plus tôt vous réagissez — souvent la différence entre 1h de réparation et 48h de catastrophe.

1010. SSL/TLS bien configuré

HTTPS oui, mais bien fait. Vérifier : version TLS 1.2 minimum (idéalement 1.3 only), certificat valide pas seulement présent, HSTS activé (Strict-Transport-Security header), pas de mixed content (toutes ressources internes en HTTPS), redirect 301 systématique HTTP→HTTPS. Outil de test : SSL Labs (ssllabs.com/ssltest) — viser score A ou A+. Sur WordPress : plugin Really Simple SSL pour automatiser, ou configurer manuellement dans Nginx/Apache.

1111. Choisir un hébergement WordPress-friendly

Un hébergement mutualisé bas de gamme (OVH Perso, 1&1 IONOS basic) = WordPress vulnérable par construction. Caractéristiques d'un bon hébergement WP : PHP 8.2+ avec OPcache, MySQL 8 ou MariaDB 10.6+, isolation entre comptes (pas de neighbor risk), monitoring sécurité par l'hébergeur, sauvegardes automatiques quotidiennes, support réactif. Recommandations : o2switch (français, RGPD, ~7€/mois — excellent pour PME), Kinsta (premium WordPress géré, 35$/mois), WP Engine (US premium, 30$/mois), AWS Lightsail (technique, 5$/mois). Éviter : les revendeurs cPanel à 2€/mois.

1212. Plan d'incident : que faire en cas de compromission

Si malgré tout vous êtes compromis : 1) Couper l'accès au site (page maintenance), 2) Faire un backup complet de l'état compromis (pour forensics), 3) Restaurer depuis backup sain antérieur à la compromission, 4) Changer TOUS les mots de passe (admin WP, FTP, DB, hébergeur), 5) Régénérer les clés/sels wp-config, 6) Scanner avec Wordfence + Sucuri, 7) Identifier le point d'entrée (plugin vulnérable ?) et patcher, 8) Re-monter, 9) Soumettre Google Search Console si Google a flaggé le site, 10) Surveillance renforcée 30 jours. Un incident bien géré = downtime 4-8h. Mal géré = client perdu, SEO détruit, semaines de récupération.