Durcir WordPress en 2026 — la checklist que nous appliquons sur les sites clients

La plupart des articles « Top 50 des astuces de sécurité WordPress » sont du bruit. Ils listent « utilisez un mot de passe fort » à côté de contrôles réellement utiles, et le lecteur n'a aucun moyen de distinguer ce qui compte.

Ceci est la checklist que nous exécutons sur chaque nouveau site WordPress pris en hébergement managé. Chaque élément est là parce que nous avons vu l'attaque qu'il prévient toucher un vrai client au cours des 18 derniers mois. Appliquez les contrôles de cette liste et vous défendrez environ 95 % de ce qui se présente aux origines WordPress.

La passe de durcissement de wp-config

define('DISALLOW_FILE_EDIT', true);
define('DISALLOW_FILE_MODS', true);
define('WP_AUTO_UPDATE_CORE', 'minor');
define('FORCE_SSL_ADMIN', true);
define('WP_DEBUG', false);

Les deux contrôles à fort impact : DISALLOW_FILE_EDIT supprime l'éditeur de thème/plugin dans le dashboard, donc un admin compromis ne peut pas déposer une webshell via l'UI. DISALLOW_FILE_MODS bloque entièrement les installations de plugins/thèmes — ce qui est correct pour les sites où les déploiements passent par la CI.

L'article complet couvre :

• Les permissions du système de fichiers et le montage noexec sur wp-content/uploads qui neutralise la plupart des webshells
• La désactivation de XML-RPC (ou le rate-limiting) — l'amplificateur de brute-force system.multicall
• Les endpoints REST API qui fuient les noms d'utilisateur, et comment les bloquer proprement
• Les jails Fail2ban qui comptent réellement les POST échoués sur wp-login.php
• L'application du 2FA (TOTP minimum, WebAuthn pour les petites équipes)
• Le file-integrity monitoring AIDE/Tripwire comme filet de sécurité post-compromission
• L'allowlisting de plugins et thèmes — le problème des plugins abandonnés

Nous livrons ce baseline sur chaque installation WordPress managée.