---
title: "Vulnerabilidade XSS"
description: "Vulnerabilidade XSS: como um script injetado é executado no navegador dos visitantes, os tipos armazenado, refletido e DOM, e como proteger o WordPress."
language: "pt"
locale: "pt-BR"
type: "definition"
canonical: "https://www.wp-masquerade.com/pt/glossario/vulnerabilidade-xss/"
published: "2026-10-28T08:00:00+00:00"
modified: "2026-10-28T20:03:42+00:00"
translations:
  pt-BR: "https://www.wp-masquerade.com/pt/glossario/vulnerabilidade-xss/index.md"
  en-US: "https://www.wp-masquerade.com/glossary/xss/index.md"
  fr-FR: "https://www.wp-masquerade.com/fr/definitions/faille-xss/index.md"
  es-ES: "https://www.wp-masquerade.com/es/glosario/vulnerabilidad-xss/index.md"
  de-DE: "https://www.wp-masquerade.com/de/glossar/cross-site-scripting/index.md"
  it-IT: "https://www.wp-masquerade.com/it/glossario/vulnerabilita-xss/index.md"
  nl-NL: "https://www.wp-masquerade.com/nl/woordenlijst/cross-site-scripting/index.md"
---

# Vulnerabilidade XSS

Uma vulnerabilidade XSS (cross-site scripting) permite que um atacante faça o próprio JavaScript ser executado na página que outro visitante está vendo. O script age então no navegador da vítima com os direitos do site: ações em nome dela, leitura dos dados exibidos ou redirecionamento.

A sigla XSS vem do inglês cross-site scripting; usa-se X em vez de C para não confundir com as folhas de estilo CSS. É uma falha de injeção: o site insere na página um dado vindo de fora sem neutralizá-lo, e o navegador o interpreta como código. O MITRE a cataloga com o identificador CWE-79. Como o script parece vir do próprio site, o navegador lhe dá a mesma confiança que ao resto da página.

## Como funciona um ataque XSS

Tudo começa com um valor que o atacante controla: um parâmetro de URL, um campo de formulário, um comentário, um cabeçalho HTTP gravado em estatísticas. Se o código exibe esse valor bruto, uma string como `<script>…</script>` ou um atributo `onerror="…"` se torna executável. O script pode então ler o conteúdo da página, enviar requisições em nome da pessoa logada, alterar o que ela vê ou redirecioná-la para outro site.

![Esquema em cinco etapas de um XSS armazenado: o atacante injeta uma tag script em um campo, o site a grava, um administrador abre a tela correspondente, a página devolve o script sem escape e o script age na sessão do administrador](https://www.wp-masquerade.com/media/2026/10/xss-stockee-pt.webp)

*Um XSS armazenado espera a vítima: basta que um administrador exiba o dado armadilhado.*

Em um site WordPress, o alvo preferido é o administrador. Um script executado na sessão dele pode criar uma conta, instalar um plugin ou mudar uma configuração, sem nunca conhecer a senha: o próprio navegador envia os cookies de login com cada requisição.

## Os tipos de XSS

- **XSS armazenado (persistente)**: o script é gravado no servidor, no banco de dados por exemplo, e devolvido a cada exibição. Não se exige nenhuma ação especial da vítima, basta abrir a página.
- **XSS refletido**: o script viaja na requisição, muitas vezes um link armadilhado, e o servidor o copia imediatamente na resposta. A vítima precisa clicar.
- **XSS baseado em DOM**: é o JavaScript da página que insere um dado não confiável, como o fragmento de uma URL. O servidor pode não ver nada passar.

A OWASP também descreve o XSS “cego” (blind XSS): uma variante armazenada que dispara mais tarde, em uma interface que o atacante não vê. É exatamente o caso dos logs, estatísticas e formulários recebidos que se consultam no Painel. Os exemplos reais de XSS em plugins populares mostram que esse cenário não tem nada de teórico.

*Vídeo: “Como Funciona o XSS (Cross-Site Scripting)?” (Guia Anônima)*

## No WordPress: escapar no último momento

A documentação para desenvolvedores do WordPress define uma regra simples: escapar o mais tarde possível, no momento em que o dado é exibido, com a função que corresponde ao contexto.

| Contexto de exibição | Função |
| --- | --- |
| Texto dentro de um elemento HTML | `esc_html()` |
| Valor de um atributo | `esc_attr()` |
| URL em href ou src | `esc_url()` |
| JavaScript inline | `esc_js()` |
| Conteúdo de um textarea | `esc_textarea()` |
| HTML com algumas tags permitidas | `wp_kses()`, `wp_kses_post()` |

```
<h2><?php echo esc_html( $titulo ); ?></h2>
<a href="<?php echo esc_url( $link ); ?>" title="<?php echo esc_attr( $info ); ?>">Ver</a>
```

Validar e sanitizar as entradas continua sendo útil, mas não substitui esse escape na saída: um mesmo valor pode ser exibido em vários contextos.

## Como se proteger sem mexer no código

- Atualizar rapidamente plugins e temas: os XSS explorados em massa costumam mirar versões já corrigidas.
- Manter poucas contas com privilégios e excluir as que não são mais usadas.
- Ficar de olho no surgimento de novos administradores, sinal frequente de um XSS explorado.
- Adicionar uma [política de segurança de conteúdo](https://www.wp-masquerade.com/pt/glossario/content-security-policy/), sabendo que uma versão rígida, que proíbe scripts inline, é difícil de manter com o WordPress. Nosso guia de [cabeçalhos de segurança HTTP para WordPress](https://www.wp-masquerade.com/pt/cabecalhos-seguranca-http-wordpress/) detalha as opções.
- Um [firewall de aplicação web](https://www.wp-masquerade.com/pt/glossario/waf/) pode barrar payloads conhecidos, sem garantia contra uma variante inédita.

O WP Masquerade Pro envia [cabeçalhos de segurança](https://www.wp-masquerade.com/pt/recursos/cabecalhos-de-seguranca/), incluindo uma CSP básica opcional. Essa CSP não restringe os scripts: portanto, não bloqueia um XSS. O WP Masquerade não é um firewall de aplicação nem um corretor de código; só a atualização do componente com defeito fecha a falha.

## Erros comuns

- Confundir XSS e [CSRF](https://www.wp-masquerade.com/pt/glossario/csrf/): o segundo faz o navegador enviar uma requisição forjada, sem executar script na página. Já um XSS permite contornar as proteções anti-CSRF, pois o script lê os tokens da página.
- Achar que um dado é “interno” porque aparece no painel de administração: um cabeçalho HTTP ou uma URL visitada vêm de fora.
- Usar `esc_html()` em um atributo ou `esc_attr()` para uma URL: cada contexto tem a sua função.
- Pensar que a proteção contra [injeção de SQL](https://www.wp-masquerade.com/pt/glossario/injecao-de-sql/) basta: um dado bem gravado no banco pode continuar perigoso na exibição.

## Termos relacionados

- [Content Security Policy (CSP)](https://www.wp-masquerade.com/pt/glossario/content-security-policy/)
- [Injeção de SQL](https://www.wp-masquerade.com/pt/glossario/injecao-de-sql/)
- [CSRF](https://www.wp-masquerade.com/pt/glossario/csrf/)
- [Cabeçalhos de segurança HTTP](https://www.wp-masquerade.com/pt/glossario/cabecalhos-de-seguranca-http/)
- [Nonce](https://www.wp-masquerade.com/pt/glossario/nonce/)


## Fontes

- [OWASP : Cross Site Scripting (XSS)](https://owasp.org/www-community/attacks/xss/)
- [MITRE CWE-79 : Improper Neutralization of Input During Web Page Generation (Cross-site Scripting)](https://cwe.mitre.org/data/definitions/79.html)
- [WordPress Developer Resources : Escaping Data](https://developer.wordpress.org/apis/security/escaping/)