Aller au contenu principal
Expert Cybersécurité & IAv9.0
Centres de ressources conformité
Besoin d'un accompagnement expert ?
Devis personnalisé sous 24h — audit, conformité, incident
Checklists Sécurité — Audit & Durcissement
Formats disponibles
📄 PDF 📊 Excel 🌐 Web

11 checklists professionnelles couvrant 2 200+ points de contrôle. Téléchargement gratuit, aucune inscription.

DOM XSS

hacking

Définition

Le DOM XSS est une variante de cross-site scripting où le code malveillant s'exécute exclusivement côté client, via manipulation du Document Object Model, sans que la charge utile transite jamais par le serveur. Contrairement au XSS réfléchi ou stocké, la vulnérabilité réside dans du JavaScript qui lit une source contrôlable par l'attaquant (location.hash, document.URL, postMessage, paramètres d'URL) et l'injecte dans un puits dangereux (innerHTML, document.write, eval, jQuery .html()) sans assainissement. Le serveur ne voit jamais le payload complet si celui-ci est placé après un fragment d'URL (#), ce qui rend les filtres et WAF côté serveur totalement inopérants. L'attaque est référencée MITRE sous CWE-79 et classée dans l'OWASP Top 10 (A03:2021 Injection). Les frameworks modernes (React, Angular, Vue) réduisent le risque via l'échappement automatique, mais l'usage de dangerouslySetInnerHTML, innerHTML natif ou de bibliothèques tierces mal configurées réintroduit la faille. La détection passe par l'analyse statique du flux source-puits (SAST, outils comme DOMPurify pour la remédiation) plutôt que par des tests boîte noire classiques, car l'exploitation dépend entièrement de la logique JavaScript côté navigateur. Un pentester doit tracer manuellement les sinks avec Burp Suite DOM Invader ou des extensions dédiées. La correction repose sur l'échappement contextuel systématique et l'usage de Content Security Policy avec nonce pour limiter l'exécution de scripts inline.

Description

Le DOM XSS est une variante de Cross-Site Scripting où le payload malveillant s'exécute entièrement côté client via la manipulation du DOM, sans jamais transiter par le serveur. Il échappe donc aux filtres côté serveur et aux IDS analysant le trafic HTTP.

Exploitation

Des sources dangereuses comme document.location ou window.name alimentent des sinks dangereux comme innerHTML, eval() ou document.write(). L'attaquant injecte du JavaScript exécuté dans le contexte de la page via des paramètres d'URL ou des fragments (#).

Défense

  • Utiliser textContent au lieu de innerHTML pour insérer du contenu utilisateur dans le DOM
  • Éviter l'utilisation de sinks dangereux avec des données non fiables (eval, document.write)
  • Déployer une Content Security Policy (CSP) stricte pour limiter l'exécution de scripts non autorisés

Articles liés

Un projet cybersécurité ?

Expert dispo · Réponse 24h

Devis