Privacidade por padrão na camada HTTP: cabeçalhos que reduzem sua superfície de rastreamento
Dois cabeçalhos de resposta — Permissions-Policy e Referrer-Policy — definem o quanto suas páginas podem vazar para ad-tech e terceiros. Configure-os uma vez e a superfície de vigilância fecha por padrão.
A maior parte do trabalho de privacidade acontece em JavaScript — lógica de consentimento, controle de tags, rotação de identificadores. Mas o navegador entrega a você dois cabeçalhos de resposta HTTP que fecham a superfície de vigilância antes que um único script seja executado, e a maioria dos sites não envia nenhum dos dois. Permissions-Policy e Referrer-Policy são privacy-by-design em sua forma mais literal: configuração, não código.
Eles importam mais agora do que há um ano. Com a desativação, em outubro de 2025, da maioria das APIs do Privacy Sandbox pelo Google, as diretivas residuais de ad-tech que essas APIs introduziram ainda estão presentes no Chrome — e um site agora pode desligá-las afirmativamente em vez de esperar que sejam removidas.
Permissions-Policy: negue os recursos que você nunca usa
Permissions-Policy controla quais recursos do navegador um documento e seus frames incorporados podem usar. É o mesmo mecanismo que regula camera, geolocation e microphone — mas ele também regula as APIs adjacentes ao rastreamento que a ad-tech utiliza.
A allowlist padrão para a maioria delas é permissiva. browsing-topics, a diretiva que controla a Topics API, tem como padrão * — toda origem na página, incluindo frames de terceiros, pode chamá-la a menos que você diga o contrário. Desabilitá-la é uma linha:
Permissions-Policy: browsing-topics=()
Uma allowlist vazia () nega o recurso a todos, inclusive à sua própria origem. Você pode bloquear todo o conjunto de APIs de interesse publicitário e de medição em um único cabeçalho:
Permissions-Policy: browsing-topics=(), join-ad-interest-group=(), run-ad-auction=(), attribution-reporting=(), shared-storage=(), private-aggregation=()
Qualquer script — próprio ou incorporado — que chame document.browsingTopics() ou envie um cabeçalho de requisição Sec-Browsing-Topics agora falha com um NotAllowedError. Você não está confiando que terceiros se comportem bem; está removendo a capacidade no nível da plataforma.
Essas diretivas estão depreciadas junto com o Privacy Sandbox, então algumas desaparecerão do Chrome ao longo das próximas versões. Defini-las como () é inofensivo depois que elas se forem e protetor até lá.
Referrer-Policy: pare de vazar suas URLs
Toda requisição de navegação e de subrecurso pode carregar um cabeçalho Referer nomeando a página de onde o usuário veio. URLs completas vazam query strings, identificadores codificados no path, termos de busca e a estrutura interna das páginas para todo terceiro que você carrega — fornecedores de analytics, fontes, CDNs, pixels de anúncios.
Os navegadores modernos têm como padrão strict-origin-when-cross-origin, que já é um piso razoável:
Referrer-Policy: strict-origin-when-cross-origin
Sob essa política, o navegador envia a URL completa apenas em requisições same-origin, envia apenas a origem em requisições cross-origin seguras e não envia nada ao fazer downgrade de HTTPS para HTTP. Assim, https://app.example/orders/4815?token=abc chega a um terceiro como https://app.example/ — origem, sem path, sem query.
Esse padrão tornou-se o padrão da especificação em novembro de 2020, mas você ainda deve definir o cabeçalho explicitamente. Um upstream mal configurado, um padrão antigo de framework ou uma tag <meta> de referrer podem sobrescrevê-lo, e um cabeçalho explícito é auditável. Se você não embute nada sensível nas URLs e quer ser estrito, strict-origin também remove o path em requisições same-origin.
Por que isso combina com analytics sem cookies
Esses cabeçalhos e um tracker focado em privacidade resolvem o mesmo problema por duas direções. O tracker controla o que o seu analytics coleta; os cabeçalhos controlam o que todos os outros na página podem alcançar.
Um tracker sem cookies que deriva identidade de um hash diário unidirecional — SHA-256(IP | UA | SALT_SECRET | YYYY-MM-DD) — nunca precisa da URL completa do referrer nem da Topics API para fazer seu trabalho. Ele lê document.referrer apenas para atribuir a origem de uma visita, e a origem basta para isso. Portanto, apertar o Referrer-Policy não custa nada ao seu analytics enquanto fecha um vazamento para todas as outras requisições da página.
O mesmo alinhamento vale para a performance. Cabeçalhos custam zero bytes de JavaScript e zero tempo de main-thread; são avaliados pelo navegador antes do parsing. Você obtém uma melhoria de privacidade mensurável sem impacto no Largest Contentful Paint ou no Interaction to Next Paint — o trade-off oposto ao de uma plataforma de gestão de consentimento, que adiciona peso de script para gerenciar permissões que um cabeçalho poderia ter negado de imediato.
Envie-os na edge
Defina ambos os cabeçalhos na sua edge ou no servidor de origem para que toda resposta os carregue, incluindo assets estáticos e HTML:
Permissions-Policy: browsing-topics=(), join-ad-interest-group=(), run-ad-auction=(), attribution-reporting=(), shared-storage=()
Referrer-Policy: strict-origin-when-cross-origin
Na Cloudflare, adicione-os em uma Transform Rule ou num Worker; no Next.js, na configuração headers(); em qualquer reverse proxy, uma única linha add_header. Não há risco de rollout: você está negando capacidades que não usa e cortando dados que nunca quis enviar.
Privacy by design costuma ser apresentado como uma decisão de arquitetura. Na camada HTTP são duas linhas de configuração, e elas vêm abertas por padrão até que você as feche.
Comments
Loading comments…