Cabeçalhos Seguros

Definition

Cabeçalhos seguros são cabeçalhos de resposta HTTP que informam aos navegadores como lidar com diversos aspectos de segurança do conteúdo web. Entre eles estão cabeçalhos como HSTS, CSP, X-Frame-Options e outros. Cabeçalhos de segurança bem configurados oferecem uma camada adicional de defesa contra vários ataques, incluindo XSS, clickjacking e ataques de downgrade de protocolo.

Você também pode estar procurando:

Content Security Policy (CSP) Ver definição HSTS (Strict Transport Security) Ver definição X-Content-Type-Options Ver definição

O que são cabeçalhos seguros

Cabeçalhos seguros são cabeçalhos de resposta HTTP que um servidor envia para dizer ao navegador como tratar o conteúdo e as conexões de uma página. Em vez de residirem no corpo da página, eles configuram as próprias defesas do navegador: o Content-Security-Policy restringe quais scripts e recursos podem ser carregados, o Strict-Transport-Security força o HTTPS, o X-Frame-Options (ou o frame-ancestors da CSP) bloqueia o enquadramento, o X-Content-Type-Options impede o MIME sniffing, e o Referrer-Policy e o Permissions-Policy limitam quais dados e APIs uma página expõe. Cada cabeçalho tem como alvo uma classe específica de ataque. Como o navegador os impõe, eles adicionam defesa em profundidade sobre a validação no lado do servidor e a lógica da aplicação, e geralmente são baratos de implantar no servidor web, no CDN ou na edge.

Por que a configuração dos cabeçalhos importa

Cabeçalhos de segurança ausentes ou fracos deixam classes de ataque conhecidas em aberto mesmo quando o código da aplicação é sólido. Sem o HSTS, um usuário pode ser rebaixado para HTTP puro e interceptado; sem uma restrição de enquadramento, a página pode sofrer clickjacking; sem uma Content Security Policy, um script injetado é executado livremente. Os cabeçalhos são um controle de baixo esforço e ampla cobertura, e é por isso que aparecem em verificações de conformidade e scanners automatizados. Mas eles são apenas um ponto de partida: uma CSP permissiva que mantém unsafe-inline, ou um cabeçalho HSTS sem includeSubDomains, dá uma falsa sensação de segurança. O detalhe da configuração importa tanto quanto a presença, e os cabeçalhos protegem o documento first-party, não o comportamento dos scripts third-party que ele carrega.

Reforçando os cabeçalhos, e o papel mais restrito da cside

Defina uma Content-Security-Policy estrita (baseada em nonce ou hash, sem unsafe-inline), HSTS com um max-age longo e includeSubDomains, X-Content-Type-Options: nosniff, uma restrição de enquadramento e um Referrer-Policy rígido; teste com um scanner de cabeçalhos e implante a CSP primeiro em modo report-only. Lembre-se de que os cabeçalhos podem ser removidos ou enfraquecidos mais adiante, já que extensões de navegador maliciosas e código injetado podem removê-los no lado do cliente. O papel da cside é mais restrito e complementar: ela gerencia e monitora a CSP e, ao rotear scripts third-party por meio de um método Script e analisar o payload, captura comportamentos de script maliciosos que os cabeçalhos sozinhos permitem, mantendo registros forenses úteis para o PCI DSS 6.4.3 e 11.6.1.

Saiba mais

Definição

Quais cabeçalhos de segurança mais importam para um site típico?

Uma Content-Security-Policy estrita, o Strict-Transport-Security, o X-Content-Type-Options definido como nosniff e um controle de enquadramento como o X-Frame-Options ou o frame-ancestors da CSP cobrem os riscos de maior impacto: injeção de script, rebaixamento de protocolo, confusão de MIME e clickjacking. O Referrer-Policy e o Permissions-Policy são acréscimos valiosos para limitar o vazamento de dados e restringir APIs poderosas do navegador.

Definição

Os cabeçalhos de segurança podem ser removidos depois que o servidor os define?

Sim. Proxies, CDNs mal configurados e, especialmente, extensões de navegador maliciosas ou com privilégios excessivos podem remover ou alterar os cabeçalhos de resposta antes ou depois de chegarem ao navegador. É por isso que os cabeçalhos são uma camada de defesa e não uma garantia, e por que monitorar o que os scripts realmente fazem no navegador continua sendo importante.

Got more questions

Talk to a security expert

We answer client-side security questions every day. Bring yours.

Book a demo

Browse all terms