Como navegadores, aplicações e gateways usam políticas HTTP para controlar origem, conteúdo, transporte, isolamento, privacidade e cache
Edição aprofundada - material de estudo e consulta profissional
Por João Ricardo Dutra••Material integral
Apresentação do capítulo
O capítulo anterior apresentou o Security Top 10 e mostrou que a proteção de uma depende de controles distribuídos entre cliente, navegador, ,, identidade, rede e operação. Este capítulo aprofunda uma parte específica dessa defesa: os cabeçalhos que instruem navegadores e intermediários sobre como tratar origens, conteúdo executável, transporte seguro, isolamento de contexto, privacidade e armazenamento em .
, e são frequentemente agrupados como cabeçalhos de segurança, mas resolvem problemas muito diferentes. define quando um navegador pode expor a uma aplicação web uma resposta obtida de outra origem. limita fontes de scripts, estilos, frames, conexões e outros recursos, reduzindo impacto de injeção de conteúdo. instrui o navegador a utilizar 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 .
Outros cabeçalhos complementam esse modelo. -Policy limita a informação enviada no Referer; Permissions-Policy controla recursos do navegador; X-Content-Type- reduz interpretações inesperadas de ; frame-ancestors e X-Frame- tratam incorporação em frames; , e participam de isolamento entre origens; -Control protege respostas sensíveis contra armazenamento indevido; atributos de reduzem exposição a scripts, transporte inseguro e requisições cross-site.
O objetivo é construir um modelo mental preciso para implementação e . O leitor deverá saber distinguir uma falha real da de uma decisão do navegador, reconhecer erros de configuração em 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 sem entender seus efeitos.
Objetivos de aprendizagem
Explicar origem, site, e a fronteira de segurança do navegador.
Descrever requisições simples, , credenciais e de .
Configurar corretamente Access-Control-Allow- e cabeçalhos relacionados.
Diferenciar de autenticação, , firewall e segurança servidor-servidor.
Projetar Content Security Policy com diretivas, , e implantação em report-only.
Compreender , includeSubDomains, preload e riscos de rollout incorreto.
Aplicar X-Content-Type-, frame-ancestors, -Policy e Permissions-Policy.
Relacionar , e ao isolamento cross-.
Definir -Control e atributos de para respostas e sessões sensíveis.
Implementar, testar e observar cabeçalhos em aplicações, e CDNs.
Estrutura do capítulo
26.1 Modelo de segurança do navegador e cabeçalhos declarativos
26.2 Origem, site e
26.3 : propósito e fluxo de decisão
26.4 Requisições simples e
26.5 Cabeçalhos de requisição e resposta
26.6 Credenciais, , Authorization e curingas
26.7 em e erros frequentes
26.8 Content Security Policy: modelo e diretivas
26.9 ,, strict-dynamic e scripts inline
26.10 Reporting e implantação gradual de
26.11 Strict Transport Security
26.12 Clickjacking, e proteção de frames
26.13 -Policy e Permissions-Policy
26.14 , e
26.15 -Control, Clear-Site-Data e
26.16 Cabeçalhos obsoletos, e laboratórios
Resumo, checklist, exercícios, glossário e referências
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 estabelece uma fronteira básica; permite exceções controladas; restringe o conteúdo que pode ser carregado ou executado; 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 . Um cliente escrito em Java, Python ou curl pode ignorar completamente e , porque esses mecanismos não foram projetados como controle de acesso universal. A ainda precisa validar credenciais, autorização, esquema e regras de negócio em todas as requisições.
O é um ponto eficiente para padronizar cabeçalhos, mas não conhece automaticamente todas as necessidades da aplicação. Uma adequada depende dos scripts, frames e conexões realmente usados por cada front-end. depende das origens consumidoras e da política de credenciais. -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
não protege a 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.
26.2 Origem, site e
Uma origem é definida conceitualmente pelo trio esquema, host e porta. ://app.empresa.com e ://.empresa.com possuem hosts diferentes e, portanto, origens diferentes. ://app.empresa.com e ://app.empresa.com diferem no esquema. ://app.empresa.com:443 e ://app.empresa.com:8443 diferem na porta. O caminho da não participa da origem.
O conceito de site é relacionado, mas não idêntico. Mecanismos como SameSite em trabalham com a noção de site, enquanto usa origem. Dois subdomínios podem ser same-site e ainda cross-. Essa diferença explica cenários em que um é enviado, mas o JavaScript não consegue ler a resposta porque a política não autorizou a origem.
A limita leitura e interação entre contextos de origens diferentes. Ela não impede todo envio de dados cross-: 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. é o protocolo que permite ao servidor declarar exceções controladas para determinadas operações.
Tabela 1 - A origem é determinada por esquema, host e porta, não pelo caminho.
A
B
Mesma origem?
Motivo
://app.exemplo.com
://app.exemplo.com/perfil
Sim
Mesmo esquema, host e porta.
://app.exemplo.com
://.exemplo.com
Não
Host diferente.
://app.exemplo.com
://app.exemplo.com
Não
Esquema diferente.
://app.exemplo.com
://app.exemplo.com:8443
Não
Porta diferente.
26.3 : propósito e fluxo de decisão
Cross- Resource Sharing é um protocolo integrado ao modelo de fetch do navegador. Quando um script tenta acessar uma de outra origem, o navegador acrescenta o cabeçalho . A resposta precisa conter cabeçalhos que indiquem se aquela origem, método, conjunto de 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 registra sucesso, o devolve 200, mas o console do navegador mostra erro de . 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 como proteção contra ou ações indevidas.
O navegador pode enviar diretamente a requisição quando ela satisfaz os critérios de uma requisição simples. Em outras situações, realiza com . O 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 específico do navegador por um período limitado.
com : o navegador negocia antes de enviar a operação real
Figura 1 - O negocia permissão; a decisão final de exposição da resposta pertence ao navegador.
26.4 Requisições simples e
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 por manter compatibilidade com padrões históricos da Web. Métodos como , e podem participar quando os e o Content-Type permanecem dentro do conjunto permitido pelo protocolo. Um application/, por exemplo, normalmente provoca .
O utiliza e inclui Access-Control--Method. Se o script pretende enviar não safelisted, o navegador também inclui Access-Control--. O servidor responde com os métodos e autorizados. A requisição real só é liberada quando a resposta satisfaz as verificações do navegador.
não é autenticação. Algumas arquiteturas cometem o erro de exigir no ou encaminhar o a que não conhecem . Como o é uma consulta de política realizada antes da requisição real, 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 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
26.5 Cabeçalhos de requisição e resposta
identifica a origem do contexto que iniciou a requisição. Access-Control-Allow- 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 e devolver exatamente a origem aprovada, nunca refletir qualquer valor sem verificação.
Access-Control-Allow-Methods e Access-Control-Allow- participam principalmente do . Access-Control-Expose- permite que JavaScript leia cabeçalhos de resposta que não pertencem ao conjunto exposto por padrão. Access-Control-Max-Age influencia o do , sujeito a limites do navegador. Access-Control-Allow-Credentials permite respostas credentialed quando combinado a uma origem explícita.
: é importante quando a resposta pode mudar conforme a origem solicitante e passa por compartilhados. Sem essa indicação, um pode reutilizar para outra origem uma resposta que contém Access-Control-Allow- específico. Em plataformas com ou , a chave de e a política devem ser projetadas em conjunto.
Tabela 2 - O conjunto forma um protocolo de negociação, não um isolado.
Cabeçalho
Direção
Função
Identifica a origem do contexto solicitante.
Access-Control-Allow-
Autoriza uma origem ou, em casos limitados, o curinga.
Access-Control-Allow-Methods
de
Declara métodos permitidos.
Access-Control-Allow-
de
Declara permitidos na requisição real.
Access-Control-Expose-
Expõe adicionais ao JavaScript.
Access-Control-Allow-Credentials
Permite resposta com credenciais em contexto .
Access-Control-Max-Age
de
Controla duração de do .
Uma requisição credentialed pode envolver , certificados de cliente ou credenciais controladas pelo agente. No fetch, o modo credentials determina se credenciais são enviadas e se respostas com Set- são consideradas. Para que o JavaScript receba uma resposta credentialed cross-, o servidor precisa retornar Access-Control-Allow-Credentials: true e uma origem explícita.
O curinga em Access-Control-Allow- 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- copiando o recebido sem validação. Reflection irrestrita transforma a política em autorização universal disfarçada.
e atributos SameSite de se relacionam, mas não são equivalentes. O pode não ser enviado por causa de SameSite, Secure ou regras de terceiros antes mesmo de ser avaliado. Em outro cenário, o é enviado e o servidor processa a requisição, mas o navegador bloqueia a leitura da resposta. O diagnóstico precisa observar envio de ,, resposta real e console do navegador separadamente.
Regra prática
Para com sessão por , trate , SameSite, e política de origem como controles complementares. Para com , valide e autorização normalmente; o fato de o navegador exigir não torna o protegido contra clientes fora do navegador.
26.7 em e erros frequentes
podem centralizar , responder sem alcançar o e aplicar allowlists por ambiente, produto ou . Essa centralização reduz duplicidade, mas exige definir ownership. Se e adicionarem cabeçalhos diferentes, a resposta pode conter valores duplicados ou contraditórios. Alguns navegadores rejeitam respostas com múltiplos Access-Control-Allow-.
A política deve ser aplicada também a respostas de erro. Uma que retorna 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 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 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.
Tabela 3 - Erros de são frequentemente erros de arquitetura e não apenas de sintaxe.
Falha
Sintoma
Correção
exige autenticação
retorna 401 antes da chamada real.
Tratar conforme política e não como operação de negócio.
só em respostas 2xx
vê erro genérico.
Aplicar também no fluxo de erro.
Origem refletida sem validação
Qualquer site recebe permissão.
Comparar com confiável.
e duplicam
Browser rejeita resposta ambígua.
Definir um único ponto de emissão.
Sem : em
Origem recebe política de outra origem.
Ajustar e chave de .
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 Content-Security-Policy ou, em casos específicos, por elemento meta. O possui maior alcance e é a forma preferida para políticas completas. A 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, 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- restringe a 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 : 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, deve ser construída a partir de inventário, testes e observação, não copiada de outra aplicação.
: cada recurso é comparado com a política antes de ser carregado ou executado
Figura 2 - A política compara cada tipo de recurso com a diretiva correspondente.
Scripts inline são uma fonte importante de risco porque uma injeção de 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 criptograficamente imprevisível pode ser gerado por resposta e incluído tanto na quanto no elemento script autorizado.
permitem autorizar conteúdo inline cujo texto é conhecido e estável. O navegador calcula o do bloco e compara com o valor da política. Pequenas mudanças no conteúdo exigem novo . 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 ou 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.
Tabela 4 - e permitem reduzir dependência de unsafe-inline.
Mecanismo
Quando usar
Cuidado principal
Arquivo externo em self
Aplicação controla os scripts no próprio host.
Comprometimento do host ainda compromete scripts.
Script inline dinâmico autorizado por resposta.
Gerar valor imprevisível e único por resposta.
Bloco inline estável e conhecido.
Qualquer alteração exige atualizar o .
strict-dynamic
Bootstrap confiável carrega dependências.
Validar compatibilidade e cadeia de confiança.
26.10 Reporting e implantação gradual de
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 e informações sensíveis. O 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 devem participar do e ser testadas com jornadas críticas, porque um incorreto pode indisponibilizar todo o front-end mesmo que a permaneça saudável.
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, de upload e serviços de terceiros ampliam a superfície. Prefira , e fontes específicas em vez de allowlists excessivamente amplas.
26.11 Strict Transport Security
Strict Transport Security permite que um host declare que deve ser acessado apenas por . O navegador armazena a política recebida em uma conexão válida e, durante max-age, transforma tentativas de em antes de enviar a requisição pela rede. Isso reduz exposição a ataques de e remoção de após o host ter sido conhecido como seguro.
O 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 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.
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 inseguro. O primeiro acesso continua sendo uma consideração quando o host ainda não está no estado ; preload pode reduzir essa janela, mas aumenta o compromisso operacional de longo prazo.
altera decisões futuras do navegador para um host conhecido
Figura 3 - Depois de aprendido, faz o navegador preferir e rejeitar .
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 frame-ancestors é o mecanismo moderno para controlar quais origens podem enquadrar a página. X-Frame- oferece DENY e SAMEORIGIN, permanecendo relevante em compatibilidade, mas não possui a flexibilidade de uma lista de origens.
X-Content-Type-: nosniff instrui o navegador a respeitar tipos 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 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 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.
Tabela 5 - Proteção de frame e tipo de conteúdo são responsabilidades diferentes.
Cabeçalho ou diretiva
Exemplo
Uso
frame-ancestors
frame-ancestors 'none'
Bloqueia incorporação por qualquer origem.
X-Frame-
DENY ou SAMEORIGIN
Compatibilidade para proteção contra framing.
X-Content-Type-
nosniff
Reduz em recursos executáveis.
Content-Type
application/
Declara o tipo real do .
26.13 -Policy e Permissions-Policy
O Referer pode revelar de origem da navegação ou carregamento. Quando contêm identificadores, parâmetros internos ou estrutura sensível, esse compartilhamento cria risco de privacidade. -Policy controla quanto da informação é enviado. Políticas como no-, same- e strict--when-cross- oferecem níveis diferentes de restrição.
A escolha deve equilibrar privacidade, antifraude, analytics e . Enviar a completa para terceiros raramente é necessário. Uma política orientada a origem reduz exposição de path e query em navegações cross-, mantendo informação suficiente para alguns controles. Dados sensíveis não devem estar em , mesmo com política restritiva, porque podem aparecer em 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
Cross--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--Embedder-Policy exige que recursos cross- incorporados sejam explicitamente compartilháveis por ou , conforme o modo adotado.
Cross--Resource-Policy permite que um recurso declare se pode ser carregado por documentos de mesma origem, mesmo site ou qualquer contexto permitido. Em conjunto, e podem produzir cross- isolation, necessário para algumas poderosas do navegador. Essa configuração deve ser testada porque recursos de terceiros sem adequados podem deixar de carregar.
Esses cabeçalhos não são substitutos de ou . controla acesso programático a respostas; protege o recurso contra determinados carregamentos cross-; separa contextos de navegação; 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.
Tabela 6 - Políticas cross- se complementam, mas protegem fronteiras distintas.
Mecanismo
Pergunta que responde
Exemplo
Com quais janelas este documento compartilha grupo de contexto?
Cross--Opener-Policy: same-
Quais recursos cross- podem ser incorporados?
Cross--Embedder-Policy: require-
Quem pode carregar este recurso?
Cross--Resource-Policy: same-site
Qual origem pode acessar a resposta via navegador?
Access-Control-Allow-:://app...
26.15 -Control, Clear-Site-Data e
Respostas sensíveis podem permanecer em do navegador, ou . -Control define diretivas para armazenamento e reutilização. no-store é apropriado quando nenhuma retenção é aceitável; private permite privado, mas não compartilhado; no- 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 .
Autenticação não torna uma resposta automaticamente não cacheável. e CDNs precisam considerar Authorization, , e regras explícitas. Uma resposta personalizada armazenada em compartilhado pode vazar dados entre usuários. Em contrapartida, desabilitar todo 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 , 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- 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. de sessão e autenticação devem usar escopo mínimo e não carregar informação sensível em texto claro.
Tabela 7 - e exigem precisão semântica; nomes intuitivos podem enganar.
Diretiva ou atributo
Significado operacional
Cuidado
no-store
Não armazenar a resposta.
Útil para dados altamente sensíveis.
private
Permitir privado, não compartilhado.
Ainda pode permanecer no dispositivo do usuário.
no-
Armazenar, mas revalidar antes do uso.
Não significa ausência de armazenamento.
Secure
Enviar apenas por canal seguro.
Depende de corretamente implantado.
HttpOnly
Impedir acesso por JavaScript.
Não impede envio automático do .
SameSite
Limitar envio em contexto cross-site.
Escolha depende do fluxo de login e integração.
26.16 Cabeçalhos obsoletos e disclosure de tecnologia
Nem todo historicamente recomendado deve continuar sendo implantado. X--Protection se relaciona a filtros antigos de navegador e não substitui . Public Key Pinning for 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- continua útil para compatibilidade, mas frame-ancestors oferece controle moderno. Pragma é legado para /1.0 e não substitui uma política -Control clara. A gestão de 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.
Tabela 8 - Segurança exige remover controles obsoletos, não apenas adicionar novos .
Item
Situação recomendada
Alternativa ou observação
X--Protection
Não tratar como controle moderno principal.
Usar e corrigir injeção/.
Public-Key-Pins
Não implantar.
Gerenciar certificados, CT e automação de renovação.
Expect-CT
Não adotar como requisito novo.
Usar ecossistema atual de Certificate Transparency.
Feature-Policy
Migrar.
Usar Permissions-Policy.
X-Powered-By
Remover quando possível.
Não substitui hardening ou patching.
26.17 Implementação em aplicações, e CDNs
A aplicação conhece melhor o conteúdo e deve participar de ,, e políticas específicas da jornada. O pode aplicar defaults, ,, remoção de disclosure, observabilidade e guardrails. A pode acrescentar ou normalizar , 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: pública, privada, portal estático, aplicação autenticada, console administrativo e download de arquivo. Cada categoria recebe baseline e exceções aprovadas. Aplicar a mesma a uma e a uma não faz sentido; da mesma forma, pode ser irrelevante para integração exclusivamente servidor-servidor.
Configuração como código e testes automatizados reduzem drift. O pode verificar presença, valor, duplicidade e consistência dos . Testes end-to-end devem validar comportamento real no navegador, porque , redirects e respostas de erro podem alterar a política. Em ambientes distribuídos, registre qual componente adicionou ou removeu cada .
Ordem de responsabilidade
Evite múltiplos componentes escrevendo o mesmo cabeçalho sem regra de precedência. Defina claramente se aplicação, , ingress, ou servidor web é a fonte autoritativa. Duplicidade pode ser tão perigosa quanto ausência.
26.18 e laboratórios
O diagnóstico começa no navegador: Network mostra , redirects, e ; Console apresenta violações de e ; ferramentas de Application mostram 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 , verifique , método, solicitados, resposta , resposta real, credenciais, e duplicidade. Para , identifique a diretiva violada, a bloqueada, ou e política efetiva. Para , confirme que o foi recebido por , o estado do host e a cobertura de subdomínios. Para , observe Age, -Control, 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 , ativar credenciais, testar , implantar em report-only, introduzir um script inline bloqueado, habilitar com max-age curto e validar em respostas de erro do .
Tabela 9 - O diagnóstico deve identificar qual agente aplicou a política.
Sintoma
Camada provável
Evidência a coletar
error, registrou 200
Política do navegador ou resposta .
, ACAO, credenciais, console e resposta real.
Script não executa após
.
Diretiva violada, / e Report-Only.
Subdomínio parou após
Cobertura includeSubDomains.
Estado e do subdomínio.
Dados de outro usuário aparecem
compartilhado.
-Control, , chave e de identidade.
Iframe legítimo foi bloqueado
frame-ancestors/XFO.
Política efetiva e origem do embedder.
Resumo do capítulo
, e são mecanismos distintos. controla acesso cross- mediado pelo navegador; restringe carregamento e execução de conteúdo; estabelece uso obrigatório de após a política ser aprendida. Nenhum deles substitui segurança de , autenticação ou autorização.
Cabeçalhos complementares reduzem outras classes de risco: frame-ancestors e X-Frame- tratam clickjacking; X-Content-Type- reduz ; -Policy melhora privacidade; Permissions-Policy limita capacidades; , e participam do isolamento; -Control e atributos de 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 , Quotas e , mecanismos que controlam consumo, protegem capacidade e aplicam contratos operacionais em .
Checklist de implementação
possui explícita e não reflete arbitrariamente.
é tratado corretamente e não depende de autenticação da operação real.
aparecem também nas respostas de erro relevantes.
Respostas variáveis por origem usam e chave de coerente.
foi implantada com inventário, report-only e plano de remoção de unsafe-inline/unsafe-eval.
Scripts inline autorizados usam ou corretamente.
foi ativado gradualmente e includeSubDomains foi precedido de inventário.
frame-ancestors, nosniff, -Policy e Permissions-Policy possuem valores adequados ao ativo.
, e foram testados com recursos de terceiros.
-Control protege respostas personalizadas e sensíveis sem bloquear legítimo indiscriminadamente.
de sessão usam Secure, HttpOnly, SameSite e escopo mínimo.
Cabeçalhos obsoletos foram removidos do baseline.
Existe um componente autoritativo para cada e testes contra duplicidade.
Jornadas críticas são testadas em navegador após mudanças de , ou aplicação.
Exercícios
Explique por que não impede que um cliente servidor-servidor chame uma .
Diferencie origem e site e relacione a diferença a e SameSite.
Descreva o fluxo completo de para um com Authorization e application/.
Explique por que Access-Control-Allow-: * não funciona com resposta credentialed.
Proponha uma para uma que carrega scripts próprios e chama uma específica.
Compare , e unsafe-inline.
Explique o risco operacional de includeSubDomains em .
Diferencie frame-src, frame-ancestors e X-Frame-.
Compare no-store e no- com um exemplo de bancária.
Explique as diferenças entre ,, e .
Monte um plano de rollout em para e sem indisponibilidade.
Liste evidências necessárias para investigar um erro de que ocorre apenas em produção.
Glossário
Tabela 10 - Vocabulário essencial do capítulo.
Termo
Definição
Conjunto explícito de origens ou fontes autorizadas.
Protocolo para compartilhamento controlado de recursos entre origens no navegador.
Política que restringe recursos carregados e executados por uma página.
Política de requisitos para incorporação cross-.
Política de isolamento entre contextos de navegação.
Política declarada pelo recurso sobre carregamento cross-.
Requisição que utiliza credenciais segundo o modo do cliente.
Política que obriga uso de por determinado período.
Inferência do tipo de conteúdo pelo navegador em desacordo com o tipo declarado.
Valor imprevisível usado para autorizar conteúdo específico em .
Combinação de esquema, host e porta.
Consulta realizada antes de determinadas requisições .
Informação sobre o contexto que originou uma navegação ou carregamento.
Conjunto de restrições que separa contextos de origens diferentes.
que indica dimensões da requisição usadas para selecionar representação em .
Referências técnicas
WHATWG. Fetch Standard - protocol, e políticas de fetch.
WHATWG. Standard - origem, navegação e políticas de contexto.
. Content Security Policy Level 3.
. 6797 - Strict Transport Security ().
. 7034 - Field X-Frame-.
. 9110 - Semantics.
. 9111 - .
. Policy.
. Permissions Policy.
. Clear Site Data.
. Cheat Sheet e Cross 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 , ingress, e utilizados.
