Security Headers: CSP, HSTS e outros
Os security headers são algumas linhas que o servidor adiciona a cada resposta. O visitante não os vê, mas o navegador entende o que pode e o que não pode ser feito no seu site. Eles são configurados no servidor e, em geral, não exigem alterações no código do site.
Analogia para o dono do site
É uma instrução para o segurança da entrada. Sem ela, ele deixa passar tudo: qualquer script de qualquer domínio, a incorporação da sua página em um site de terceiros, tentativas de adivinhar o tipo de arquivo. Com a instrução, surge uma lista: estes podem entrar, estes não, esta porta deve permanecer fechada. Os headers não corrigem falhas no código, mas impedem que elas sejam exploradas.
O que cada header faz
| Header | O que ele garante | Gravidade |
|---|---|---|
| Strict-Transport-Security | O navegador acessa seu site somente via HTTPS e não volta para uma conexão aberta | Média |
| Content-Security-Policy | Define de onde os scripts podem ser carregados. A principal proteção contra XSS | Média |
| X-Frame-Options | Impede que suas páginas sejam incorporadas em um frame no site de terceiros (clickjacking) | Baixa |
| X-Content-Type-Options | Impede que o navegador adivinhe o tipo de arquivo: caso contrário, um arquivo enviado por upload pode ser executado como script | Baixa |
| Referrer-Policy | Limita qual endereço é enviado a sites externos na navegação | Info |
| Permissions-Policy | Desativa recursos desnecessários do navegador: câmera, microfone, geolocalização | Info |
Além disso, os flags de cookies são verificados: Secure, HttpOnly e SameSite. Eles evitam o sequestro de sessão.
Como isso se relaciona com negócios e SEO
Os headers em si não melhoram o ranqueamento: eles não são um fator de ranqueamento. Eles atuam em outra frente: o HSTS elimina o risco de uma conexão aberta, e o CSP impede que scripts externos adicionem links ocultos e redirecionamentos às páginas. Essas injeções levam à queda nas posições e ao aviso "este site pode prejudicar seu computador" no navegador.
Como aparece no relatório do Security Shield
A verificação de headers ocorre em qualquer modo, inclusive no rápido e gratuito. Cada header ausente se torna um achado separado, com sua gravidade, classe CWE e categoria OWASP; a partir deles, é calculada uma nota de A+ a F. A ausência de CSP e HSTS pesa mais do que a ausência de Referrer-Policy. Para este grupo, a correção automática funciona: o serviço gera um trecho de configuração pronto, em .htaccess ou um bloco para nginx.
Como começar
- Adicione
X-Content-Type-Options: nosniffeReferrer-Policy: strict-origin-when-cross-origin: quase nunca causam problemas. - Bloqueie a incorporação em frames:
X-Frame-Options: SAMEORIGIN, mas verifique se você não incorpora suas páginas em outros domínios. - Garanta que todo o HTTP redirecione para HTTPS e só então ative o HSTS.
- Deixe o CSP por último e comece pelo modo de relatório
Content-Security-Policy-Report-Only.
No modo Report-Only, a política não bloqueia nada, apenas informa o que bloquearia. Deixe rodando por uma semana com tráfego real, analise os relatórios, adicione os domínios necessários e só depois mude para o header definitivo. Caso contrário, você corre o risco de desativar widgets, analytics e pagamentos.
Como evitar que o problema volte
Os headers ficam na configuração do servidor, e ela pode se perder durante uma migração, troca de hospedagem ou integração com CDN. Mantenha um trecho da configuração no repositório junto com o projeto e repita a verificação após mudanças na infraestrutura: o funcionamento do serviço é descrito no artigo sobre o Security Shield. Para o acesso à conta, veja segurança da conta.
