# Cabeçalhos de segurança HTTP no WordPress: Os 6 essenciais Cabeçalhos de segurança HTTP são instruções no servidor que mandam o navegador bloquear ataques antes do conteúdo carregar. Segundo o Cloudflare Radar (2026), 82,4% dos ataques de camada de aplicação no Brasil aparecem como DDoS. Seis cabeçalhos cobrem a maioria dos riscos comuns. Configure por .htaccess ou plugin e valide o resultado. Os cabeçalhos de segurança HTTP são linhas que o servidor envia junto com cada página e que ensinam o navegador a recusar comportamento perigoso, como carregar script de origem desconhecida ou abrir o site dentro de um iframe falso. No WordPress, um certificado SSL sozinho não entrega isso: ele cifra o tráfego, mas não diz ao navegador o que recusar. A FULL gerencia 150 mil sites conectados e, nos tickets de suporte, ataque que passa por site com HTTPS ativo costuma explorar justamente a ausência desses cabeçalhos. Este guia mostra os 6 essenciais e como aplicá-los. Para o panorama completo, veja o guias de segurança WordPress da FULL. --- ## Os 6 cabeçalhos de segurança HTTP essenciais Seis cabeçalhos de segurança HTTP cobrem a maior parte da exposição de um WordPress comum: Strict-Transport-Security, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy e Permissions-Policy. A combinação deles é o que o Mozilla Observatory mede para dar a nota de A a F. A tabela resume cada um.

Legenda: o servidor anexa os cabeçalhos a cada resposta, e o navegador aplica a regra antes de renderizar a página.

Os 6 cabeçalhos de segurança HTTP e o ataque que cada um bloqueia
Cabeçalho O que faz Ataque que mitiga
Strict-Transport-SecurityForça o navegador a usar só HTTPS por um período definidoDowngrade para HTTP e interceptação na rede
Content-Security-PolicyLista as origens de script e estilo permitidasCross-site scripting e injeção de código
X-Frame-OptionsImpede que o site seja embutido em iframe de terceirosClickjacking e roubo de clique
X-Content-Type-OptionsProíbe o navegador de adivinhar o tipo do arquivoMIME sniffing e upload disfarçado
Referrer-PolicyControla qual URL vaza ao sair do siteVazamento de token em parâmetros de URL
Permissions-PolicyDesliga câmera, microfone e geolocalização por padrãoAbuso de API do navegador por script invasor
O MDN Web Docs da Mozilla documenta o comportamento exato de cada diretiva. Aplicar os seis em conjunto, e não isolados, move a nota de F para A no scanner. --- ## Por que o SSL sozinho não basta no WordPress Instalar SSL resolve a confidencialidade do tráfego, mas não impede que um script malicioso rode dentro da página: em boa parte dos casos de invasão que chegam ao suporte da FULL, o site tinha o cadeado verde e mesmo assim foi comprometido. SSL e cabeçalhos de segurança HTTP são camadas diferentes. O SSL cifra o caminho entre navegador e servidor; os cabeçalhos definem o que o navegador aceita executar depois que o conteúdo chega. Um exemplo concreto: o cross-site scripting injeta JavaScript que o navegador roda como se fosse seu, e nenhum certificado impede isso, como detalha como o cross-site scripting afeta o WordPress. O Content-Security-Policy corta esse vetor ao recusar script de origem não declarada. Para fechar a porta da rede, o redirecionamento forçado para HTTPS trabalha em par com o Strict-Transport-Security. --- ## Vulnerabilidades reais que esses cabeçalhos atenuam Cabeçalhos de segurança HTTP não substituem patch de plugin, mas reduzem o estrago quando uma falha é explorada antes da correção. O caso mais didático é o CVE-2020-35489 no Contact Form 7, com CVSS 10.0, que permitia upload irrestrito de arquivo. Nesse cenário, um X-Content-Type-Options nosniff com Content-Security-Policy limita o que o arquivo enviado executa no navegador da vítima. A falha foi corrigida na versão 5.3.2, e hoje o Contact Form 7 está seguro, segundo o WPVulnerability. No All in One Security, o CVE-2026-8438 (CVSS 7.2) saiu na versão 5.4.8, mantendo o risco atual em atenção, sem nada crítico em aberto. A FULL é a única CNA brasileira reconhecida pela CISA desde maio de 2022, autorizada a atribuir identificadores CVE oficiais. Você confere o registro de cada falha citada no NVD/NIST. O firewall de aplicação do WordPress complementa os cabeçalhos ao filtrar a requisição antes do PHP. --- ## Passo a passo: Como aplicar cabeçalhos de segurança HTTP Aplicar os cabeçalhos de segurança HTTP leva poucos minutos por três caminhos: editar o .htaccess no Apache, ajustar o bloco server no Nginx, ou usar o All in One Security sem tocar em código. Os 4 passos abaixo cobrem o método por .htaccess, o mais comum em hospedagem compartilhada brasileira. ### Passo 1: Faça backup do .htaccess antes de editar Antes de tocar no arquivo, baixe uma cópia do .htaccess atual: uma diretiva mal formada derruba o site inteiro com erro 500. Use o gerenciador de arquivos da hospedagem ou FTP e guarde o original em local seguro. Esse cuidado de 30 segundos evita o cenário mais comum de ticket: site fora do ar após edição direta. Quem quer entender cada flag do arquivo encontra o detalhamento em controles de segurança no .htaccess. ### Passo 2: Adicione os cabeçalhos no bloco do Apache Abra o .htaccess na raiz do WordPress e cole o bloco dentro de ``. Cada linha usa a diretiva `Header set` seguida do nome e do valor do cabeçalho. Comece com valores conservadores: `Strict-Transport-Security "max-age=31536000"` e `X-Frame-Options "SAMEORIGIN"` raramente quebram algo. O módulo mod_headers precisa estar ativo, o que é padrão no Apache 2.4 da maioria das hospedagens gerenciadas. ### Passo 3: Construa o content-security-policy aos poucos O Content-Security-Policy é o cabeçalho que mais quebra layout, então monte-o em modo de relatório primeiro, com `Content-Security-Policy-Report-Only`. Isso registra o que seria bloqueado sem bloquear de fato. Temas com Elementor e Gutenberg carregam scripts inline, e uma diretiva script-src restrita demais derruba o editor. Libere as origens reais que aparecem no relatório e só então troque para o modo de bloqueio. ### Passo 4: Valide a nota no mozilla observatory Depois de salvar, rode o domínio no Mozilla Observatory ou no securityheaders.com para ver a nota de A a F e o que ainda falta. A ferramenta lista cada cabeçalho ausente e sugere o valor recomendado. Repita o teste a cada ajuste até chegar em A. Datas de teste deste guia: configurações validadas entre e . --- ## Aplicar por plugin: O caminho sem código Para quem não administra o servidor, o All in One Security aplica os seis cabeçalhos de segurança HTTP numa aba dedicada com caixas de seleção, sem editar o .htaccess. O risco atual do plugin é de atenção, com 0 falhas críticas sem patch e a última correção na versão 5.4.8, segundo o perfil público do WPVulnerability. A vantagem é a reversão em um clique: se um cabeçalho quebra o checkout, você desmarca a caixa em vez de caçar a linha no arquivo. A limitação é que o cabeçalho só entra depois que o WordPress carrega, um passo atrás do servidor. Sites atrás de um CDN têm uma terceira opção: aplicar a regra na borda. Veja o detalhe em guia de security headers no WordPress. Cada abordagem tem um foco: o .htaccess compete por controle no servidor, o All in One Security por interface sem código, e o CDN por velocidade na borda. --- ## Onde os cabeçalhos quebram o site e como evitar Três combinações de cabeçalhos de segurança HTTP causam a maioria dos chamados, e saber a causa poupa horas de diagnóstico. A mais comum: em sites WooCommerce que embutem o iframe do gateway no checkout, `X-Frame-Options DENY` global bloqueia a janela de pagamento sem aviso. O Strict-Transport-Security com preload e SSL ausente em um subdomínio deixa esse subdomínio fora do ar até o certificado sair; por isso o preload entra por último. Quem expõe a API deve revisar a proteção da REST API do WordPress em paralelo. --- ## Proteja vários sites com o bundle FULL Configurar cabeçalhos, manter o firewall ativo e acompanhar CVE em um site só é viável na unha; em uma carteira de dez ou vinte sites, vira trabalho repetitivo e propenso a erro. O plano PRO da FULL custa R$849 e cobre até dez sites, o que dá R$85 por site. Esse plano inclui o All in One Security junto de outros 16 plugins premium, como o WP Rocket e o Rank Math PRO. A gente vê no suporte da FULL que o cliente de agência some com a fila de chamados de segurança quando padroniza cabeçalhos e firewall no mesmo bundle, em vez de licenciar plugin a plugin em cada site separado. Você ativa tudo em um clique e replica o mesmo padrão entre todos os sites da conta. Veja os planos em FULL.services/planos e a página do All in One Security nas soluções da FULL. --- --- ---

Perguntas frequentes sobre cabeçalhos de segurança HTTP

Por que apenas instalar SSL não protege o WordPress por completo?

SSL cifra o tráfego entre navegador e servidor, mas não diz ao navegador o que recusar depois que o conteúdo chega. Um ataque de cross-site scripting injeta JavaScript que roda como se fosse seu, e o certificado não impede isso. Os cabeçalhos de segurança HTTP, como o Content-Security-Policy, é que recusam script de origem não declarada. SSL e cabeçalhos são camadas diferentes e complementares.

É possível adicionar cabeçalhos de segurança HTTP sem editar código?

Sim, é possível. Um plugin como o All in One Security aplica os seis cabeçalhos numa aba dedicada com caixas de seleção, sem você tocar no .htaccess. A vantagem é a reversão em um clique se algum cabeçalho quebrar uma função. A limitação é que o cabeçalho só entra depois que o WordPress carrega, um passo atrás do servidor em performance. Para a maioria dos sites, o ganho de segurança compensa.

Qual a diferença entre aplicar o cabeçalho no .htaccess e no plugin?

O .htaccess aplica o cabeçalho no nível do Apache, antes do PHP rodar, o que é mais rápido e funciona mesmo se o WordPress falhar. O plugin aplica depois que o WordPress carrega, mas oferece interface visual e reversão em um clique. No Nginx o .htaccess é ignorado e você usa a diretiva add_header no bloco server. Servidor para controle máximo, plugin para conveniência.

Quanto custa proteger vários sites com cabeçalhos de segurança na FULL?

O plano PRO da FULL custa R$849 e cobre até dez sites, o que dá R$85 por site, incluindo o All in One Security e outros 16 plugins premium. Para uma agência que gerencia carteira, padronizar a configuração de cabeçalhos e firewall no mesmo bundle sai mais barato que licenciar plugin por plugin. A ativação é em um clique e o padrão se replica entre os sites da conta.

O que o cabeçalho Content-Security-Policy bloqueia na prática?

O Content-Security-Policy bloqueia scripts, estilos e recursos de origens que você não declarou explicitamente na política. Na prática, ele corta o cross-site scripting recusando JavaScript injetado por terceiros antes de rodar. É o cabeçalho mais poderoso e o que mais quebra layout, porque temas com Elementor e Gutenberg usam scripts inline. Por isso ele deve ser montado em modo de relatório primeiro, liberando as origens reais aos poucos.

--- ## Próximos passos para blindar seu WordPress Os cabeçalhos de segurança HTTP são a camada que transforma um site com HTTPS em um site que o navegador defende ativamente, e a ordem certa de aplicação evita os três conflitos mais comuns: Content-Security-Policy rígido demais, X-Frame-Options no checkout e preload de HSTS sem SSL completo. Comece com os valores conservadores, valide no Mozilla Observatory e só endureça o que o relatório confirmar como seguro. Para escanear seu site agora e ver se algum plugin está vulnerável, use o FULL Scan, gratuito e sem instalação. Para aprofundar cada tópico de proteção, o guia de segurança para WordPress reúne os tutoriais em sequência, e o FULL Academy mantém tudo num só lugar para continuar aprendendo.