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.

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:

<IfModule mod_headers.c>
  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=()"
</IfModule>

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

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.