XSS via innerHTML e como evitá-lo

Definir el.innerHTML = userInput analisa a string como HTML. Se userInput contiver tags <script> ou atributos de manipuladores de eventos (onclick, onerror), o navegador os interpreta — executando código controlado pelo invasor na página.

Qualquer código que insira dados do usuário em HTML — modelos no servidor, renderização no cliente — corre risco de XSS se os dados não forem escapados. Aplicativos de página única que constroem innerHTML a partir de respostas de APIs ficam especialmente expostos quando essas respostas incluem conteúdo do usuário.

Um nome de usuário "Bob<img src=x onerror=alert(1)>" definido por meio de div.innerHTML = `Welcome, ${user}` executa alert(1) quando a imagem não consegue ser carregada. A mesma carga útil como texto simples (via textContent) é inofensiva — o navegador vê apenas caracteres, não tags.

textContent define somente texto — os caracteres especiais de HTML aparecem como caracteres literais, nunca como tags. Essa é a ferramenta certa em 90% dos casos. Use innerHTML somente quando realmente precisar renderizar marcação, não texto.

Para criar elementos com dados do usuário, construa-os com createElement e textContent: const li = document.createElement("li"); li.textContent = name; ul.appendChild(li);. O resultado é estruturalmente idêntico ao innerHTML, mas seguro contra XSS por construção.

Para HTML confiável gerado pelo servidor (saída do seu próprio modelo, texto rico higienizado de um editor confiável), innerHTML é adequado. Nunca o aplique diretamente a dados de fontes não confiáveis sem sanitização.

Se os usuários enviarem texto rico (um editor de comentários, renderização de markdown), higienize-o antes de definir innerHTML: el.innerHTML = DOMPurify.sanitize(richHtml). DOMPurify remove tags e atributos perigosos, mantendo formatação segura como <b>, <em> e <a>.

el.insertAdjacentHTML("beforeend", html) analisa strings HTML — a mesma superfície de XSS que innerHTML. As mesmas regras se aplicam: nunca forneça dados do usuário diretamente; higienize-os ou use métodos do DOM. O mesmo vale para document.write, embora ninguém deva mais usá-lo.

React, Vue, Svelte e Angular escapam texto interpolado por padrão — {name} é seguro. Eles oferecem mecanismos para contornar esse escape (dangerouslySetInnerHTML no React, v-html no Vue), que apresentam o mesmo risco de XSS; use-os com moderação e sanitização.

Até os valores de atributos podem ser vetores: <a href={url}> com url="javascript:alert(1)" executa o código quando recebe um clique. Valide os endereços por esquema (permita apenas http:, https:, mailto: e tel:) antes de inserir a entrada do usuário em href, src ou outros atributos que contenham endereços.

Os navegadores modernos oferecem suporte a Trusted Types: configure a CSP com require-trusted-types-for 'script' e innerHTML recusará strings brutas — somente valores encapsulados por uma política serão aceitos. Isso torna o XSS impossível por meio da API, e não da disciplina.

Nenhuma camada isolada é suficiente. Combine: validação da entrada no servidor, escape da saída durante a renderização, CSP para bloquear scripts injetados, Tipos Confiáveis para rejeitar cadeias de caracteres brutas e revisão de segurança de qualquer uso de innerHTML. A defesa em camadas continua eficaz mesmo quando há um erro em qualquer camada.

Por que el.textContent = userInput é seguro contra XSS, enquanto el.innerHTML = userInput é perigoso?

innerHTML em entradas fornecidas pelo usuário é o vetor clássico de XSS. Use textContent para texto, createElement+textContent para estrutura e DOMPurify quando for necessário HTML avançado. Valide os esquemas de URL dos valores de atributos. Combine CSP e Tipos Confiáveis para neutralizar erros que escapem à revisão do código. As plataformas modernas fazem o escape por padrão — mantenha raros os atalhos inseguros e revise-os.