Sécuriser WordPress (2026) : hardening, WAF, 2FA, backups

Sécuriser WordPress : hardening + WAF + sauvegardes (guide 2026)

Un WordPress sécurisé, ce n’est pas “un plugin magique”. C’est une stratégie en couches : réduire la surface d’attaque, filtrer les requêvos (WAF), verrouiller l’auth, et surtout être capable de restaurer vite.

Schéma sécurité WordPress : durcissement serveur, WAF, sauvegardes chiffrées et réponse aux incidents

Ce guide vous donne une checklist actionnable, adaptée aux setups classiques (Apache/Nginx, Docker, reverse proxy, Cloudflare).

TL;DR (les 12 actions qui font le plus de différence)

Mettre à jour WordPress core + thèmes + plugins (et supprimer l’inutile)
Forcer HTTPS partout + HSTS (si prêt)
Activer 2FA sur tous les admins (au minimum)
Protéger /wp-login.php + /wp-admin (WAF + rate-limit + challenge)
Gérer XML-RPC (désactiver si possible, sinon limiter)
Bloquer l’exécution PHP dans uploads
Principe du moindre privilège (rôles, comptes, clés)
WAF (Cloudflare/ModSecurity) + règles “anti-bot/scanners”
Backups DB + fichiers + test de restauration
Journaux + alerting (au moins 401/403/5xx)
Secrets hors Git (variables d’env / secrets), salts WP corrects
Plan d’incident : qui fait quoi, en combien de temps

1) Commence par la base : mises à jour + hygiène plugins

La majorité des compromissions WordPress viennent de plugins obsolèvos (ou abandonnés).

Checklist rapide :

Mets à jour core / plugins / thèmes (idéalement via staging)
Supprime les plugins désactivés (surface d’attaque inutile)
Évite les “nulled themes/plugins”
Limite les comptes admin (1–2 max)

WordPress rappelle que la sécurité est surtout une question de réduction de risque (pas de risque zéro) et de discipline de mise à jour.

2) Architecture : reverse proxy + séparation (containment)

Même si vous n’as “qu’un site”, sépare au moins :

reverse proxy (TLS + règles),
WordPress,
base de données (jamais exposée publiquement).

Architecture WordPress (proxy → WordPress → DB)

Points non négociables :

Pas de port DB public (3306, etc.)
Firewall strict (80/443 uniquement, SSH limité)
Backups hors serveur

3) WAF : filtre avant WordPress (Cloudflare / ModSecurity)

Un WAF bloque une partie des attaques avant même que PHP/WordPress ne les traite (SQLi, XSS, scanners, brute-force).

Option A — Cloudflare (simple + efficace)

Paramètres de base recommandés :

SSL/TLS en Full (Strict)
Activer les Managed Rules
Activer l’OWASP / ModSecurity Core Rule Set (si dispo)

Option B — WAF côté serveur

Si vous êvos sur Nginx/Apache/LiteSpeed, vous pouvez utiliser un WAF côté serveur (ex: ModSecurity).

4) Rate limiting : login & admin-ajax

Les endpoints les plus “tapés” :

/wp-login.php
/xmlrpc.php (si activé)
/wp-admin/admin-ajax.php

Exemple (inspiré de règles Cloudflare) :

/wp-login.php : 5 req / minute / IP, puis blocage 1h
/wp-admin/admin-ajax.php : 18 req / minute / IP, puis blocage 1h

Astuce : commence par “challenge” plutôt que “block�� si vous avez beaucoup d’utilisateurs derrière un même IP (entreprise).

5) XML-RPC : désactiver si vous pouvez, limiter sinon

xmlrpc.php est souvent abusé (brute-force / amplification).

Désactiver (le plus simple)

Nginx :

location = /xmlrpc.php { return 403; }

Apache/LiteSpeed (.htaccess) :

<Files "xmlrpc.php">
  Require all denied
</Files>

si vous en as besoin (Jetpack/outil legacy), garde-le mais rate-limit et/ou autorise uniquement certaines IPs.

6) Verrouiller l’auth : 2FA + politiques de comptes

2FA sur tous les admins (non négociable)
Mots de passe uniques + forts
Supprimer les comptes inactifs / anciens prestataires
Utiliser un compte admin “maintenance” séparé ; travailler au quotidien en Editor