XSS Moderne: DOM, Stored et Reflected avec Exemples Reels en Environnement de Test

Le rapport HackerOne 2025 classe le XSS comme le deuxieme bug le plus signale en bug bounty public, avec une mediane de 750 USD par decouverte et des pics a 20 000 USD sur des cibles entreprise. La famille survit parce que les navigateurs evoluent alors que les pipelines frontend continuent de concatener des chaines dans innerHTML sans ceremonie. L'equipe Basilisk monte un lab avec trois applications volontairement faillibles, capture chaque requete dans Burp Suite Community 2026.4 et detaille chaque vecteur avec payload, contexte et correctif. Avant de copier le moindre payload, verifie que ton lab est isole comme decrit dans Pentest Web depuis Zero: Construire un Lab Sur avec DVWA, Juice Shop et Burp Suite, car tirer des scripts sur des tiers sans autorisation ecrite reste un delit sous la LCEN et l'article 323-1 du Code penal francais.

Le Reflected XSS apparait quand l'entree utilisateur revient dans la reponse HTTP sans encodage adapte, generalement via querystring ou formulaire GET. Dans notre lab une recherche sur /search?q= injecte le terme dans un

, donc le classique

Le Stored XSS reste le plus dangereux car il persiste en base et touche tout visiteur futur. Sur DVWA on regle le niveau medium, on poste dans le champ commentaire le payload et le webhook collecte des sessions de moderateurs en quelques secondes. En production la surface inclut les rendus Markdown, les modeles d'email transactionnel, les exports CSV ouverts dans Excel et meme les metadonnees EXIF lues par un dashboard interne, comme detaille dans Hygiene des Metadonnees : Nettoyer EXIF, PDF et Office avant Publication. La defense solide combine sanitisation en entree et escape en sortie, jamais un seul des deux.

Le DOM-based XSS se produit entierement dans le navigateur, sans que le payload touche le serveur. Le classique location.hash injecte dans document.write existe toujours dans les widgets de chat legacy et dans les SPAs React qui passent le hash a dangerouslySetInnerHTML. On adapte le challenge niveau 1 du Google XSS Game dans le lab et on montre la chasse aux sinks en ouvrant DevTools, en activant 'Pause on exceptions' et en lancant l'extension DOM Invader de Burp. Le flux de triage reprend la methodo de SQL Injection en Pratique: Exploiter, Detecter et Mitiger dans un Lab Controle: identifier la source, tracer jusqu'au sink, valider avec un payload minimal.

La mitigation moderne ne consiste plus a filtrer les chevrons. Content Security Policy niveau 3 avec nonce par requete bloque l'injection inline meme quand l'attaquant arrive a glisser du HTML dans la page, a condition de ne jamais retomber sur 'unsafe-inline' comme repli. Trusted Types, supporte sur Chromium depuis 83 et enfin sur Firefox 135, transforme les affectations a innerHTML en erreur de type sauf passage par une policy enregistree. Couple a DOMPurify 3.2 pour du HTML riche, Google mesure environ 90% de surface en moins. Branche ca dans la CI selon AppSec Shift-Left: SAST, SCA et Secrets Scanning sans Bloquer l Equipe en lancant Semgrep avec la regle javascript.lang.security.audit.xss a chaque PR.

Takeaway pratique: monte aujourd'hui un lab avec DVWA, Juice Shop et un Next.js depouille, reproduis les trois vecteurs jusqu'a sortir un popup sur chacun, puis ajoute CSP a nonce, Trusted Types et DOMPurify et rejoue exactement les memes payloads. Tout ce qui tire encore merite un ajustement de policy jusqu'a casser le tir. Conserve chaque iteration dans un runbook personnel car les bons rapports XSS sur YesWeHack, HackerOne ou le programme Shopify exigent une reproduction en une phrase, un impact prouve et un patch suggere. Lis aussi Threat Modeling STRIDE en Sprints : Exemple Complet sur un Microservice pour classer chaque injection dans Tampering et Elevation avant de pousser le ticket, ce reflexe bascule le triage en P1 plus vite.