Porque é que os Cabeçalhos Desaparecem ou Ficam Fracos
- As configurações de alojamento predefinidas não incluem nenhum deles. A maioria dos servidores e plataformas web não adiciona cabeçalhos de segurança a menos que os configure explicitamente.
- Uma CSP é adicionada uma vez e depois nunca revisitada. À medida que uma aplicação adiciona novos scripts de terceiros, embeds ou fontes, uma CSP estática escrita há um ano bloqueia-os silenciosamente - ou pior, alguém alarga-a com um wildcard para parar os erros, anulando a política.
- O HSTS é adicionado sem as diretivas que o tornam realmente eficaz. Um cabeçalho
Strict-Transport-Securitysimples, com ummax-agecurto e semincludeSubDomainsoupreload, oferece uma proteção muito mais fraca do que aparenta. - Cabeçalhos obsoletos copiados de um tutorial antigo permanecem, como o
X-XSS-Protection, que os navegadores modernos ignoram ou que pode ele próprio introduzir risco.
Como Identificar o Problema
Esta é a capacidade de segurança mais profunda do Scanverra. O scanner de segurança realiza uma análise real das diretivas CSP - verificando especificamente base-uri, form-action, object-src e frame-ancestors, além de detetar fontes wildcard demasiado abrangentes - e uma verificação completa de profundidade do HSTS, cobrindo max-age, includeSubDomains e preload. Especificamente para a diretiva preload, faz uma chamada em tempo real à API do hstspreload.org para confirmar que o seu domínio está realmente na lista de preload do Chrome, não apenas a alegar estar. Também assinala cabeçalhos obsoletos como o X-XSS-Protection, e mapeia cada resultado para uma referência CWE e OWASP Top 10 - por exemplo, um cabeçalho HSTS em falta mapeia para CWE-319 e OWASP A05:2021 - para que os resultados se traduzam diretamente em documentação de conformidade.
Como Corrigir
1. Adicione HSTS com o conjunto completo de diretivas
1Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadDepois de adicionar preload, submeta o seu domínio em hstspreload.org - a diretiva por si só não o inscreve, e a verificação em tempo real do Scanverra continuará a assinalar a lacuna até a submissão ser realmente aceite.
2. Escreva uma Content-Security-Policy delimitada ao que o seu site realmente carrega
1Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; base-uri 'self'; form-action 'self'; object-src 'none'; frame-ancestors 'self'Adicione origens confiáveis específicas a script-src/style-src apenas conforme necessário - nunca recorra a um wildcard (*) ou a uma fonte apenas de esquema (https:) só para silenciar erros na consola, já que isso anula por completo o propósito da política.
3. Adicione os restantes cabeçalhos padrão
1X-Content-Type-Options: nosniff
2X-Frame-Options: DENY
3Referrer-Policy: strict-origin-when-cross-originO frame-ancestors na sua CSP é o substituto moderno do X-Frame-Options e é mais flexível - envie ambos, já que os navegadores mais antigos apenas respeitam o cabeçalho legado.
4. Remova cabeçalhos obsoletos em vez de os deixar em vigor
O X-XSS-Protection está obsoleto e a OWASP recomenda explicitamente removê-lo por completo em vez de o definir com qualquer valor - uma CSP real é o substituto moderno, não um complemento a ele.
Como o Scanverra Deteta Isto
O scanner de segurança do Scanverra lê os seus cabeçalhos de resposta em produção e realiza uma análise genuína ao nível das diretivas, não uma simples verificação de presença - cobertura de diretivas CSP e deteção de wildcards, profundidade do valor HSTS incluindo uma consulta em tempo real ao hstspreload.org, e deteção de cabeçalhos obsoletos, cada resultado mapeado para referências CWE, OWASP e PCI quando aplicável.