Cabeçalhos de segurança HTTP: o que HSTS, CSP e X-Content-Type-Options revelam sobre a maturidade técnica de um site
Um guia sobre os cabeçalhos de resposta HTTP que a OWASP recomenda como proteção básica, o que cada um realmente impede e por que a ausência deles é um gap de configuração, não uma prova de invasão.
Confiabilidade e Segurança
Leitura executiva
Principais conclusões
- Strict-Transport-Security (HSTS) instrui o navegador a nunca tentar HTTP de novo naquele domínio, mesmo que um link ou digitação aponte para a versão insegura.
- Content-Security-Policy (CSP) declara de onde o navegador pode carregar scripts, estilos e outros recursos, reduzindo o efeito de uma injeção de conteúdo mesmo que ela ocorra.
- A OWASP recomenda um conjunto núcleo de cabeçalhos de resposta como proteção básica, não como certificação completa de segurança da aplicação.
- Ausência de um cabeçalho é uma lacuna de configuração observável publicamente; não equivale a uma vulnerabilidade explorável confirmada nem substitui um teste de penetração.
Um site pode ter certificado HTTPS válido, cadeado verde no navegador, e ainda assim responder sem nenhum dos cabeçalhos de segurança que a OWASP recomenda como proteção básica. O cadeado confirma que a conexão está criptografada. Ele não confirma que o navegador foi instruído a recusar uma tentativa futura de conexão insegura, nem que existe uma política declarada sobre de onde scripts podem ser carregados.
Esses cabeçalhos de resposta HTTP são configuração de servidor, não código de aplicação. Isso os torna verificáveis publicamente, sem acesso a nenhuma conta ou ao repositório do site — e é exatamente por isso que a ausência deles é um achado comum em uma auditoria orientada a evidências.
O que pode ser observado, e o que isso prova
A OWASP Secure Headers Project define um conjunto núcleo de cabeçalhos de resposta recomendados para qualquer aplicação web. Cinco deles são diretamente observáveis na resposta HTTP de qualquer página pública:
| Cabeçalho | O que declara | O que reduz |
|---|---|---|
Strict-Transport-Security (HSTS) | Por quanto tempo o navegador deve exigir HTTPS neste domínio | Ataques de downgrade de protocolo e sequestro de cookie em uma tentativa inicial de HTTP |
Content-Security-Policy (CSP) | De onde scripts, estilos e outros recursos podem ser carregados | O efeito de uma injeção de conteúdo, mesmo que ela ocorra |
X-Content-Type-Options | Que o navegador não deve adivinhar (sniff) o tipo de conteúdo de uma resposta | Execução de um arquivo como um tipo diferente do declarado |
Referrer-Policy | Quanta informação da URL de origem é enviada para o próximo site | Vazamento de parâmetros sensíveis de URL para terceiros |
Permissions-Policy | Quais APIs do navegador (câmera, microfone, geolocalização) a página pode usar | Uso não intencional de APIs sensíveis por scripts de terceiros |
A OWASP recomenda configurar o HSTS com max-age de dois anos (63072000 segundos), a diretiva includeSubDomains e, quando aplicável, preload — um prazo longo o suficiente para que o navegador nunca "esqueça" a exigência de HTTPS entre visitas.
Nenhum desses cabeçalhos, isolado, prova que a aplicação está livre de vulnerabilidades. Cada um reduz uma classe específica de risco na camada de transporte e carregamento de conteúdo; nenhum audita a lógica de negócio, o controle de acesso ou as dependências da aplicação.
Método: da resposta HTTP à priorização
1. Capture a resposta HTTP da página real, não de uma versão em cache
Ferramentas de inspeção de rede do navegador (aba Network) ou uma requisição direta mostram os cabeçalhos exatamente como o servidor os enviou. CDNs e proxies às vezes removem ou substituem cabeçalhos configurados na origem — por isso a verificação deve ser feita contra a URL pública final, não contra o ambiente de desenvolvimento.
2. Verifique presença, não apenas o nome do cabeçalho
Um cabeçalho presente com uma diretiva fraca (por exemplo, um CSP com unsafe-inline liberado de forma ampla) reduz a proteção que o cabeçalho deveria oferecer. A verificação de presença é o primeiro filtro; a leitura da diretiva é a etapa seguinte, normalmente feita por engenharia durante uma revisão dedicada.
3. Cruze com a fundação do documento HTML
Doctype declarado, charset definido no início do <head> e uma tag de viewport são pré-requisitos de renderização previsível — não são cabeçalhos de segurança, mas costumam faltar nos mesmos projetos que também não configuram cabeçalhos de resposta, porque ambos são decisões de configuração de baixo nível que ficam para trás em migrações apressadas.
4. Não confunda ausência de cabeçalho com vulnerabilidade confirmada
A diferença entre "o cabeçalho não foi encontrado" e "o site foi invadido" é a diferença entre uma auditoria de configuração pública e um teste de penetração. Trate a ausência como um item de investigação para engenharia, não como um incidente de segurança confirmado.
Falsos positivos e limitações
- CDNs e proxies reversos podem adicionar ou remover cabeçalhos entre a origem e o navegador. Confirme a configuração tanto na origem quanto no ponto de entrega final.
- Um cabeçalho presente pode estar mal configurado. Presença não equivale a uma diretiva correta; uma política de CSP vazia ou excessivamente permissiva ainda conta como "presente" em uma checagem simples de existência do cabeçalho.
- Nenhum desses cinco cabeçalhos cobre autenticação, controle de acesso ou dependências desatualizadas. Eles são uma fatia observável publicamente da postura de segurança, não uma auditoria completa.
Plano de ação
- Verificar a resposta HTTP da página pública principal e confirmar quais dos cinco cabeçalhos núcleo estão presentes. Responsável sugerido: Engenharia.
- Priorizar HSTS e CSP primeiro — são os dois com maior redução de risco de downgrade de protocolo e injeção de conteúdo, respectivamente.
- Revisar as diretivas, não apenas a presença, em uma sessão dedicada de engenharia — especialmente CSP, cuja política errada tanto pode ser permissiva demais quanto quebrar funcionalidades legítimas.
- Reverificar após qualquer mudança de CDN, proxy reverso ou provedor de hospedagem, já que esses componentes podem sobrescrever cabeçalhos configurados na origem sem aviso.
O Remountly verifica a presença destes cinco cabeçalhos na resposta HTTP pública de uma página como parte da categoria de Boas Práticas, ao lado de HTTPS, conteúdo misto e padrões de API obsoletos como document.write. Essa verificação é evidência de configuração observável — o mesmo princípio por trás de transformar problemas técnicos em impacto financeiro: comece pelo que pode ser observado publicamente antes de presumir a causa.
Respostas diretas
Perguntas frequentes
O Remountly testa se um site pode ser invadido?
Não. O Remountly verifica, a partir da resposta HTTP pública, se cinco cabeçalhos de segurança recomendados pela OWASP estão presentes: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy e Permissions-Policy. Isso é uma checagem de configuração observável, não um teste de penetração nem uma auditoria de vulnerabilidades da aplicação.
Por que HTTPS sozinho não é suficiente?
HTTPS protege os dados em trânsito entre o navegador e o servidor, mas não impede que um usuário digite ou clique em um link para a versão http:// do mesmo domínio antes do redirecionamento acontecer. O HSTS fecha essa janela ao instruir o navegador a nunca tentar a versão insegura, mesmo na primeira tentativa, depois que o cabeçalho foi visto uma vez dentro do prazo de max-age.
Um site pode ter todos os cabeçalhos recomendados e ainda ser vulnerável?
Sim. Os cabeçalhos reduzem classes específicas de risco, mas não cobrem falhas de lógica de negócio, controle de acesso quebrado, dependências desatualizadas ou erros de autenticação. Eles são uma camada de defesa observável publicamente, não uma auditoria de segurança completa da aplicação.