CORS, CSP, HSTS e outros cabeçalhos HTTP

Cabeçalhos como políticas declarativas entre servidor, gateway e navegador

Princípio central

Cabeçalhos não corrigem lógica de autorização, autenticação ou negócio; eles governam comportamento de clientes e intermediários.

Edição aprofundada - material de estudo e consulta profissional

radio_button_unchecked Apresentação do capítulo

O capítulo anterior apresentou o OWASP API Security Top 10 e mostrou que a proteção de uma API depende de controles distribuídos entre cliente, navegador, gateway , backend , identidade, rede e operação. Este capítulo aprofunda uma parte específica dessa defesa: os cabeçalhos HTTP que instruem navegadores e intermediários sobre como tratar origens, conteúdo executável, transporte seguro, isolamento de contexto, privacidade e armazenamento em cache .

CORS , CSP e HSTS são frequentemente agrupados como cabeçalhos de segurança, mas resolvem problemas muito diferentes. CORS define quando um navegador pode expor a uma aplicação web uma resposta obtida de outra origem. CSP limita fontes de scripts, estilos, frames, conexões e outros recursos, reduzindo impacto de injeção de conteúdo. HSTS instrui o navegador a utilizar HTTPS para um host durante um período definido. Nenhum deles substitui autenticação, autorização, validação de dados ou correção de vulnerabilidades no backend .

Outros cabeçalhos complementam esse modelo. Referrer -Policy limita a informação enviada no Referer; Permissions-Policy controla recursos do navegador; X-Content-Type- Options reduz interpretações inesperadas de MIME ; frame-ancestors e X-Frame- Options tratam incorporação em frames; COOP , COEP e CORP participam de isolamento entre origens; Cache -Control protege respostas sensíveis contra armazenamento indevido; atributos de cookies reduzem exposição a scripts, transporte inseguro e requisições cross-site.

O objetivo é construir um modelo mental preciso para implementação e troubleshooting . O leitor deverá saber distinguir uma falha real da API de uma decisão do navegador, reconhecer erros de configuração em API Gateways e CDNs, planejar rollout seguro de políticas restritivas e testar as proteções sem confiar apenas em scanners automáticos.

Como estudar este capítulo

Para cada cabeçalho, identifique cinco elementos: quem envia, quem aplica, qual ativo protege, qual ameaça reduz e qual comportamento legítimo pode ser quebrado. Essa análise evita a prática perigosa de copiar um conjunto de headers sem entender seus efeitos.

Objetivos de aprendizagem

• Explicar origem, site, same-origin policy e a fronteira de segurança do navegador.
• Descrever requisições CORS simples, preflight , credenciais e cache de preflight .
• Configurar corretamente Access-Control-Allow- Origin e cabeçalhos relacionados.
• Diferenciar CORS de autenticação, CSRF , firewall e segurança servidor-servidor.
• Projetar Content Security Policy com diretivas, nonces , hashes e implantação em report-only.
• Compreender HSTS , includeSubDomains, preload e riscos de rollout incorreto.
• Aplicar X-Content-Type- Options , frame-ancestors, Referrer -Policy e Permissions-Policy.
• Relacionar COOP , COEP e CORP ao isolamento cross- origin .
• Definir Cache -Control e atributos de cookies para respostas e sessões sensíveis.
• Implementar, testar e observar cabeçalhos em aplicações, gateways e CDNs.

Estrutura do capítulo

• 26.1 Modelo de segurança do navegador e cabeçalhos declarativos
• 26.2 Origem, site e Same-Origin Policy
• 26.3 CORS : propósito e fluxo de decisão
• 26.4 Requisições simples e preflight
• 26.5 Cabeçalhos CORS de requisição e resposta
• 26.6 Credenciais, cookies , Authorization e curingas
• 26.7 CORS em API Gateways e erros frequentes
• 26.8 Content Security Policy: modelo e diretivas
• 26.9 Nonces , hashes , strict-dynamic e scripts inline
• 26.10 Reporting e implantação gradual de CSP
• 26.11 HTTP Strict Transport Security
• 26.12 Clickjacking, MIME sniffing e proteção de frames
• 26.13 Referrer -Policy e Permissions-Policy
• 26.14 COOP , COEP e CORP
• 26.15 Cache -Control, Clear-Site-Data e cookies
• 26.16 Cabeçalhos obsoletos, troubleshooting e laboratórios
• Resumo, checklist, exercícios, glossário e referências

radio_button_unchecked 26.1 Modelo de segurança do navegador e cabeçalhos declarativos

Navegadores executam código fornecido por múltiplas origens e precisam impedir que uma página maliciosa leia dados de outra aplicação apenas porque o usuário está autenticado nela. Essa proteção não é implementada por um único mecanismo. A Same-Origin Policy estabelece uma fronteira básica; CORS permite exceções controladas; CSP restringe o conteúdo que pode ser carregado ou executado; cookies possuem atributos próprios; e políticas de isolamento reduzem compartilhamento entre contextos.

Cabeçalhos de segurança são declarativos: o servidor envia uma política e o agente compatível decide como aplicá-la. Isso cria uma diferença importante entre segurança do navegador e segurança da API . Um cliente escrito em Java, Python ou curl pode ignorar completamente CORS e CSP , porque esses mecanismos não foram projetados como controle de acesso universal. A API ainda precisa validar credenciais, autorização, esquema e regras de negócio em todas as requisições.

O gateway é um ponto eficiente para padronizar cabeçalhos, mas não conhece automaticamente todas as necessidades da aplicação. Uma CSP adequada depende dos scripts, frames e conexões realmente usados por cada front-end. CORS depende das origens consumidoras e da política de credenciais. Cache -Control depende da sensibilidade e da possibilidade de compartilhamento. Portanto, a plataforma pode fornecer defaults e guardrails, enquanto o produto mantém ownership da política específica.

Distinção essencial

CORS não protege a API contra chamadas externas; ele controla se um navegador entrega a resposta ao JavaScript de outra origem. Um atacante ou sistema servidor-servidor continua capaz de enviar a requisição. Autorização e proteção contra abuso permanecem obrigatórias.

radio_button_unchecked 26.2 Origem, site e Same-Origin Policy

Uma origem é definida conceitualmente pelo trio esquema, host e porta. https ://app.empresa.com e https :// api .empresa.com possuem hosts diferentes e, portanto, origens diferentes. https ://app.empresa.com e http ://app.empresa.com diferem no esquema. https ://app.empresa.com:443 e https ://app.empresa.com:8443 diferem na porta. O caminho da URL não participa da origem.

O conceito de site é relacionado, mas não idêntico. Mecanismos como SameSite em cookies trabalham com a noção de site, enquanto CORS usa origem. Dois subdomínios podem ser same-site e ainda cross- origin . Essa diferença explica cenários em que um cookie é enviado, mas o JavaScript não consegue ler a resposta porque a política CORS não autorizou a origem.

A Same-Origin Policy limita leitura e interação entre contextos de origens diferentes. Ela não impede todo envio de dados cross- origin : formulários, imagens, links e outros recursos historicamente realizam requisições. A proteção principal está em restringir a capacidade do script de observar conteúdo e manipular objetos de outra origem. CORS é o protocolo que permite ao servidor declarar exceções controladas para determinadas operações.

radio_button_unchecked 26.3 CORS : propósito e fluxo de decisão

Cross- Origin Resource Sharing é um protocolo integrado ao modelo de fetch do navegador. Quando um script tenta acessar uma API de outra origem, o navegador acrescenta o cabeçalho Origin . A resposta precisa conter cabeçalhos que indiquem se aquela origem, método, conjunto de headers e uso de credenciais são permitidos. Quando a política não corresponde, a requisição pode até alcançar o servidor, mas a resposta não é disponibilizada ao JavaScript.

Essa característica produz um sintoma frequente: o backend registra sucesso, o gateway devolve 200, mas o console do navegador mostra erro de CORS . Não há contradição. O servidor processou a operação; o navegador bloqueou a exposição da resposta. Por isso, operações com efeito colateral não podem depender de CORS como proteção contra CSRF ou ações indevidas.

O navegador pode enviar diretamente a requisição quando ela satisfaz os critérios de uma requisição CORS simples. Em outras situações, realiza preflight com OPTIONS . O preflight pergunta ao servidor se o método e os cabeçalhos pretendidos são aceitos antes de enviar a operação real. A resposta positiva pode ser armazenada em cache específico do navegador por um período limitado.

CORS com preflight : o navegador negocia antes de enviar a operação real

radio_button_unchecked 26.4 Requisições simples e preflight

O termo requisição simples não significa que a operação seja segura para o negócio. Ele indica que o navegador pode enviá-la sem preflight por manter compatibilidade com padrões históricos da Web. Métodos como GET , HEAD e POST podem participar quando os headers e o Content-Type permanecem dentro do conjunto permitido pelo protocolo. Um POST application/ json , por exemplo, normalmente provoca preflight .

O preflight utiliza OPTIONS e inclui Access-Control- Request -Method. Se o script pretende enviar headers não safelisted, o navegador também inclui Access-Control- Request - Headers . O servidor responde com os métodos e headers autorizados. A requisição real só é liberada quando a resposta satisfaz as verificações do navegador.

Preflight não é autenticação. Algumas arquiteturas cometem o erro de exigir token no OPTIONS ou encaminhar o preflight a backends que não conhecem CORS . Como o preflight é uma consulta de política realizada antes da requisição real, gateways normalmente o tratam de forma específica. Entretanto, responder permissivamente a qualquer origem e método também cria risco; a política precisa ser derivada de configuração confiável.

Exemplo de preflight e resposta

OPTIONS /clientes/123 HTTP/1.1
Host: api.empresa.example
Origin: https://portal.empresa.example
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: authorization, content-type
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://portal.empresa.example
Access-Control-Allow-Methods: GET, PUT
Access-Control-Allow-Headers: Authorization, Content-Type
Access-Control-Max-Age: 600
Vary: Origin

radio_button_unchecked 26.5 Cabeçalhos CORS de requisição e resposta

Origin identifica a origem do contexto que iniciou a requisição. Access-Control-Allow- Origin informa qual origem está autorizada a ler a resposta. O valor pode ser uma origem específica ou o curinga em cenários sem credenciais. Quando a lista permitida é dinâmica, o servidor deve validar o valor recebido contra uma allowlist e devolver exatamente a origem aprovada, nunca refletir qualquer valor sem verificação.

Access-Control-Allow-Methods e Access-Control-Allow- Headers participam principalmente do preflight . Access-Control-Expose- Headers permite que JavaScript leia cabeçalhos de resposta que não pertencem ao conjunto exposto por padrão. Access-Control-Max-Age influencia o cache do preflight , sujeito a limites do navegador. Access-Control-Allow-Credentials permite respostas credentialed quando combinado a uma origem explícita.

Vary : Origin é importante quando a resposta pode mudar conforme a origem solicitante e passa por caches compartilhados. Sem essa indicação, um cache pode reutilizar para outra origem uma resposta que contém Access-Control-Allow- Origin específico. Em plataformas com CDN ou gateway , a chave de cache e a política CORS devem ser projetadas em conjunto.

Uma requisição credentialed pode envolver cookies , certificados de cliente ou credenciais HTTP controladas pelo agente. No fetch, o modo credentials determina se credenciais são enviadas e se respostas com Set- Cookie são consideradas. Para que o JavaScript receba uma resposta credentialed cross- origin , o servidor precisa retornar Access-Control-Allow-Credentials: true e uma origem explícita.

O curinga em Access-Control-Allow- Origin não pode ser usado para expor respostas credentialed. Essa restrição reduz risco de um site arbitrário ler dados associados à sessão do usuário. Também é inadequado gerar Access-Control-Allow- Origin copiando o Origin recebido sem validação. Reflection irrestrita transforma a política em autorização universal disfarçada.

CORS e atributos SameSite de cookies se relacionam, mas não são equivalentes. O cookie pode não ser enviado por causa de SameSite, Secure ou regras de terceiros antes mesmo de CORS ser avaliado. Em outro cenário, o cookie é enviado e o servidor processa a requisição, mas o navegador bloqueia a leitura da resposta. O diagnóstico precisa observar envio de cookies , preflight , resposta real e console do navegador separadamente.

Regra prática

Para APIs com sessão por cookie , trate CORS , SameSite, CSRF e política de origem como controles complementares. Para APIs com bearer token , valide token e autorização normalmente; o fato de o navegador exigir preflight não torna o endpoint protegido contra clientes fora do navegador.

radio_button_unchecked 26.7 CORS em API Gateways e erros frequentes

API Gateways podem centralizar CORS , responder preflight sem alcançar o backend e aplicar allowlists por ambiente, produto ou API . Essa centralização reduz duplicidade, mas exige definir ownership. Se gateway e backend adicionarem cabeçalhos diferentes, a resposta pode conter valores duplicados ou contraditórios. Alguns navegadores rejeitam respostas com múltiplos Access-Control-Allow- Origin .

A política deve ser aplicada também a respostas de erro. Uma API que retorna CORS apenas em 2xx pode fazer o navegador esconder o corpo de 401, 403 ou 500, dificultando diagnóstico e experiência do cliente. A seção on-error ou equivalente do gateway precisa produzir os mesmos cabeçalhos relevantes sem abrir permissões adicionais.

Outro erro frequente é permitir origens por comparação textual insegura. Testes como endsWith("empresa.com") podem aceitar domínios maliciosos. O valor precisa ser interpretado como origem e comparado com allowlist exata ou regra de subdomínio cuidadosamente definida. Expressões regulares devem ser ancoradas e testadas contra esquemas, portas, case normalization e origens nulas quando aplicável.

radio_button_unchecked 26.8 Content Security Policy: modelo e diretivas

Content Security Policy define restrições sobre os recursos que uma página pode carregar ou executar. A política pode ser enviada no header Content-Security-Policy ou, em casos específicos, por elemento meta. O header possui maior alcance e é a forma preferida para políticas completas. A CSP não corrige a vulnerabilidade que permitiu injeção, mas pode reduzir o que o conteúdo injetado consegue fazer.

As diretivas são especializadas. default-src fornece fallback para vários tipos de recurso. script-src controla scripts; style-src controla estilos; img-src imagens; connect-src conexões realizadas por fetch, XHR, WebSocket e mecanismos relacionados; font-src fontes; frame-src conteúdo carregado em frames; frame-ancestors define quem pode incorporar a página; object-src controla plugins; base- uri restringe a URL base; form-action limita destinos de formulário.

Uma política deve ser mínima e compatível com a aplicação real. Autorizar amplamente https : ou usar unsafe-inline e unsafe-eval reduz proteção. Ao mesmo tempo, bloquear recursos sem inventário pode quebrar login, telemetria, fontes, integrações e funcionalidades legítimas. Por isso, CSP deve ser construída a partir de inventário, testes e observação, não copiada de outra aplicação.

CSP : cada recurso é comparado com a política antes de ser carregado ou executado

Exemplo de política CSP restritiva

Content-Security-Policy:
  default-src 'none';
  script-src 'self' 'nonce-R4nd0mBase64';
  style-src 'self';
  img-src 'self' data:;
  connect-src 'self' https://api.empresa.example;
  frame-ancestors 'none';
  base-uri 'none';
  form-action 'self'

radio_button_unchecked 26.9 Nonces , hashes , strict-dynamic e scripts inline

Scripts inline são uma fonte importante de risco porque uma injeção de HTML pode se transformar em execução de JavaScript. Remover inline scripts e servir arquivos estáticos é a solução mais simples quando possível. Quando a aplicação precisa de script inline, um nonce criptograficamente imprevisível pode ser gerado por resposta e incluído tanto na CSP quanto no elemento script autorizado.

Hashes permitem autorizar conteúdo inline cujo texto é conhecido e estável. O navegador calcula o hash do bloco e compara com o valor da política. Pequenas mudanças no conteúdo exigem novo hash . Nonces são mais adequados para conteúdo dinâmico, desde que não sejam reutilizados nem inseridos automaticamente em conteúdo controlado por usuário.

strict-dynamic permite que scripts confiáveis carregados por nonce ou hash propaguem confiança a scripts adicionados por eles, reduzindo dependência de allowlists de host. Essa estratégia exige testes de compatibilidade e compreensão do bootstrap da aplicação. unsafe-inline e unsafe-eval devem ser tratados como concessões temporárias com plano de remoção, não como configuração padrão.

radio_button_unchecked 26.10 Reporting e implantação gradual de CSP

Content-Security-Policy-Report-Only permite observar violações sem bloquear recursos. É útil para inventariar dependências e descobrir código inline, domínios de terceiros e fluxos não documentados. Entretanto, report-only não protege o usuário; ele é uma etapa de implantação. Uma organização madura define prazo para transformar observações em política efetiva.

Relatórios podem conter URLs e informações sensíveis. O endpoint de coleta precisa de controle de volume, retenção e privacidade. Eventos devem ser agregados por diretiva, origem e versão da aplicação para distinguir ataques, extensões de navegador, ruído e regressões reais. A política efetiva e a política de observação podem coexistir, permitindo endurecimento progressivo.

O rollout recomendado começa por inventário, passa por report-only, corrige violações legítimas, bloqueia diretivas de menor risco e evolui até política restritiva. Alterações de CSP devem participar do pipeline e ser testadas com jornadas críticas, porque um header incorreto pode indisponibilizar todo o front-end mesmo que a API permaneça saudável.

CSP não é lista de domínios confiáveis

Autorizar um domínio significa aceitar todo conteúdo que ele possa servir naquele contexto. CDNs compartilhadas, endpoints de upload e serviços de terceiros ampliam a superfície. Prefira nonces , hashes e fontes específicas em vez de allowlists excessivamente amplas.

radio_button_unchecked 26.11 HTTP Strict Transport Security

HTTP Strict Transport Security permite que um host declare que deve ser acessado apenas por HTTPS . O navegador armazena a política recebida em uma conexão HTTPS válida e, durante max-age, transforma tentativas de HTTP em HTTPS antes de enviar a requisição pela rede. Isso reduz exposição a ataques de downgrade e remoção de TLS após o host ter sido conhecido como seguro.

O header possui a diretiva max-age e pode incluir includeSubDomains. Esta última estende a política aos subdomínios e exige inventário completo: qualquer subdomínio sem HTTPS funcional pode se tornar inacessível. A diretiva preload é usada como sinal de intenção para programas de preload, mas a inclusão real depende de requisitos e processos externos ao protocolo.

HSTS não corrige certificado expirado, hostname incorreto ou cadeia inválida. Ao contrário, o navegador deve falhar de forma rígida e não oferecer downgrade inseguro. O primeiro acesso continua sendo uma consideração quando o host ainda não está no estado HSTS ; preload pode reduzir essa janela, mas aumenta o compromisso operacional de longo prazo.

HSTS altera decisões futuras do navegador para um host conhecido

Exemplos de HSTS

Strict-Transport-Security: max-age=31536000; includeSubDomains
# Implantação gradual possível
Strict-Transport-Security: max-age=300
Strict-Transport-Security: max-age=86400
Strict-Transport-Security: max-age=31536000; includeSubDomains

radio_button_unchecked 26.12 Clickjacking, MIME sniffing e proteção de frames

Clickjacking ocorre quando uma aplicação é incorporada de forma invisível ou enganosa em outro site e o usuário interage com controles sem perceber o contexto real. A diretiva CSP frame-ancestors é o mecanismo moderno para controlar quais origens podem enquadrar a página. X-Frame- Options oferece DENY e SAMEORIGIN, permanecendo relevante em compatibilidade, mas não possui a flexibilidade de uma lista de origens.

X-Content-Type- Options : nosniff instrui o navegador a respeitar tipos MIME em contextos relevantes em vez de inferir conteúdo executável. Isso reduz cenários em que um recurso servido com tipo incorreto é interpretado como script ou stylesheet. O header não substitui Content-Type correto; ambos devem ser configurados.

frame-ancestors protege documentos que podem ser enquadrados, enquanto frame-src controla quais frames a própria página pode carregar. Confundir as duas diretivas produz políticas ineficazes. Também é importante observar que APIs JSON puras normalmente não precisam ser renderizadas em frame, mas portais, consoles administrativos e páginas de autenticação precisam de proteção explícita.

radio_button_unchecked 26.13 Referrer -Policy e Permissions-Policy

O header Referer pode revelar URL de origem da navegação ou carregamento. Quando URLs contêm identificadores, parâmetros internos ou estrutura sensível, esse compartilhamento cria risco de privacidade. Referrer -Policy controla quanto da informação é enviado. Políticas como no- referrer , same- origin e strict- origin -when-cross- origin oferecem níveis diferentes de restrição.

A escolha deve equilibrar privacidade, antifraude, analytics e troubleshooting . Enviar a URL completa para terceiros raramente é necessário. Uma política orientada a origem reduz exposição de path e query em navegações cross- origin , mantendo informação suficiente para alguns controles. Dados sensíveis não devem estar em URL , mesmo com política restritiva, porque podem aparecer em logs e histórico.

Permissions-Policy permite habilitar ou desabilitar recursos de navegador para o documento e frames, como câmera, microfone, geolocalização e fullscreen, conforme o conjunto suportado. O objetivo é reduzir capacidades disponíveis a conteúdo próprio e de terceiros. A antiga nomenclatura Feature-Policy foi substituída; configurações devem usar a sintaxe e os recursos atuais do agente alvo.

Exemplos de privacidade e capacidades do navegador

Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=(self)
# Exemplo mais restritivo
Referrer-Policy: no-referrer

radio_button_unchecked 26.14 COOP , COEP e CORP

Cross- Origin -Opener-Policy controla a relação entre um documento e janelas abertas ou que o abriram. Ao isolar grupos de contexto, reduz ataques e interferências que dependem de referências entre janelas. Cross- Origin -Embedder-Policy exige que recursos cross- origin incorporados sejam explicitamente compartilháveis por CORS ou CORP , conforme o modo adotado.

Cross- Origin -Resource-Policy permite que um recurso declare se pode ser carregado por documentos de mesma origem, mesmo site ou qualquer contexto permitido. Em conjunto, COOP e COEP podem produzir cross- origin isolation, necessário para algumas APIs poderosas do navegador. Essa configuração deve ser testada porque recursos de terceiros sem headers adequados podem deixar de carregar.

Esses cabeçalhos não são substitutos de CSP ou CORS . CORS controla acesso programático a respostas; CORP protege o recurso contra determinados carregamentos cross- origin ; COOP separa contextos de navegação; COEP define requisitos de incorporação. A arquitetura precisa saber qual lado publica cada política e como CDNs, imagens, fontes e scripts de terceiros se comportam.

radio_button_unchecked 26.15 Cache -Control, Clear-Site-Data e cookies

Respostas sensíveis podem permanecer em cache do navegador, proxy ou CDN . Cache -Control define diretivas para armazenamento e reutilização. no-store é apropriado quando nenhuma retenção é aceitável; private permite cache privado, mas não compartilhado; no- cache exige revalidação antes do uso; max-age define frescor. As diretivas devem ser escolhidas pela semântica da resposta, não por uma regra única para toda a API .

Autenticação não torna uma resposta automaticamente não cacheável. Gateways e CDNs precisam considerar Authorization, cookies , Vary e regras explícitas. Uma resposta personalizada armazenada em cache compartilhado pode vazar dados entre usuários. Em contrapartida, desabilitar todo cache indiscriminadamente pode degradar desempenho e aumentar custo. O desenho deve separar conteúdo público, privado, imutável e transacional.

Clear-Site-Data permite solicitar limpeza de categorias de dados do site, como cache , cookies e storage, dependendo do suporte. Pode ser útil em logout ou resposta a incidente, mas deve ser usado com cuidado para não eliminar estado legítimo ou causar loops. Não substitui revogação de sessão no servidor.

Set- Cookie possui atributos relevantes para segurança. Secure restringe envio a canais seguros; HttpOnly impede acesso por JavaScript; SameSite influencia envio em contextos cross-site; Path e Domain controlam escopo; Max-Age e Expires definem persistência. Cookies de sessão e autenticação devem usar escopo mínimo e não carregar informação sensível em texto claro.

Exemplos de cache , limpeza e cookie

Cache-Control: no-store
Clear-Site-Data: "cache", "cookies", "storage"
Set-Cookie: __Host-session=<valor>; Path=/; Secure; HttpOnly; SameSite=Lax
# Conteúdo público versionado
Cache-Control: public, max-age=31536000, immutable

radio_button_unchecked 26.16 Cabeçalhos obsoletos e disclosure de tecnologia

Nem todo header historicamente recomendado deve continuar sendo implantado. X- XSS -Protection se relaciona a filtros antigos de navegador e não substitui CSP . Public Key Pinning for HTTP criou riscos operacionais significativos e foi abandonado por navegadores; HPKP não deve ser reintroduzido como hardening genérico. Expect-CT perdeu relevância com a evolução de Certificate Transparency e suporte dos agentes.

Feature-Policy foi substituído por Permissions-Policy. X-Frame- Options continua útil para compatibilidade, mas frame-ancestors oferece controle moderno. Pragma é legado para cache HTTP /1.0 e não substitui uma política Cache -Control clara. A gestão de headers precisa acompanhar padrões e suporte real, removendo recomendações obsoletas de templates corporativos.

Cabeçalhos como Server e X-Powered-By podem revelar produtos e versões. Reduzir disclosure evita entregar informações desnecessárias, mas não deve ser confundido com correção de vulnerabilidades. Um atacante pode identificar tecnologia por outros sinais. A prioridade continua sendo patching, configuração segura, inventário e redução de superfície.

radio_button_unchecked 26.17 Implementação em aplicações, gateways e CDNs

A aplicação conhece melhor o conteúdo e deve participar de CSP , cookies , cache e políticas específicas da jornada. O gateway pode aplicar defaults, CORS , HSTS , remoção de disclosure, observabilidade e guardrails. A CDN pode acrescentar ou normalizar headers , mas sua posição no fluxo precisa ser compreendida para evitar sobrescrita e duplicidade.

Uma política corporativa madura define uma matriz por tipo de ativo: API JSON pública, API privada, portal estático, aplicação autenticada, console administrativo e download de arquivo. Cada categoria recebe baseline e exceções aprovadas. Aplicar a mesma CSP a uma API JSON e a uma SPA não faz sentido; da mesma forma, CORS pode ser irrelevante para integração exclusivamente servidor-servidor.

Configuração como código e testes automatizados reduzem drift. O pipeline pode verificar presença, valor, duplicidade e consistência dos headers . Testes end-to-end devem validar comportamento real no navegador, porque proxies , redirects e respostas de erro podem alterar a política. Em ambientes distribuídos, registre qual componente adicionou ou removeu cada header .

Ordem de responsabilidade

Evite múltiplos componentes escrevendo o mesmo cabeçalho sem regra de precedência. Defina claramente se aplicação, gateway , ingress, CDN ou servidor web é a fonte autoritativa. Duplicidade pode ser tão perigosa quanto ausência.

radio_button_unchecked 26.18 Troubleshooting e laboratórios

O diagnóstico começa no navegador: Network mostra preflight , redirects, cookies e headers ; Console apresenta violações de CORS e CSP ; ferramentas de Application mostram cookies e storage. Em seguida, compare a resposta observada no navegador com curl ou um cliente servidor-servidor. Se curl funciona e fetch falha, a diferença provavelmente está no modelo de segurança do navegador, não na conectividade básica.

Para CORS , verifique Origin , método, headers solicitados, resposta OPTIONS , resposta real, credenciais, Vary e duplicidade. Para CSP , identifique a diretiva violada, a URL bloqueada, nonce ou hash e política efetiva. Para HSTS , confirme que o header foi recebido por HTTPS , o estado do host e a cobertura de subdomínios. Para cache , observe Age, Cache -Control, Vary e o componente que serviu a resposta.

Laboratórios devem ser executados em ambientes autorizados. É útil montar duas origens locais em portas diferentes, observar requisição simples e preflight , ativar credenciais, testar allowlist , implantar CSP em report-only, introduzir um script inline bloqueado, habilitar HSTS com max-age curto e validar headers em respostas de erro do gateway .

radio_button_unchecked Resumo do capítulo

CORS , CSP e HSTS são mecanismos distintos. CORS controla acesso cross- origin mediado pelo navegador; CSP restringe carregamento e execução de conteúdo; HSTS estabelece uso obrigatório de HTTPS após a política ser aprendida. Nenhum deles substitui segurança de backend , autenticação ou autorização.

Cabeçalhos complementares reduzem outras classes de risco: frame-ancestors e X-Frame- Options tratam clickjacking; X-Content-Type- Options reduz MIME sniffing ; Referrer -Policy melhora privacidade; Permissions-Policy limita capacidades; COOP , COEP e CORP participam do isolamento; Cache -Control e atributos de cookies protegem estado e respostas sensíveis.

A implantação correta exige ownership, rollout gradual, testes em navegador, consistência em respostas de erro e observabilidade. Templates genéricos sem compreensão podem quebrar aplicações ou produzir falsa sensação de segurança. A política precisa refletir a arquitetura e ser revisada conforme padrões, navegadores e produtos evoluem.

Próximo passo do curso

O próximo capítulo aprofunda Rate Limiting , Quotas e Throttling , mecanismos que controlam consumo, protegem capacidade e aplicam contratos operacionais em API Gateways .

radio_button_unchecked Checklist de implementação

• CORS possui allowlist explícita e não reflete Origin arbitrariamente.
• Preflight é tratado corretamente e não depende de autenticação da operação real.
• Headers CORS aparecem também nas respostas de erro relevantes.
• Respostas variáveis por origem usam Vary e chave de cache coerente.
• CSP foi implantada com inventário, report-only e plano de remoção de unsafe-inline/unsafe-eval.
• Scripts inline autorizados usam nonce ou hash corretamente.
• HSTS foi ativado gradualmente e includeSubDomains foi precedido de inventário.
• frame-ancestors, nosniff, Referrer -Policy e Permissions-Policy possuem valores adequados ao ativo.
• COOP , COEP e CORP foram testados com recursos de terceiros.
• Cache -Control protege respostas personalizadas e sensíveis sem bloquear cache legítimo indiscriminadamente.
• Cookies de sessão usam Secure, HttpOnly, SameSite e escopo mínimo.
• Cabeçalhos obsoletos foram removidos do baseline.
• Existe um componente autoritativo para cada header e testes contra duplicidade.
• Jornadas críticas são testadas em navegador após mudanças de gateway , CDN ou aplicação.

radio_button_unchecked Exercícios

• Explique por que CORS não impede que um cliente servidor-servidor chame uma API .
• Diferencie origem e site e relacione a diferença a CORS e SameSite.
• Descreva o fluxo completo de preflight para um PUT com Authorization e application/ json .
• Explique por que Access-Control-Allow- Origin : * não funciona com resposta credentialed.
• Proponha uma CSP para uma SPA que carrega scripts próprios e chama uma API específica.
• Compare nonce , hash e unsafe-inline.
• Explique o risco operacional de includeSubDomains em HSTS .
• Diferencie frame-src, frame-ancestors e X-Frame- Options .
• Compare no-store e no- cache com um exemplo de API bancária.
• Explique as diferenças entre CORS , CORP , COOP e COEP .
• Monte um plano de rollout em gateway para CSP e CORS sem indisponibilidade.
• Liste evidências necessárias para investigar um erro de CORS que ocorre apenas em produção.

radio_button_unchecked Glossário

radio_button_unchecked Referências técnicas

• WHATWG. Fetch Standard - CORS protocol, preflight e políticas de fetch.
• WHATWG. HTML Standard - origem, navegação e políticas de contexto.
• W3C . Content Security Policy Level 3.
• IETF . RFC 6797 - HTTP Strict Transport Security ( HSTS ).
• IETF . RFC 7034 - HTTP Header Field X-Frame- Options .
• IETF . RFC 9110 - HTTP Semantics.
• IETF . RFC 9111 - HTTP Caching .
• W3C . Referrer Policy.
• W3C . Permissions Policy.
• W3C . Clear Site Data.
• OWASP . HTTP Headers Cheat Sheet e Cross Origin Resource Sharing Cheat Sheet.

Nota de atualização

Cabeçalhos e comportamento de navegadores evoluem. Antes de adotar uma política corporativa, valide a especificação atual, o suporte dos navegadores-alvo e o comportamento da versão específica do gateway , ingress, CDN e framework utilizados.