Security Headers

Security headers WordPress são cabeçalhos HTTP enviados pelo servidor a cada requisição que instruem o navegador a aplicar políticas de segurança no site. Cobrem desde a obrigatoriedade de conexão HTTPS até bloqueio de scripts inline, defesa contra clickjacking e controle de iframes. Configurados corretamente, fecham vetores clássicos de ataque (XSS, MIME sniffing, content injection) sem custo de performance e sem alterar o conteúdo visível ao usuário.

O que são security headers

Quando um navegador faz uma requisição a um site, o servidor responde com o HTML da página e um conjunto de cabeçalhos HTTP. Esses cabeçalhos carregam metadados: tipo de conteúdo, política de cache, idioma, cookies. Os headers de segurança são um subconjunto que define como o navegador deve tratar aquela página em termos de proteção contra ataques.

Cada header dá uma instrução explícita ao navegador. Strict-Transport-Security força HTTPS. Content-Security-Policy lista quais scripts podem rodar. X-Frame-Options diz se a página pode ser carregada em iframe. X-Content-Type-Options bloqueia o MIME sniffing. Sem eles, o navegador opera em modo permissivo, abrindo brechas que ataques exploram.

O conceito de headers segurança http virou padrão da OWASP e é checado por ferramentas como Mozilla Observatory, securityheaders.com e Lighthouse. Sites profissionais entregam nota A ou A+ nesses testes. Sites sem configuração entregam D ou F, com vulnerabilidades documentadas em cada relatório público.

O ganho é direto: pelo custo de algumas linhas no servidor, você fecha categorias inteiras de ataque. Não substitui firewall, sanitização de input nem outras camadas, mas é fundação técnica que todo site sério deveria ter ativa em produção.

Headers essenciais para WordPress

Strict-Transport-Security (HSTS) força o navegador a sempre acessar o site via HTTPS, mesmo que o usuário digite http://. O valor padrão é max-age=31536000; includeSubDomains. Combina com HTTPS bem configurado e elimina o risco de downgrade attack. Para sites com hsts wordpress ativado, é o primeiro item da checklist de segurança.

Content-Security-Policy (CSP) é o mais poderoso e também o mais delicado. Lista origens permitidas para scripts, estilos, imagens, frames e conexões. Um CSP bem feito bloqueia injeção de scripts maliciosos antes que eles executem no navegador. Em WordPress, o desafio é compatibilidade: muitos plugins carregam recursos externos e exigem ajustes finos para não quebrar funcionalidades.

X-Frame-Options previne clickjacking ao impedir que o site seja carregado dentro de iframes em outros domínios. Os valores comuns são DENY (nunca permite) ou SAMEORIGIN (permite apenas no próprio domínio). Sites que não precisam ser embedáveis em terceiros devem usar DENY como padrão.

X-Content-Type-Options: nosoff impede que o navegador faça MIME type sniffing — técnica que pode reinterpretar arquivos enviados como imagens como se fossem scripts. Referrer-Policy controla o que vai no header Referer quando o usuário sai para outro site. Permissions-Policy define quais APIs do navegador (câmera, microfone, geolocalização) o site pode usar. Cada um fecha um vetor específico, e juntos formam a base do hardening.

Como implementar via .htaccess

Em hospedagens com Apache (a maioria das opções compartilhadas e parte das gerenciadas), o caminho mais direto é editar o .htaccess na raiz do site WordPress. Os headers são adicionados via diretiva Header sempre dentro de um bloco IfModule mod_headers.c, garantindo que o módulo está disponível antes de aplicar.

Um bloco mínimo recomendado inclui Strict-Transport-Security com max-age de um ano, X-Frame-Options SAMEORIGIN, X-Content-Type-Options nosniff, Referrer-Policy strict-origin-when-cross-origin e Permissions-Policy restritivo. Esse pacote dá nota B ou A em securityheaders.com sem quebrar nada.

O csp wordpress merece tratamento à parte. Por usar muitos plugins que carregam scripts inline e recursos externos, aplicar CSP estrito de cara costuma quebrar partes do site. A prática recomendada é começar em modo Report-Only (Content-Security-Policy-Report-Only), monitorar os relatórios, ajustar a política aos recursos legítimos e só então mudar para enforcement.

Em servidores Nginx, a sintaxe muda: as diretivas vão no bloco server ou location do arquivo de configuração, no formato add_header Nome “Valor” always. A lógica é a mesma. Sites em hospedagens gerenciadas costumam expor uma interface de painel para configurar headers sem mexer em arquivo, simplificando o processo.

Como testar security headers

Mozilla Observatory (observatory.mozilla.org) é a referência aberta. Você cola a URL, ele faz uma série de testes e devolve nota de A+ a F com explicação de cada item. Mostra exatamente quais headers estão presentes, quais estão ausentes e quais estão mal configurados. É o ponto de partida obrigatório para qualquer auditoria de hardening.

Securityheaders.com (mantido por Scott Helme, referência da indústria) é mais focado em headers especificamente. Devolve nota e relatório com sugestões diretas de melhoria. Útil em check-ups recorrentes para garantir que mudanças no servidor não derrubaram a configuração.

O DevTools do Chrome também ajuda no debug pontual. Abra a aba Network, recarregue a página, clique no documento principal e veja a aba Headers. Você visualiza os headers reais retornados pelo servidor — o que combinado com a aba Console mostra eventuais violações de CSP em tempo real durante navegação.

Para sites WordPress que querem avançar no hardening, vale combinar a configuração de headers com auditorias periódicas em busca de novas vulnerabilidades e com práticas mais amplas de hardening WordPress. Headers sozinhos não bloqueiam plugin desatualizado nem senha fraca.

Para gerenciar headers, monitoramento de tentativas de ataque, firewall e bloqueio de IPs em um único painel, a FULL Services entrega o AIOS (All-In-One Security) já licenciado dentro da stack profissional, com configuração de security headers via interface visual e proteção integrada contra os ataques mais comuns ao ecossistema WordPress. Em vez de empilhar plugins e editar .htaccess manualmente, você roda em um conjunto pré-validado em produção.