« Il faut sanitiser les entrées utilisateur » est un des conseils de sécurité les plus répétés dans l’écosystème WordPress, et pourtant l’un des plus souvent mal appliqués, en particulier parce qu’on confond régulièrement trois notions distinctes : sanitiser une donnée, la valider, et l’échapper à l’affichage. Ce sont trois étapes différentes, avec des fonctions différentes, à des moments différents du traitement.
Dans cet article, je me concentre sur la première étape, la sanitation, celle qui intervient dès qu’une donnée entre dans WordPress, que ce soit via un formulaire, une requête AJAX, l’API REST ou une URL. L’objectif de la sanitation est de nettoyer une donnée brute pour la ramener à un format sûr et prévisible, avant même de savoir si elle est valide au sens métier.
Sanitation, validation, échappement : bien distinguer
Ces trois notions se complètent mais ne se remplacent jamais l’une l’autre :
- La sanitation nettoie une donnée brute (retire les balises HTML indésirables, les espaces superflus, les caractères non conformes) pour obtenir un format cohérent, avant stockage ;
- La validation vérifie qu’une donnée déjà sanitisée respecte une règle métier (un email a-t-il un format valide et existe-t-il vraiment, un nombre est-il dans la bonne plage) ;
- L’échappement protège l’affichage d’une donnée au moment où elle ressort vers le HTML, indépendamment de ce qui a été fait à l’entrée.
Une erreur fréquente consiste à croire qu’une donnée sanitisée à l’entrée n’a plus besoin d’être échappée à la sortie. C’est faux : ce sont deux protections indépendantes, contre deux risques différents, et l’une ne dispense jamais de l’autre.
sanitize_text_field, la fonction la plus utilisée
sanitize_text_field() est la fonction de sanitation la plus courante pour un champ texte simple. Elle retire les balises HTML, convertit les entités dangereuses, supprime les espaces en début et fin de chaîne, et normalise les retours à la ligne superflus :
$nom = sanitize_text_field( wp_unslash( $_POST['nom'] ) );
Notez l’appel à wp_unslash() avant la sanitation : WordPress ajoute automatiquement des barres obliques d’échappement aux données de $_POST, $_GET et $_COOKIE pour compatibilité historique avec les « magic quotes ». Il faut les retirer avant tout traitement, sans quoi la donnée sanitisée contiendra des barres obliques indésirables.
Les fonctions spécialisées par type de donnée
WordPress fournit une fonction de sanitation dédiée pour chaque type de donnée courant, et il est important d’utiliser la bonne plutôt que de tout faire passer par sanitize_text_field() :
| Type de donnée | Fonction | Effet |
|---|---|---|
| Texte libre court | sanitize_text_field | Retire HTML, espaces superflus |
| Adresse email | sanitize_email | Retire les caractères invalides pour un email |
| Clé, identifiant technique | sanitize_key | Minuscules, chiffres et tirets bas uniquement |
| Nom de fichier | sanitize_file_name | Retire les caractères dangereux pour un système de fichiers |
| Nombre entier positif | absint | Convertit en entier positif ou zéro |
| Contenu multiligne (textarea) | sanitize_textarea_field | Comme sanitize_text_field, mais conserve les retours à la ligne |
Exemple complet dans un formulaire de réglages
Voici un exemple représentatif du traitement d’un formulaire simple d’extension, qui applique la bonne fonction à chaque champ :
function mon_plugin_enregistrer_reglages() {
check_admin_referer( 'mon_plugin_save', 'mon_plugin_nonce' );
if ( ! current_user_can( 'manage_options' ) ) {
wp_die( 'Action non autorisée.' );
}
$nom = sanitize_text_field( wp_unslash( $_POST['nom'] ) );
$email = sanitize_email( wp_unslash( $_POST['email'] ) );
$limite = absint( $_POST['limite'] );
$cle_api = sanitize_key( wp_unslash( $_POST['cle_api'] ) );
if ( ! is_email( $email ) ) {
wp_die( 'Adresse email invalide.' );
}
update_option( 'mon_plugin_nom', $nom );
update_option( 'mon_plugin_email', $email );
update_option( 'mon_plugin_limite', $limite );
update_option( 'mon_plugin_cle_api', $cle_api );
}
Remarquez que la validation de l’email intervient après sa sanitation, via is_email(), qui vérifie le format sans modifier la donnée : c’est une étape distincte, qui peut aboutir au rejet complet de la donnée si elle ne convient pas, contrairement à la sanitation qui la transforme silencieusement.
Le cas d’absint et des types numériques
absint() mérite une attention particulière : elle convertit systématiquement la valeur en entier positif, ce qui signifie qu’une valeur négative devient positive plutôt que d’être rejetée. Si le contexte métier exige de distinguer une valeur négative invalide d’une valeur positive, il faut valider séparément avec intval() puis une comparaison explicite, plutôt que de se reposer sur absint() seule.
Un piège que je vois régulièrement : sanitiser une donnée avec
sanitize_text_field()puis l’insérer directement dans une requête SQL sans passer par$wpdb->prepare(), en pensant que la sanitation suffit. Elle ne suffit pas : la sanitation nettoie le format, elle ne protège pas contre l’injection SQL, qui reste du ressort exclusif de la préparation de requête.
En résumé
Sanitiser une entrée utilisateur consiste à choisir la fonction adaptée à chaque type de donnée, sanitize_text_field() pour du texte simple, sanitize_email() pour un email, absint() pour un entier positif, sanitize_key() pour une clé technique. Cette étape reste distincte de la validation métier et de l’échappement à l’affichage : les trois sont nécessaires, à des moments différents, et aucune ne remplace les deux autres.
