XSS em aplicações React: onde o React não te protege

Uma das grandes vantagens do React é proteger contra XSS por padrão: tudo que você coloca entre chaves vira texto, não HTML. Isso leva muita gente a acreditar que aplicações React são imunes. Não são.

Brecha 1: dangerouslySetInnerHTML

O nome já avisa. Renderizar HTML vindo do usuário ou de um CMS sem sanitizar permite injetar scripts. Se precisar renderizar HTML, passe por uma biblioteca de sanitização como o DOMPurify antes.

Brecha 2: links com javascript:

<a href={usuario.site}>Site</a>

Se site for javascript:alert(document.cookie), o clique executa código. Valide que URLs começam com https:// — validação na entrada, como em Validação rigorosa de dados: prevenindo falhas de segurança e dados inconsistentes com Zod e TypeScript.

Brecha 3: dados injetados em scripts

Estado inicial serializado em <script> sem escapar < permite fechar a tag e abrir outra. Escape ao serializar.

Brecha 4: bibliotecas de terceiros

Editores de texto rico, renderizadores de markdown e widgets podem ter vulnerabilidades próprias. Mantenha dependências atualizadas (Dependências vulneráveis: npm audit e além).

Defesa em profundidade

• Content Security Policy: mesmo que um script seja injetado, a CSP impede que ele execute ou envie dados para fora (Headers de segurança HTTP: CSP, HSTS e companhia).
• Cookies de sessão `HttpOnly`: um script injetado não consegue lê-los (CSRF e cookies SameSite: o que mudou e o que ainda importa).
• Sanitize no servidor o que vai ser armazenado (Sanitização de entradas: o que limpar, onde e por quê).

Revisões de segurança em frontend fazem parte da frente de Segurança Anti-Hacker. Fale com a gente.