# XSS (Cross-Site Scripting) XSS WordPress é a aplicação ao CMS de uma das classes de ataque mais comuns na web: Cross-Site Scripting, em que um atacante consegue injetar código JavaScript malicioso em páginas legítimas e fazer com que esse código execute no navegador de outras pessoas que visitam o site. O resultado pode ser roubo de cookies, sequestro de sessão, redirecionamentos forçados, defacement ou roubo de dados de formulários. O core do WordPress tem mitigação forte; a maioria dos casos reais explora plugins mal escritos. ## O que é XSS O nome "Cross-Site Scripting" descreve o vetor original do ataque: rodar script de um site no contexto de outro site. Na prática moderna, o conceito é mais amplo: qualquer execução de JavaScript em página onde o atacante não deveria ter capacidade de inserir código. O fluxo típico envolve três personagens. O atacante encontra um campo onde input do usuário é refletido na página sem escape adequado. Insere JavaScript malicioso nesse campo. Vítima abre a página, o JavaScript executa no navegador dela com cookies e sessão dela ativa, e o atacante consegue executar ações em nome da vítima. Quem busca o que é xss costuma estar tentando entender uma CVE em plugin instalado, ou auditando código próprio. Em ambos os casos, a resposta envolve duas perguntas: onde input do usuário entra na página e onde esse input é exibido. XSS mora exatamente entre esses dois pontos. Para o usuário final, XSS é praticamente invisível. A página parece normal, o domínio é o legítimo, o cadeado HTTPS está ativo. Mas no fundo, código do atacante está rodando junto, lendo cookies, capturando teclas, redirecionando para domínios maliciosos. É exatamente essa invisibilidade que torna XSS tão perigoso. ## Tipos de XSS: refletido, persistente e DOM XSS refletido é a variante mais simples. O input malicioso vai em uma URL ou em um POST, é processado pelo servidor e refletido de volta na resposta sem escape. O atacante envia link com payload para a vítima, ela clica, o JavaScript executa. Tudo acontece em uma única requisição. Não persiste no banco, mas funciona se a vítima clicar. XSS persistente é a variante mais perigosa. O input malicioso é salvo no banco do site (em comentário, em metadado, em opção de plugin) e exibido depois para todos que visitarem a página afetada. Um único ataque atinge todos os visitantes seguintes. Comentários WordPress sem moderação foram vetores históricos clássicos. XSS baseado em DOM acontece inteiramente no navegador. O servidor não está envolvido na manipulação. JavaScript do site lê parâmetros da URL ou do hash e os insere no DOM sem escape. Atacante envia URL com payload, a vítima abre, o próprio script da página injeta o conteúdo malicioso. É o tipo mais difícil de detectar via auditoria de servidor. O termo cross site scripting cobre todos os três. CVEs em plugins WordPress costumam mencionar qual variante específica está envolvida, e a defesa varia ligeiramente para cada uma. Combine com proteção geral contra [vulnerabilidades](https://full.services/glossario/vulnerabilidade-wordpress/) e [CSRF](https://full.services/glossario/csrf/) em conjunto. ## Como WordPress se protege contra XSS O core fornece um conjunto rico de funções de escape, cada uma para um contexto específico. esc_html escapa para uso dentro de HTML normal. esc_attr escapa para uso dentro de atributos HTML. esc_url normaliza e valida URLs. esc_js escapa string para uso em código JavaScript inline. esc_textarea escapa para uso dentro de textareas. wp_kses permite HTML restrito controlado por allowlist. O editor visual do WordPress (TinyMCE) e o Gutenberg passam por filtros internos que permitem só um conjunto de tags HTML em conteúdo de posts. Tags como script, iframe, embed e onclick são removidas automaticamente do conteúdo gerado pelo editor. Assinante e Contribuidor têm filtros ainda mais restritivos que Administrador. O sistema de comentários sanitiza input por padrão e exige moderação de comentários novos vindos de email não cadastrado. Plugins de antispam (Akismet, Antispam Bee) somam camada extra. URLs em comentários ganham rel=nofollow ugc automaticamente para proteger SEO mesmo quando passam pelo filtro. Para usuários acima de Editor, o WordPress permite por padrão o uso de HTML mais amplo e até de unfiltered_html (capacidade especial). Isso é por design: editores precisam poder embutir vídeos, código de demo e widgets externos. A contrapartida é que essas contas precisam ter senhas fortes, 2FA ativo e auditoria de capacidade. Combine com hardening via [wp-config.php](https://full.services/glossario/wp-config/). ## Como prevenir XSS no seu código A regra de ouro é: nunca exiba dado vindo de fora sem escape. Toda saída precisa passar pela função de escape correspondente ao contexto. echo $variavel sem esc_html ou similar é vulnerabilidade pronta. echo esc_html($variavel) elimina o ataque no ato. O segundo passo é escolher a função certa para o contexto. esc_html para conteúdo dentro de elementos HTML. esc_attr para conteúdo dentro de atributos. esc_url para URLs. esc_js para strings que vão entrar em JavaScript. Usar esc_html dentro de atributo HTML deixa passar payloads que esc_attr bloqueia. O terceiro passo é fazer o mesmo na entrada via [sanitização](https://full.services/glossario/sanitizacao/). Sanitizar na entrada e escapar na saída são camadas complementares, e ataque xss costuma atravessar exatamente quando uma das duas é esquecida. Use sanitize_text_field, esc_url_raw e wp_kses para entrada; esc_html, esc_attr e esc_url para saída. O quarto passo é configurar Content Security Policy via cabeçalho HTTP. CSP define quais origens podem carregar scripts, estilos e recursos. Bem configurada, CSP bloqueia execução de JavaScript inline mesmo se a página tiver XSS, neutralizando o ataque mesmo quando ele consegue ser injetado. Combine com proteção contra [SQL Injection](https://full.services/glossario/sql-injection/) para fechar os dois vetores mais comuns juntos. Para times que querem proteção contínua contra XSS sem auditar plugin a plugin manualmente, a FULL Services entrega o **AIOS** já licenciado e configurado dentro da stack profissional, com firewall de aplicação que bloqueia payloads conhecidos de XSS, hardening padrão de WordPress e cabeçalhos de CSP pré-tunados. Em vez de revisar código de cada plugin caso a caso, o site roda em uma camada de segurança validada em produção desde o primeiro deploy. **Também conhecido como:** cross-site scripting, ataque xss ## Termos relacionados - [Sanitização](https://full.services/glossario/sanitizacao/) - [Vulnerabilidade WordPress](https://full.services/glossario/vulnerabilidade-wordpress/) - [CSRF (Cross-Site Request Forgery)](https://full.services/glossario/csrf/) - [SQL Injection](https://full.services/glossario/sql-injection/) --- Glossário WordPress da FULL Services: [XSS (Cross-Site Scripting)](https://full.services/glossario/xss/)