Nox 
Lorsqu’on navigue sur Internet, chaque page web que nous visitons n’est pas seulement un ensemble de textes et d’images. En arrière-plan, elle repose sur une structure appelée DOM (Document Object Model). Le DOM est une représentation en arbre du contenu d’une page web : chaque élément (paragraphe, image, bouton, formulaire…) est un « nœud » que l’on peut manipuler.
Les développeurs utilisent JavaScript pour interagir avec ce DOM : ajouter un élément, modifier un texte, réagir à un clic de souris, etc. C’est ce qui rend les sites modernes dynamiques et interactifs. Mais cette souplesse a aussi un revers : si les données manipulées ne sont pas correctement contrôlées, elles peuvent être exploitées par un attaquant pour injecter du contenu malveillant directement dans le navigateur de la victime.
C’est là qu’interviennent les DOM Attacks, une forme particulière d’attaque basée sur la manipulation du DOM. Bien que proches des attaques XSS classiques, elles se distinguent par le fait qu’elles ne nécessitent pas forcément de passer par le serveur. L’attaque s’exécute directement côté client, dans le navigateur, rendant parfois leur détection et leur prévention plus délicates.
Qu’est-ce qu’un DOM Attack ?
Un DOM Attack, souvent appelé DOM-based XSS (Cross-Site Scripting), est une vulnérabilité qui se produit lorsque le code JavaScript d’une page web manipule le DOM à partir de données non sécurisées fournies par l’utilisateur.
Contrairement aux attaques XSS traditionnelles, où la charge malveillante transite par le serveur avant d’être renvoyée au navigateur, ici l’attaque se joue entièrement côté client. L’attaquant injecte du contenu dans l’application en profitant d’éléments comme :
- l’URL (via
document.locationoudocument.URL), - le hash ou les paramètres de requête (
window.location.hash,location.search), - le referrer (
document.referrer), - ou toute autre donnée manipulée directement par le JavaScript du site.
Si ces données sont réinjectées sans vérification dans le DOM (par exemple avec innerHTML), le navigateur exécute le script malveillant.
En résumé, un DOM Attack n’a pas besoin de modifier les fichiers du serveur : il exploite simplement la logique JavaScript existante et le comportement du navigateur. C’est ce qui le rend à la fois discret et redoutable.
Fonctionnement d’une attaque
Pour bien comprendre un DOM Attack, il faut imaginer le scénario du point de vue de l’attaquant. L’objectif est d’exploiter la manière dont une application web manipule les données côté client, afin d’injecter du code malveillant directement dans le navigateur de la victime.
1. Manipulation de l’entrée utilisateur
L’attaquant commence par identifier un point d’entrée vulnérable :
- une portion de l’URL (
document.location), - un paramètre GET (
location.search), - un fragment de l’URL (le hash
#...), - ou même l’
HTTP referrer.
Ces valeurs peuvent être contrôlées facilement en modifiant le lien que la victime va consulter.
2. Réinjection dans le DOM
Le problème survient quand le JavaScript de la page réutilise ces données sans les valider.
Exemple typique :
// Script vulnérable
var search = document.location.hash.substr(1);
document.getElementById("result").innerHTML = search;
Ici, le contenu de l’URL après # est directement injecté dans le DOM via innerHTML.
3. Exécution du code malveillant
Si l’attaquant envoie un lien comme :
http://site.com/page.html#<img src=x onerror=alert('Hacked!')>
Alors la victime, en cliquant sur ce lien, exécutera du JavaScript malveillant contenu dans le hash de l’URL.
Résultat : une fenêtre d’alerte s’affiche — simple démonstration — mais dans un vrai scénario, cela pourrait être :
- du vol de cookies,
- une redirection vers un site de phishing,
- l’injection d’un keylogger,
- ou l’exécution de tout autre script hostile.
4. Particularité : pas de trace côté serveur
Contrairement à d’autres attaques, ici aucune requête modifiée n’atteint le serveur. Tout se déroule dans le navigateur de la victime. Cela signifie que :
- les logs du serveur ne montrent rien de suspect,
- les systèmes de détection traditionnels (IDS/IPS) peuvent passer à côté,
- la vulnérabilité réside uniquement dans le code JavaScript exécuté côté client.
👉 Cette mécanique rend le DOM Attack particulièrement dangereux : il est invisible côté serveur, simple à exploiter, et souvent sous-estimé par les développeurs.
Conséquences possibles
Un DOM Attack peut sembler inoffensif lorsqu’on en fait une démonstration avec une simple fenêtre d’alerte. Mais dans la réalité, les impacts pour l’utilisateur — et pour le site vulnérable — peuvent être beaucoup plus graves. Voici quelques exemples concrets :
1. Vol de cookies et de sessions
L’attaquant peut injecter un script qui lit les cookies de session de la victime (s’ils ne sont pas marqués HttpOnly). Ces cookies sont ensuite envoyés vers un serveur contrôlé par l’attaquant. Avec ces informations, il peut se faire passer pour l’utilisateur et accéder à son compte (emails, réseaux sociaux, back-office d’entreprise…).
2. Redirections malveillantes
Un script injecté peut rediriger la victime vers un site frauduleux :
- une fausse page de connexion (phishing),
- un site diffusant des malwares,
- ou un clone du site légitime conçu pour récolter des informations sensibles.
3. Défiguration d’interface (Defacement)
Le contenu de la page peut être modifié en direct :
- affichage de messages trompeurs,
- remplacement d’images,
- injection de formulaires factices pour voler des données.
Cela peut nuire à la crédibilité du site victime.
4. Espionnage et enregistrement des actions
Un DOM Attack peut inclure un keylogger JavaScript, capable d’enregistrer les frappes clavier de l’utilisateur : identifiants, mots de passe, messages, numéros de carte bancaire… Tout est envoyé en temps réel à l’attaquant.
5. Portail vers d’autres attaques
Une fois que le script malveillant est exécuté dans le navigateur, l’attaquant a une grande liberté d’action :
- scanner les failles côté client,
- exploiter d’autres vulnérabilités JavaScript,
- ou utiliser l’attaque comme point de départ pour une compromission plus large.
👉 En résumé : le DOM Attack transforme le navigateur de la victime en porte d’entrée contrôlée par l’attaquant. C’est un outil polyvalent qui peut aller du simple canular jusqu’au vol massif de données sensibles.
Anecdotes et cas réels
Les DOM Attacks ne sont pas qu’un risque théorique : de nombreuses applications web, y compris parmi les plus populaires, ont déjà été victimes de vulnérabilités de type DOM-based XSS.
1. Gmail (Google)
En 2005, une faille de type DOM XSS avait été découverte dans Gmail.
- L’attaque exploitait la manière dont Gmail affichait certaines données depuis l’URL.
- En injectant du code JavaScript dans le navigateur de la victime, un attaquant pouvait détourner la session Gmail et accéder aux emails.
- Ce type de vulnérabilité avait mis en lumière la nécessité pour Google de renforcer sa politique de sécurité côté client.
2. Facebook
Facebook a connu plusieurs vulnérabilités DOM XSS au fil des années, signalées notamment via son bug bounty program :
- Certaines failles permettaient d’injecter du code malveillant directement via les paramètres de l’URL.
- Conséquence possible : vol de tokens d’accès, utilisation frauduleuse de comptes, diffusion de liens malveillants dans Messenger ou sur le mur des victimes.
- Heureusement, ces vulnérabilités ont été corrigées rapidement, mais elles illustrent bien que même les géants du web ne sont pas à l’abri.
3. PayPal
Une autre plateforme emblématique, PayPal, a également fait l’objet de rapports de vulnérabilités DOM XSS.
- L’attaque consistait à injecter du JavaScript via des paramètres de redirection non sécurisés.
- En cas d’exploitation, cela permettait de détourner des sessions financières, rendant le scénario particulièrement critique.
4. GitHub (2019)
En 2019, un chercheur en sécurité a signalé une faille DOM XSS sur GitHub.
- Elle reposait sur la manipulation de l’URL utilisée par certaines pages.
- Exploitée, elle pouvait permettre à un attaquant de charger un script malveillant directement dans l’interface GitHub de la victime.
- Bien que GitHub ait réagi très vite, l’incident a montré que même une plateforme orientée développeurs peut laisser échapper ce type de faille.
5. Autres cas marquants
- Plusieurs CMS (WordPress, Joomla, Drupal) ont déjà publié des correctifs pour des plugins vulnérables aux DOM Attacks.
- Des frameworks front-end mal configurés (AngularJS, React mal utilisés, jQuery avant ses versions corrigées) ont aussi été à l’origine de failles similaires.
👉 Ces exemples démontrent que le DOM Attack est une menace réelle, persistante et non limitée aux « petits sites ». Les plus grandes entreprises du web y ont déjà été confrontées, et les chercheurs en sécurité continuent régulièrement d’en trouver de nouvelles.
Prévention et bonnes pratiques
La meilleure défense contre un DOM Attack repose sur une combinaison de bonnes pratiques de développement et de mesures de sécurité côté navigateur. Voici les points essentiels :
1. Valider et assainir les entrées utilisateur
- Jamais faire confiance aux données issues de l’utilisateur : URL, hash, referrer, paramètres GET/POST.
- Nettoyer et filtrer les entrées avant toute utilisation dans le DOM.
- Utiliser des fonctions ou des librairies de sanitization (comme DOMPurify en JavaScript).
2. Éviter l’utilisation de innerHTML
innerHTMLinsère directement du code interprété comme du HTML/JavaScript, ce qui ouvre la porte aux injections.- Préférer :
textContent(ajoute uniquement du texte, sans interprétation),setAttributepour les attributs d’éléments,- ou encore les API modernes du DOM (
createElement,appendChild).
Exemple :
// Mauvaise pratique
element.innerHTML = userInput;
// Bonne pratique
element.textContent = userInput;
3. Mettre en place une Content Security Policy (CSP)
- La CSP est une couche de sécurité qui limite ce que le navigateur est autorisé à exécuter.
- Exemple : interdire l’exécution de scripts inline ou non autorisés.
- Une politique CSP bien configurée peut bloquer de nombreux scénarios de DOM XSS.
4. Utiliser des frameworks modernes avec précaution
- Des frameworks comme React, Angular ou Vue protègent par défaut contre beaucoup d’injections, car ils échappent automatiquement le contenu.
- Mais attention : si on force l’insertion avec des fonctions comme
dangerouslySetInnerHTML(React) oubypassSecurityTrustHtml(Angular), on réintroduit le risque.
5. Auditer et tester régulièrement le code
- Mettre en place des tests de sécurité automatisés (linting, analyse statique).
- Recourir à des outils comme Burp Suite, OWASP ZAP ou des scanners spécialisés pour détecter les DOM XSS.
- Faire appel à des bug bounty ou à des pentests réguliers pour repérer les failles avant les attaquants.
6. Sensibiliser les développeurs
- Beaucoup de DOM Attacks naissent d’une méconnaissance des risques liés aux manipulations du DOM.
- Former les équipes de développement et intégrer la sécurité dès la conception (DevSecOps).
👉 En appliquant ces bonnes pratiques, on réduit drastiquement les risques liés aux DOM Attacks. Comme toujours en cybersécurité, la vigilance continue et l’hygiène de code sont les meilleures armes.
Conclusion
Les DOM Attacks représentent une menace discrète mais redoutable. Contrairement aux failles XSS classiques, elles n’impliquent pas nécessairement le serveur et échappent souvent aux systèmes de détection traditionnels. Tout se joue dans le navigateur, à travers le code JavaScript et la manière dont il manipule le DOM.
Comme nous l’avons vu, les conséquences peuvent être graves : vol de sessions, phishing, espionnage des utilisateurs, ou encore défigurations de pages. Même les géants du web — Google, Facebook, PayPal, GitHub — ont déjà été confrontés à de telles vulnérabilités.
La prévention repose sur une règle d’or : ne jamais faire confiance aux données manipulées côté client. En combinant validation stricte, usage de fonctions sûres (textContent, setAttribute), mise en place de Content Security Policy, et bonnes pratiques de développement, il est possible de réduire fortement ce risque.
En fin de compte, le DOM Attack rappelle une vérité fondamentale de la cybersécurité : chaque couche d’une application, qu’elle soit côté serveur ou côté client, peut devenir une surface d’attaque. Seule une approche globale, continue et consciente de ces risques permet de construire des applications web à la fois performantes et sécurisées.
À propos de l'auteur
