# Security headers e CSP no WordPress: 6 camadas de defesa Os security headers são instruções HTTP que mandam o navegador bloquear XSS, clickjacking e downgrade de HTTPS antes da página renderizar. Segundo o Cloudflare Radar (2026), no Brasil o WAF mitigou 16,4% dos ataques de camada de aplicação nos últimos dias. CSP é a camada mais difícil: errar a diretiva quebra o tema. Aplique em seis camadas, do mais simples ao mais arriscado. Os security headers são cabeçalhos de resposta HTTP que o servidor envia junto com cada página e que dizem ao navegador como se comportar com aquele conteúdo. Eles fecham uma classe de brecha que plugin de firewall não alcança: o que acontece dentro do navegador do visitante depois que o HTML já saiu do servidor. Um Content-Security-Policy bem escrito barra a execução de script injetado por XSS, o X-Frame-Options impede que seu site seja embutido num iframe de phishing, e o Strict-Transport-Security força HTTPS mesmo se alguém tentar um downgrade. Este guia mostra como aplicar as seis camadas no WordPress, do header de uma linha até o CSP em modo report. Para o contexto completo de proteção, vale ver os guias de segurança WordPress da FULL. --- ## Diagnóstico rápido: Quais security headers faltam no seu site Rodar um teste de exposição leva menos de 30 segundos e revela quais security headers o seu WordPress já envia e quais faltam, porque o WordPress não adiciona nenhum desses seis cabeçalhos por padrão e o tema raramente cuida disso, deixando a maioria das instalações com nota F no primeiro teste de configuração de segurança. O Mozilla Observatory, que analisa a configuração de segurança de um domínio e atribui uma nota de A+ a F, mostra exatamente quais cabeçalhos estão ausentes. A tabela abaixo resume os seis security headers que importam e o que cada um protege.
Security headers essenciais no WordPress: função e prioridade
Header O que protege Risco de quebrar o site
Content-Security-PolicyExecução de script injetado (XSS)Alto
Strict-Transport-SecurityDowngrade de HTTPS para HTTPMédio
X-Frame-OptionsClickjacking via iframeBaixo
X-Content-Type-OptionsMIME sniffing de uploadsBaixo
Referrer-PolicyVazamento de URL em links externosBaixo
Permissions-PolicyAcesso indevido a câmera, microfone, geoBaixo
A leitura dessa tabela define a ordem de trabalho: comece pelos de risco baixo, deixe o Content-Security-Policy por último. Quem nunca mexeu nisso pode seguir o guia do iniciante sobre cabeçalhos HTTP de segurança antes de avançar. --- ## Por que o plugin de segurança não resolve os security headers sozinho Um plugin de firewall bloqueia tráfego na entrada do servidor, mas os 6 security headers operam numa camada diferente, dentro do navegador, depois que o HTML já foi entregue, e essa distinção entre filtrar requisição no servidor e instruir comportamento no navegador do visitante é a que mais confunde administradores que acham que um plugin cobre tudo. O firewall do All in One Security filtra requisição maliciosa antes dela chegar ao WordPress; um header de resposta como o X-Frame-Options diz ao navegador do visitante para recusar embutir a página num iframe. São defesas complementares, não substitutas. Segundo o perfil público do WPVulnerability, o Contact Form 7 acumulou uma falha crítica de upload arbitrário, a CVE-2020-35489 (CVSS 10.0, corrigida na versão 5.3.2). Um Content-Security-Policy restritivo teria limitado o estrago de scripts injetados por brechas desse tipo, mesmo com o firewall passando. Por isso security headers entram no roteiro de hardening de segurança do WordPress como camada própria. --- ## Como aplicar os security headers em 6 camadas Aplicar os 6 security headers no WordPress segue uma ordem de risco crescente, ao longo de 4 passos práticos: comece pelos cabeçalhos que não quebram nada, ative o Strict-Transport-Security sobre HTTPS válido e deixe o Content-Security-Policy para o final, em modo report, porque ele é o único que costuma derrubar o tema na primeira tentativa. Em servidor Apache, os cabeçalhos vão no `.htaccess`; em Nginx, no bloco `server`; e no plano gerenciado, o painel ou o All in One Security cuida disso sem editar arquivo. Os passos abaixo cobrem o caminho via `.htaccess`, que é o mais comum em hospedagem compartilhada. Para entender a sintaxe do arquivo, o material sobre controles avançados de .htaccess no WordPress ajuda.

Legenda: o relatório mostra a nota F antes de qualquer header ser aplicado, o ponto de partida da maioria dos sites.

### Passo 1: Force HTTPS antes de qualquer header Confirme que o site responde em HTTPS válido em todos os subdomínios antes de tocar nos security headers. O Strict-Transport-Security só faz sentido sobre uma base HTTPS sólida, porque ele instrui o navegador a recusar HTTP para sempre. Se faltar certificado, resolva primeiro com o certificado SSL gratuito. Um certificado Let's Encrypt cobre o domínio em poucos minutos. ### Passo 2: Adicione os headers de risco baixo Abra o `.htaccess` e adicione os quatro headers que não quebram o front-end. Eles instruem o navegador sem alterar como o conteúdo é montado: ``` Header set X-Frame-Options "SAMEORIGIN" Header set X-Content-Type-Options "nosniff" Header set Referrer-Policy "strict-origin-when-cross-origin" Header set Permissions-Policy "geolocation=(), camera=(), microphone=()" ``` Salve, recarregue o site e confira que tudo abre normal. Esses quatro raramente causam efeito colateral. ### Passo 3: Ative o strict-transport-security Adicione o HSTS com max-age de um ano e o subdomínio incluído, depois de confirmar HTTPS em tudo: ``` Header set Strict-Transport-Security "max-age=31536000; includeSubDomains" ``` Só adicione `preload` quando tiver certeza absoluta de que todo subdomínio terá HTTPS pelos próximos meses, porque a remoção da lista preload é lenta. ### Passo 4: Monte o content-security-policy em modo report Comece o Content-Security-Policy pelo header `Content-Security-Policy-Report-Only`, que registra violações sem bloquear nada. Isso evita derrubar o tema no primeiro dia. Deixe rodando por duas semanas, leia os relatórios e mapeie cada script legítimo que precisa ser liberado antes de promover para o header de bloqueio. --- ## O risco real do CSP: Quando os security headers quebram o tema O Content-Security-Policy é o único dos 6 security headers que costuma derrubar o site logo na primeira tentativa, e a causa é quase sempre uma só: script inline sem permissão num tema que nunca foi escrito pensando em CSP, o que faz a página perder funcionalidade antes de barrar qualquer atacante. Um CSP com diretiva `script-src 'self'` aplicado a um tema que carrega JavaScript inline sem nonce, num ambiente WordPress com Elementor ativo, bloqueia o editor visual e quebra popups e formulários, sem nenhum erro visível no painel do administrador. O sintoma aparece só no console do navegador. Na maioria dos casos que chegam ao suporte da FULL, o problema é justamente esse: o CSP foi para produção em modo bloqueio antes de mapear os scripts do tema. A correção tende a ser começar pelo modo report, ler as violações e liberar só o necessário. Para classes de injeção relacionadas, vale revisar a proteção contra ataques de SQL injection no WordPress. --- ## Quem escreve sobre vulnerabilidade aqui cataloga CVE A FULL é a única empresa brasileira credenciada como CNA (CVE Numbering Authority) sob a CISA desde maio de 2022, autorizada a atribuir identificadores CVE oficiais, o que muda o peso do que está escrito aqui: quem fala de Content-Security-Policy e XSS neste guia opera o processo formal de catalogação de falhas, não apenas resume documentação de terceiros. O Elementor, por exemplo, registra hoje atenção no perfil público do WPVulnerability, com seis falhas recentes catalogadas e um histórico que inclui a CVE-2023-48777 (CVSS 9.9, corrigida na versão 3.18.2), uma brecha de upload arbitrário que permitia execução remota. Nenhum security header substitui a atualização do plugin, mas um CSP restritivo reduz a superfície de exploração de scripts injetados enquanto o patch não chega. Esse cruzamento entre header e CVE real é o que separa proteção de teatro de segurança. Para acompanhar isso de perto, veja como verificar vulnerabilidades no WordPress. --- ## Segurança no plano da FULL: R$849 por ano para 10 sites A configuração manual de security headers funciona, mas em escala vira tempo perdido editando cada `.htaccess` à mão, e é aí que o painel resolve: no plano PRO da FULL, por R$849 ao ano, o All in One Security já entra ativado nos 10 sites do plano, com firewall, varredura e hardening de cabeçalhos centralizados. Isso coloca o preço em R$85 por site por ano, com a defesa padronizada no mesmo painel em vez de espalhada por arquivos soltos. A gente vê no suporte que a maior parte dos sites que chega com problema de segurança nunca teve um único header de resposta configurado, e padronizar isso por painel elimina o erro de digitação no arquivo. Os planos completos estão em FULL.services/planos. Vale também escanear o site antes: o FULL Scan aponta plugin vulnerável de graça e sem instalar nada. --- ## Como validar os security headers depois de aplicar Validar leva menos de 1 minuto e fecha o ciclo, porque sem teste você não tem como saber se os security headers realmente chegaram ao navegador do visitante: rode o domínio no Mozilla Observatory ou no securityheaders.com e confira a nota saltar de F para A à medida que cada cabeçalho entra. O DevTools do Chrome, na aba Network, mostra os cabeçalhos de resposta de cada requisição, útil para confirmar que o Content-Security-Policy está no header certo e não duplicado. Segundo o Cloudflare Radar, no Brasil a distribuição de ataques de camada de aplicação nos últimos dias ficou em 82,4% de DDoS e 16,4% mitigados por WAF, o que mostra que a defesa precisa ser em camadas: header no navegador, firewall no servidor e CDN na borda. O OWASP Secure Headers Project ranqueia o Content-Security-Policy e o Strict-Transport-Security entre os cabeçalhos mais críticos, e a leitura completa está no projeto Secure Headers da OWASP. ---

Perguntas frequentes sobre security headers

Por que um plugin de segurança não aplica todos os security headers sozinho?

Porque firewall e header de resposta operam em camadas diferentes. O plugin de firewall, como o All in One Security, bloqueia requisição maliciosa na entrada do servidor; os security headers instruem o navegador do visitante depois que o HTML saiu. O All in One Security aplica os headers simples por painel, mas o Content-Security-Policy exige mapear os scripts do seu tema, algo que nenhum plugin faz às cegas sem arriscar quebrar o front-end do site.

É possível ativar Content-Security-Policy sem quebrar o tema do WordPress?

Sim, desde que você comece pelo modo report. Aplique o header Content-Security-Policy-Report-Only por cerca de duas semanas: ele registra cada violação sem bloquear nada. Você lê os relatórios, identifica os scripts legítimos do tema e dos plugins, libera só esses na política e só então promove para o header de bloqueio. Pular essa etapa é o que derruba o editor do Elementor e os formulários no primeiro dia, sem erro visível no painel.

Qual a diferença entre Content-Security-Policy e X-Frame-Options?

O Content-Security-Policy controla quais recursos a página pode carregar e executar, sendo a principal defesa contra XSS, com diretivas como script-src e default-src. O X-Frame-Options é mais simples e cuida de uma coisa só: impedir que seu site seja embutido num iframe de outro domínio, o que bloqueia clickjacking. O CSP moderno cobre o iframe pela diretiva frame-ancestors, mas o X-Frame-Options segue como camada de compatibilidade para navegadores antigos.

Quanto tempo leva para configurar security headers em um site WordPress?

Os quatro headers de risco baixo levam cerca de 10 minutos: bastam quatro linhas no .htaccess e um teste no Mozilla Observatory. O Strict-Transport-Security entra logo depois, em poucos minutos, desde que o HTTPS já esteja válido. O Content-Security-Policy é o demorado: o modo report roda por cerca de duas semanas de observação antes do bloqueio. No total, a base sobe rápido e o CSP maduro fica pronto em duas a três semanas.

O que o Strict-Transport-Security protege que o certificado SSL não protege?

O certificado SSL criptografa a conexão quando ela já é HTTPS, mas não impede que o visitante chegue por HTTP na primeira vez. O Strict-Transport-Security fecha essa janela: ele instrui o navegador a só aceitar HTTPS naquele domínio por um período definido em max-age, normalmente 31536000 segundos, um ano. Isso bloqueia ataque de downgrade, em que um atacante força a conexão para HTTP antes do redirecionamento acontecer. É a diferença entre ter HTTPS e exigir HTTPS.

--- ## Próximos passos para blindar o WordPress por camadas Os security headers são a camada que a maioria dos sites WordPress ignora e que custa quatro linhas para começar. O caminho honesto é incremental: aplique hoje os quatro headers de risco baixo, ative o Strict-Transport-Security assim que o HTTPS estiver firme e suba o Content-Security-Policy em modo report antes de bloquear. Cada etapa é validada no Mozilla Observatory, sem fé cega. Para continuar aprendendo, o FULL Academy reúne os tutoriais, guias e reviews de segurança em um só lugar. E ao tratar de termos como security headers, HTTPS, firewall WordPress e XSS, o glossário da FULL fecha as lacunas de conceito.