XSS no React: dangerouslySetInnerHTML e scripts de terceiros

O React escapa automaticamente todos os valores renderizados por JSX antes de inseri-los no DOM. Quando você escreve {userInput} em JSX, o React faz o equivalente a atribuir um valor a textContent — o valor é tratado como texto, nunca como HTML. Por padrão, isso impede a maioria dos ataques XSS em aplicações React.

dangerouslySetInnerHTML={{ __html: htmlString }} é o recurso de exceção do React que ignora o escape automático. O nome é intencionalmente alarmante: ele informa que você está assumindo a responsabilidade pela segurança da string HTML. O React define innerHTML diretamente, executando qualquer HTML, incluindo scripts e manipuladores de eventos.

Você realmente precisa de dangerouslySetInnerHTML ao renderizar HTML proveniente de um editor de texto formatado, como TipTap ou Quill, de um CMS que armazena HTML ou de um conversor de Markdown para HTML. Essas fontes produzem marcação HTML real, que precisa ser renderizada como HTML, e não como texto escapado.

Se a string HTML contiver <script>stealCookies()</script> ou <img src=x onerror="stealData()">, defini-la como innerHTML executará o código do atacante. Qualquer conteúdo fornecido pelo usuário que seja passado diretamente para dangerouslySetInnerHTML sem sanitização é uma vulnerabilidade XSS crítica.

DOMPurify é o sanitizador de HTML padrão do setor para navegadores. Ele analisa a string HTML em um contexto isolado, remove elementos e atributos perigosos (tags de script, manipuladores de eventos e URLs javascript:) e retorna uma string HTML segura. Uso: DOMPurify.sanitize(dirtyHtml) antes de passá-la para dangerouslySetInnerHTML.

Scripts de terceiros (análises, widgets de bate-papo e redes de anúncios) são executados com as mesmas permissões que o JavaScript da sua aplicação. Um script de terceiros comprometido ou malicioso pode ler document.cookie, acessar localStorage, ler campos de formulários e fazer solicitações a servidores externos — tudo isso sem qualquer indicação para o usuário.

A Política de Segurança de Conteúdo é um cabeçalho HTTP que declara quais scripts têm permissão para ser executados. Mesmo que uma carga XSS seja injetada no DOM, uma CSP configurada corretamente pode bloquear sua execução, restringindo scripts embutidos e permitindo somente origens de scripts autorizadas. A CSP é a segunda linha de defesa depois da sanitização da entrada.

Os pacotes npm são um vetor real de ataques XSS. Uma dependência pode incluir código malicioso que extrai variáveis de ambiente ou dados do usuário. O incidente de node-ipc em 2022 e o comprometimento de ua-parser-js em 2021 demonstraram que pacotes amplamente utilizados podem ser assumidos e adulterados. Audite as dependências com npm audit e use arquivos de bloqueio.

Um ataque XSS bem-sucedido permite que um atacante roube o token JWT do usuário em sessionStorage (enviando-o a um servidor controlado pelo atacante), execute ações como o usuário autenticado (chamadas de API usando a sessão do usuário), modifique o DOM para exibir conteúdo de phishing ou registre cada tecla pressionada pelo usuário na aplicação.

A API Trusted Types do navegador exige que todos os destinos do DOM (innerHTML, eval, script.src) recebam objetos tipados especiais em vez de strings brutas. Isso impede que cargas XSS baseadas em strings cheguem ao DOM no nível da plataforma. O React está avançando rumo à compatibilidade com Trusted Types, e a CSP pode impor seu uso.

O padrão seguro para renderizar HTML de um CMS é: buscar o HTML, passá-lo por DOMPurify.sanitize() com uma lista de permissões de tags e atributos seguros e, em seguida, renderizá-lo com dangerouslySetInnerHTML={{ __html: cleanHtml }}. Nunca ignore a etapa de sanitização, mesmo que você confie no CMS, pois o próprio banco de dados do CMS pode ser comprometido.

O que o DOMPurify faz quando você chama DOMPurify.sanitize(htmlString)?

O React escapa automaticamente os valores de JSX, impedindo a maioria dos ataques XSS. dangerouslySetInnerHTML ignora essa proteção para permitir a renderização legítima de HTML — sempre sanitize a entrada primeiro com DOMPurify. Scripts de terceiros e pacotes npm comprometidos são vetores de XSS na cadeia de suprimentos. A Política de Segurança de Conteúdo fornece uma segunda camada de defesa. Um ataque XSS bem-sucedido permite roubo de tokens, personificação e phishing.