Che cosa può davvero bloccare l'header Permissions-Policy

La versione breve

Permissions-Policy è un header di risposta HTTP che consente a un sito di limitare l'accesso a determinate funzionalità del browser: fotocamera, microfono, geolocalizzazione, fullscreen, pagamento, sensori e un lungo elenco di API minori.

Non è uno scudo generale per la privacy. Non fermerà tutto il tracciamento, non bloccherà i cookie, non impedirà le richieste di rete e non renderà sicuro il JavaScript di terze parti. Ciò che può fare bene è più limitato, ma comunque prezioso: ridurre le capacità del browser disponibili per le tue pagine e per i frame incorporati.

Questo conta perché i siti web moderni sono assemblati con snippet di analytics, embed multimediali, widget di chat, gestori del consenso, script pubblicitari, mappe, flussi di pagamento ed esperimenti interni. La maggior parte di questi componenti non ha bisogno di accedere ad API potenti del dispositivo. Una buona policy lo rende esplicito.

Se stai già revisionando gli header in produzione, abbina questo lavoro a un controllo diretto della risposta effettiva. La nostra guida al debugging di redirect e header HTTP in produzione copre l'abitudine che qui conta: ispezionare ciò che il browser riceve davvero, non ciò che il file di configurazione dice che dovrebbe accadere.

Che cosa controlla Permissions-Policy

L'header controlla l'accesso a funzionalità del browser nominate. L'elenco esatto cambia nel tempo perché le API del browser cambiano, ma le direttive comuni includono:

• camera
• microphone
• geolocation
• fullscreen
• payment
• usb
• bluetooth
• accelerometer
• gyroscope
• magnetometer
• screen-wake-lock
• clipboard-read
• clipboard-write
• publickey-credentials-get
• interest-cohort nelle discussioni più vecchie, ora per lo più storico

Una direttiva può consentire una funzionalità a nessuno, all'origine corrente o a origini selezionate. Per esempio:

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

Questo significa che fotocamera e microfono sono disabilitati per il documento e per i suoi contesti di navigazione annidati, mentre la geolocalizzazione è consentita solo per la stessa origine.

Un esempio più permissivo:

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

Questo consente alla tua origine e a un provider di mappe nominato di usare la geolocalizzazione, e alla tua origine più un provider video di richiedere il fullscreen.

La policy viene valutata dal browser. Se una funzionalità non è consentita, il JavaScript che usa quell'API dovrebbe fallire o comportarsi come se non fosse disponibile. La modalità esatta di errore dipende dall'API. A volte una promise viene rifiutata. A volte una capacità semplicemente non appare utilizzabile.

Che cosa può bloccare sulle tue pagine

Sulle pagine first-party, Permissions-Policy è soprattutto utile come guardrail. Riduce il raggio d'azione di codice accidentale o inatteso.

Una pagina marketing, per esempio, probabilmente non ha bisogno di microfono, fotocamera, Bluetooth, USB, sensori di movimento o API di pagamento. Puoi negare queste funzionalità a livello globale:

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

Questo non rende affidabile ogni script sulla pagina. Significa però che se un esperimento del tag manager, una dipendenza compromessa o un widget incollato prova a chiamare un'API limitata, il browser non dovrebbe concedergli l'accesso.

Per i team con molti contributori, è un'impostazione predefinita utile. Sposta la conversazione dalla fiducia vaga alla capacità esplicita. Se una funzionalità futura ha davvero bisogno della fotocamera, qualcuno deve cambiare la policy e spiegare perché.

È il tipo giusto di attrito.

Che cosa può bloccare negli iframe

L'header diventa particolarmente utile per i contenuti incorporati.

I browser trattano già gli iframe come contesti di navigazione separati, ma i contenuti incorporati di terze parti possono comunque richiedere funzionalità potenti se consentite dalla policy e dagli attributi dell'iframe. Permissions-Policy consente alla pagina padre di impostare un limite massimo.

Per esempio, se la tua pagina incorpora un player video, un widget di supporto e una mappa, puoi evitare di dare a ogni frame accesso a ogni funzionalità. Potresti consentire il fullscreen solo per il frame video e la geolocalizzazione solo per il frame della mappa.

Ci sono due livelli da capire:

1. L'header HTTP Permissions-Policy imposta la policy per il documento.
2. L'attributo allow dell'iframe può delegare funzionalità specifiche a un frame, ma solo entro ciò che la policy padre consente.

Un semplice iframe potrebbe apparire così:

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

Se il tuo header nega completamente il fullscreen, l'attributo iframe non può annullare quel diniego. Se il tuo header consente il fullscreen per quell'origine, l'attributo iframe può delegarlo.

Questa gerarchia è uno dei motivi per cui vale la pena usare l'header. Offre ai team di piattaforma o sicurezza un modo per impostare confini a livello di sito, permettendo comunque ai team di prodotto di abilitare embed specifici dove necessario.

Che cosa non può bloccare

È qui che i team a volte sopravvalutano l'header.

Permissions-Policy non sostituisce una content security policy. Non decide quali script possono essere caricati. Non impedisce a uno script di inviare dati sulla rete. Non sanifica l'HTML. Non previene l'XSS. Non blocca lo spam nei form. Se il problema è l'abuso dei form, parti dai meccanismi descritti in perché il tuo modulo di contatto è la tua più grande responsabilità per lo spam, non da questo header.

Inoltre non sostituisce la governance dei cookie. Cookie, local storage, consenso, embed di terze parti e protezioni anti-tracciamento del browser sono questioni separate. Se stai rivedendo i controlli privacy in modo ampio, il panorama dei cookie merita un passaggio dedicato; le modifiche pratiche sono trattate in che cosa è cambiato per i cookie nel 2026 e che cosa fare al riguardo.

Soprattutto, Permissions-Policy non rende privato il JavaScript di terze parti. Se carichi uno script di terze parti nella tua pagina first-party, in genere viene eseguito con i privilegi della tua pagina, soggetto ad altri vincoli del browser e ai tuoi header di sicurezza. Negare l'accesso alla fotocamera è positivo. Non impedisce a quello script di leggere il contenuto del DOM, osservare le azioni dell'utente o effettuare richieste di rete consentite.

Per questo servono controlli diversi: selezione attenta dei vendor, CSP, iframe sandboxed, Subresource Integrity dove applicabile, minimizzazione dei dati e revisioni noiose ma necessarie.

Una policy predefinita sensata

Non esiste un header universale adatto a ogni sito, ma la maggior parte dei siti di contenuto e marketing può iniziare in modo restrittivo.

Un primo passaggio ragionevole:

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

Poi riaggiungi solo ciò che il sito usa davvero.

Per esempio:

• Uno store che usa Payment Request API potrebbe avere bisogno di payment=(self).
• Un localizzatore di punti vendita potrebbe avere bisogno di geolocation=(self) o di un'origine di mappe fidata.
• Un'app di conferenza potrebbe avere bisogno di camera=(self) e microphone=(self).
• Un sito ricco di video potrebbe avere bisogno di fullscreen=(self "https://trusted-video.example").

La parte importante non è copiare una policy enorme da una checklist e considerare il lavoro finito. Parti dall'inventario delle funzionalità. Quali pagine hanno bisogno di quali capacità del browser? Quali embed hanno bisogno di delega? Quali funzionalità sarebbero sorprendenti se venissero richieste?

Come distribuirlo senza rompere nulla

Distribuiscilo come qualsiasi altro header di produzione: deliberatamente.

1. Fai l'inventario dell'uso delle funzionalità

Cerca nel tuo codebase chiamate ad API del browser come getUserMedia, geolocation, requestFullscreen, PaymentRequest, Web Bluetooth, WebUSB e API wake lock.

Poi controlla gli embed di terze parti. La documentazione di provider video, mappe, pagamenti e identità spesso menziona i valori allow richiesti per gli iframe.

2. Inizia in un ambiente a basso rischio

Aggiungi un header restrittivo in staging e testa i percorsi principali. Presta attenzione ai messaggi della console del browser. I browser spesso segnalano quando una funzionalità è bloccata dalla permissions policy.

3. Usa policy specifiche per pagina dove necessario

Non imporre una sola policy globale se il tuo prodotto ha tipi di pagina molto diversi. Un blog, un checkout, una pagina con mappa e una stanza video probabilmente hanno bisogno di capacità diverse.

La maggior parte dei web server, framework e piattaforme edge può impostare header in modo condizionale per path. Spesso è più pulito che indebolire l'intero sito per una singola funzionalità.

4. Verifica la risposta reale

Gli header possono essere aggiunti, sovrascritti, duplicati o rimossi da CDN, reverse proxy, app server e middleware. Controlla la risposta finale in browser DevTools o con strumenti da riga di comando.

Testa anche i contesti incorporati. Il fatto che una pagina top-level appaia corretta non garantisce che un iframe abbia ricevuto la delega che intendevi.

5. Documenta le eccezioni

Ogni funzionalità consentita dovrebbe avere un proprietario e una ragione. Sembra burocratico finché, sei mesi dopo, nessuno ricorda perché geolocation era stata aperta a un dominio vendor che non appare più sulla pagina.

Errori di sintassi comuni

La sintassi moderna dell'header è compatta, ma è facile sbagliare di poco.

Usa parentesi vuote per negare una funzionalità:

Permissions-Policy: microphone=()

Usa self per l'origine corrente:

Permissions-Policy: geolocation=(self)

Usa origini tra virgolette per origini esterne specifiche:

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

Evita di fare affidamento su vecchi esempi di Feature-Policy, a meno che tu non stia intenzionalmente supportando un comportamento legacy. L'header più vecchio usava una sintassi diversa e non è ciò attorno a cui dovresti progettare oggi.

Ricorda anche che il supporto del browser varia per direttiva. Un browser può supportare l'header ma non una particolare direttiva di funzionalità. È normale. Tratta l'header come una misura di difesa in profondità, non come il tuo unico controllo di privacy o sicurezza.

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

💡 Prova questo: Verifica che la tua Permissions-Policy venga inviata come previsto con Get Headers, che mostra gli header di risposta grezzi inviati dal tuo server.

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

Il valore pratico per la privacy

Il valore privacy di Permissions-Policy non è rendere un sito anonimo o privo di tracker. Non lo fa.

Il suo valore è restringere l'accesso a capacità sensibili del browser. Posizione, fotocamera, microfono, sensori del dispositivo, API hardware locali e flussi di pagamento sono potenti. La maggior parte delle pagine non ne ha bisogno. Molti componenti incorporati non dovrebbero mai poterli richiedere.

Questo è un miglioramento reale. Riduce prompt accidentali, limita l'esposizione non necessaria di capacità e offre al tuo team un artefatto concreto da revisionare quando vengono rilasciate nuove funzionalità.

La versione migliore di questo header è noiosa: restrittiva di default, allentata solo dove una funzionalità visibile all'utente lo richiede, e testata come parte del normale processo di rilascio.