Cross-Site Request Forgery (CSRF)
Définition : Dans la sécurité WordPress, attaque exploitant la session d'un utilisateur pour lui faire envoyer une requête non voulue. Cette mesure intervient dans une chaîne de protection et ne remplace pas les autres vérifications.
Comprendre et utiliser
À quoi sert cette notion ?
Attaque exploitant la session d'un utilisateur pour lui faire envoyer une requête non voulue. Un usage concret consiste à protéger une action sensible d'administration par nonce et permissions. La fiche précise ainsi ce que résout l'élément et pourquoi son comportement importe dans un projet WordPress.
Fonctionnement technique
La sécurité des extensions repose sur plusieurs contrôles distincts : identifier le demandeur, vérifier ses permissions, valider les données reçues, traiter les erreurs et encoder correctement les valeurs affichées. Une seule barrière ne suffit pas à protéger tout le parcours. Pour ce terme, retenir précisément : attaque exploitant la session d'un utilisateur pour lui faire envoyer une requête non voulue. La valeur pratique dépend de son cycle d'exécution et du type de données réellement manipulées.
Dans quel contexte l’utiliser ?
Exemple professionnel : Protéger une action sensible d'administration par nonce et permissions. Avant l'application, relever la version de WordPress, le type d'installation, les droits disponibles et les éventuelles extensions participant au traitement.
Étude de cas : application professionnelle
Une intervention documentaire ATOOLPHA part du problème suivant : protéger une action sensible d'administration par nonce et permissions. L'équipe relève l'état attendu et observe le comportement réel. Elle reproduit ensuite un cas limite lié à la notion : un nonce ne prouve jamais à lui seul le droit d'accomplir l'action. Elle contrôle alors les données réellement affectées. Elle note toute divergence avant déploiement.
Exemple technique commenté
Extrait PHP dans le contexte WordPress chargé, présenté comme exemple pédagogique isolé et non comme extension autonome. Les fonctions nécessitant un hook, un contrôle de permission ou une activation préalable doivent être intégrées à ces mécanismes.
if ( ! current_user_can( 'manage_options' ) ) {
wp_die( 'Accès refusé.' );
}
check_admin_referer( 'atoolpha_update_settings' );Décryptage du code et résultat attendu
Permission et nonce remplissent deux rôles distincts. Examiner les arguments dans l'ordre, identifier le type de retour et distinguer les valeurs fictives des paramètres réellement requis par la fonction ou la commande.
Exercice guidé pour vérifier la notion
En préproduction, tester une valeur valide, une valeur malformée, une session anonyme et un compte insuffisamment autorisé. Examiner aussi la trace de l'échec : aucune information privée ne doit apparaître dans les réponses ou journaux. Pour « Cross-Site Request Forgery (CSRF) », vérifier ensuite ce cas ciblé : protéger une action sensible d'administration par nonce et permissions. Conserver la valeur observée, la date et le contexte de test.
Précautions et limites
Point de vigilance particulier : un nonce ne prouve jamais à lui seul le droit d'accomplir l'action. Les opérations qui modifient des données nécessitent permissions adéquates, sauvegarde si besoin et vérification après exécution.
À ne pas confondre
Un contrôle CSRF ne remplace pas l'autorisation, l'échappement HTML ne sécurise pas une requête SQL, et une URL valide peut rester non autorisée pour une action. Cette distinction évite d'attribuer à « Cross-Site Request Forgery (CSRF) » des responsabilités qui relèvent d'un autre mécanisme WordPress.
Diagnostic avancé
Lorsque le comportement ne correspond pas aux attentes, contrôler en priorité : un nonce ne prouve jamais à lui seul le droit d'accomplir l'action. Examiner ensuite les paramètres d'entrée, les éventuels retours d'erreur et les effets observables sur la cible exacte.
Choix d’architecture et déploiement
Définir les frontières de confiance avant de coder : entrée HTTP, fichier envoyé, données persistées et sortie navigateur. Appliquer les capacités WordPress, les nonces pour les actions concernées, la validation métier, l'assainissement adapté et l'échappement au point de rendu. Pour le scénario retenu, documenter aussi les conditions d'installation, les dépendances de version et une manière réversible de corriger une erreur.
