En 2025, plus de 60 % des vulnérabilités critiques signalées dans les plugins WordPress impliquaient une absence ou un contournement de vérification CSRF, selon les données de Patchstack. Derrière ce chiffre alarmant se cache une réalité simple : une attaque CSRF ne cherche pas à briser vos défenses frontales. Elle se sert de vous — ou de votre administrateur — comme arme.
Contrairement aux injections SQL ou aux attaques XSS qui visent les données ou les scripts côté serveur, le Cross-Site Request Forgery exploite la confiance qu’un site accorde à un navigateur authentifié. Un clic sur le mauvais lien suffit à supprimer un compte administrateur, changer un mot de passe ou installer un plugin malveillant — sans que vous vous en rendiez compte sur le moment.
Dans ce guide, vous apprendrez comment fonctionnent ces attaques, pourquoi WordPress y est vulnérable malgré son système de nonces, et les 7 mesures concrètes pour protéger votre site en 2026.
CSRF (prononcer « sea-surf ») est une technique d’attaque qui abuse de l’identité d’un utilisateur authentifié pour exécuter des requêtes HTTP non autorisées à son insu. L’OWASP classe le CSRF parmi les vulnérabilités web les plus dangereuses depuis des années, et WordPress — en tant que CMS dominant avec 43 % de part de marché — est une cible de choix.
Exemple concret : un attaquant peut intégrer dans un email HTML une balise image invisible :
<img src="https://votresite.com/wp-admin/user-new.php?action=createuser
&user_login=hacker&user_pass=P@ss123!&role=administrator"
width="0" height="0" />Si vous êtes connecté en tant qu’administrateur au moment de l’ouverture de cet email, un nouveau compte administrateur est créé automatiquement — sans aucune confirmation de votre part.
WordPress intègre un système de nonces (number used once) pour protéger ses formulaires contre le CSRF. Un nonce est un jeton cryptographique unique, lié à :
update-user_42, delete-post_15)Chaque formulaire sensible dans WordPress intègre ce jeton via wp_nonce_field(), et le serveur le vérifie avec check_admin_referer() avant d’exécuter l’action. Sans nonce valide, la requête est rejetée.
Le problème : WordPress fournit les outils, mais ne force pas les développeurs à les utiliser. De nombreux plugins oublient de vérifier les nonces, notamment :
wp_ajax_) sans appel à check_ajax_referer()En 2024-2025, plusieurs CVE critiques ont été publiées pour ce motif. Un plugin de formulaires très populaire (100 000+ installations actives) était exposé via une action AJAX non protégée, permettant à n’importe quel visiteur de modifier les paramètres globaux du site — CVSS Score : 8.8/10. Vérifiez systématiquement la base NVD NIST et CVE MITRE pour vos plugins installés.
Pour comprendre les attaques connexes qui partagent les mêmes vecteurs d’exploitation, consultez notre guide sur les attaques XSS WordPress et notre analyse des injections SQL WordPress.
Recherchez dans vos logs Apache ou Nginx des requêtes POST vers /wp-admin/ ou /wp-json/ avec un Referer extérieur à votre domaine :
grep "POST /wp-admin" /var/log/apache2/access.log | grep -v "votredomaine.com"Toute requête POST admin dont le Referer pointe vers un domaine tiers mérite une investigation immédiate. Selon Wordfence, ce type de pattern représentait en 2024 environ 12 % de toutes les tentatives d’intrusion bloquées sur les sites WordPress protégés.
La majorité des CSRF exploités en production ciblent des plugins non mis à jour. Selon Wordfence, 97 % des sites WordPress compromis utilisaient au moins un composant avec une vulnérabilité connue et déjà corrigée. Un plugin à jour, c’est une faille CSRF patchée.
Si vous développez des fonctionnalités WordPress, appliquez systématiquement les nonces pour toute action sensible :
// Dans le formulaire
wp_nonce_field('mon_action_securisee', 'mon_nonce');
// Lors du traitement
if (!isset($_POST['mon_nonce']) ||
!wp_verify_nonce($_POST['mon_nonce'], 'mon_action_securisee')) {
wp_die('Requête non autorisée', 403);
}Pour chaque handler AJAX, ajoutez la vérification :
add_action('wp_ajax_mon_action', 'handler_mon_action');
function handler_mon_action() {
check_ajax_referer('mon_action_nonce', 'security');
// Traitement sécurisé
}Pour l’API REST, n’oubliez jamais le permission_callback :
'permission_callback' => function() {
return current_user_can('manage_options');
}L’attribut SameSite=Strict empêche le navigateur d’envoyer les cookies de session lors de requêtes cross-site — bloquant la majorité des CSRF au niveau du navigateur. Ajoutez dans wp-config.php :
@ini_set('session.cookie_samesite', 'Strict');
@ini_set('session.cookie_secure', '1');
@ini_set('session.cookie_httponly', '1');Combinez cette mesure avec une configuration complète des en-têtes HTTP, détaillée dans notre guide sur les en-têtes de sécurité HTTP WordPress.
Les solutions comme Wordfence Premium, Cloudflare WAF ou Sucuri intègrent des règles CSRF qui analysent les requêtes entrantes et bloquent celles dont les tokens sont absents ou invalides, avant même que PHP soit exécuté. C’est une couche de défense complémentaire indispensable.
La fenêtre d’exploitation CSRF est directement liée à la durée de vos sessions admin ouvertes. Forcez la déconnexion après inactivité et imposez la double authentification : même si un CSRF crée un nouveau compte administrateur, le 2FA bloque l’accès effectif. Retrouvez la procédure complète dans notre guide sur la sécurisation de la connexion WordPress.
Si un CSRF réussit à piéger un admin, l’éditeur de thèmes/plugins intégré devient une porte d’entrée pour injecter du code malveillant. Désactivez-le dans wp-config.php :
define('DISALLOW_FILE_EDIT', true);
define('DISALLOW_FILE_MODS', true); // Bloque aussi l'installation de plugins/thèmesL’API REST WordPress introduit un vecteur CSRF souvent négligé. Par défaut, les endpoints REST utilisent des nonces spécifiques (via le header X-WP-Nonce), mais de nombreux plugins exposent des routes sans vérification d’authentification adéquate. Un endpoint REST mal sécurisé peut être appelé depuis n’importe quel site tiers tant que l’utilisateur cible est connecté à WordPress.
Bonne pratique : auditez régulièrement vos routes REST avec GET /wp-json/wp/v2/ et vérifiez que chaque route sensible exige une authentification explicite. Pour une couverture complète, référez-vous à notre guide sur la sécurisation de l’API REST WordPress.
Non. Le CSRF exploite une session authentifiée existante. Sans cookie de session valide, l’attaque ne peut pas s’exécuter avec vos privilèges. C’est pourquoi se déconnecter après chaque session admin est une bonne pratique simple mais efficace.
Partiellement. Wordfence détecte certains patterns CSRF via son WAF et ses règles de pare-feu, mais ne peut pas compenser une mauvaise implémentation de nonces dans un plugin tiers custom. La protection applicative (code propre avec nonces) reste la première ligne de défense.
Consultez régulièrement les bases Patchstack, CVE MITRE et NVD NIST. Activez les notifications de mises à jour dans votre tableau de bord et abonnez-vous aux alertes de sécurité WordPress.
Non directement. HTTPS chiffre le transit des données mais ne vérifie pas l’intention ou l’origine légitime de la requête. L’attribut SameSite des cookies et les nonces restent les mécanismes clés anti-CSRF, indépendamment du protocole de transport.
Le CSRF est souvent sous-estimé parce qu’il est invisible à l’œil nu : aucun message d’erreur, aucun symptôme immédiat. Pourtant, une seule requête forgée peut suffire à compromettre l’intégralité de votre site WordPress — compte admin créé, contenu modifié, plugin malveillant installé.
La protection est à portée de main : plugins à jour, nonces correctement implémentés, attribut SameSite, WAF, et double authentification couvrent l’essentiel des vecteurs CSRF connus. Pour une vision globale de votre posture de sécurité, notre checklist sécurité WordPress 2026 vous guidera sur l’ensemble des points à vérifier.
Vous souhaitez un audit de sécurité complet de votre WordPress ou avez subi une tentative d’intrusion ? Contactez SecuriteWP — notre équipe analyse votre site et met en place les protections adaptées.
Les attaques supply chain WordPress ciblent la chaîne de distribution des plugins et thèmes. Découvrez comment elles fonctionnent, les IOC à surveiller et les mesures concrètes pour protéger votre site.
Votre base de données MySQL est le cœur de WordPress : elle contient tout. Découvrez comment la sécuriser avec 8 techniques concrètes pour 2026.
Découvrez quelles permissions de fichiers appliquer sur WordPress (644, 755, 600) pour sécuriser votre installation et éviter les intrusions. Guide complet 2026 avec commandes SSH.
Apprenez à configurer les bonnes permissions de fichiers WordPress (chmod 755/644/640). Guide complet SSH, FTP, WP-CLI pour sécuriser votre site contre les intrusions.
Un backdoor CVSS 10 découvert dans Smart Slider 3 PRO 3.5.1.35 et deux failles XSS dans Gravity Forms 2.9.30 : analyse et mesures d’urgence pour protéger votre site WordPress.
Votre site WordPress a été piraté ? Suivez ce guide de remédiation complet : détection, nettoyage des fichiers infectés, base de données, sécurisation post-hack et demande de révision Google.
Nos experts français assurent un support et une prestation de qualité.
