Un premier aperçu de l'API HTML Sanitizer

Si vous avez déjà utilisé innerHTML pour afficher du contenu généré par les utilisateurs, vous avez accepté un certain niveau de risque XSS. La solution habituelle consiste à intégrer une bibliothèque comme DOMPurify pour nettoyer la chaîne au préalable. Cela fonctionne, mais cela implique de charger du JavaScript supplémentaire et de faire confiance à un tiers pour rester à jour avec l’évolution du comportement du parseur du navigateur. L’API HTML Sanitizer est la réponse du navigateur à ce problème—et il vaut la peine de la comprendre dès maintenant, même si elle n’est pas encore prête pour une utilisation en production partout.

Pourquoi innerHTML a toujours été un risque

innerHTML fait exactement ce que vous lui demandez : il analyse une chaîne et injecte le résultat dans le DOM, sans poser de questions. C’est pratique jusqu’à ce que quelqu’un transmette <img src=x onerror="stealCookies()"> comme commentaire ou nom d’utilisateur.

Des bibliothèques comme DOMPurify résolvent ce problème en analysant elles-mêmes la chaîne, en parcourant l’arbre DOM résultant et en supprimant tout ce qui est dangereux avant de vous le retourner. C’est efficace, mais fragile. Le comportement d’analyse du navigateur évolue avec le temps, et une bibliothèque qui vit dans l’espace utilisateur doit constamment suivre ces changements. Le navigateur lui-même, en revanche, sait toujours exactement comment il analysera et exécutera un morceau de balisage donné.

Ce que fournit l’API HTML Sanitizer

L’API HTML Sanitizer native déplace la désinfection dans le navigateur. Au lieu de définir innerHTML directement, vous utilisez de nouvelles méthodes qui analysent, désinfectent et injectent en une seule étape.

Les méthodes sécurisées sont celles que vous utiliserez le plus souvent :

• Element.setHTML()
• ShadowRoot.setHTML()
• Document.parseHTML()

Celles-ci suppriment toujours le contenu non sécurisé contre les XSS—balises <script>, attributs de gestionnaires d’événements comme onclick, URL javascript: dans les attributs de navigation—quelle que soit la configuration que vous transmettez. Sans aucune configuration, setHTML() est essentiellement un remplacement direct de innerHTML avec une protection XSS automatique :

const userContent = `<p>Hello!</p><script>alert('xss')<\/script>`;
document.getElementById("output").setHTML(userContent);
// Affiche : <p>Hello!</p>
// Le <script> est silencieusement supprimé

Les méthodes non sécurisées—setHTMLUnsafe(), ShadowRoot.setHTMLUnsafe() et Document.parseHTMLUnsafe()—vous donnent plus de contrôle. Elles appliquent uniquement la configuration de désinfection que vous fournissez, sans imposer la base de sécurité XSS. Utilisez-les uniquement lorsque vous avez une raison spécifique d’autoriser des éléments ou des attributs que les méthodes sécurisées bloqueraient, et uniquement avec une configuration soigneusement construite.

Configuration du Sanitizer

Les deux familles de méthodes acceptent une instance Sanitizer optionnelle ou un dictionnaire de configuration. Vous pouvez créer une configuration d’autorisation (spécifier exactement ce qui est autorisé, supprimer tout le reste) ou une configuration de suppression (spécifier ce qu’il faut supprimer, autoriser tout le reste).

Une configuration d’autorisation est généralement le choix le plus sûr :

const sanitizer = new Sanitizer({
  elements: ["p", "b", "em", "a"],
  attributes: ["href"]
});

document.getElementById("comments").setHTML(untrustedInput, { sanitizer });

La classe Sanitizer expose également des méthodes comme allowElement() et removeElement() pour modifier les configurations de manière programmatique tout en les maintenant cohérentes en interne.

Prise en charge par les navigateurs et que faire à ce sujet

Voici la situation honnête : début 2026, l’API HTML Sanitizer vient tout juste de commencer à être déployée dans les navigateurs. Firefox 148 a ajouté la prise en charge, et Chrome 146 a suivi, mais une disponibilité large entre navigateurs est encore en cours. Elle ne fait pas encore partie de la plateforme web Baseline, ce qui signifie que vous ne pouvez pas compter sur sa disponibilité pour tous vos utilisateurs aujourd’hui. Vous pouvez suivre la prise en charge actuelle sur Can I Use.

Pour le code de production, utilisez la détection de fonctionnalités et revenez à DOMPurify :

if (typeof Element.prototype.setHTML === "function") {
  element.setHTML(untrustedHTML);
} else {
  element.innerHTML = DOMPurify.sanitize(untrustedHTML);
}

Conclusion

L’API HTML Sanitizer représente exactement le type de chose que les standards des navigateurs devraient faire : prendre un modèle dangereux et largement mal géré et rendre le chemin sûr le plus facile. setHTML() versus innerHTML n’est pas vraiment un débat pour l’instant—la prise en charge par les navigateurs prend cette décision pour vous. Mais comprendre l’API maintenant signifie que vous serez prêt à l’adopter à mesure que la prise en charge s’élargira, et vous aurez une image plus claire de ce que la désinfection HTML native du navigateur est réellement conçue pour faire.

FAQ

Complete picture for complete understanding

Capture every clue your frontend is leaving so you can instantly get to the root cause of any issue with OpenReplay — the open-source session replay tool for developers. Self-host it in minutes, and have complete control over your customer data.

Check our GitHub repo and join the thousands of developers in our community.