Comment empêcher le XSS ?

Le XSS survient quand des données non fiables sont interprétées comme du code par le navigateur. Toute la stratégie de prévention découle d'un principe : garder les données comme des données. Le navigateur change constamment de contexte d'analyse — HTML, attributs, JavaScript, CSS, URL — et chaque contexte a des caractères différents qui permettent d'en sortir. Le correctif n'est donc pas une fonction magique ; c'est faire le bon encodage au bon endroit.

Encodage de sortie contextuel (le contrôle principal)

Encodez les valeurs non fiables au point de sortie, pour le contexte spécifique :

• Corps HTML → encoder en entités HTML (< devient <).
• Attribut HTML → encoder pour attribut et toujours mettre l'attribut entre guillemets.
• À l'intérieur d'un <script> / d'une chaîne JS → encoder pour JavaScript (échappements Unicode).
• Paramètre d'URL → encoder pour URL.

Les frameworks modernes (React, Angular, Vue) auto-échappent par défaut, ce qui explique pourquoi le XSS n'apparaît souvent que là où les développeurs recourent à des échappatoires comme dangerouslySetInnerHTML ou v-html.

API DOM sûres

Pour le rendu côté client, préférez textContent, setAttribute et createElement à innerHTML, document.write et eval. Lorsque vous devez réellement rendre du HTML riche, faites-le passer par un assainisseur éprouvé comme DOMPurify plutôt que d'en écrire un vous-même.

Validation des entrées — utile, pas suffisante

Validez et rejetez les entrées manifestement mauvaises (listes d'autorisation, longueur, type) à la frontière. Mais la validation seule ne peut pas arrêter le XSS, car des données légitimes (un nom contenant un <) doivent quand même être encodées à la sortie.

Content-Security-Policy comme rempart

Une CSP stricte basée sur un nonce ou un hachage qui interdit le script en ligne et eval fait que même si une charge utile passe au travers, le navigateur refuse de l'exécuter. C'est de la défense en profondeur, pas un contrôle principal.

Les recruteurs veulent entendre d'abord « encodage de sortie contextuel », la compréhension que la validation ne suffit pas, et la CSP présentée comme un rempart — ainsi qu'une API sûre ou un assainisseur nommé.