Sanitizacao de DOM e o processo de limpar e validar conteudo HTML antes de ser inserido no Document Object Model, ajudando a prevenir ataques XSS e outras vulnerabilidades de injecao. Navegadores modernos fornecem APIs de sanitizacao integradas, enquanto varias bibliotecas oferecem funcoes de sanitizacao. A sanitizacao adequada e crucial ao lidar com conteudo gerado pelo usuario ou dados de terceiros que precisam ser renderizados como HTML.
A sanitização de DOM é o processo de limpar HTML não confiável para que ele possa ser inserido em uma página sem carregar marcação executável ou perigosa. Quando o código atribui uma string a innerHTML, outerHTML ou a um sink de DOM semelhante, o navegador a analisa e a transforma em nós vivos, incluindo qualquer tag de script, manipulador onerror, URL javascript: ou outro conteúdo ativo que ela contenha. Um sanitizador analisa esse HTML, percorre a árvore resultante e remove ou reescreve tudo o que não estiver em uma lista de permissão de tags e atributos seguros, retornando uma marcação que é renderizada como pretendido mas não pode executar código. Bibliotecas como o DOMPurify fazem isso de forma robusta, e os navegadores agora oferecem uma Sanitizer API nativa e o método setHTML, mais seguro, para o mesmo propósito.
A sanitização é uma defesa primária contra o XSS baseado em DOM e o armazenado. Qualquer recurso que renderize como HTML conteúdo gerado por usuários ou third-party, comentários, campos de rich-text, mensagens de chat ou blocos de CMS, é um ponto de injeção em potencial, e o simples escaping não basta quando o conteúdo é genuinamente destinado a ser HTML. Abordagens ingênuas, como colocar a tag de script em uma lista negra ou usar uma regex para remover elementos, deixam escapar o enorme espaço de truques de parser: XSS por mutação, marcação malformada que os navegadores reparam para uma forma executável, peculiaridades de conteúdo externo em SVG e MathML, e atributos de manipuladores de eventos. Um sanitizador auditado que opera sobre a árvore analisada em vez do texto bruto fecha essas brechas e transforma uma vulnerabilidade de alta gravidade em uma saída inerte.
Prefira sinks seguros como textContent ou o binding do framework, e só recorra à inserção de HTML quando for necessário; então sanitize com uma biblioteca mantida como o DOMPurify ou a Sanitizer API nativa em vez de filtros artesanais, mantendo-a atualizada à medida que novos contornos são descobertos. Combine-a com uma Content Security Policy estrita para que um payload que passe despercebido ainda assim não possa ser executado. A sanitização reside no seu próprio código, então ela não cobre o que um script third-party comprometido faz depois de carregado, já que esse script pode chamar innerHTML por conta própria. A cside aborda essa lacuna roteando scripts third-party por meio de um proxy híbrido e analisando o payload, detectando e bloqueando gravações de DOM inseguras que esses scripts tentam realizar e registrando-as para fins forenses.
Não. O escaping converte caracteres como os sinais de menor e maior em entidades HTML para que o texto seja renderizado literalmente, o que é correto quando você quer exibir a marcação como texto simples. A sanitização mantém o conteúdo como HTML de verdade mas remove as partes perigosas. Use o escaping para saída de texto e a sanitização apenas quando o conteúdo do usuário precisar ser renderizado como marcação real.
Quase nunca. A análise de HTML dos navegadores tem incontáveis casos extremos, conteúdo externo, peculiaridades de mutação e recuperação de marcação malformada, que filtros e regexes escritos à mão deixam escapar, levando a contornos. Use uma biblioteca mantida e amplamente testada como o DOMPurify ou a Sanitizer API embutida, e mantenha-a atualizada à medida que os pesquisadores descobrem novas técnicas de evasão.
We answer client-side security questions every day. Bring yours.