Validation des entrées et encodage des sorties

Les vulnérabilités par injection — SQL, commandes, LDAP, XPath et autres — surviennent lorsque des entrées non fiables sont interprétées comme du code. La validation des entrées garantit que les données respectent les types, longueurs et formats attendus avant d'être traitées, stockées ou renvoyées.

La validation par liste d'autorisation (liste blanche) définit ce qui est acceptable (IS) : uniquement les caractères alphanumériques, uniquement les entiers compris entre 1 et 100, uniquement les formats d'e-mail valides. La validation par liste de refus (liste noire) tente de bloquer les entrées malveillantes connues et est toujours incomplète. Préférez les listes d'autorisation.

La validation côté client améliore l'expérience utilisateur, mais n'offre aucune sécurité — les attaquants la contournent facilement à l'aide des outils de développement du navigateur ou de curl. Validez toujours côté serveur. La validation côté client est une commodité ; côté serveur, c'est le contrôle de sécurité.

Nombres : vérifiez le type et la plage. Chaînes : vérifiez la longueur et le jeu de caractères. Dates : analysez-les strictement et vérifiez la plage. Fichiers : vérifiez l'extension AND les octets magiques/le type MIME — ne faites jamais confiance à l'extension seule. URL : analysez et validez le schéma, l'hôte et les composants du chemin.

La conséquence la plus importante de la validation des entrées pour les bases de données est de ne jamais concaténer une entrée utilisateur dans SQL. Utilisez des requêtes paramétrées (instructions préparées), où l'entrée utilisateur est transmise comme paramètre et non interpolée dans la chaîne query.

Une même chaîne exige un encodage différent selon le contexte. Corps HTML : encodez en HTML (< > &). Attribut HTML : encodage des attributs HTML. JavaScript : échappement JS. Paramètre d'URL : encodage d'URL (encodage en pourcentage). L'utilisation d'un encodage incorrect laisse des failles que les attaquants peuvent exploiter.

N'insérez jamais directement des données utilisateur dans HTML. Utilisez un moteur ou une bibliothèque de modèles qui échappe automatiquement le HTML. Dans React, {value} est sûr ; dangerouslySetInnerHTML contourne l'échappement. Dans Django, les modèles échappent automatiquement le contenu, sauf si vous utilisez explicitement le filtre safe.

Lors de l'insertion de données dans JavaScript (par exemple, une variable initialisée avec des données utilisateur), l'encodage HTML est insuffisant. Utilisez l'encodage JSON : JSON.stringify(value). Cela empêche les données de sortir du contexte d'un littéral de chaîne JS.

Les données fournies par l'utilisateur et insérées dans des URL doivent être encodées en pourcentage à l'aide de encodeURIComponent() (JS) ou de urllib.parse.quote() (Python). Des données non encodées peuvent manipuler la structure de l'URL, ce qui entraîne des redirections ouvertes ou une traversée de chemin.

CSP ajoute une deuxième ligne de défense contre XSS. Une CSP stricte utilisant des valeurs nonce empêche l'exécution de scripts en ligne même si une charge utile XSS est injectée, car le navigateur refuse d'exécuter les scripts sans l'attribut nonce correct.

Le XSS fondé sur le DOM survient lorsque JavaScript lit des sources contrôlées par un attaquant (location.hash, document.URL, cookie) et écrit vers des puits dangereux (innerHTML, document.write, eval). Auditez tous les flux de données des API du navigateur vers les puits du DOM à l'aide d'outils d'analyse statique.

Pourquoi la validation des entrées côté serveur est-elle essentielle même lorsque la validation côté client est mise en œuvre ?

La validation des entrées (listes d'autorisation, vérification des types, limites de longueur), combinée à un encodage des sorties adapté au contexte (HTML, JS, URL, paramétrage SQL), constitue la principale défense contre les attaques par injection et les attaques XSS. Les deux doivent être appliquées côté serveur, sans exception.