🔒 Cabeçalhos de segurança HTTP para WordPress: guia completo de configuração

O seu site WordPress está a funcionar, o plugin de segurança está instalado, mas uma verificação no securityheaders.com dá-lhe um F. Parece-lhe familiar?

Os cabeçalhos de segurança HTTP são uma camada invisível de proteção que é esquecida mesmo depois de configurar uma firewall e a autenticação de dois fatores. Não precisam de renovações de licença, não sobrecarregam o servidor e bloqueiam classes inteiras de ataques: desde clickjacking até sequestro de sessão. E demoram 10 minutos a adicionar.

A seguir, passo a passo: quais os cabeçalhos de que realmente precisa, como configurá-los via.htaccess, functions.php ou um plugin, e como verificar se a proteção está a funcionar, e não apenas listada.

💡 Visão geral rápida:

• Verifique os cabeçalhos atuais do seu site através do securityheaders.com ou do Mozilla Observatory para ver a imagem real
• Ative um conjunto básico de 4 a 5 cabeçalhos: X-Content-Type-Options, X-Frame-Options, HSTS, Referrer-Policy, Permissions-Policy
• Escolha o seu método: um par de linhas no.htaccess (Apache/LiteSpeed), um snippet no functions.php ou o plugin Headers Security Advanced & HSTS WP
• Deixe o CSP para mais tarde: é complicado de configurar e quebra o Gutenberg se for feito sem testes
• Após a implementação, verifique novamente: uma pontuação A+ é alcançável em 10 minutos

O que são os cabeçalhos de segurança HTTP

Quando um navegador solicita uma página, o servidor web envia de volta mais do que apenas código HTML. Cada resposta HTTP contém campos de serviço, os cabeçalhos. Alguns tratam da cache e do tipo de conteúdo, e outros tratam da segurança.

O navegador lê os cabeçalhos de segurança antes mesmo de começar a renderizar a página. Se o servidor disser «proíbo a incorporação deste site em frames», o navegador não o fará, mesmo que o código da página contenha um <iframe>. Se o servidor disser «use apenas HTTPS durante um ano», o navegador memoriza e não acederá à versão HTTP, mesmo que o utilizador a digite manualmente.

Nenhum JavaScript, nenhum plugin, nenhuma firewall afeta isto. Isto está ao nível do protocolo. É precisamente por isso que os cabeçalhos são uma linha de defesa separada e independente.

Porque é que um site WordPress precisa disto

Plugins de segurança como o Wordfence ou o Solid Security fecham vulnerabilidades ao nível da aplicação: força bruta, injeções, uploads maliciosos. Os cabeçalhos HTTP funcionam um nível acima: protegem o próprio canal de comunicação entre o servidor e o visitante.

Eis o que os cabeçalhos corretamente configurados bloqueiam:

• Clickjacking. Um atacante incorpora o seu site num frame transparente por cima do dele e interceta os cliques do utilizador. Bloqueado pelo cabeçalho X-Frame-Options ou pela diretiva frame-ancestors no CSP.

• MIME sniffing. O navegador tenta «adivinhar» o tipo de ficheiro e pode executar uma imagem carregada como JavaScript. Bloqueado por X-Content-Type-Options: nosniff.

• Sequestro de sessão. Um atacante numa rede Wi-Fi aberta altera a resposta do servidor e rouba os cookies de início de sessão. O HSTS proíbe o navegador de aceder à versão HTTP do site.

• Fuga de referrer. Ao seguir um link externo, o site de destino vê de que página o utilizador veio, incluindo o URL com parâmetros. O Referrer-Policy limita isto.

• Acesso não autorizado ao dispositivo. Uma página web solicita o microfone, a câmara ou a geolocalização sem o conhecimento do utilizador. O Permissions-Policy bloqueia tais pedidos ao nível do navegador.

O CSP adiciona outra camada: define explicitamente quais os domínios que podem carregar scripts, estilos e tipos de letra. Mesmo que código malicioso entre na base de dados, o navegador não o executará porque a origem não está na lista de permissões. Mas o CSP exige cuidado: um pequeno erro e o editor Gutenberg deixa de funcionar.

Cabeçalhos de segurança HTTP essenciais: o que incluem e porquê

Abaixo estão os cabeçalhos que vale a pena configurar em qualquer site WordPress. Para cada um, especificamos: contra que ataque protege, o valor recomendado e onde podem surgir quebras.

X-Content-Type-Options

O mais simples e seguro de configurar. O único valor válido é nosniff. O navegador deixa de «adivinhar» o tipo MIME de um ficheiro com base no seu conteúdo e confia apenas no tipo que o servidor enviou no cabeçalho Content-Type.

Sem este cabeçalho, o navegador pode tratar uma imagem carregada por um utilizador como um script e executá-la, um cenário clássico de ataque de upload de ficheiros.

Valor recomendado: nosniff

Riscos de quebra: mínimos. Só podem ocorrer problemas se o servidor servir ficheiros com um Content-Type incorreto, mas isso é um problema à parte que vale a pena corrigir em vez de mascarar.

X-Frame-Options

Controla se o seu site pode ser incorporado num <frame>, <iframe> ou <object> noutro site.

Dois valores principais:

• DENY, uma proibição total de incorporação. Proteção máxima.
• SAMEORIGIN, incorporação permitida apenas a partir do mesmo domínio. Necessário se você próprio usa frames nas suas páginas (por exemplo, pré-visualização no painel de administração).

Para a maioria dos sites WordPress, SAMEORIGIN funciona. Se tiver a certeza de que não são usados frames, defina DENY.

Valor recomendado: SAMEORIGIN

Riscos de quebra: alguns plugins usam iframes para pré-visualizações. Se algo deixar de ser exibido no painel de administração após ativar DENY, mude para SAMEORIGIN.

Strict-Transport-Security (HSTS)

Diz ao navegador: «durante os próximos N segundos, acede a este domínio apenas via HTTPS». Protege contra ataques de downgrade e sequestro de cookies em redes abertas.

O parâmetro chave é max-age. Recomenda-se começar com um valor pequeno (um dia ou uma semana) e, após verificação, aumentá-lo para um ano.

O parâmetro opcional includeSubDomains estende a regra a todos os subdomínios, importante se tiver vários e usar uma CDN.

O parâmetro preload adiciona o site à lista global de HSTS dos navegadores: Chrome, Firefox e Safari acederão ao seu domínio apenas via HTTPS, mesmo antes do primeiro pedido. Submeta uma candidatura através de hstspreload.org.

Valor recomendado: max-age=31536000; includeSubDomains

Riscos de quebra: se ativar o HSTS e o certificado SSL expirar, os utilizadores não conseguirão aceder ao site de todo. Mantenha a atenção na renovação automática do certificado.

Referrer-Policy

Gere que informação sobre a página de origem o navegador envia ao seguir um link para outro site.

Valores principais, do mais restritivo ao mais permissivo:

• no-referrer, não é enviado absolutamente nada.
• strict-origin-when-cross-origin, para um domínio diferente, é enviado apenas o domínio (sem caminho ou parâmetros); para o seu próprio, o URL completo. O equilíbrio ideal entre privacidade e analítica.
• strict-origin, sempre apenas o domínio, sem caminho.

Se não quiser que os sites de destino saibam de onde veio o utilizador, defina no-referrer. Mas tenha em mente: perderá o tráfego de referência na sua própria analítica.

Valor recomendado: strict-origin-when-cross-origin

Riscos de quebra: mínimos. Alguns serviços de terceiros podem exigir um referrer para funcionar (por exemplo, gateways de pagamento com verificação de origem). Pode detetar esses casos através da consola do navegador.

Permissions-Policy

Anteriormente chamada Feature-Policy. Restringe o acesso da página web a APIs de «hardware» do navegador: microfone, câmara, geolocalização, USB, APIs de pagamento, e assim por diante.

Formato: название-фичи=(разрешённый-источник). Por exemplo:

1
Permissions-Policy: camera=(), microphone=(), geolocation=(self)

Este exemplo bloqueia completamente o acesso à câmara e ao microfone para todas as origens, e permite a geolocalização apenas para o próprio site (self).

Lista completa de funcionalidades na MDN. Para um site WordPress sem videochamadas e funcionalidades PWA, é suficiente bloquear a câmara, o microfone e a geolocalização; o resto é opcional.

Valor recomendado: depende da funcionalidade do site. Mínimo: camera=(), microphone=(), geolocation=(self).

Riscos de quebra: se o site tiver funcionalidades de videochamada, PWA ou WebUSB, verifique quais as funcionalidades de que necessita e não as bloqueie.

Content-Security-Policy (CSP)

O cabeçalho mais poderoso e mais perigoso de configurar. Define uma lista de permissões de origens para scripts, estilos, fontes, imagens, frames e outros recursos.

Exemplo de uma política mínima para WordPress:

1
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:;
2

*Porquê unsafe-inline e unsafe-eval:* o WordPress, o Gutenberg e dezenas de plugins geram scripts inline e usam eval(). Sem estas diretivas, o painel de administração simplesmente não funciona. Este é o preço da compatibilidade.

Recomendação: não ative o CSP primeiro. Configure os outros 5 cabeçalhos primeiro. Implemente o CSP apenas se tiver recursos para testes e monitorização; comece com o modo Content-Security-Policy-Report-Only e recolha registos de violações durante um par de semanas antes de mudar para o modo de aplicação.

Riscos de quebra: elevados. Um erro no CSP pode quebrar completamente o frontend e o painel de administração. Teste sempre num ambiente de staging ou via Report-Only.

Como verificar os cabeçalhos atuais do seu site

Antes de configurar, uma auditoria. Três ferramentas, da simples à detalhada:

• securityheaders.com, introduza o URL e obtenha uma pontuação de A+ a F com uma discriminação para cada cabeçalho. Grátis, sem registo.

• Mozilla Observatory, uma auditoria mais detalhada: avalia não só os cabeçalhos, mas também as configurações de TLS, atributos de cookies, CORS e outros aspetos. Também grátis.

• Chrome DevTools, abra o separador Network, selecione qualquer pedido para o seu site e veja a secção Response Headers. Uma forma rápida de verificar se as alterações «pegaram» após editar o.htaccess.

Verifique o seu site agora mesmo. Se a pontuação for inferior a B, nem sequer tem os cabeçalhos básicos, e um terço dos itens abaixo configura em 5 minutos.

Formas de configurar cabeçalhos HTTP no WordPress

Três caminhos, do manual ao automático. Escolha com base na sua situação.

Método 1: via.htaccess (Apache/LiteSpeed)

O método mais rápido para sites em Apache ou LiteSpeed. Adicione ao ficheiro .htaccess na raiz do site (antes de # BEGIN WordPress):

1
<IfModule mod_headers.c>
2
    Header set X-Content-Type-Options "nosniff"
3
    Header set X-Frame-Options "SAMEORIGIN"
4
    Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"
5
    Header set Referrer-Policy "strict-origin-when-cross-origin"
6
    Header set Permissions-Policy "camera=(), microphone=(), geolocation=(self)"
7
</IfModule>

O invólucro <IfModule mod_headers.c> garante que o site não vai abaixo com um erro 500 se o módulo mod_headers não estiver ativo. Se tiver a certeza de que está ativo, pode omiti-lo.

Depois de guardar, execute no terminal (se tiver WP-CLI) ou simplesmente abra o site e verifique os cabeçalhos através do securityheaders.com. As alterações no .htaccess aplicam-se instantaneamente; não é necessário reiniciar o servidor.

Método 2: via functions.php (Nginx / universal)

Funciona independentemente do servidor web, adequado tanto para Nginx como para Apache. Adicione ao functions.php do seu tema filho ou através do plugin Code Snippets:

1
function sdstudio_add_security_headers() {
2
    header( 'X-Content-Type-Options: nosniff' );
3
    header( 'X-Frame-Options: SAMEORIGIN' );
4
    header( 'Strict-Transport-Security: max-age=31536000; includeSubDomains' );
5
    header( 'Referrer-Policy: strict-origin-when-cross-origin' );
6
    header( 'Permissions-Policy: camera=(), microphone=(), geolocation=(self)' );
7
}
8
add_action( 'send_headers', 'sdstudio_add_security_headers' );

O hook send_headers é acionado antes de o WordPress começar a enviar conteúdo, pelo que os cabeçalhos seguem logo na primeira resposta do servidor.

Para Nginx, este método é preferível a mexer na configuração do servidor (especialmente em alojamento partilhado, onde o acesso ao nginx.conf muitas vezes não está disponível). A desvantagem: os cabeçalhos só funcionam para pedidos PHP que passam pelo WordPress. Ficheiros estáticos (imagens, CSS, JS) são servidos diretamente pelo Nginx e não recebem os cabeçalhos. Estes exigem configuração ao nível do servidor.

Método 3: via o plugin headers security advanced & hsts wp

Se não quiser mexer em código, use um plugin dedicado. O Headers Security Advanced & HSTS WP reúne todos os cabeçalhos de segurança numa única interface e ativa-os com um só botão.

O plugin define valores predefinidos para todos os cabeçalhos principais imediatamente após a ativação: X-Content-Type-Options, X-Frame-Options, HSTS, CSP, Referrer-Policy, Permissions-Policy e vários adicionais (CORP, COOP, COEP). Cada cabeçalho pode ser desativado ou personalizado conforme as suas necessidades.

A vantagem desta abordagem: o plugin não depende do servidor web e funciona de forma idêntica em Apache, Nginx, LiteSpeed e IIS. Na desativação, devolve a configuração do site ao estado original.

Alternativa: Redirection

O plugin Redirection é conhecido como um gestor de redirecionamentos, mas também pode adicionar cabeçalhos HTTP. Após a instalação e configuração básica, vá à secção Site → Headers; a interface permite especificar quaisquer pares "cabeçalho: valor".

Esta opção funciona se já tiver o Redirection instalado para gestão de links e não quiser adicionar outro plugin. Mas um plugin de cabeçalhos dedicado oferece mais controlo e valores predefinidos.

No vídeo, uma demonstração visual da configuração de cabeçalhos através do plugin Headers Security Advanced: da instalação à verificação do resultado no securityheaders.com.

⁉️🤔 Perguntas frequentes

E se o site avariar depois de ativar os cabeçalhos?

Primeiro, verifique o cabeçalho Content-Security-Policy: ele causa a grande maioria das avarias. Desative o CSP (ou mude-o para o modo Report-Only) e verifique o site novamente. Um erro 500 após editar o.htaccess: verifique a sintaxe à procura de um espaço extra, aspas não fechadas ou a falta do módulo mod_headers. Via FTP, renomeie o.htaccess, o site voltará à vida e pode encontrar o erro com calma.

Em 9 de cada 10 casos, o problema é especificamente o CSP, não os outros cabeçalhos. X-Content-Type-Options, X-Frame-Options, HSTS e Referrer-Policy são fisicamente incapazes de avariar o site; não afetam a renderização nem a lógica PHP. Comece sempre por esses.

É obrigatório um plugin ou pode ser feito via código?

Pode e deve ser feito via código se souber editar o functions.php ou o.htaccess. Definir cabeçalhos diretamente através da configuração do servidor funciona mais rápido do que um plugin, sem uma camada PHP pelo meio. Mas um plugin é mais conveniente para quem não quer mexer em código e fornece uma interface visual com predefinições para cada cabeçalho.

Nos nossos sites de teste, usamos ambas as abordagens: em produção,.htaccess (menos pontos de falha); em sites de clientes onde o alojamento não permite editar a configuração, o plugin. O resultado no securityheaders.com é idêntico: A+ em ambos os casos.

Preciso de configurar o CSP se o site estiver em WordPress?

Para a maioria dos sites, não. O CSP no WordPress exige unsafe-inline e unsafe-eval para o Gutenberg e dezenas de plugins funcionarem, o que reduz o efeito protetor a algo simbólico. Um CSP completo faz sentido em projetos de alta carga com um especialista de segurança dedicado que analisará cada relatório de violação. Para todos os outros, os 5 cabeçalhos básicos fornecem a maior parte da proteção prática.

Como verifico se os cabeçalhos estão a funcionar após a instalação?

Abra o site num navegador, inicie as DevTools (F12) → separador Network → clique no primeiro pedido para o seu domínio → secção Response Headers. Se vir os cabeçalhos adicionados, está tudo a funcionar. Para verificação automatizada, use o securityheaders.com: mostra não só a presença, mas também a correção dos valores, além de uma pontuação final de A+ a F.

E se o alojamento não permitir editar o.htaccess e não houver acesso ao functions.php?

Instale o Headers Security Advanced & HSTS WP através do painel de administração do WordPress. O plugin injeta cabeçalhos ao nível do PHP e não requer a edição de ficheiros do servidor. Isto funciona em qualquer alojamento onde o WordPress corra, desde partilhado barato a Managed WordPress.

Os cabeçalhos HTTP afetam a velocidade do site?

Praticamente não. Os cabeçalhos são um par de dúzias de bytes de texto na resposta do servidor. Não realizam cálculos, não fazem consultas à base de dados e não sobrecarregam o CPU. O atraso que adicionam mede-se em microssegundos. A única exceção é o CSP com uma lista de permissões complexa de centenas de domínios: o navegador gasta tempo a analisá-la, mas mesmo assim, o impacto na velocidade de renderização não excede um par de milissegundos.

O que definir e por onde começar

Os cabeçalhos de segurança HTTP não são uma ação única de "definir e esquecer". São uma linha de base que deve estar em todos os sites por defeito, como um certificado SSL.

O plano para hoje:

• Verifique o seu site no securityheaders.com. Se a pontuação for D ou F, nem sequer tem o X-Content-Type-Options.

• Adicione os 5 cabeçalhos básicos usando qualquer um dos três métodos acima. Se o site estiver em Apache, via.htaccess (30 segundos). Nginx sem acesso à configuração, via functions.php (2 minutos). Se não quiser mexer em código, o plugin Headers Security Advanced (3 minutos incluindo a instalação).

• Verifique novamente o site. A pontuação deve subir para A ou A+.

• Deixe o CSP de lado. Volte a ele quando os cabeçalhos básicos tiverem funcionado durante um mês sem problemas e tiver tempo para testar via Report-Only.

Uma hora e o seu site WordPress ganha uma camada de defesa que a grande maioria dos sites na internet não tem. Comece com uma verificação agora mesmo.