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.

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 janeiro e junho de 2026.

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.

• Se o tema usa Elementor com scripts inline → comece o Content-Security-Policy em modo Report-Only e libere os nonces antes de bloquear.
• Se o site é WooCommerce com gateway em iframe → troque X-Frame-Options DENY por frame-ancestors no Content-Security-Policy.
• Se o Strict-Transport-Security incluir preload → confirme SSL ativo em todos os subdomínios antes, senão um subdomínio sem certificado fica inacessível.
• Se a hospedagem é Nginx, não Apache → use a diretiva add_header no bloco server, porque o .htaccess é ignorado no Nginx.

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

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.