Permissions-Policy è un header di risposta. Dice quali funzioni — camera, microfono, geolocalizzazione — la pagina e gli iframe possono usare. camera=() le spegne. Non è più Feature-Policy. Il banner cookie non lo imposta. MDN lo marca sperimentale.
Il banner cookie non scrive l’header Permissions-Policy. Permissions-Policy è un header di risposta con cui il server dice al browser quali API e funzioni della pagina — camera, microfono, geolocalizzazione, autoplay — sono permesse nel documento e negli iframe. MDN lo marca sperimentale, non Baseline. Non è il consenso al marketing. Non è più Feature-Policy: il nome è cambiato, la sintassi HTTP anche.
In breve: header di risposta. Sintassi Permissions-Policy: camera=(), geolocation=(). Lista vuota: funzione spenta. self: solo same-origin. *: tutti. L’attributo allow sull’iframe è un altro piano, default src. Il vecchio header si chiamava Feature-Policy e usava apici, non le parentesi. Verifica del 22 settembre 2026 su MDN.
Cosa trovi in questo articolo
Cosa è Permissions-Policy (e cosa non è il banner)
MDN, sulla guida Permissions Policy e sull’header Permissions-Policy, parte da un fatto: lo sviluppatore dichiara quali funzioni il codice del sito — e il contenuto di terzi negli iframe — può usare. Esempi elencati da MDN: cambiare l’autoplay su mobile e sui video di terzi; limitare camera, microfono, altoparlanti; permettere a un iframe la Fullscreen API; non far eseguire script a elementi fuori dal viewport. Non è un testo in pagina. È un header di risposta. MDN: sperimentale, disponibilità limitata, non Baseline. Prima di produzione si legge la tabella di compatibilità.
Non è la CSP. MDN lo dice: Permissions Policy è simile alla CSP, ma controlla le funzioni, non il comportamento di sicurezza (script, origini, frame). Non è CORS: CORS decide chi può leggere una risposta. Non è Referrer-Policy: Referrer-Policy decide cosa della URL esce. Non è il cookie SameSite. Il banner che chiede il marketing non spegne getUserMedia(). Quattro header, un popup, cinque mestieri.
Questo pezzo sta nel cluster Sicurezza, accanto alla CSP e a Referrer-Policy. La CSP limita cosa la pagina può eseguire. Permissions-Policy limita quali API può chiamare. Due piani, due header.
Allowlist: vuota, self, origini
MDN, pagina dell’header, sintassi: una o più direttive separate da virgola, ciascuna con una allowlist tra parentesi. Opzionale, per direttiva, report-to=<endpoint>, da mappare con Reporting-Endpoints.
| Allowlist | Cosa permette MDN |
|---|---|
() (vuota) | funzione spenta nel documento e negli iframe. Sull’attributo allow dell’iframe l’equivalente è 'none' |
self | permessa nel documento e negli iframe same-origin. Non nei documenti cross-origin innestati. Equivalente iframe: self |
* | permessa in questo documento e in tutti gli iframe, qualunque origine. Va usata da sola |
"https://a.example.com" | origini nominate, tra virgolette, separate da spazio. Sull’attributo allow le origini non si virgolettano |
src | solo sull’attributo allow dell’iframe: permessa se il documento caricato ha la stessa origine dell’attributo src. È il default negli iframe |
Esempio da produzione, se la pagina non deve usare camera né geolocalizzazione, nemmeno in un widget di terzi:
Permissions-Policy: camera=(), microphone=(), geolocation=()MDN elenca le direttive una per una. camera: se la policy non la consente, la Promise di getUserMedia() rifiuta con NotAllowedError. autoplay: senza gesto dell’utente, HTMLMediaElement.play() rifiuta e l’attributo autoplay viene ignorato. Ogni direttiva ha un default proprio (*, self o none) se non la si elenca: sta sulla scheda di quella direttiva, non in un plugin «privacy pack».
Header, iframe allow, Feature-Policy
MDN: la policy si mette sulla risposta HTTP. In pagina, sugli iframe, resta l’attributo allow. Nota esplicita della guida: Permissions Policy si chiamava Feature Policy. Il nome è cambiato, la sintassi dell’header HTTP anche. L’attributo <iframe allow=" … "> è rimasto uguale. Chi copia Feature-Policy: camera 'none' su un header Permissions-Policy scrive una stringa che il browser nuovo non legge come la nuova grammatica.
Vecchia grammatica, apici: Feature-Policy: geolocation 'none'. Nuova grammatica, parentesi: Permissions-Policy: geolocation=(). Due header, due epoche. L’iframe, esempio MDN, usa ancora allow="camera 'src'; geolocation 'src'". Default sull’iframe, se manca allow: src. Non è il default dell’header.
Le violazioni, scrive MDN, si possono segnalare con la Reporting API, verso l’endpoint indicato da report-to o verso "default", e osservare in pagina con ReportingObserver. Si verifica sugli header della risposta, in staging, e tentando getUserMedia() o l’autoplay da un iframe di terzi. Non sul lucchetto della home. Non sul testo del banner. Il certificato TLS cifra il transito; non decide se la camera è accesa.
Errori da evitare
Lasciare il default e un widget di terzi con camera o geolocalizzazione: se la direttiva non è in header, vale il default di quella direttiva, non il testo del cookie.
Copiare
Feature-Policy: camera 'none'e aspettarsi chePermissions-Policyla capisca: sintassi diversa, header diverso.Trattare il banner cookie come Permissions-Policy: il consenso non scrive l’header.
Confondere Permissions-Policy con CSP, CORS o Referrer-Policy: tre header, tre mestieri, più questo.
Mettere
*«per far funzionare il widget» e regalare camera e microfono a ogni iframe.Fidarsi del plugin «GDPR pack» senza leggere
Permissions-Policysulla risposta e senza provaregetUserMedia()da un iframe.
In sintesi
Permissions-Policy è un header di risposta. Dice quali funzioni il documento e gli iframe possono usare. camera=() spegne la camera. Non è Feature-Policy: nome e sintassi HTTP sono cambiati. Non è il banner cookie. MDN lo marca sperimentale: si legge la compatibilità prima di produzione. MDN, 22 settembre 2026.
