XSS via `innerHTML` et prévention

La définition el.innerHTML = userInput analyse la chaîne comme du HTML. Si userInput contient des balises <script> ou des attributs gestionnaires d'événements (onclick, onerror), le navigateur les interprète et exécute le code contrôlé par l'attaquant sur la page.

Tout code qui insère des données utilisateur dans du HTML — modèles côté serveur ou rendu côté client — présente un risque XSS si les données ne sont pas échappées. Les applications monopages qui construisent innerHTML à partir de réponses d'API sont particulièrement exposées lorsque ces réponses contiennent du contenu utilisateur.

Un nom d'utilisateur "Bob<img src=x onerror=alert(1)>" défini via div.innerHTML = `Welcome, ${user}` exécute alert(1) lorsque le chargement de l'image échoue. La même valeur utile sous forme de texte brut (via textContent) est inoffensive : le navigateur ne voit que des caractères, pas des balises.

textContent ne définit que du texte : les caractères spéciaux HTML apparaissent comme des caractères littéraux, jamais comme des balises. C'est l'outil adapté dans 90 % des cas. N'utilisez innerHTML que lorsque vous devez réellement afficher du balisage, et non du texte.

Pour créer des éléments contenant des données utilisateur, construisez-les avec createElement et textContent : const li = document.createElement("li"); li.textContent = name; ul.appendChild(li);. Le résultat est structurellement identique à innerHTML, mais sa conception le rend sûr contre XSS.

Pour du HTML fiable généré par le serveur (la sortie de vos propres modèles ou du texte enrichi nettoyé provenant d'un éditeur fiable), innerHTML convient. Ne l'appliquez jamais directement à des données provenant de sources non fiables sans les assainir.

Si les utilisateurs envoient du texte enrichi (éditeur de commentaires ou rendu Markdown), nettoyez-le avant de définir innerHTML : el.innerHTML = DOMPurify.sanitize(richHtml). DOMPurify supprime les balises et attributs dangereux tout en conservant les mises en forme sûres comme <b>, <em> et <a>.

el.insertAdjacentHTML("beforeend", html) analyse les chaînes HTML : la même surface d'attaque XSS qu'avec innerHTML. Les mêmes règles s'appliquent : ne transmettez jamais directement des données utilisateur ; nettoyez-les ou utilisez les méthodes DOM. Il en va de même pour document.write, même si plus personne ne devrait l'utiliser aujourd'hui.

React, Vue, Svelte et Angular échappent par défaut le texte interpolé : {name} est sûr. Ils proposent des mécanismes de contournement (dangerouslySetInnerHTML dans React et v-html dans Vue) qui présentent le même risque XSS ; utilisez-les avec parcimonie et après nettoyage.

Même les valeurs d'attributs peuvent servir de vecteurs : <a href={url}> avec url="javascript:alert(1)" exécute le code lors du clic. Validez les URL schéma par schéma (n'autorisez que http:, https:, mailto: et tel:) avant de placer une entrée utilisateur dans href, src ou tout autre attribut contenant une URL.

Les navigateurs modernes prennent en charge Trusted Types : configurez CSP avec require-trusted-types-for 'script' et innerHTML refusera les chaînes brutes ; seules les valeurs enveloppées par une politique seront acceptées. Cela rend les attaques XSS impossibles grâce à l'API plutôt qu'à la seule discipline des développeurs.

Aucune couche unique ne suffit. Combinez la validation des entrées sur le serveur, l’échappement des sorties lors du rendu, CSP pour bloquer les scripts injectés, les types de confiance pour refuser les chaînes brutes et un audit de sécurité pour toute utilisation de innerHTML. Une défense en couches résiste à une erreur présente dans n’importe quelle couche.

Pourquoi el.textContent = userInput est-il sûr contre XSS, tandis que el.innerHTML = userInput est-il dangereux ?

innerHTML appliqué à une entrée utilisateur est le vecteur XSS classique. Utilisez textContent pour le texte, createElement+textContent pour la structure et DOMPurify lorsqu’un HTML riche est nécessaire. Validez les schémas d’URL pour les valeurs d’attributs. Ajoutez CSP et les types de confiance pour neutraliser les erreurs qui échappent à la revue du code. Les frameworks modernes échappent les valeurs par défaut : gardez leurs mécanismes de contournement non sûrs rares et soumis à une revue.