O que é XSS e como impedir que o código seja executado em sua página da web?
Publicado em 2026-10-20 por frfrand
Cross-Site Scripting explicado: diferencias entre texto y código, casos en comentarios y formularios, escape por contexto y sanitización segura.
XSS significa Cross-Site Scripting e descreve uma família de vulnerabilidades nas quais conteúdo não confiável acaba sendo interpretado como código ativo dentro de uma página da web. Em muitos casos, a origem é um dado inserido por uma pessoa: um comentário, uma biografia, um nome de produto ou um parâmetro da URL.
O problema não é permitir que alguém escreva texto. O problema aparece quando a aplicação trata esse texto como se fosse parte das instruções que o navegador deve executar.
O exemplo de uma seção de comentários
Imagine um site onde os usuários podem publicar avaliações. Cada avaliação deveria ser exibida como texto, mesmo que contenha sinais estranhos, aspas ou fragmentos de código.
Se o sistema introduzir esse conteúdo no HTML sem o tratamento adequado, o navegador pode interpretá-lo como marcação ou executar instruções que não pertencem ao site.
Isso pode permitir ações indesejadas no contexto da página, acesso a certos dados disponíveis para os scripts ou manipulação do conteúdo que o visitante vê. O impacto depende das permissões, da arquitetura e das proteções existentes.
Por que não basta bloquear a palavra «script»?
Porque os navegadores interpretam HTML, atributos, JavaScript, URLs e CSS de maneiras diferentes. Uma lista improvisada de palavras proibidas não contempla todos os contextos.
A defesa correta depende de onde o dado está sendo colocado. Mostrar texto entre tags HTML não exige exatamente o mesmo tratamento que usar um valor dentro de uma URL ou um atributo.
Por isso, o OWASP recomenda codificação de saída adaptada ao contexto e, quando realmente for necessário aceitar HTML, sanitização por meio de ferramentas apropriadas.
O que é escapar conteúdo?
Escapar significa representar certos caracteres como dados para que não sejam interpretados como sintaxe ativa naquele contexto.
Um exemplo fácil: se você quiser mostrar literalmente <b>Hola</b> como texto, ele não deve se transformar em uma tag HTML ativa. Um framework pode convertê-lo em texto visível ou usar entidades apropriadas.
Muitas bibliotecas modernas de interface aplicam proteções por padrão ao inserir valores como texto. Mas existem funções especiais para inserir HTML sem esse tratamento; usá-las com conteúdo não confiável aumenta o risco.
O React e outros frameworks evitam XSS automaticamente?
Eles ajudam muito quando você usa as funções seguras, mas não eliminam qualquer possibilidade.
Por exemplo, o React costuma escapar texto interpolado normalmente. No entanto, existem mecanismos para inserir HTML de forma deliberada. Se você alimentar esses mecanismos com conteúdo não confiável sem sanitizar, poderá reintroduzir o problema.
Também importam as URLs, bibliotecas externas, versões e componentes que convertem dados em código de maneiras especiais.
E se eu precisar permitir texto enriquecido?
Em um blog ou editor pode ser razoável permitir títulos, links e negritos. Nesse caso não dá para mostrar absolutamente tudo como texto simples, mas também não convém aceitar HTML arbitrário.
A alternativa costuma ser utilizar um formato limitado e uma biblioteca de sanitização mantida, com uma lista controlada de elementos e atributos permitidos. Além disso, é importante não modificar depois o HTML sanitizado de uma forma que volte a torná-lo inseguro.
Uma política CSP resolve isso?
Content Security Policy pode reduzir determinados riscos ao limitar de onde os scripts são carregados e o que pode ser executado. Mas não deve ser a única defesa.
Um WAF também não substitui uma implementação segura. Alguns ataques XSS ocorrem completamente dentro da lógica do navegador e não necessariamente passam por um filtro de requisições do servidor.
Três erros comuns
Confiar no que vem do banco de dados. Que um dado esteja armazenado não significa que seja seguro: talvez tenha sido inserido por outro usuário há um mês.
Escapar no lugar errado. Um método adequado para texto HTML pode não ser suficiente para uma URL ou um contexto JavaScript.
Permitir HTML por conveniência. Se você precisar apenas de texto, mostre-o como texto. Reduzir funções perigosas facilita muito a segurança.
Como se relaciona com o ArduMaker?
Uma aplicação implantada em um VPS do ArduMaker pode estar perfeitamente configurada quanto a portas e HTTPS e, ainda assim, apresentar XSS se seu frontend interpretar mal conteúdo externo. A prevenção se trabalha principalmente no código e na forma de representar dados.
Em resumo: XSS aparece quando conteúdo não confiável deixa de ser tratado como dado e se torna código ativo. As defesas centrais são saída segura, codificação contextual e sanitização quando necessário.
Fonte: Guia de prevenção XSS da OWASP · Segurança de conteúdos no MDN.