Cabeçalhos HTTP: segurança com CSP e HSTS

Você implantou o aplicativo. As páginas carregam, os formulários funcionam e nada parece quebrado. Então você executa uma varredura e ela volta com uma lista de descobertas sobre cabeçalhos - e nada disso é óbvio.

Essa é uma primeira reação normal. Os cabeçalhos não aparecem na tela, por isso é difícil dizer se eles são importantes ou se o scanner está apenas sendo exigente. Este guia percorre os cabeçalhos que você verá com mais frequência, o que cada um realmente faz em linguagem simples e como verificar o seu sem suposições.

Cabeçalhos de segurança são instruções que seu servidor envia ao navegador junto com a página. O navegador os lê e ajusta a forma como lida com seu conteúdo: quais scripts podem ser executados, se a página pode carregar em HTTP simples, se outro site pode incorporá-la em um quadro.

Nada na página muda. É exatamente por isso que essas descobertas parecem abstratas: o site pode parecer e se comportar perfeitamente, embora falte um conjunto de proteções que seriam importantes no dia em que algo desse errado.

O enquadramento honesto é este: os cabeçalhos reduzem uma classe específica de risco. Eles não tornam um site seguro por si só, e uma verificação limpa do cabeçalho não prova que um site é totalmente seguro. Pense nelas como uma camada entre várias e uma das camadas mais baratas para acertar.

Quando um navegador solicita uma página, seu servidor responde com a página e um bloco de metadados chamado cabeçalhos de resposta. Você mesmo pode vê-los: abra as ferramentas de desenvolvedor do seu navegador, vá para a guia Rede, recarregue a página e clique na solicitação principal. Os cabeçalhos estão ali.

Os cabeçalhos de segurança são simplesmente aqueles que informam ao navegador para impor uma regra. Alguns são rigorosos, alguns são consultivos e todos são definidos na configuração do seu servidor, na sua estrutura ou na sua plataforma de hospedagem - não no seu HTML.

CSP informa ao navegador quais fontes de conteúdo podem ser carregadas em sua página. É o cabeçalho mais poderoso aqui e aquele que as pessoas consideram mais intimidante.

Na prática, um CSP explica coisas como: os scripts só podem vir do seu próprio domínio e de um CDN confiável; as imagens podem vir de qualquer lugar acima de HTTPS; a página não pode ser enquadrada por outro site. Se algo tentar carregar de uma fonte que você não permitiu, o navegador bloqueará e registrará a tentativa no console.

CSP é uma defesa adicional contra injeção de script, juntamente com codificação e higienização de saída segura. É também o cabeçalho com maior probabilidade de quebrar alguma coisa se você defini-lo de forma muito agressiva. O caminho prático para um iniciante é começar no modo somente relatório, observar o que teria sido bloqueado, corrigir os problemas reais e, em seguida, aplicá-lo.

HSTS diz ao navegador para falar com seu site apenas através de HTTPS, por um período definido. Depois que um navegador visualizar esse cabeçalho, ele se recusará a fazer uma conexão HTTP insegura com seu domínio - mesmo que um usuário digite http:// ou segue um link antigo.

Depois que o navegador conhece a política HSTS, ele atualiza as solicitações HTTP antes de enviá-las. A primeira visita ainda poderá usar HTTP, a menos que o domínio já esteja coberto por uma entrada de pré-carregamento HSTS.

A única coisa a respeitar aqui é o compromisso. HSTS é lembrado pelo navegador pelo tempo que você especificar, então comece com uma duração curta enquanto confirma que cada subdomínio funciona em HTTPS e, em seguida, aumente-o quando estiver confiante.

X-Frame-Options controla se outro site pode carregar suas páginas dentro de um frame - um <iframe> na página de outra pessoa.

Por que se importar? Porque o enquadramento é o mecanismo por trás do clickjacking, em que um invasor sobrepõe sua página real com elementos invisíveis ou disfarçados para que o usuário clique em algo que não pretendia. Se o seu aplicativo tiver alguma ação de login - um botão de exclusão, um pagamento, uma alteração nas configurações - enquadrá-lo em outro lugar é um risco que você não deseja.

A configuração comum é SAMEORIGIN, que permite que suas próprias páginas se enquadrem, mas bloqueia todas as outras. Se você nunca pretende ser enquadrado, esse geralmente é o padrão correto.

Referrer-Policy decide quanto do seu URL é compartilhado com outros sites quando um usuário clica em um link fora da sua página. Os navegadores modernos normalmente usam strict-origin-when-cross-origin: o URL completo pode ser enviado em solicitações de mesma origem, enquanto as solicitações HTTPS de origem cruzada recebem apenas a origem. Uma política explícita mais fraca pode revelar mais.

Isso é importante porque URLs completos às vezes contêm valores confidenciais em strings de consulta - tokens, IDs, endereços de e-mail, termos de pesquisa. Vazá-los para terceiros é tranquilo e fácil de passar despercebido.

Uma linha de base sensata é enviar apenas a origem, ou nada, em solicitações entre sites. Não custa quase nada e elimina um vazamento acidental de dados.

Mais alguns cabeçalhos aparecem com frequência suficiente para serem conhecidos pelo nome:

• X-Content-Type-Options: nosniff impede que o navegador adivinhe o tipo de arquivo, o que pode transformar um arquivo carregado em um script executável.

• Permissions-Policy desativa recursos do navegador que você não usa, como câmera, microfone ou geolocalização.

• Cross-Origin-Opener-Policy e cabeçalhos de origem cruzada relacionados isolam sua página de outras, o que ajuda a conter certos ataques.

Você não precisa de todos eles no primeiro dia. Saber o que eles fazem ajuda você a ler um relatório de varredura sem entrar em pânico.

Você tem duas maneiras de olhar.

Primeiro, a rota manual: ferramentas do desenvolvedor, guia Rede, clique na solicitação da página e leia os cabeçalhos de resposta. Isso é útil para confirmar a presença de um único cabeçalho e definir da maneira esperada.

Em segundo lugar, o caminho prático para mais de uma página: execute uma varredura. Um scanner busca seu site da mesma forma que um navegador faria e relata quais cabeçalhos de segurança estão presentes, quais estão faltando e o que cada lacuna expõe. Isso fornece uma lista priorizada em vez de uma parede de texto bruto - e verifica as páginas que você não pensaria em abrir manualmente.

Uma ferramenta de uso geral, como a verificação de segurança leve e gratuita do VICE, sinalizará as descobertas do cabeçalho junto com outros problemas, com as evidências por trás de cada um para que você possa ver por que foi levantado.

Os cabeçalhos residem na configuração, então a maioria das correções são pequenas: adicione uma linha à configuração do seu servidor, uma configuração na sua estrutura ou uma opção no painel do seu host. Altere um cabeçalho de cada vez e confirme se o site ainda funciona.

Em seguida, verifique novamente. Esta é a etapa que as pessoas pulam. Editar uma configuração não significa que o cabeçalho esteja correto em todas as páginas, e marcar algo como corrigido em um painel não é o mesmo que confirmá-lo. Somente uma nova verificação no mesmo escopo informa que a alteração realmente entrou em vigor.

Comece com uma verificação gratuita, observe o que seus cabeçalhos realmente estão fazendo e corrija as principais descobertas, uma de cada vez. Essa é uma primeira tentativa razoável - e uma posição muito melhor do que esperar que os padrões fossem bons.