Os cabeçalhos de segurança são instruções enviadas pelo servidor junto com cada página. Eles orientam o navegador sobre como tratar conteúdo, enquadramentos, permissões e conexões seguras. No WordPress, uma configuração cuidadosa ajuda a reduzir algumas superfícies de ataque, mas não substitui atualizações, controle de usuários, backup ou proteção do login.
A forma mais segura de começar é aplicar poucas regras, testar o site e avançar em etapas. Copiar uma configuração extensa da internet pode bloquear o editor, formulários, vídeos incorporados, fontes externas e integrações de pagamento.
Neste guia, você vai configurar um conjunto inicial de cabeçalhos no Apache ou no Nginx. Também vai aprender por que HSTS e Content Security Policy precisam de atenção especial.
O que os cabeçalhos de segurança resolvem no WordPress
Os cabeçalhos atuam no navegador do visitante. Eles podem impedir que o conteúdo seja interpretado de uma forma diferente da declarada, limitar o uso do site dentro de quadros e restringir recursos sensíveis, como câmera e microfone.
Eles são úteis em sites institucionais, blogs, portfólios e lojas. O impacto da configuração, porém, depende do funcionamento de cada projeto.
Considere um site de clínica com formulário de contato e mapa incorporado. Uma política que bloqueie localização pode ser aceitável, desde que o mapa continue funcionando. Em uma plataforma que realmente solicita a localização do usuário, a mesma regra pode interromper um recurso necessário.
O mesmo cuidado vale para lojas WooCommerce. Uma política muito rígida pode impedir scripts do provedor de pagamento ou etapas de autenticação. Por isso, a validação deve incluir as ações reais do visitante, não apenas a página inicial.
O projeto OWASP Secure Headers oferece uma referência técnica sobre os cabeçalhos e seus objetivos em OWASP Secure Headers. A documentação da Mozilla também explica o comportamento de cada cabeçalho em HTTP Headers.
Pré requisitos antes de alterar o servidor
Não comece pelas regras. Primeiro, confirme que o ambiente permite uma recuperação rápida.
Você precisa de:
- Acesso ao painel da hospedagem ou ao servidor.
- Certificado SSL válido e redirecionamento estável para HTTPS.
- Backup recente dos arquivos e do banco de dados.
- Uma forma de restaurar a configuração anterior.
- Lista das integrações externas usadas pelo site.
- Janela de teste com baixo impacto para os visitantes.
Se o HTTPS ainda apresenta alertas ou conteúdo misto, resolva isso antes de ativar HSTS. O guia sobre configuração de SSL no WordPress ajuda a revisar essa etapa.
Anote também se o site usa CDN, proxy reverso ou serviço de proteção. Essas camadas podem adicionar os cabeçalhos antes de a resposta chegar ao navegador. Configurar a mesma regra no proxy e no servidor pode gerar valores duplicados ou dificultar o diagnóstico.
Em uma VPS da LetsCloud, a alteração depende da pilha instalada. Um servidor com Nginx exige um arquivo diferente de um ambiente com Apache. A LetsCloud entra como infraestrutura para executar a configuração, mas a responsabilidade sobre arquivos, testes e recuperação continua com quem administra a VPS.
Quais cabeçalhos configurar primeiro
Um conjunto inicial pode incluir quatro regras com impacto relativamente previsível.
X Content Type Options
O valor nosniff instrui o navegador a respeitar o tipo de conteúdo declarado pelo servidor. Isso reduz interpretações inesperadas de arquivos.
Exemplo de resposta:
X-Content-Type-Options: nosniff
Referrer Policy
Esse cabeçalho controla quanto da URL de origem é enviado quando o visitante abre outro endereço. O valor strict-origin-when-cross-origin preserva informações úteis em navegação interna e reduz o envio de detalhes para outros domínios.
Exemplo:
Referrer-Policy: strict-origin-when-cross-origin
Permissions Policy
A política de permissões restringe recursos do navegador. Um site institucional que não usa câmera, microfone ou localização pode negar essas funções.
Exemplo:
Permissions-Policy: camera=(), microphone=(), geolocation=()
Não desative um recurso antes de verificar se formulários, chamadas por vídeo, mapas ou plugins dependem dele.
Proteção contra enquadramento
X-Frame-Options: SAMEORIGIN limita o carregamento do site dentro de um quadro a páginas da mesma origem. Isso pode reduzir tentativas de induzir cliques sobre uma interface escondida.
A diretiva frame-ancestors da Content Security Policy oferece controle mais atual e detalhado. Mesmo assim, X-Frame-Options ainda pode ser usado em uma implantação inicial quando não há necessidade de liberar domínios externos específicos.
Se o seu site precisa aparecer dentro de uma plataforma externa, não aplique essa regra sem testar a integração.
Como configurar cabeçalhos no Apache
Em instalações com Apache, as regras costumam ser aplicadas na configuração do servidor ou no arquivo .htaccess. O módulo de cabeçalhos precisa estar disponível.
Antes da alteração, faça uma cópia do arquivo. Não remova o bloco criado pelo WordPress para os links permanentes.
Uma configuração inicial é:
<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
Header always set X-Frame-Options "SAMEORIGIN"
</IfModule>Salve o arquivo e abra o site em uma janela anônima. Depois, entre no painel e teste o editor. Se o servidor retornar erro 500, restaure a cópia imediatamente. Esse erro pode indicar sintaxe incorreta, módulo indisponível ou restrição da hospedagem.
Em hospedagem compartilhada, confirme se o provedor permite mod_headers. Quando a diretiva não é aceita no .htaccess, o suporte da hospedagem pode precisar aplicar a configuração no servidor.
Como configurar cabeçalhos no Nginx
No Nginx, as diretivas são adicionadas ao bloco responsável pelo domínio. O local exato varia conforme a organização do servidor.
Um conjunto inicial pode usar:
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header X-Frame-Options "SAMEORIGIN" always;Depois de editar o arquivo, valide a sintaxe antes de recarregar o serviço:
sudo nginx -tSomente recarregue o Nginx se o teste confirmar que a sintaxe está correta. Mantenha a sessão administrativa aberta até verificar que o domínio e o painel continuam acessíveis.
Se houver proxy reverso, confira em qual camada as respostas são finalizadas. Um cabeçalho configurado no servidor de aplicação pode ser alterado ou removido pelo proxy.
Como tratar HSTS sem bloquear o domínio
HSTS orienta o navegador a acessar o domínio apenas por HTTPS durante um período definido. Isso pode ser útil quando o site já opera de forma estável com certificado válido.
O cuidado é importante porque o navegador memoriza a política. Se o certificado expirar ou o HTTPS deixar de funcionar, visitantes que receberam a regra podem não conseguir abrir o site por HTTP.
Comece com um período curto, como cinco minutos:
Strict-Transport-Security: max-age=300
Teste o domínio, o painel, páginas internas e serviços vinculados. Depois, aumente o período de forma gradual. Não adicione includeSubDomains sem confirmar que todos os subdomínios funcionam por HTTPS. Isso inclui ambientes antigos, webmail, sistemas internos e páginas de campanha.
Também não solicite inclusão em listas de preload durante o teste. Essa decisão exige uma análise específica, pois a reversão não é imediata.
Por que CSP exige uma implantação gradual
Content Security Policy, ou CSP, define quais origens podem fornecer scripts, estilos, imagens, fontes, quadros e outros recursos. Ela oferece controle valioso, mas uma política copiada sem inventário quase sempre encontra exceções em um site WordPress real.
Construtores visuais, plugins de métricas, fontes externas, vídeos, mapas, pagamentos e widgets podem carregar arquivos de vários domínios. Bloquear esses recursos sem perceber pode deixar a página visualmente correta, mas impedir uma conversão ou uma ação administrativa.
Comece no modo de relatório com Content-Security-Policy-Report-Only. Esse modo permite observar violações sem aplicar todos os bloqueios. Registre os domínios necessários e avalie cada origem. Não libere curingas amplos apenas para eliminar avisos.
Depois do inventário, aplique a política em uma cópia de teste. Valide o painel, o editor de blocos, a biblioteca de mídia e os fluxos públicos. Uma CSP efetiva deve ser criada para o site concreto, não como um trecho universal.
Como validar o site depois da configuração
Abra as ferramentas de desenvolvimento do navegador. Na aba de rede, selecione a resposta principal do domínio e procure os cabeçalhos adicionados.
A validação deve seguir uma lista de ações reais:
- Abrir a página inicial e páginas internas.
- Entrar e sair do painel.
- Criar um rascunho no editor.
- Enviar um formulário de contato.
- Abrir vídeos, mapas e arquivos incorporados.
- Testar busca, comentários e área restrita, quando existirem.
- Simular carrinho e pagamento em ambiente de teste, no caso de loja.
- Verificar o console do navegador.
- Confirmar respostas de erro, como página não encontrada.
Os cabeçalhos devem aparecer também nas respostas de erro. É por isso que os exemplos usam always quando a sintaxe do servidor permite.
Depois de uma mudança técnica, acompanhe o comportamento do site. O guia sobre monitoramento de erros no WordPress apresenta uma rotina para observar falhas sem depender apenas de reclamações.
Erros comuns ao adicionar cabeçalhos de segurança
O primeiro erro é aplicar muitas regras ao mesmo tempo. Quando algo quebra, fica difícil descobrir qual diretiva causou o problema.
Outro erro é configurar cabeçalhos em um plugin, no servidor e na CDN simultaneamente. A duplicação pode produzir respostas inconsistentes. Escolha uma camada principal e documente a decisão.
Também é comum ativar HSTS antes de estabilizar o HTTPS. Isso transforma uma falha temporária de certificado em um bloqueio persistente para alguns navegadores.
Na CSP, o erro frequente é liberar qualquer origem para fazer os alertas desaparecerem. Uma política ampla demais perde parte de sua utilidade. Uma política rígida demais quebra funções. O equilíbrio depende de inventário e teste.
Por fim, cabeçalhos não corrigem senhas fracas, contas administrativas desnecessárias ou plugins abandonados. Combine essa camada com a proteção do login do WordPress e uma rotina de atualização.
Checklist final para publicar as regras
Antes de encerrar a mudança, confirme:
- O site usa HTTPS sem alertas.
- Existe backup recente e acessível.
- A configuração anterior foi guardada.
- Cada cabeçalho foi aplicado com uma finalidade conhecida.
- Não existem valores duplicados na resposta.
- O painel e o editor foram testados.
- Formulários e integrações continuam funcionando.
- HSTS começou com duração curta.
- Subdomínios foram verificados antes de qualquer regra abrangente.
- CSP foi observada primeiro em modo de relatório.
- A equipe sabe onde os cabeçalhos são configurados.
- Uma data de revisão foi registrada.
Inclua essa verificação no checklist antes de publicar um site WordPress para que a configuração não fique isolada da revisão geral.
Perguntas frequentes sobre cabeçalhos de segurança
Preciso de plugin para configurar cabeçalhos de segurança?
Não necessariamente. Servidor, proxy e CDN podem enviar os cabeçalhos sem plugin. Um plugin pode facilitar o acesso quando você não controla a infraestrutura, mas adiciona outra dependência. Evite configurar a mesma regra em mais de uma camada.
HSTS pode ser removido depois?
A resposta do servidor pode ser alterada, mas navegadores que já receberam a política podem mantê la até o fim do período definido. Por isso, comece com uma duração curta e não use subdomínios ou preload durante os primeiros testes.
CSP pode bloquear o editor do WordPress?
Sim. O editor, temas e plugins podem depender de scripts, estilos, imagens e conexões que a política não autorizou. Use o modo de relatório, faça um inventário e teste primeiro fora da produção.
Os cabeçalhos substituem um plugin de segurança?
Não. Eles atuam em uma parte específica da interação entre servidor e navegador. Atualizações, controle de acesso, backup, monitoramento e proteção do servidor continuam necessários.
Como saber se o servidor já envia um cabeçalho?
Consulte a resposta na aba de rede das ferramentas do navegador ou use uma requisição que mostre os cabeçalhos HTTP. Verifique a página principal, o painel e respostas de erro. CDN e proxy podem produzir resultados diferentes do servidor de origem.
Próximo passo para proteger o WordPress
Depois de validar os cabeçalhos, documente onde cada regra foi aplicada, o motivo do valor escolhido e como desfazer a mudança. Essa informação reduz o tempo de diagnóstico quando a hospedagem, o proxy ou uma integração forem alterados.
O próximo passo é revisar login, contas administrativas e atualizações. Cabeçalhos ajudam a limitar comportamentos do navegador, mas a segurança do WordPress depende de várias camadas funcionando juntas.
