Os 10 erros mais comuns em cabeçalhos de segurança (e como corrigi-los)

Os cabeçalhos de resposta HTTP são aquele raro controle de segurança que custa algumas linhas de configuração e protege cada visitante na hora. É também por isso que errar é tão comum: são fáceis de copiar e colar e difíceis de testar. Estes são os dez problemas que aparecem repetidamente nas análises.

1. Sem HSTS (ou HSTS sem o caminho de preload)

Sem Strict-Transport-Security, uma única requisição em texto puro pode ser interceptada antes do redirecionamento para HTTPS. Defina um max-age longo e inclua subdomínios:

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

Só adicione preload quando cada subdomínio for exclusivamente HTTPS — é difícil de reverter rapidamente.

2. Uma Content-Security-Policy que permite unsafe-inline

script-src 'unsafe-inline' reabre exatamente o buraco de XSS que a CSP existe para fechar. Migre para nonces ou hashes:

Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-{random}'; object-src 'none'; base-uri 'self'

3. Deixar a CSP em modo report-only para sempre

Content-Security-Policy-Report-Only é para a fase de implantação. Muitos sites a deixam ali por meses, coletando relatórios sem aplicar nada. Use report-only para encontrar violações e mude para o cabeçalho que aplica quando estiver silencioso.

4. X-Frame-Options em vez de frame-ancestors

X-Frame-Options é legado e não consegue expressar uma lista de permissões. Prefira a diretiva de CSP, respeitada pelos navegadores modernos:

Content-Security-Policy: frame-ancestors 'self'

5. X-Content-Type-Options ausente

Sem X-Content-Type-Options: nosniff, um navegador pode fazer MIME-sniffing de uma resposta e executar algo que você serviu como texto. É um único cabeçalho sem desvantagem — sempre defina.

6. Uma Referrer-Policy perigosa ou ausente

O padrão vaza URLs completas (incluindo tokens na query string) a terceiros. Uma escolha segura e amplamente compatível:

Referrer-Policy: strict-origin-when-cross-origin

7. Permissions-Policy no padrão do navegador

Se seu app não usa câmera, microfone nem geolocalização, declare isso explicitamente para que um script comprometido também não possa:

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

8. Definir cabeçalhos no HTML mas não na API

Cabeçalhos aplicados por um framework de frontend costumam ignorar rotas de API, redirecionamentos e páginas de erro. Os scanners testam esses caminhos diretamente. Defina os cabeçalhos de segurança na borda — um proxy reverso, CDN ou middleware da plataforma — para que a cobertura seja uniforme.

9. Cabeçalhos conflitantes de várias camadas

Quando seu app e seu CDN definem Content-Security-Policy, o navegador pode ver dois cabeçalhos e aplicar a *interseção*, quebrando funções silenciosamente. Escolha uma camada autoritativa e remova as duplicatas.

10. Cachear respostas sensíveis

Páginas autenticadas e respostas de API com dados pessoais não devem ser cacheáveis por proxies compartilhados:

Cache-Control: no-store

Confirme com uma nova análise

Cabeçalhos interagem, então mude-os em lotes pequenos e reanalise após cada um. Se você está começando a ler os resultados, comece por Como ler um relatório de análise de segurança de site; para a camada de transporte sob esses cabeçalhos, veja Configurações de SSL/TLS que colocam seu site em risco. A verificação completa de cabeçalhos roda em cada análise — veja todas as verificações na página de recursos.