Uma Primeira Olhada na API HTML Sanitizer

Se você já usou innerHTML para renderizar conteúdo gerado por usuários, aceitou algum nível de risco de XSS. A solução usual é incorporar uma biblioteca como DOMPurify para sanitizar a string primeiro. Isso funciona, mas significa enviar JavaScript extra e confiar em terceiros para se manterem à frente do comportamento evolutivo do parser do navegador. A API HTML Sanitizer é a resposta do navegador para este problema—e vale a pena entendê-la agora, mesmo que ainda não esteja pronta para uso em produção em todos os lugares.

Por Que innerHTML Sempre Foi um Risco

innerHTML faz exatamente o que você pede: analisa uma string e injeta o resultado no DOM, sem fazer perguntas. Isso é conveniente até que alguém passe <img src=x onerror="stealCookies()"> como um comentário ou nome de usuário.

Bibliotecas como DOMPurify resolvem isso analisando a string por conta própria, percorrendo a árvore DOM resultante e removendo qualquer coisa perigosa antes de devolvê-la a você. É eficaz, mas frágil. O comportamento de análise do navegador muda ao longo do tempo, e uma biblioteca que vive no espaço do usuário tem que constantemente perseguir essas mudanças. O próprio navegador, por outro lado, sempre sabe exatamente como irá analisar e executar um determinado pedaço de marcação.

O Que a API HTML Sanitizer Fornece

A API HTML Sanitizer nativa move a sanitização para dentro do navegador. Em vez de definir innerHTML diretamente, você usa novos métodos que analisam, sanitizam e injetam em uma única etapa.

Os métodos seguros são aqueles que você usará com mais frequência:

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

Estes sempre removem conteúdo inseguro contra XSS—tags <script>, atributos manipuladores de eventos como onclick, URLs javascript: em atributos de navegação—independentemente da configuração que você passar. Sem nenhuma configuração, setHTML() é essencialmente um substituto direto para innerHTML com proteção automática contra XSS:

const userContent = `<p>Hello!</p><script>alert('xss')<\/script>`;
document.getElementById("output").setHTML(userContent);
// Renderiza: <p>Hello!</p>
// O <script> é silenciosamente removido

Os métodos inseguros—setHTMLUnsafe(), ShadowRoot.setHTMLUnsafe() e Document.parseHTMLUnsafe()—oferecem mais controle. Eles aplicam apenas a configuração do sanitizador que você fornecer, sem impor a linha de base segura contra XSS. Use-os apenas quando tiver uma razão específica para permitir elementos ou atributos que os métodos seguros bloqueariam, e apenas com uma configuração cuidadosamente construída.

Configurando o Sanitizer

Ambas as famílias de métodos aceitam uma instância opcional de Sanitizer ou um dicionário de configuração. Você pode construir uma configuração de permissão (especificar exatamente o que é permitido, descartar todo o resto) ou uma configuração de remoção (especificar o que remover, permitir todo o resto).

Uma configuração de permissão é geralmente a escolha mais segura:

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

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

A classe Sanitizer também expõe métodos como allowElement() e removeElement() para modificar configurações programaticamente mantendo-as internamente consistentes.

Suporte dos Navegadores e O Que Fazer a Respeito

Aqui está o panorama honesto: no início de 2026, a API HTML Sanitizer apenas começou a ser implementada nos navegadores. O Firefox 148 adicionou suporte, e o Chrome 146 seguiu, mas a disponibilidade ampla entre navegadores ainda está se consolidando. Ainda não faz parte da plataforma web Baseline, o que significa que você não pode confiar que estará disponível para todos os seus usuários hoje. Você pode acompanhar o suporte atual no Can I Use.

Para código de produção, use detecção de recursos e recorra ao DOMPurify como alternativa:

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

Conclusão

A API HTML Sanitizer representa exatamente o tipo de coisa que os padrões dos navegadores deveriam fazer: pegar um padrão perigoso e amplamente mal gerenciado e tornar o caminho seguro o caminho fácil. setHTML() versus innerHTML ainda não é realmente um debate—o suporte dos navegadores toma essa decisão por você. Mas entender a API agora significa que você estará pronto para adotá-la à medida que o suporte se amplia, e terá uma visão mais clara do que a sanitização HTML nativa do navegador foi realmente projetada para fazer.

Perguntas Frequentes

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.