O que o cabeçalho Permissions-Policy consegue realmente restringir

A versão curta

Permissions-Policy é um cabeçalho de resposta HTTP que permite a um site limitar o acesso a certos recursos do navegador: câmera, microfone, geolocalização, tela cheia, pagamento, sensores e uma longa lista de APIs menores.

Ele não é um escudo geral de privacidade. Não vai impedir todo rastreamento, bloquear cookies, impedir requisições de rede ou tornar JavaScript de terceiros seguro. O que ele consegue fazer bem é mais limitado e ainda assim valioso: reduzir as capacidades do navegador disponíveis para as suas próprias páginas e para frames incorporados.

Isso importa porque sites modernos são costurados a partir de snippets de analytics, incorporações de mídia, widgets de chat, gerenciadores de consentimento, scripts de publicidade, mapas, fluxos de pagamento e experimentos internos. A maioria desses componentes não precisa de acesso a APIs poderosas do dispositivo. Uma boa política torna isso explícito.

Se você já está revisando cabeçalhos em produção, combine esse trabalho com uma verificação direta da resposta real. Nosso guia sobre debugging redirects and HTTP headers in production aborda o hábito que importa aqui: inspecionar o que o navegador realmente recebe, não o que o seu arquivo de configuração diz que deveria acontecer.

O que Permissions-Policy controla

O cabeçalho controla o acesso a recursos nomeados do navegador. A lista exata muda ao longo do tempo porque as APIs do navegador mudam, mas diretivas comuns incluem:

• camera
• microphone
• geolocation
• fullscreen
• payment
• usb
• bluetooth
• accelerometer
• gyroscope
• magnetometer
• screen-wake-lock
• clipboard-read
• clipboard-write
• publickey-credentials-get
• interest-cohort em discussões mais antigas, agora em grande parte histórico

Uma diretiva pode permitir um recurso para ninguém, para a origem atual ou para origens selecionadas. Por exemplo:

Permissions-Policy: camera=(), microphone=(), geolocation=(self)

Isso significa que câmera e microfone são desativados para o documento e seus contextos de navegação aninhados, enquanto a geolocalização é permitida apenas para a mesma origem.

Um exemplo mais permissivo:

Permissions-Policy: geolocation=(self "https://maps.example"), fullscreen=(self "https://video.example")

Isso permite que a sua própria origem e um provedor de mapas nomeado usem geolocalização, e que a sua própria origem mais um provedor de vídeo solicitem tela cheia.

A política é avaliada pelo navegador. Se um recurso for negado, o JavaScript que usa essa API deve falhar ou se comportar como se ela estivesse indisponível. O modo exato de falha depende da API. Às vezes uma promise é rejeitada. Às vezes uma capacidade simplesmente não parece utilizável.

O que ele pode restringir nas suas próprias páginas

Em páginas próprias, Permissions-Policy é mais útil como uma proteção. Ele reduz o raio de impacto de código acidental ou inesperado.

Uma página de marketing, por exemplo, provavelmente não precisa das APIs de microfone, câmera, Bluetooth, USB, sensores de movimento ou pagamento. Você pode negar esses recursos globalmente:

Permissions-Policy: camera=(), microphone=(), bluetooth=(), usb=(), payment=(), accelerometer=(), gyroscope=(), magnetometer=()

Isso não torna todos os scripts da página confiáveis. Significa que, se um experimento de gerenciador de tags, uma dependência comprometida ou um widget colado tentar chamar uma API restrita, o navegador não deve conceder acesso.

Para equipes com muitos colaboradores, esse é um padrão útil. Ele desloca a conversa de uma confiança vaga para uma capacidade explícita. Se um recurso futuro realmente precisar da câmera, alguém terá de alterar a política e explicar o motivo.

Esse é o tipo certo de fricção.

O que ele pode restringir em iframes

O cabeçalho se torna especialmente útil em torno de conteúdo incorporado.

Os navegadores já tratam iframes como contextos de navegação separados, mas conteúdo incorporado de terceiros ainda pode solicitar recursos poderosos se isso for permitido pela política e pelos atributos do iframe. Permissions-Policy permite que a página pai defina um teto.

Por exemplo, se a sua página incorpora um player de vídeo, um widget de suporte e um mapa, você pode evitar dar a todos os frames acesso a todos os recursos. Você pode permitir tela cheia apenas para o frame de vídeo e geolocalização apenas para o frame do mapa.

Há duas camadas a entender:

1. O cabeçalho HTTP Permissions-Policy define a política para o documento.
2. O atributo allow do iframe pode delegar recursos específicos a um frame, mas apenas dentro do que a política pai permite.

Um iframe simples poderia se parecer com isto:

<iframe src="https://video.example/embed/123" allow="fullscreen"></iframe>

Se o seu cabeçalho nega tela cheia por completo, o atributo do iframe não pode substituir essa negação. Se o seu cabeçalho permite tela cheia para essa origem, o atributo do iframe pode delegá-la.

Essa hierarquia é um dos motivos pelos quais vale a pena usar o cabeçalho. Ele dá às equipes de plataforma ou segurança uma forma de definir limites para todo o site, mantendo a possibilidade de as equipes de produto habilitarem incorporações específicas quando necessário.

O que ele não pode restringir

É aqui que as equipes às vezes superestimam o cabeçalho.

Permissions-Policy não substitui uma Content Security Policy. Ele não decide quais scripts podem carregar. Não impede que um script envie dados pela rede. Não sanitiza HTML. Não previne XSS. Não bloqueia spam de formulários. Se abuso de formulários é o problema, comece pelos mecanismos descritos em por que seu formulário de contato é sua maior responsabilidade de spam, não por este cabeçalho.

Ele também não substitui a governança de cookies. Cookies, armazenamento local, consentimento, incorporações de terceiros e proteções de rastreamento do navegador são questões separadas. Se você está revisando controles de privacidade de forma ampla, o cenário de cookies merece sua própria análise; as mudanças práticas são abordadas em o que mudou para cookies em 2026 e o que fazer a respeito.

Mais importante: Permissions-Policy não torna JavaScript de terceiros privado. Se você carrega um script de terceiros na sua página própria, em geral ele é executado com os privilégios da sua página, sujeito a outras restrições do navegador e aos seus cabeçalhos de segurança. Negar acesso à câmera é bom. Isso não impede que esse script leia conteúdo do DOM, observe ações do usuário ou faça requisições de rede permitidas.

Para isso, você precisa de controles diferentes: seleção cuidadosa de fornecedores, CSP, iframes em sandbox, Subresource Integrity quando aplicável, minimização de dados e revisões tediosas, mas necessárias.

Uma política padrão sensata

Não há um cabeçalho universal que sirva para todos os sites, mas a maioria dos sites de conteúdo e marketing pode começar de forma restritiva.

Uma primeira abordagem razoável:

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=(), bluetooth=(), accelerometer=(), gyroscope=(), magnetometer=(), screen-wake-lock=()

Depois, adicione de volta apenas o que o site realmente usa.

Por exemplo:

• Uma loja que usa Payment Request API pode precisar de payment=(self).
• Um localizador de lojas pode precisar de geolocation=(self) ou de uma origem de mapas confiável.
• Um aplicativo de conferência pode precisar de camera=(self) e microphone=(self).
• Um site com muito vídeo pode precisar de fullscreen=(self "https://trusted-video.example").

O ponto importante não é copiar uma política enorme de um checklist e considerar o trabalho concluído. Comece pelo inventário de recursos. Quais páginas precisam de quais capacidades do navegador? Quais incorporações precisam de delegação? Quais recursos seriam surpreendentes se fossem solicitados?

Como implantar sem quebrar coisas

Lance isso como qualquer outro cabeçalho de produção: deliberadamente.

1. Faça um inventário do uso de recursos

Procure no seu codebase chamadas a APIs do navegador, como getUserMedia, geolocation, requestFullscreen, PaymentRequest, Web Bluetooth, WebUSB e APIs de wake lock.

Depois verifique incorporações de terceiros. A documentação de provedores de vídeo, mapas, pagamento e identidade muitas vezes menciona valores obrigatórios para allow em iframe.

2. Comece em um ambiente de baixo risco

Adicione um cabeçalho restritivo em staging e teste as jornadas principais. Preste atenção às mensagens do console do navegador. Os navegadores frequentemente informam quando um recurso é bloqueado pela permissions policy.

3. Use políticas específicas por página quando necessário

Não force uma política global única se o seu produto tem tipos de página muito diferentes. Um blog, checkout, página de mapa e sala de vídeo provavelmente precisam de capacidades diferentes.

A maioria dos servidores web, frameworks e plataformas de borda consegue definir cabeçalhos condicionalmente por caminho. Isso costuma ser mais limpo do que enfraquecer o site inteiro por causa de um recurso.

4. Verifique a resposta real

Cabeçalhos podem ser adicionados, sobrescritos, duplicados ou removidos por CDNs, reverse proxies, servidores de aplicação e middleware. Verifique a resposta final no DevTools do navegador ou com ferramentas de linha de comando.

Teste também os contextos incorporados. Uma página de nível superior aparentemente correta não garante que um iframe tenha recebido a delegação pretendida.

5. Documente exceções

Todo recurso permitido deve ter um responsável e um motivo. Isso soa burocrático até seis meses depois, quando ninguém lembra por que geolocation foi aberto para um domínio de fornecedor que não aparece mais na página.

Erros comuns de sintaxe

A sintaxe moderna do cabeçalho é compacta, mas é fácil errar em pequenos detalhes.

Use parênteses vazios para negar um recurso:

Permissions-Policy: microphone=()

Use self para a origem atual:

Permissions-Policy: geolocation=(self)

Use origens entre aspas para origens externas específicas:

Permissions-Policy: fullscreen=(self "https://video.example")

Evite depender de exemplos antigos de Feature-Policy, a menos que você esteja intencionalmente dando suporte a comportamento legado. O cabeçalho mais antigo usava uma sintaxe diferente e não é aquilo em torno do qual você deve projetar hoje.

Lembre também que o suporte do navegador varia por diretiva. Um navegador pode dar suporte ao cabeçalho, mas não a uma diretiva de recurso específica. Isso é normal. Trate o cabeçalho como uma medida de defesa em profundidade, não como seu único controle de privacidade ou segurança.

<!-- tool-cta:start -->

💡 Experimente isto: Verifique se a sua Permissions-Policy está sendo entregue conforme o esperado com Get Headers, que mostra os cabeçalhos de resposta brutos que o seu servidor está enviando.

<!-- tool-cta:end -->

O valor prático para a privacidade

O valor de privacidade de Permissions-Policy não é tornar um site anônimo ou livre de rastreadores. Ele não faz isso.

Seu valor é estreitar o acesso a capacidades sensíveis do navegador. Localização, câmera, microfone, sensores do dispositivo, APIs de hardware local e fluxos de pagamento são poderosos. A maioria das páginas não precisa deles. Muitos componentes incorporados nunca deveriam poder solicitá-los.

Isso é uma melhoria real. Reduz prompts acidentais, limita a exposição desnecessária de capacidades e dá à sua equipe um artefato concreto para revisar quando novas funcionalidades são lançadas.

A melhor versão desse cabeçalho é tediosa: restritiva por padrão, flexibilizada apenas quando um recurso voltado ao usuário exige isso, e testada como parte do processo normal de release.