Comment utiliser la désinfection des entrées pour prévenir les attaques web

La désinfection des entrées consiste à modifier ou supprimer les données potentiellement malveillantes saisies par les utilisateurs afin de prévenir les attaques web telles que l’injection SQL et le cross-site scripting (XSS). Malgré tous nos investissements dans les outils de sécurité, la base de code peut constituer le maillon le plus faible de la cybersécurité de toute organisation.

La désinfection et la validation des entrées constituent généralement la première ligne de défense. En veillant à ce que seules des entrées correctement formatées et sûres soient traitées, les développeurs peuvent réduire le risque d’exécution de code malveillant, de fuites de données et de défaillances applicatives.

Nous aborderons ici la désinfection et la validation des entrées, ainsi que d’autres facteurs clés, comme les configurations serveur, afin de sécuriser efficacement les formulaires web.

Étapes pour utiliser la désinfection des entrées afin de prévenir les attaques web

Les cybercriminels continuent d’exploiter les vulnérabilités courantes pour lancer des cyberattaques comme l’injection SQL, le cross-site scripting (XSS), l’inclusion de fichiers distants (RFI), et la traversée de répertoires. Même si des menaces plus avancées existent — comme l’apprentissage automatique antagoniste, l’obfuscation avancée et les exploits zero-day — les attaques classiques restent répandues et sont toujours à l’origine de la plupart des failles de sécurité. Pour prévenir ces risques, les développeurs doivent désinfecter et valider correctement les données avant de les traiter ou de les stocker.

• Identifier les entrées utilisateur : Examinez tous les points d’entrée de vos applications où les utilisateurs peuvent envoyer des données, comme les formulaires et les barres de recherche. Cela inclut également les requêtes GET et POST, les cookies et toute autre entrée fournie par l’utilisateur.
• Mettre en œuvre la validation des entrées : Vérifiez que les entrées utilisateur respectent des règles strictes et définies concernant les types de données, les longueurs et les caractères autorisés. Par exemple, si vous attendez un nombre, vérifiez que l’entrée est bien numérique. Utilisez des fonctions de validation comme filter_var() en PHP ou des expressions régulières en JavaScript.
• Désinfecter les entrées : Une fois l’entrée validée, désinfectez-la en supprimant ou en encodant les caractères potentiellement malveillants. En PHP, vous pouvez essayer des fonctions comme htmlspecialchars() ou htmlentities(). En JavaScript, utilisez encodeURIComponent().
• Utiliser des requêtes préparées pour les requêtes de base de données : Évitez d’insérer directement les entrées utilisateur dans les requêtes SQL. Utilisez plutôt des requêtes préparées avec des paramètres liés afin de prévenir les attaques par injection SQL. Ainsi, les entrées sont traitées comme des données et non comme du code exécutable.
• Vérifier l’encodage sûr des sorties : Lorsque vous affichez une entrée utilisateur, veillez à ce qu’elle soit correctement échappée afin d’éviter les attaques XSS. C’est particulièrement important pour les données affichées en HTML, en JavaScript ou dans les paramètres d’URL.
• Tester la validation et la désinfection des entrées : Testez régulièrement tous les champs de saisie à la recherche de vulnérabilités à l’aide d’outils de sécurité automatisés et de tests d’intrusion manuels. Vérifiez qu’aucune entrée malveillante ne peut contourner vos procédures de validation et de désinfection.

Quelle est la différence entre désinfecter et valider une entrée ?

La désinfection consiste à supprimer les caractères dangereux des entrées utilisateur, tandis que la validation vérifie si les données présentent le format et le type attendus. La désinfection modifie l’entrée pour garantir qu’elle respecte un format valide avant son affichage ou son insertion dans une base de données.

À l’inverse, la validation vérifie qu’une entrée — par exemple dans un formulaire web — respecte des règles et des contraintes précises (comme l’interdiction des guillemets simples). Prenons par exemple l’entrée suivante :

<input id="num" name="num" type="number" />

En l’absence de validation, rien n’empêche un attaquant d’exploiter le formulaire en saisissant des données inattendues au lieu d’un nombre attendu. Il pourrait également tenter d’exécuter directement du code si les formulaires envoyés sont stockés dans une base de données, ce qui est courant.

Pour éviter une telle situation, les développeurs doivent ajouter une étape de validation au cours de laquelle les données sont inspectées avant de poursuivre. Par exemple, avec un langage répandu comme PHP, vous pouvez vérifier le type et la longueur des données, ainsi que de nombreux autres critères.

Pourquoi utiliser la désinfection et la validation des entrées

La désinfection et la validation des entrées sont nécessaires pour empêcher les attaquants d’exploiter des champs de saisie mal sécurisés afin d’injecter du code malveillant, de manipuler des bases de données ou de compromettre les données des utilisateurs. Ces mesures de sécurité garantissent qu’une application ne traite que des données sûres et attendues, ce qui réduit les risques de sécurité.

Les techniques les plus couramment utilisées contre les entrées mal sécurisées sont les attaques XSS, au cours desquelles les attaquants injectent des scripts malveillants dans des sites web pourtant dignes de confiance.

Certaines attaques XSS sont plus évidentes que d’autres. Même si vous prenez le temps de désinfecter et de valider vos entrées, un attaquant compétent pourrait trouver un moyen d’injecter du code malveillant dans certaines conditions.

Une démonstration classique d’attaque consiste à injecter le script suivant dans une entrée mal sécurisée, où l’espace réservé « XSS » correspond à du JavaScript arbitraire :

<script>alert('XSS')</script>

Si le contenu de l’entrée est affiché sur la page, l’attaquant peut exécuter du JavaScript arbitraire sur le site web ciblé. Le cas typique est celui d’une entrée de recherche vulnérable qui affiche le terme recherché sur la page :

https://mysite.com/?s=<script>alert('XSS')</script>

La situation est encore pire si l’entrée malveillante est stockée dans la base de données. Le code de démonstration peut sembler amusant à tester, mais dans des conditions réelles, les attaquants peuvent faire beaucoup de choses avec JavaScript, allant parfois jusqu’à dérober des cookies.

Quand ne pas utiliser la désinfection

La désinfection ne doit pas être utilisée comme unique mesure de sécurité, car elle ne prévient pas toutes les formes d’attaque et peut supprimer par inadvertance des données nécessaires.

Le principal problème de la désinfection est la fausse impression de sécurité réseau qu’elle peut donner. Supprimer les caractères indésirables et les balises HTML ne constitue qu’un niveau de vérification. Cette opération est souvent mal exécutée et supprime trop d’informations, comme les guillemets légitimes et les caractères spéciaux, sans couvrir tous les angles d’attaque. Il ne faut pas appliquer aveuglément des règles génériques.

Le contexte est essentiel, notamment les langages de programmation utilisés. Il est important de suivre un principe appelé « échapper tard » (par exemple, juste avant la sortie), car vous connaissez alors le contexte exact dans lequel les données sont utilisées.

D’après mon expérience, les situations les plus délicates surviennent lorsqu’il faut autoriser des entrées brutes et d’autres configurations permissives. Dans ces cas, il devient difficile de désinfecter correctement les données, et vous devez maintenir une liste blanche personnalisée des caractères autorisés ou inscrire manuellement certains schémas malveillants sur une liste noire.

Il est plutôt recommandé d’utiliser des bibliothèques et des frameworks robustes.

Plus généralement, les développeurs ne doivent pas hésiter à renvoyer des erreurs lorsque les entrées sont incorrectes, plutôt que de se fier à des suppositions ou à des corrections, qui sont propices aux erreurs et aux failles.

Bonnes pratiques : désinfection des entrées, validation et mode strict

Les équipes de développement peuvent suivre certains principes et bonnes pratiques pour obtenir les meilleurs résultats possibles. Nous aborderons les grandes catégories ainsi que les points particuliers à surveiller.

Ne faites pas confiance aux entrées utilisateur

Certains sites web ne prennent pas la peine de vérifier les entrées utilisateur, ce qui expose l’application au niveau de danger maximal. Heureusement, cette pratique devient plus rare grâce à la sensibilisation à la sécurité et à l’analyse du code. Cependant, une désinfection incomplète n’est pas non plus une excellente solution.

Voici quelques vecteurs d’attaque possibles auxquels vous devez penser.

Requêtes GET

Si les développeurs ne désinfectent pas correctement les chaînes de caractères, les attaquants peuvent tirer parti de failles XSS telles que les suivantes :

https://mysite.com/?s=<script>console.log('you are in trouble!');</script>

La sensibilisation classique à la cybersécurité met généralement en avant l’exemple ci-dessus avec un simple console.log, voire une alerte. Il montre toutefois que n’importe qui peut exécuter du JavaScript arbitraire sur votre page en envoyant simplement une version raccourcie de l’URL malformée à des victimes qui ne se méfient de rien.

Certaines failles XSS peuvent même être persistantes (stockées dans la base de données, par exemple), ce qui évite aux attaquants de devoir inciter la victime à cliquer sur un élément en envoyant des charges malveillantes aux utilisateurs du site web.

Cookies

Les sites web utilisent souvent les cookies HTTP pour gérer les sessions, personnaliser l’expérience et assurer le suivi. Les développeurs peuvent par exemple connecter les utilisateurs, mémoriser leurs préférences et analyser leur comportement.

Le serveur génère un cookie, ou une donnée approximative, et l’envoie au navigateur afin qu’il l’enregistre pour une utilisation ultérieure. Par conséquent, le vol de cookies permet aux attaquants d’usurper l’identité des victimes en leur donnant un accès immédiat aux comptes ciblés, sans connexion.

De plus, les pirates n’ont pas besoin de compromettre l’ordinateur de la victime. Comme les cookies HTTP sont envoyés avec chaque requête, les attaquants peuvent intercepter ces requêtes pour voler des données lors d’attaques de type « homme du milieu » (MITM), par exemple.

Une approche plus sophistiquée peut utiliser une attaque XSS pour insérer du code malveillant dans le site web ciblé afin de copier les cookies des utilisateurs et d’effectuer des actions nuisibles en leur nom.

Bien que Google prévoie de supprimer progressivement les cookies dans son navigateur Chrome en 2025, il reste important de développer de bonnes pratiques de cybersécurité. Par exemple, SSL (Secure Sockets Layer) n’est plus une couche facultative. Toutefois, si le code envoie des requêtes non-SSL, les cookies seront transmis en clair ; veillez donc à utiliser SSL partout.

Une autre bonne pratique consiste à toujours utiliser l’attribut httpOnlySameSiteL’attribut est également recommandé aux développeurs.

Même si les cookies sont pratiques pour les utilisateurs et les développeurs, les systèmes d’authentification et les API modernes permettent de meilleures approches. Comme le stockage des données dans des bases de données côté client présente de nombreuses vulnérabilités en matière de sécurité et de confidentialité, il vaut mieux mettre en œuvre d’autres pratiques plus sûres.

Requêtes POST

Les requêtes POST sont des requêtes côté serveur ; elles n’exposent donc pas les données dans l’URL, par exemple lorsque vous téléversez une image sur votre compte en ligne ou envoyez un formulaire de contact, comme dans l’exemple suivant :

<form action="https://my-website.com/contact" method="POST">

Une idée reçue veut que les requêtes POST soient plus sécurisées que les requêtes GET. En réalité, au mieux, les requêtes POST relèvent de la sécurité par l’obscurité. Même s’il vaut mieux utiliser les requêtes POST pour modifier des données utilisateur, elles ne sont pas idéales à des fins liées à la sécurité et ne renforcent pas magiquement la sécurité.

Une façon simple de désinfecter les données POST provenant des entrées en PHP pourrait consister à utiliser les commandes suivantes :

filter_var($_POST['message'], FILTER_SANITIZE_STRING);
filter_var('bobby.fisher@chess.com', FILTER_VALIDATE_EMAIL)

Une autre bonne pratique en PHP consiste à utiliser htmlentities() pour échapper tout caractère HTML indésirable dans une chaîne.

Comme pour les cookies, utilisez toujours SSL pour chiffrer les données, de sorte que seules les informations TCP/IP restent non chiffrées.

Traversée de répertoires

Si la base de code comprend une balise d’image, comme…

<img src="/getImages?filename=image12.png" />

…les pirates peuvent alors essayer d’utiliser…

https://yourwebsite.com/getImages?filename=../../../etc/passwd

…pour accéder aux informations des utilisateurs.

Cependant, si votre serveur est correctement configuré, ces tentatives de divulgation d’informations confidentielles seront bloquées. Vous devriez également envisager de filtrer les entrées utilisateur et de vérifier que seuls les formats et types de données attendus sont transmis.

Ne faites pas confiance à la validation côté client

Une idée reçue courante, surtout chez les débutants, consiste à s’appuyer uniquement sur HTML et JavaScript pour valider les données d’un formulaire. Même si HTML permet de définir des modèles et des champs obligatoires, par exemple en fixant une limite de caractères ou en exigeant que certains champs soient remplis, aucun attribut HTML ni code JavaScript ne peut être modifié côté client.

Les pirates peuvent également envoyer le formulaire à l’aide de cURL ou de n’importe quel client HTTP ; le côté client ne constitue donc pas une couche sécurisée pour valider les formulaires.

Activer le mode strict

Chaque fois que possible, activez le mode strict, qu’il s’agisse de PHP, de JavaScript, de SQL ou de tout autre langage. Cependant, comme le mode strict empêche de nombreuses syntaxes pratiques, son activation peut être difficile si votre dette technique et votre code existant sont importants.

Mais si vous ne codez pas en mode strict, le moteur commence à faire des suppositions et peut même modifier automatiquement les valeurs pour faire fonctionner le code. Cela ouvre des vulnérabilités que les pirates peuvent exploiter pour injecter des commandes malveillantes.

En 2015, par exemple, Andrew Nacin, contributeur majeur de WordPress, a expliqué comment une faille de sécurité critique aurait pu être évitée simplement en activant le mode strict dans SQL. Il a montré comment les pirates pouvaient exploiter une vulnérabilité critique en utilisant des caractères de quatre octets pour forcer la troncature de MySQL, puis injecter du code malveillant dans la base de données.

Une solution simple pour empêcher cette attaque aurait été d’exécuter la commande SET SESSION sql_mode = "STRICT_ALL_TABLES", mais il est impossible de l’activer sans casser tous les sites web propulsés par WordPress.

Consulter le Web Security Testing Guide d’OWASP

OWASP, l’Open Web Application Security Project, tient à jour une documentation complète appelée Web Security Testing Guide (WTSG), qui comprend la validation des entrées.

Ce guide explique comment tester différentes injections et autres attaques sournoises visant les entrées. Son contenu est fréquemment mis à jour et propose des explications détaillées pour divers scénarios.

Vous pouvez par exemple consulter leur page consacrée aux tests du cross-site scripting persistant pour comprendre le fonctionnement du XSS persistant et savoir comment reproduire l’exploit.

En résumé : désinfecter, valider et échapper tard

La désinfection des entrées contribue à réduire les risques de sécurité, mais elle ne doit jamais constituer votre seule ligne de défense. Validez toujours les entrées avant de les stocker et échappez les sorties avant de les afficher afin de prévenir les attaques potentielles.

S’appuyer uniquement sur la désinfection des entrées peut entraîner des vulnérabilités ; utilisez donc des bibliothèques et des frameworks de sécurité adaptés à votre contexte spécifique. La combinaison de ces méthodes peut renforcer votre sécurité et protéger vos applications contre les cyberattaques.

Consultez nos guides consacrés aux outils de débogage et de sécurité du code et aux solutions de pare-feu pour applications web (WAF) pour découvrir les meilleurs outils de sécurité capables d’améliorer votre posture de sécurité globale.

Liz Ticong a mis à jour cet article en février 2025.