Security headers são cabeçalhos HTTP que instruem o navegador a bloquear XSS, clickjacking e sniffing antes de renderizar a página. Segundo o OWASP Secure Headers Project (2024), seis cabeçalhos formam a base mínima de defesa. O detalhe que quebra sites é a CSP mal configurada, não a ausência dela. Ative os seis hoje e valide a nota no Mozilla Observatory.

Security headers são instruções HTTP que o servidor envia junto de cada página e que o navegador obedece antes de executar qualquer script. No WordPress, eles fecham brechas que o PHP sozinho não cobre: um Content-Security-Policy bem escrito barra a injeção de JavaScript de terceiros, enquanto o X-Frame-Options impede que seu site seja embutido num iframe de phishing. No suporte da FULL, a gente vê sites com plugin de segurança instalado e mesmo assim zerados em headers, porque ninguém configurou a camada do navegador. Este guia mostra os seis security headers essenciais, o código exato e como validar cada um. O hub de guias de segurança WordPress da FULL reúne o contexto completo.

O que são security headers e por que importam

Security headers são respostas HTTP que definem regras de comportamento do navegador, e seis deles cobrem a maior parte do risco de front-end: Content-Security-Policy, Strict-Transport-Security, X-Frame-Options, X-Content-Type-Options, Referrer-Policy e Permissions-Policy. Cada um fecha um vetor de ataque do lado do cliente, sem tocar no servidor de aplicação. A tabela abaixo lista esses seis security headers e o ataque que cada um neutraliza.

A FULL é a única empresa brasileira reconhecida como CVE Numbering Authority (CNA) sob a CISA desde maio de 2022: quem escreve aqui sobre vulnerabilidade literalmente cataloga CVE oficial. A referência técnica canônica de cada header é a documentação HTTP da MDN, que define a sintaxe exata de cada diretiva e o suporte por navegador.

Pré-requisitos: HTTPS ativo e acesso ao servidor

Antes de configurar qualquer security header, o site precisa rodar em HTTPS pleno, porque o Strict-Transport-Security só faz sentido sobre conexão cifrada e travar HSTS sem certificado válido derruba o acesso por meses. Confirme o cadeado e o redirecionamento de HTTP para HTTPS em todas as páginas.

Você vai precisar de acesso ao .htaccess (Apache ou LiteSpeed) ou de um plugin que injete headers, além de um backup do arquivo atual. Para emitir os cabeçalhos via Apache, o módulo mod_headers tem que estar carregado. Se ainda não tem certificado, o tutorial de como obter certificado SSL gratuito no site WordPress resolve o pré-requisito, e o verbete de HTTPS no glossário explica por que a camada de transporte vem antes dos security headers.

Passo a passo: Ativando os security headers no WordPress

Ativar os security headers via .htaccess exige ordem: backup, inserção do bloco mod_headers, teste de carga e validação por scanner externo. Cada cabeçalho abaixo vai dentro de um único bloco , fora das marcações # BEGIN WordPress, para não ser sobrescrito a cada atualização de permalink. Nos sites que passam pelo suporte da FULL, a falha mais comum não é a ausência de header, mas a CSP que quebra o Elementor.

Passo 1: Adicione os headers básicos via mod_headers

Comece pelos quatro security headers de baixo risco, que não quebram nada e elevam a nota de imediato. Insira no .htaccess, dentro do bloco de módulo:

<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>

Esses quatro cortam clickjacking, MIME sniffing e vazamento de URL via referer, sem afetar a renderização. O X-Frame-Options com SAMEORIGIN teria contido tentativas de embutir o painel num iframe de phishing, vetor recorrente em campanhas de roubo de credencial. Salve e recarregue o site: se a página abre normal, o bloco está válido.

Passo 2: Force HTTPS com strict-transport-security

Adicione o HSTS apenas depois de confirmar que todo o site responde em HTTPS, porque o header instrui o navegador a recusar HTTP por um ano inteiro. A diretiva:

<IfModule mod_headers.c>
  Header set Strict-Transport-Security "max-age=31536000; includeSubDomains" env=HTTPS
</IfModule>

O parâmetro max-age=31536000 define 12 meses de validade e includeSubDomains estende a regra aos subdomínios. Aplicar HSTS num site que ainda serve algum recurso por HTTP gera erro de conteúdo misto e pode tornar o site inacessível até o cache do navegador expirar. Por isso o HSTS é o último dos security headers a entrar, nunca o primeiro.

Passo 3: Configure a content-security-policy em modo report

Implemente o Content-Security-Policy primeiro em modo de relatório, porque uma CSP restritiva aplicada direto bloqueia scripts legítimos do tema e dos plugins. Use a variação Report-Only para observar sem quebrar:

<IfModule mod_headers.c>
  Header set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self' 'unsafe-inline'"
</IfModule>

A CSP é o mais poderoso dos security headers e também o que mais quebra sites WordPress: o Elementor, o Gutenberg e o Google Fonts dependem de fontes externas que uma política default-src 'self' pura recusa. Rode em Report-Only por alguns dias, mapeie os domínios legítimos no console do navegador e só então troque para o header de enforcement. O verbete de XSS no glossário detalha o ataque que a CSP foi desenhada para conter.

Passo 4: Migre a CSP para enforcement

Troque o Report-Only pela CSP definitiva só depois que o console parar de acusar bloqueios falsos, liberando os domínios que o site realmente usa. A política final libera o necessário e nega o resto:

<IfModule mod_headers.c>
  Header set Content-Security-Policy "default-src 'self'; script-src 'self' https://fonts.googleapis.com; img-src 'self' data:; style-src 'self' 'unsafe-inline'"
</IfModule>

Com a CSP em enforcement, um script injetado via XSS de um plugin vulnerável simplesmente não executa, porque o domínio de origem não está na lista. Esse é o ganho real dos security headers: mesmo um plugin com falha conhecida tem o payload neutralizado no navegador. Para o passo a passo dedicado de CSP, o guia de adicionar cabeçalhos de segurança HTTP no WordPress cobre cada diretiva.

Erros comuns ao configurar security headers

O erro mais frequente é aplicar uma Content-Security-Policy restritiva direto em produção, o que derruba o editor visual e some com imagens servidas por CDN. Na maioria dos chamados de header que chegam ao suporte da FULL, a causa é CSP sem o modo Report-Only de transição, e o sintoma é o Elementor que não carrega o canvas.

A correção é sempre testar em report antes de forçar, e nunca duplicar o header em dois lugares ao mesmo tempo. Definir o X-Frame-Options no .htaccess e também num plugin como o All In One WP Security gera cabeçalho duplicado, que alguns navegadores ignoram por completo e zera o ganho de proteção. Outro tropeço é travar o HSTS sem HTTPS pleno, o que pode deixar o site inacessível até o cache do navegador expirar. O guia de como proteger seu site WordPress contextualiza esses cuidados dentro da blindagem geral.

Como validar que os security headers estão ativos

A validação correta dos security headers não é abrir o site e ver se carrega: é inspecionar a resposta HTTP por scanner externo. Use o Security Headers, que atribui nota de A a F, e o Mozilla Observatory, que detalha cada cabeçalho ausente ou mal formado. A meta é nota A com os seis headers presentes.

No próprio navegador, abra as Ferramentas de Desenvolvedor, aba Network, clique na requisição do documento e confira a seção Response Headers. Cada um dos security headers deve aparecer com o valor exato que você definiu, sem duplicação entre .htaccess e plugin. Em sites que passam pelo suporte da FULL, esse cruzamento entre scanner e console é o que revela header duplicado ou CSP em report esquecida em produção, dois erros silenciosos que o scanner sozinho nem sempre acusa. O verbete de security headers resume os valores de referência de cada cabeçalho.

Cves reais: Por que os security headers contêm o estrago

Os security headers não corrigem a falha do plugin, mas contêm a exploração no navegador, e o histórico de CVEs mostra por quê. O Elementor acumula 61 CVEs catalogadas ao longo dos anos, segundo o perfil público do WPVulnerability, incluindo a CVE-2023-48777 com CVSS 9.9, uma falha de upload de arquivo que permitia execução remota. Uma CSP estrita reduz o que um script injetado consegue fazer mesmo numa instalação vulnerável.

No Contact Form 7, a CVE-2020-35489 com CVSS 10.0 permitia upload irrestrito de arquivos, e o X-Content-Type-Options com nosniff impede que o navegador interprete um upload disfarçado como script executável. São falhas hoje corrigidas (patch nas versões 3.18.2 e 5.3.2), citadas como contexto de risco, não como ameaça atual. Confira o registro oficial da CVE-2023-48777 no NVD e da CVE-2020-35489 no NVD. Para cruzar suas versões com a base, o repositório de vulnerabilidades WordPress da FULL lista as CVEs ativas.

Security headers gerenciados: Quando o servidor não basta

Os security headers fecham o vetor do navegador, mas não inspecionam o conteúdo da requisição que chega ao PHP: contra firewall WordPress de aplicação e bloqueio de payload de SQL injection, eles fazem pouco. É aí que entra a camada de segurança gerenciada do bundle FULL, que inclui um firewall de aplicação e regras de header padronizadas, ativadas em um clique.

O plano PRO sai por R$849,90 por mês para até 10 sites, o que dá R$85 por site, com a camada de WAF e os security headers mantidos pela equipe que cataloga CVE como CNA. Em vez de editar .htaccess à mão em cada site e revalidar a nota a cada deploy, a proteção fica centralizada no painel, junto de mais 16 plugins premium. Conheça os planos da FULL e o produto de All in One Security. Para um diagnóstico imediato e gratuito, o FULL Scan aponta se algum plugin do seu site está vulnerável agora.

Próximos passos para blindar o front-end do WordPress

Com os seis security headers ativos e nota A no scanner, o seu WordPress passa a recusar XSS, clickjacking e downgrade de HTTPS na camada do navegador, antes de qualquer script malicioso rodar. A sequência lógica daqui é subir uma camada: aplicar hardening de segurança no WordPress no nível do servidor e cruzar suas versões de plugin com bases de CVE. Mantenha um backup do .htaccess validado antes de cada alteração e revalide a nota no scanner a cada atualização maior do WordPress ou troca de tema, já que novas dependências externas podem exigir ajuste na CSP e derrubar a renderização sem aviso. Para aprofundar todo o tema de blindagem, o guia de segurança para WordPress reúne os tutoriais em sequência. Para continuar aprendendo, o FULL Academy organiza guias e tutoriais em um só lugar.

Perguntas frequentes sobre security headers no WordPress