Último dia de Halloween: +30% em uma recargaO bônus vale uma única vez: recarregue de uma vez todo o valor de que precisa. Dê uma olhada no seu painel: há surpresas escondidas. 00h00min00s Receber o bônus
Início / Base de conhecimento / Ferramentas e integrações / Verificação de Security Headers

Verificação de Security Headers

Ferramentas e integrações 2 min de leitura Atualizado em 02.11.2026
Seis headers que são ativados no servidor e quase não têm custo, a ordem de implementação do mais seguro ao mais delicado, e por que o CSP deve ser executado em modo de relatório.

A verificação de cabeçalhos de segurança mostra quais mecanismos de proteção estão ativados no site e quais não estão. Esta é a forma mais barata de hardening: quase tudo é configurado no lado do servidor e não exige alterações no código. A ferramenta é a auditoria de cabeçalhos de segurança.

O que é verificado

CabeçalhoProtege contraImportância
Strict-Transport-SecurityForça o uso de https: protege contra o sequestro de conexãoMédia
Content-Security-PolicyLimita de onde os scripts são carregados: a principal proteção contra injeção de códigoMédia
X-Frame-OptionsImpede que o site seja incorporado em outro frame (clickjacking)Baixa
X-Content-Type-OptionsImpede que o navegador adivinhe o tipo do arquivoBaixa
Referrer-PolicyLimita o que é enviado para análises externas na transição entre páginasInformativa
Permissions-PolicyDesativa recursos desnecessários: câmera, microfone, geolocalizaçãoInformativa

Por onde começar

  1. HSTS: se o site já está totalmente em https, ele pode ser ativado com uma única linha.
  2. Proteção contra clickjacking e adivinhação de tipo: também uma linha, sem efeitos colaterais.
  3. Content-Security-Policy: o mais útil e o mais delicado. Comece no modo de relatório, caso contrário você corre o risco de quebrar seus próprios scripts.
  4. Outros: opcionais. Esses cabeçalhos não quebram nada e deixam a configuração mais organizada.
Cuidado com o CSP
A política de segurança de conteúdo interrompe o carregamento de tudo o que não for explicitamente permitido: fontes externas, análises, widgets, scripts inline. Já nos demos mal com isso: um script inline sem um parâmetro de permissão simplesmente não é executado, e a página perde funcionalidades silenciosamente. Comece pelo modo de relatório e só depois ative.

O que os cabeçalhos não fazem

Eles não protegem contra invasões por vulnerabilidades no código, não curam um site infectado e não substituem as atualizações do CMS. A função deles é reduzir as possibilidades de ataque no navegador do visitante e diminuir os danos se algo der errado. Uma verificação completa é feita por um scanner à parte: veja a análise de malware e backdoors.

Relação com outras verificações

Esses mesmos cabeçalhos estão incluídos no relatório do Shield e, em parte, no SEO Audit. A análise teórica de cada um está no glossário: cabeçalhos de segurança. Para ver os cabeçalhos brutos da resposta, use a verificação de cabeçalhos.

Perguntas frequentes

Com qual header começar?
Com o HSTS, se o site já estiver totalmente em https. Depois, com a proteção contra clickjacking e contra adivinhação de tipo (type sniffing): elas são ativadas com uma linha e não quebram nada.
Por que é perigoso ativar o CSP de imediato?
A política interrompe o carregamento de tudo o que não for explicitamente permitido: fontes externas, analytics, widgets e scripts inline deixam de funcionar silenciosamente.
Esses headers afetam o SEO?
Não diretamente, mas fazem parte da avaliação de segurança e reduzem o risco de invasão, que pode fazer você perder posições por muito tempo.
Este artigo foi útil?
Experimente no seu projeto Tudo o que está descrito no artigo está disponível no painel: o bônus de cadastro já está no seu saldo.
Abrir painel