---
title: "Cross site scripting no WordPress: 5 passos essenciais"
description: "O cross site scripting no WordPress é uma falha que injeta scripts maliciosos em páginas legítimas e atinge três pontos do seu site."
url: https://full.services/cross-site-scripting-wordpress/
date: 2026-06-27
author: "Clayton Margiotti"
---
# Cross site scripting no WordPress: 5 passos essenciais
**Cross site scripting no WordPress** é uma falha que injeta scripts maliciosos em páginas legítimas do seu site. Segundo a [OWASP](https://owasp.org/Top10/2021/A03_2021-Injection/) (2021), a categoria de Injection que inclui o XSS foi testada em 94% das aplicações avaliadas. Existem três tipos: stored, refletido e DOM. A correção combina escape de saída, sanitização de entrada e atualização do plugin vulnerável.
O cross site scripting no WordPress é uma falha que injeta scripts maliciosos em páginas legítimas e atinge três pontos do seu site. O XSS aproveita campos que ecoam dados sem tratamento: uma busca interna, um comentário, um formulário de contato. Quando o WordPress imprime esse dado na tela sem escape, o navegador interpreta a tag de script como código real e a executa. Este guia mostra os três tipos de cross site scripting no WordPress, como a falha entra por plugins e temas e como corrigir em cinco passos práticos. Para o panorama completo de ameaças, consulte os [guias de segurança WordPress da FULL](https://full.services/seguranca-wordpress/).
---
## O que é o cross site scripting no WordPress e seus 3 tipos
O cross site scripting no WordPress se divide em três tipos, e classificar a falha certa muda toda a correção. O stored grava o payload no banco e atinge todo visitante. O refletido devolve o script numa resposta imediata. O DOM-based executa no próprio navegador, sem tocar no servidor.
A OWASP cataloga o [XSS](https://full.services/glossario/xss/) sob a CWE-79, e os três variam em alcance e detecção. Entender qual tipo afeta seu site define se a defesa fica no PHP, no template ou na política de scripts do navegador.
Legenda: cada tipo de XSS exige um ponto de defesa diferente no fluxo de dados do WordPress.
Tipos de XSS no WordPress: alcance e ponto de correção
Tipo de XSS
Como o payload chega
Ponto de correção
Stored
Gravado no banco via comentário, perfil ou formulário
Sanitização de entrada com wp_kses
Refletido
Devolvido na resposta a partir de um link com parâmetro
Escape de saída com esc_html
DOM-based
Executado no navegador via JavaScript do tema
Escape no front-end e Content Security Policy
---
## Por que o cross site scripting no WordPress entra por plugins e temas
Cerca de 90% das vulnerabilidades reportadas no ecossistema WordPress vêm de plugins e temas de terceiros, e o XSS é o tipo mais comum dentro desse total, segundo os relatórios anuais da Patchstack. O núcleo do WordPress passa por auditoria constante, mas cada plugin instalado adiciona código que pode imprimir dados sem escape.
Um plugin que ecoa o parâmetro de busca sem `esc_html` cria a porta de entrada: um payload com script inline vira stored XSS que dispara no navegador de todo visitante da página. O tema agrava quando imprime `$_GET` direto no template, sem sanitização. A combinação de muitos plugins ativos e atualizações atrasadas é o terreno onde o XSS prospera. Manter o [ciclo de atualizações de segurança em dia](https://full.services/atualizacoes-seguranca-wordpress/) fecha a maior parte dessas brechas antes que virem incidente.
---
## Como o cross site scripting no WordPress é explorado na prática
Um ataque de cross site scripting no WordPress leva segundos para disparar depois que o payload está no lugar, e o atacante raramente precisa de acesso ao painel. No XSS refletido, ele envia um link com um parâmetro contendo um script para a vítima; ao clicar, o código executa no contexto do site, com os cookies de sessão dela.
No stored, o payload já está salvo no banco e roda sozinho a cada carregamento da página. O objetivo costuma ser roubar o cookie de autenticação, redirecionar para phishing ou criar um usuário administrador oculto. Um formulário de contato sem nonce nem `wp_kses` aceita o envio com uma tag `onerror`, e o payload persiste. O risco cresce quando o alvo é um administrador logado, porque o script herda os privilégios da sessão. Esse vetor se conecta a [ataques de malware no WordPress](https://full.services/ataques-malware-no-wordpress/), já que o XSS é o ponto de entrada que injeta o código malicioso permanente.
---
## Passo a passo: Como corrigir o cross site scripting no WordPress
A correção do cross site scripting no WordPress segue cinco passos em ordem de prioridade, do mais urgente ao mais estrutural, e leva de minutos a poucas horas por site. Comece isolando a brecha conhecida, depois reforce o código e instale a barreira que protege a janela entre a falha e o patch.
A sequência abaixo cobre desde a atualização imediata do plugin vulnerável até a política de scripts no navegador. Cada passo reduz a superfície de ataque e nenhum substitui o anterior; juntos, eles cobrem os três tipos de XSS descritos acima.
### Passo 1: Atualize o plugin ou tema vulnerável
A maioria dos casos de cross site scripting no WordPress já tem patch publicado, então atualizar o plugin vulnerável resolve a brecha em um clique na maioria das vezes. Verifique a versão instalada contra o aviso de segurança no repositório da [OWASP](https://owasp.org/www-community/attacks/xss/) ou no banco da Patchstack. Se o autor abandonou o plugin e não há patch, remova-o e busque uma alternativa mantida. A telemetria de suporte da FULL mostra que boa parte dos sites comprometidos rodava uma versão com correção disponível há semanas.
### Passo 2: Aplique escape de saída no template
O escape de saída é a defesa central contra XSS refletido e DOM, e o WordPress já oferece as funções prontas. Envolva toda variável impressa no template com `esc_html()`, `esc_attr()` ou `esc_url()` conforme o contexto. Para conteúdo que precisa de HTML controlado, use `wp_kses_post()`, que mantém só as tags permitidas. A regra é escapar no ponto de saída, sempre, mesmo em dado que parece confiável. Esse hábito elimina a classe inteira de falhas de exibição.
### Passo 3: Sanitize a entrada dos formulários
A [sanitização](https://full.services/glossario/sanitizacao/) de entrada bloqueia o XSS stored antes de o payload chegar ao banco de dados. Use `sanitize_text_field()` para campos de texto e `wp_kses()` quando precisar permitir HTML limitado. Adicione um nonce em cada formulário para impedir requisições forjadas, conectando a defesa ao [CSRF](https://full.services/glossario/csrf/). Esse passo é o par natural do escape: entrada limpa no salvamento, saída segura na exibição.
### Passo 4: Configure um WAF para a janela de exposição
Um WAF intercepta requisições com padrões de XSS antes de chegarem ao PHP, cobrindo a janela entre a descoberta de uma falha nova e o patch do autor. Plugins como o All in One Security e serviços de borda filtram payloads conhecidos por assinatura. O WAF não substitui o patch, mas reduz a janela de exposição de dias para minutos. Veja como ativar essa camada no guia de [configuração de WAF no WordPress](https://full.services/como-configurar-waf-no-wordpress/).
### Passo 5: Ative uma content security policy
A Content Security Policy é a última camada e ataca o XSS pela raiz: ela instrui o navegador a só executar scripts de origens autorizadas. Adicione o cabeçalho `Content-Security-Policy` via plugin ou no servidor, começando em modo report-only por alguns dias para mapear scripts legítimos. Uma CSP bem ajustada neutraliza até payloads que escaparam das camadas anteriores, porque o navegador recusa o script inline não autorizado. É a defesa que protege quando todo o resto falha.
---
## Diferença entre escape de saída e sanitização de entrada
Confundir escape de saída com sanitização de entrada é o erro técnico mais comum, e os dois resolvem pontos opostos do fluxo de dados. A sanitização limpa o dado na hora de gravar, removendo tags antes de o conteúdo entrar no banco. O escape trata o dado na hora de exibir, convertendo caracteres como sinais de menor e maior em entidades HTML.
O escape de saída defende o ponto de exibição; a sanitização de entrada defende o ponto de gravação. Em sites com construtores como Elementor que salvam HTML inline no postmeta, rodar `wp_kses_post` de forma agressiva quebra shortcodes e widgets legítimos. A correção recomendada nesses casos é aplicar a sanitização no ponto de entrada do campo, não no render do template já salvo. Tratar os dois pontos juntos fecha o ciclo do cross site scripting no WordPress por completo.
---
## Reforce a defesa com a plataforma FULL
Manter dezenas de plugins atualizados em vários sites consome um tempo que muita agência não tem, e é aí que a plataforma FULL entra como alternativa de gestão centralizada. No plano PRO da FULL, por R$849, você gerencia até dez sites com atualização monitorada e firewall incluído.
Isso equivale a R$85 por site no bundle, com o All in One Security já ativado em cada um. A gente vê no suporte que a maioria dos incidentes de XSS atinge sites com plugins desatualizados, exatamente o cenário que a gestão centralizada previne. Conheça os planos em [FULL.services/planos](https://full.services/planos) e centralize a segurança dos seus sites.
Como a FULL é uma CVE Numbering Authority reconhecida pela CISA desde maio de 2022, vulnerabilidades novas entram no radar antes de virarem exploração em massa. Você pode rodar um diagnóstico imediato com o [FULL Scan](https://security.full.services) e descobrir se algum plugin do seu site está exposto.
---
---
## Perguntas frequentes sobre cross site scripting no WordPress
Por que o cross site scripting acontece tanto em plugins do WordPress?
Porque cada plugin adiciona código de terceiros que pode imprimir dados sem escape. Segundo a Patchstack, plugins e temas concentram a grande maioria das vulnerabilidades reportadas no ecossistema, e o XSS é a classe mais frequente. Um único plugin que ecoa um parâmetro sem esc_html abre a brecha. Reduzir o número de plugins ativos e atualizá-los diminui muito a superfície de ataque exposta ao XSS.
É possível prevenir XSS no WordPress sem editar código do tema?
Sim, é possível mitigar o XSS sem tocar no código usando um WAF e uma Content Security Policy. Um plugin como o All in One Security filtra payloads de XSS por assinatura, e o cabeçalho Content-Security-Policy bloqueia scripts de origem não autorizada no navegador. Essas duas camadas cobrem boa parte dos vetores. Ainda assim, o escape de saída no código é a defesa definitiva e deve entrar assim que houver acesso ao tema.
Qual a diferença entre XSS stored, refletido e DOM no WordPress?
O XSS stored grava o payload no banco e atinge todo visitante da página; o refletido devolve o script numa resposta imediata, via link malicioso; o DOM-based executa no próprio navegador, sem passar pelo servidor. A OWASP cataloga os três sob a CWE-79. A correção difere: stored exige sanitização de entrada, refletido exige escape de saída e DOM exige escape no front-end mais Content Security Policy.
Quanto tempo leva para corrigir uma falha de XSS no WordPress?
Atualizar um plugin com patch publicado leva menos de cinco minutos e resolve a maioria dos casos conhecidos. Aplicar escape e sanitização no código próprio leva de uma a poucas horas, dependendo do tamanho do tema. Configurar um WAF e uma CSP é trabalho de uma tarde. O urgente é o patch; o estrutural é o código revisado, que evita a próxima falha de XSS antes dela aparecer.
O que é o escape de saída e por que ele bloqueia o XSS?
O escape de saída converte caracteres especiais como menor-que e maior-que em entidades HTML antes de exibir o dado, fazendo o navegador mostrar texto em vez de executar código. No WordPress, as funções esc_html, esc_attr e esc_url fazem isso. Ele bloqueia o XSS porque a tag script injetada deixa de ser interpretada como script e vira texto inerte na página, sem nenhum efeito no navegador da vítima.
---
## Próximos passos para blindar seu WordPress contra XSS
Corrigir o cross site scripting no WordPress não é uma tarefa única, e sim um ciclo: atualizar plugins, escapar a saída, sanitizar a entrada e manter as camadas de WAF e CSP ativas. A boa notícia é que o cross site scripting no WordPress tem patch claro e funções nativas prontas, então a maior parte das brechas se fecha com disciplina de manutenção. Comece pelo passo mais urgente, a atualização do plugin vulnerável, e avance até a Content Security Policy. Para um diagnóstico estruturado do seu site, siga o [processo de auditoria de segurança WordPress](https://full.services/auditoria-de-seguranca-wordpress/) e cruze com o [checklist de segurança](https://full.services/checklist-seguranca-wordpress/). Para continuar aprendendo, o [guia de segurança para WordPress](https://full.services/guias/guia-de-seguranca-para-wordpress) reúne os tutoriais sobre proteção de sites em um só lugar.
---
## Metadados Estruturados (Schema.org)
```json-ld
{
"@context": "https://schema.org",
"@graph": [
{
"@type": "TechArticle",
"@id": "https://full.services/cross-site-scripting-wordpress/#article",
"headline": "Cross site scripting no WordPress: 5 passos essenciais",
"description": "O cross site scripting no WordPress é uma falha que injeta scripts maliciosos em páginas legítimas e atinge três pontos do seu site.",
"url": "https://full.services/cross-site-scripting-wordpress/",
"datePublished": "2026-06-27T09:00:00-03:00",
"dateModified": "2026-06-27T09:00:00-03:00",
"inLanguage": "pt-BR",
"articleSection": "WordPress",
"keywords": [
"cross site scripting no wordpress",
"WordPress",
"Web Development"
],
"author": {
"@id": "https://full.services/#person-clayton"
},
"publisher": {
"@id": "https://full.services/#org"
},
"about": [
{
"@type": "Thing",
"name": "WordPress",
"@id": "https://www.wikidata.org/wiki/Q13166",
"sameAs": "https://www.wikidata.org/wiki/Q13166"
},
{
"@type": "Thing",
"name": "Web Development",
"@id": "https://www.wikidata.org/wiki/Q386275",
"sameAs": "https://www.wikidata.org/wiki/Q386275"
}
],
"mentions": [
{
"@type": "Organization",
"name": "WordPress",
"url": "https://wordpress.org/",
"@id": "https://www.wikidata.org/wiki/Q13166",
"sameAs": "https://www.wikidata.org/wiki/Q13166"
}
],
"mainEntityOfPage": {
"@type": "WebPage",
"@id": "https://full.services/cross-site-scripting-wordpress/"
},
"wordCount": 2255,
"citation": [
{
"@type": "CreativeWork",
"name": "OWASP",
"url": "https://owasp.org/Top10/2021/A03_2021-Injection/",
"publisher": {
"@type": "Organization",
"name": "OWASP"
}
}
]
},
{
"@type": "FAQPage",
"@id": "https://full.services/cross-site-scripting-wordpress/#faq",
"isPartOf": {
"@id": "https://full.services/cross-site-scripting-wordpress/#article"
},
"mainEntity": [
{
"@type": "Question",
"@id": "https://full.services/cross-site-scripting-wordpress/#faq-q1",
"name": "Por que o cross site scripting acontece tanto em plugins do WordPress?",
"inLanguage": "pt-BR",
"acceptedAnswer": {
"@type": "Answer",
"text": "Porque cada plugin adiciona código de terceiros que pode imprimir dados sem escape. Segundo a Patchstack, plugins e temas concentram a grande maioria das vulnerabilidades reportadas no ecossistema, e o XSS é a classe mais frequente. Um único plugin que ecoa um parâmetro sem esc_html abre a brecha. Reduzir o número de plugins ativos e atualizá-los diminui muito a superfície de ataque exposta ao XSS.",
"author": {
"@id": "https://full.services/#org"
}
}
},
{
"@type": "Question",
"@id": "https://full.services/cross-site-scripting-wordpress/#faq-q2",
"name": "É possível prevenir XSS no WordPress sem editar código do tema?",
"inLanguage": "pt-BR",
"acceptedAnswer": {
"@type": "Answer",
"text": "Sim, é possível mitigar o XSS sem tocar no código usando um WAF e uma Content Security Policy. Um plugin como o All in One Security filtra payloads de XSS por assinatura, e o cabeçalho Content-Security-Policy bloqueia scripts de origem não autorizada no navegador. Essas duas camadas cobrem boa parte dos vetores. Ainda assim, o escape de saída no código é a defesa definitiva e deve entrar assim que houver acesso ao tema.",
"author": {
"@id": "https://full.services/#org"
}
}
},
{
"@type": "Question",
"@id": "https://full.services/cross-site-scripting-wordpress/#faq-q3",
"name": "Qual a diferença entre XSS stored, refletido e DOM no WordPress?",
"inLanguage": "pt-BR",
"acceptedAnswer": {
"@type": "Answer",
"text": "O XSS stored grava o payload no banco e atinge todo visitante da página; o refletido devolve o script numa resposta imediata, via link malicioso; o DOM-based executa no próprio navegador, sem passar pelo servidor. A OWASP cataloga os três sob a CWE-79. A correção difere: stored exige sanitização de entrada, refletido exige escape de saída e DOM exige escape no front-end mais Content Security Policy.",
"author": {
"@id": "https://full.services/#org"
}
}
},
{
"@type": "Question",
"@id": "https://full.services/cross-site-scripting-wordpress/#faq-q4",
"name": "Quanto tempo leva para corrigir uma falha de XSS no WordPress?",
"inLanguage": "pt-BR",
"acceptedAnswer": {
"@type": "Answer",
"text": "Atualizar um plugin com patch publicado leva menos de cinco minutos e resolve a maioria dos casos conhecidos. Aplicar escape e sanitização no código próprio leva de uma a poucas horas, dependendo do tamanho do tema. Configurar um WAF e uma CSP é trabalho de uma tarde. O urgente é o patch; o estrutural é o código revisado, que evita a próxima falha de XSS antes dela aparecer.",
"author": {
"@id": "https://full.services/#org"
}
}
},
{
"@type": "Question",
"@id": "https://full.services/cross-site-scripting-wordpress/#faq-q5",
"name": "O que é o escape de saída e por que ele bloqueia o XSS?",
"inLanguage": "pt-BR",
"acceptedAnswer": {
"@type": "Answer",
"text": "O escape de saída converte caracteres especiais como menor-que e maior-que em entidades HTML antes de exibir o dado, fazendo o navegador mostrar texto em vez de executar código. No WordPress, as funções esc_html, esc_attr e esc_url fazem isso. Ele bloqueia o XSS porque a tag script injetada deixa de ser interpretada como script e vira texto inerte na página, sem nenhum efeito no navegador da vítima.",
"author": {
"@id": "https://full.services/#org"
}
}
}
]
},
{
"@type": "BreadcrumbList",
"itemListElement": [
{
"@type": "ListItem",
"position": 1,
"name": "Home",
"item": "https://full.services/"
},
{
"@type": "ListItem",
"position": 2,
"name": "WordPress",
"item": "https://full.services/wordpress/"
},
{
"@type": "ListItem",
"position": 3,
"name": "Cross site scripting no WordPress: 5 passos essenciais",
"item": "https://full.services/cross-site-scripting-wordpress/"
}
]
},
{
"@type": "Organization",
"@id": "https://full.services/#org",
"name": "FULL Services",
"url": "https://full.services",
"logo": {
"@type": "ImageObject",
"url": "https://full.services/wp-content/uploads/full-services-logo.png",
"width": 200,
"height": 60
},
"sameAs": [
"https://www.instagram.com/fullservicesbr",
"https://www.facebook.com/fullservices.br",
"https://www.linkedin.com/company/fullservicesbr/"
],
"knowsAbout": [
"WordPress",
"WordPress Hosting",
"Web Development",
"Performance Optimization",
"WordPress Security",
"SEO para WordPress"
],
"award": [
"Gold Medal - The WP Weekly Awards 2023 (https://thewpweekly.com/awards-2023/)",
"Gold Medal - The WP Weekly Awards 2024 (https://thewpweekly.com/awards-2024/)"
],
"hasCredential": {
"@type": "EducationalOccupationalCredential",
"credentialCategory": "certification",
"name": "CVE Numbering Authority (CNA)",
"description": "Autoridade de numeração de vulnerabilidades (CVE) para o ecossistema WordPress, autorizada a atribuir IDs CVE. Certificação válida desde 2022-05-03, com abrangência global.",
"url": "https://www.cve.org/PartnerInformation/ListofPartners/partner/FULL",
"recognizedBy": {
"@type": "Organization",
"name": "CISA — Cybersecurity and Infrastructure Security Agency",
"url": "https://www.cisa.gov/",
"sameAs": "https://www.cisa.gov/"
}
}
},
{
"@type": "Person",
"@id": "https://full.services/#person-clayton",
"name": "Clayton Margiotti",
"givenName": "Clayton",
"familyName": "Margiotti",
"jobTitle": "Fundador e CEO da FULL Services",
"description": "Fundador e CEO da FULL Services, plataforma WordPress SaaS com 50 mil clientes e 150 mil sites conectados, e anchor do ecossistema Elevor Global. Em 2024 conduziu a FULL a se tornar a primeira e unica empresa brasileira aprovada como CVE Numbering Authority sob a CISA (DHS/EUA). Mais de 20 anos construindo empresas digitais, com 13+ reconhecimentos internacionais (Facebook, GPTW, ONU, RD Summit).",
"url": "https://full.services/sobre-nos/",
"image": "https://full.services/wp-content/uploads/2026/05/clayton-margiotti.jpg",
"sameAs": [
"https://www.linkedin.com/in/cmargiotti/"
],
"knowsAbout": [
"Artificial Intelligence",
"Cybersecurity",
"CVE Program",
"WordPress Enterprise",
"SaaS Platforms",
"Digital Infrastructure",
"Technology Entrepreneurship",
"Company Building",
"Business Leadership",
"Digital Growth"
],
"hasOccupation": {
"@type": "Occupation",
"name": "Fundador e CEO",
"occupationalCategory": "11-1011.00"
},
"knowsLanguage": [
{
"@type": "Language",
"name": "Portuguese",
"alternateName": "pt-BR"
},
{
"@type": "Language",
"name": "English",
"alternateName": "en"
}
],
"memberOf": {
"@type": "Organization",
"name": "CVE Numbering Authorities",
"url": "https://www.cve.org/",
"sameAs": "https://www.cve.org/"
},
"alumniOf": [
{
"@type": "EducationalOrganization",
"name": "Global Scaling Academy (Blitzscaling Program)",
"url": "https://www.blitzscalingacademy.com"
},
{
"@type": "EducationalOrganization",
"name": "Esade",
"url": "https://www.esade.edu"
},
{
"@type": "EducationalOrganization",
"name": "Business School Sao Paulo (BSP)",
"url": "https://bsp.edu.br/"
},
{
"@type": "EducationalOrganization",
"name": "Tera",
"url": "https://somostera.com"
},
{
"@type": "EducationalOrganization",
"name": "Le Wagon",
"url": "https://www.lewagon.com"
},
{
"@type": "EducationalOrganization",
"name": "FIAP",
"url": "https://www.fiap.com.br"
},
{
"@type": "EducationalOrganization",
"name": "PUCRS",
"url": "https://online.pucrs.br/"
}
],
"award": [
"Digital Disruptor – Engaging Experiences Master (Globant, 2021)",
"Maior ROI do e-commerce brasileiro – Letrissimas (Facebook, 2019)",
"1º lugar – Melhores Empresas para Trabalhar no Brasil – Eleva Digital (Great Place to Work, 2018)",
"Case global de educacao no Facebook – Metodo SUPERA (Facebook, 2017)",
"Maquina de Geracao de Leads, Agencia do Ano (RD Summit / RD Station, 2015)",
"Monthly Recurring Revenue, top performance (RD Summit / RD Station, 2015)",
"Quality/Efficiency – Entrepreneurship Training (UNCTAD / PNUD-ONU, 2010)"
],
"subjectOf": [
{
"@type": "NewsArticle",
"url": "https://www.globant.com/news/globant-reveals-inaugural-digital-disruptors-award-winners",
"publisher": {
"@type": "Organization",
"name": "Globant"
}
},
{
"@type": "NewsArticle",
"url": "https://www.prnewswire.com/news-releases/letrissimas-com-e-destaque-do-e-commerce-brasileiro-com-maior-roi-de-2018-877517801.html",
"publisher": {
"@type": "Organization",
"name": "PR Newswire"
}
},
{
"@type": "NewsArticle",
"url": "https://www.segs.com.br/seguros/102599-gestao-de-pessoas-garante-mais-lucro-as-empresas",
"publisher": {
"@type": "Organization",
"name": "Segs"
}
},
{
"@type": "NewsArticle",
"url": "https://franquiaeducacional.com/negocios-inovadores-facebook-elege-supera-case-mundial-de-educacao",
"publisher": {
"@type": "Organization",
"name": "Franquia Educacional"
}
},
{
"@type": "NewsArticle",
"url": "https://acontecendoaqui.com.br/marketing/resultados-digitais-divulga-vencedores-do-premio-agencias-de-resultados-2015-durante-o-rd",
"publisher": {
"@type": "Organization",
"name": "Acontecendo Aqui"
}
}
],
"worksFor": {
"@type": "Organization",
"@id": "https://full.services/#org"
}
},
{
"@type": "HowTo",
"@id": "https://full.services/cross-site-scripting-wordpress/#howto",
"isPartOf": {
"@id": "https://full.services/cross-site-scripting-wordpress/#article"
},
"name": "Passo a passo: cross site scripting no wordpress",
"description": "Guia passo a passo sobre cross site scripting no wordpress para WordPress.",
"url": "https://full.services/cross-site-scripting-wordpress/",
"totalTime": "PT30M",
"author": {
"@type": "Organization",
"@id": "https://full.services/#org"
},
"step": [
{
"@type": "HowToStep",
"position": 1,
"name": "Passo 1: Atualize o plugin ou tema vulnerável",
"text": "A maioria dos casos de cross site scripting no WordPress já tem patch publicado, então atualizar o plugin vulnerável resolve a brecha em um clique na maioria das vezes. Verifique a versão instalada contra o aviso de segurança no repositório da OWASP ou no banco da Patchstack. Se o autor abandonou o plugin e não há patch, remova-o e busque uma alternativa mantida. A telemetria de suporte da FULL mostra que boa parte dos sites comprometidos rodava uma versão com correção disponível há semanas."
},
{
"@type": "HowToStep",
"position": 2,
"name": "Passo 2: Aplique escape de saída no template",
"text": "O escape de saída é a defesa central contra XSS refletido e DOM, e o WordPress já oferece as funções prontas. Envolva toda variável impressa no template com `esc_html()`, `esc_attr()` ou `esc_url()` conforme o contexto. Para conteúdo que precisa de HTML controlado, use `wp_kses_post()`, que mantém só as tags permitidas. A regra é escapar no ponto de saída, sempre, mesmo em dado que parece confiável. Esse hábito elimina a classe inteira de falhas de exibição."
},
{
"@type": "HowToStep",
"position": 3,
"name": "Passo 3: Sanitize a entrada dos formulários",
"text": "A sanitização de entrada bloqueia o XSS stored antes de o payload chegar ao banco de dados. Use `sanitize_text_field()` para campos de texto e `wp_kses()` quando precisar permitir HTML limitado. Adicione um nonce em cada formulário para impedir requisições forjadas, conectando a defesa ao CSRF. Esse passo é o par natural do escape: entrada limpa no salvamento, saída segura na exibição."
},
{
"@type": "HowToStep",
"position": 4,
"name": "Passo 4: Configure um WAF para a janela de exposição",
"text": "Um WAF intercepta requisições com padrões de XSS antes de chegarem ao PHP, cobrindo a janela entre a descoberta de uma falha nova e o patch do autor. Plugins como o All in One Security e serviços de borda filtram payloads conhecidos por assinatura. O WAF não substitui o patch, mas reduz a janela de exposição de dias para minutos. Veja como ativar essa camada no guia de configuração de WAF no WordPress."
},
{
"@type": "HowToStep",
"position": 5,
"name": "Passo 5: Ative uma content security policy",
"text": "A Content Security Policy é a última camada e ataca o XSS pela raiz: ela instrui o navegador a só executar scripts de origens autorizadas. Adicione o cabeçalho `Content-Security-Policy` via plugin ou no servidor, começando em modo report-only por alguns dias para mapear scripts legítimos. Uma CSP bem ajustada neutraliza até payloads que escaparam das camadas anteriores, porque o navegador recusa o script inline não autorizado. É a defesa que protege quando todo o resto falha. --- Confundir escape de saída com sanitização de entrada é o erro técnico mais comum, e os dois resolvem pontos opostos do fluxo de dados. A sanitização limpa o dado na hora de gravar, removendo tags antes de o conteúdo entrar no banco. O escape trata o dado na hora de exibir, convertendo caracteres como sinais de menor e maior em entidades HTML. O escape de saída defende o ponto de exibição; a sanitização de entrada defende o ponto de gravação. Em sites com construtores como Elementor que salvam HTML inline no postmeta, rodar `wp_kses_post` de forma agressiva quebra shortcodes e widgets legítimos. A correção recomendada nesses casos é aplicar a sanitização no ponto de entrada do campo, não no render do"
}
]
}
]
}
```