Un CMS fournit un paragraphe avec des liens et une mise en forme. Le frontend l’affiche, jusqu’au jour où ce champ contient aussi du code que le navigateur pourrait exécuter. La Sanitizer API de Chrome 146 facilite un rendu plus sûr. Mais pourquoi interpréter cette information comme du HTML ?
Le risque commence lors de l’insertion
Avec du contenu non fiable, innerHTML peut introduire une vulnérabilité XSS. Le problème ne vient pas de l’API qui transmet les données, mais de leur interprétation comme HTML actif. Pour un titre, un libellé ou un message, textContent traite la valeur comme du texte.
container.innerHTML = cmsContent;
container.textContent = userInput;Quand le formatage est nécessaire
Un article peut exiger des paragraphes, des liens et des listes. Element.setHTML() analyse le contenu et supprime les constructions considérées comme dangereuses pour les XSS. Chrome a annoncé cette API en mars 2026 et mentionné également Firefox. L’exemple repose sur la documentation et n’a pas été exécuté dans plusieurs navigateurs.
const container = document.querySelector('#article');
const cmsContent = `<p>Hello</p><img src="x" onerror="alert('XSS')">`;
container.setHTML(cmsContent);Une API native ne remplace pas une politique de contenu
Distinguez les champs de texte brut des contenus enrichis. Un composant label ne devrait pas interpréter du HTML arbitraire ; un composant de contenu riche peut appliquer une politique documentée. Examinez aussi les aperçus, extensions et outils d’administration.
Prévoir les navigateurs sans setHTML
MDN indique une disponibilité limitée. Détectez la méthode sur les navigateurs et webviews visés. Si elle manque, utilisez un outil de nettoyage maintenu et correctement configuré. Ne revenez jamais à innerHTML sans filtrage.
if ('setHTML' in Element.prototype) {
container.setHTML(cmsContent);
} else {
// Use a reviewed, safely configured sanitizer fallback.
}Tester les attaques et les contenus légitimes
Vérifiez les attributs d’événement, les balises imprévues et les protocoles dangereux, mais aussi les liens, les listes et les tableaux autorisés. Testez l’accessibilité. Content Security Policy, l’encodage adapté au contexte et Trusted Types constituent des protections complémentaires.
Le gain principal vient souvent de la réduction des endroits où le système interprète du HTML non fiable. Limitez ces points d’insertion et protégez les autres de manière cohérente.
Sources
Contactez-nous
Dites-nous comment nous pouvons vous aider ; nous répondons sous deux jours ouvrés.
