Segurança de Headers HTTP
Nesta aula, você aprenderá sobre a importância dos headers HTTP para a segurança de aplicações web, explorando em detalhe Content Security Policy (CSP), HTTP Strict Transport Security (HSTS), X-Frame-Options e Referrer-Policy, com exemplos práticos de configuração e boas práticas.
Headers HTTP são campos enviados pelo servidor ao navegador durante uma resposta HTTP, controlando aspectos como cache, conexão e, crucialmente, segurança. Configurar corretamente os headers de segurança é uma das medidas mais eficazes e simples para proteger uma aplicação web contra ataques comuns como XSS, clickjacking e downgrade de protocolo. Nesta aula, vamos explorar quatro headers fundamentais: CSP, HSTS, X-Frame-Options e Referrer-Policy, entendendo seu funcionamento, como configurá-los e as melhores práticas.
Esses headers funcionam como uma camada de defesa adicional, complementando a segurança no servidor e no código. Eles instruem o navegador a adotar comportamentos mais restritivos, mitigando riscos mesmo quando a aplicação possui vulnerabilidades. Ao final desta aula, você será capaz de implementar esses headers em seus projetos e entender o impacto de cada um na segurança geral.
CSP
Content Security Policy (CSP) é um header que permite restringir as origens de conteúdo que o navegador pode carregar em uma página, como scripts, estilos, imagens e fontes. Isso ajuda a prevenir ataques de Cross-Site Scripting (XSS) e injeção de conteúdo, pois o navegador bloqueia qualquer recurso que não esteja explicitamente permitido pela política.
A política é definida por meio de diretivas, como default-src, script-src, style-src e img-src, cada uma controlando um tipo de recurso. Por exemplo, uma política restritiva pode permitir apenas scripts da própria origem e de um CDN confiável, bloqueando scripts inline e eval. A configuração é feita no servidor, adicionando o header Content-Security-Policy com a política desejada.
Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data:;No exemplo acima, scripts são permitidos apenas da própria origem e de um CDN, estilos permitem inline, e imagens podem ser carregadas da própria origem ou via data URI. É importante testar a política em um ambiente de desenvolvimento, usando o modo de relatório (Content-Security-Policy-Report-Only) para receber violações sem bloquear conteúdo. Uma boa prática é começar com uma política restritiva e ir ajustando conforme a aplicação funciona.
HSTS
HTTP Strict Transport Security (HSTS) é um header que informa ao navegador que o site deve ser acessado apenas por HTTPS, forçando o uso de conexão segura e prevenindo ataques de downgrade para HTTP. Quando um navegador recebe esse header, ele automaticamente converte qualquer link HTTP para HTTPS e, se a conexão HTTPS falhar, exibe um erro em vez de cair para HTTP.
O header HSTS inclui o parâmetro max-age, que define o tempo (em segundos) durante o qual a política é válida. Pode-se incluir includeSubDomains para aplicar a todos os subdomínios e preload para ser incluído na lista de pré-carregamento do navegador, garantindo que a política seja aplicada antes mesmo do primeiro acesso.
Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadPara usar HSTS, o site deve estar acessível via HTTPS e o certificado deve ser válido. É recomendável começar com um max-age menor (ex.: 300 segundos) e aumentar gradualmente, após testar. Para o preload, é necessário submeter o domínio ao site hstspreload.org. HSTS não é uma solução mágica: se o usuário digitar o domínio pela primeira vez sem HTTPS, ele pode ser vítima de um ataque, mas a pré-carga ajuda a mitigar isso.
X-Frame-Options
O header X-Frame-Options protege contra clickjacking, um ataque onde o site é embutido em um iframe malicioso e o usuário é induzido a clicar em elementos invisíveis. Ao definir esse header, você controla se o navegador pode renderizar a página em um frame. As opções são: DENY (nunca permitir), SAMEORIGIN (permitir apenas se a origem do frame for a mesma do site) e ALLOW-FROM (obsoleta, não suportada em navegadores modernos).
A configuração é simples:
X-Frame-Options: DENYOu para permitir apenas na mesma origem:
X-Frame-Options: SAMEORIGINEmbora o X-Frame-Options seja amplamente suportado, ele é limitado em comparação com a diretiva frame-ancestors do CSP, que oferece mais controle (ex.: permitir origens específicas). Recomenda-se usar ambos: CSP para uma política mais granular e X-Frame-Options como fallback para navegadores antigos. Em aplicações modernas, prefira frame-ancestors.
Referrer-Policy
O header Referrer-Policy controla quanta informação de referência (a URL de origem) é enviada no cabeçalho Referer quando o usuário navega para outros sites. Isso é importante para privacidade, pois a URL pode conter dados sensíveis, como tokens de sessão ou parâmetros de consulta. Políticas como no-referrer não enviam nenhuma informação, enquanto same-origin envia apenas para a mesma origem.
Opções comuns incluem: no-referrer, no-referrer-when-downgrade (padrão, envia para HTTPS, mas não para HTTP), same-origin, strict-origin, strict-origin-when-cross-origin (recomendado, envia apenas a origem para outras origens e a URL completa para a mesma origem).
Referrer-Policy: strict-origin-when-cross-originEssa configuração equilibra privacidade e funcionalidade, enviando a origem completa para a mesma origem (necessário para alguns recursos) e apenas a origem para sites externos. É uma boa prática usar essa política por padrão, a menos que sua aplicação precise de mais informações.
Boas Práticas
Além de configurar os headers individualmente, é importante integrar a configuração ao pipeline de desenvolvimento. Use bibliotecas ou middleware que definem esses headers automaticamente, como Helmet para Node.js, ou configure no servidor web (Apache, Nginx) ou em plataformas de hospedagem. Teste as configurações com ferramentas como o Security Headers Analyzer da Mozilla Observatory. Lembre-se de que headers são parte da segurança, mas não substituem outras práticas como validação de entrada, sanitização e autenticação robusta.
Exercícios
- Explique qual é a função do header CSP e cite duas diretivas comuns. Dê um exemplo de política que bloqueie scripts inline e permita scripts de um CDN.
- O que é HSTS e como ele protege contra ataques de downgrade? Descreva os parâmetros
max-ageeincludeSubDomains. - Qual é a diferença entre X-Frame-Options e a diretiva CSP
frame-ancestors? Cite uma situação em que você usaria cada um. - Por que o header Referrer-Policy é importante para a privacidade? Dê um exemplo de política que envie apenas a origem para sites externos.
- Você é responsável por configurar os headers de segurança de um site de comércio eletrônico. Proponha uma configuração completa (em formato de cabeçalhos) que aplique CSP, HSTS, X-Frame-Options e Referrer-Policy, justificando suas escolhas.
script-src (controla scripts) e img-src (controla imagens). Exemplo: Content-Security-Policy: script-src 'self' https://cdn.example.com; object-src 'none'max-age define o tempo (em segundos) que a política é válida; includeSubDomains aplica a política a todos os subdomínios.frame-ancestors permite listar origens permitidas, sendo mais flexível. Use X-Frame-Options para compatibilidade com navegadores antigos e frame-ancestors quando precisar de controle granular.strict-origin-when-cross-origin.Content-Security-Policy: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; frame-ancestors 'none'; Strict-Transport-Security: max-age=31536000; includeSubDomains; X-Frame-Options: DENY; Referrer-Policy: strict-origin-when-cross-origin Justificativa: CSP restringe recursos para própria origem, HSTS força HTTPS, X-Frame-Options bloqueia frames (reforçado por frame-ancestors), e Referrer-Policy protege a privacidade.