Ce poate bloca efectiv antetul Permissions-Policy

Varianta scurtă

Permissions-Policy este un antet de răspuns HTTP care permite unui site să limiteze accesul la anumite funcționalități ale browserului: cameră, microfon, geolocație, fullscreen, plată, senzori și o listă lungă de API-uri mai mici.

Nu este un scut general de confidențialitate. Nu va opri toată urmărirea, nu va bloca cookie-urile, nu va preveni cererile de rețea și nu va face sigur JavaScript-ul terț. Ce poate face bine este mai restrâns, dar tot valoros: reduce capabilitățile browserului disponibile pentru propriile pagini și pentru cadrele încorporate.

Acest lucru contează deoarece site-urile moderne sunt alcătuite din fragmente de analytics, încorporări media, widgeturi de chat, manageri de consimțământ, scripturi de publicitate, hărți, fluxuri de plată și experimente interne. Majoritatea acestor componente nu au nevoie de acces la API-uri puternice ale dispozitivului. O politică bună face acest lucru explicit.

Dacă analizați deja antetele în producție, asociați această activitate cu o verificare directă a răspunsului real. Ghidul nostru despre depanarea redirecționărilor și a antetelor HTTP în producție acoperă obiceiul care contează aici: inspectați ce primește efectiv browserul, nu ce spune fișierul de configurare că ar trebui să se întâmple.

Ce controlează Permissions-Policy

Antetul controlează accesul la funcționalități de browser numite. Lista exactă se schimbă în timp deoarece API-urile browserului se schimbă, dar directivele comune includ:

• camera
• microphone
• geolocation
• fullscreen
• payment
• usb
• bluetooth
• accelerometer
• gyroscope
• magnetometer
• screen-wake-lock
• clipboard-read
• clipboard-write
• publickey-credentials-get
• interest-cohort în discuții mai vechi, acum în mare parte istoric

O directivă poate permite o funcționalitate pentru nimeni, pentru originea curentă sau pentru origini selectate. De exemplu:

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

Aceasta înseamnă că camera și microfonul sunt dezactivate pentru document și pentru contextele sale de navigare imbricate, în timp ce geolocația este permisă numai pentru aceeași origine.

Un exemplu mai permisiv:

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

Aceasta permite propriei origini și unui furnizor de hărți numit să folosească geolocația, iar propriei origini plus unui furnizor video să solicite fullscreen.

Politica este evaluată de browser. Dacă o funcționalitate nu este permisă, JavaScript-ul care folosește acel API ar trebui să eșueze sau să se comporte ca și cum funcționalitatea nu ar fi disponibilă. Modul exact de eșec depinde de API. Uneori o promisiune este respinsă. Alteori, o capabilitate pur și simplu nu pare utilizabilă.

Ce poate bloca pe propriile pagini

Pe paginile first-party, Permissions-Policy este cel mai util ca balustradă de protecție. Reduce raza de impact a codului accidental sau neașteptat.

O pagină de marketing, de exemplu, probabil nu are nevoie de microfon, cameră, Bluetooth, USB, senzori de mișcare sau API-uri de plată. Puteți refuza aceste funcționalități global:

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

Acest lucru nu face ca fiecare script de pe pagină să fie de încredere. Înseamnă că, dacă un experiment dintr-un tag manager, o dependență compromisă sau un widget lipit încearcă să apeleze un API restricționat, browserul nu ar trebui să îi acorde acces.

Pentru echipele cu mulți contributori, acesta este un implicit util. Mută conversația de la încredere vagă la capabilitate explicită. Dacă o funcționalitate viitoare chiar are nevoie de cameră, cineva trebuie să schimbe politica și să explice de ce.

Acesta este tipul corect de fricțiune.

Ce poate bloca în iframe-uri

Antetul devine deosebit de util în jurul conținutului încorporat.

Browserele tratează deja iframe-urile ca pe contexte de navigare separate, dar conținutul terț încorporat poate totuși solicita funcționalități puternice dacă este permis de politică și de atributele iframe-ului. Permissions-Policy permite paginii părinte să stabilească o limită superioară.

De exemplu, dacă pagina dvs. încorporează un player video, un widget de suport și o hartă, puteți evita să oferiți fiecărui cadru acces la fiecare funcționalitate. Ați putea permite fullscreen numai pentru cadrul video și geolocația numai pentru cadrul hărții.

Există două straturi de înțeles:

1. Antetul HTTP Permissions-Policy stabilește politica pentru document.
2. Atributul allow al iframe-ului poate delega funcționalități specifice unui cadru, dar numai în limitele permise de politica părintelui.

Un iframe simplu ar putea arăta astfel:

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

Dacă antetul dvs. refuză complet fullscreen, atributul iframe-ului nu poate anula acel refuz. Dacă antetul dvs. permite fullscreen pentru acea origine, atributul iframe-ului îl poate delega.

Această ierarhie este unul dintre motivele pentru care merită folosit antetul. Oferă echipelor de platformă sau securitate o modalitate de a stabili limite la nivel de site, permițând în același timp echipelor de produs să activeze încorporări specifice acolo unde este necesar.

Ce nu poate bloca

Aici echipele supraestimează uneori antetul.

Permissions-Policy nu înlocuiește o content security policy. Nu decide ce scripturi se pot încărca. Nu oprește un script să trimită date prin rețea. Nu sanitizează HTML. Nu previne XSS. Nu blochează spamul prin formulare. Dacă abuzul formularelor este problema, începeți cu mecanica descrisă în de ce formularul dvs. de contact este cea mai mare vulnerabilitate la spam, nu cu acest antet.

De asemenea, nu înlocuiește guvernanța cookie-urilor. Cookie-urile, local storage, consimțământul, încorporările terțe și protecțiile browserului împotriva urmăririi sunt probleme separate. Dacă analizați controalele de confidențialitate în sens larg, peisajul cookie-urilor merită o trecere separată; schimbările practice sunt acoperite în ce s-a schimbat pentru cookie-uri în 2026 și ce trebuie făcut.

Cel mai important, Permissions-Policy nu face privat JavaScript-ul terț. Dacă încărcați un script terț în pagina dvs. first-party, acesta rulează în general cu privilegiile paginii dvs., sub rezerva altor constrângeri ale browserului și a antetelor dvs. de securitate. Refuzarea accesului la cameră este bună. Nu oprește acel script să citească conținutul DOM, să observe acțiunile utilizatorului sau să facă cereri de rețea permise.

Pentru asta, aveți nevoie de controale diferite: selecție atentă a furnizorilor, CSP, iframe-uri sandboxed, Subresource Integrity acolo unde este aplicabil, minimizarea datelor și revizuiri plictisitoare, dar necesare.

O politică implicită rezonabilă

Nu există un antet universal care să se potrivească fiecărui site, dar majoritatea site-urilor de conținut și marketing pot începe restrictiv.

O primă variantă rezonabilă:

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

Apoi adăugați înapoi doar ceea ce site-ul folosește efectiv.

De exemplu:

• Un magazin care folosește Payment Request API poate avea nevoie de payment=(self).
• Un locator de locații poate avea nevoie de geolocation=(self) sau de o origine de hartă de încredere.
• O aplicație de conferințe poate avea nevoie de camera=(self) și microphone=(self).
• Un site axat puternic pe video poate avea nevoie de fullscreen=(self "https://trusted-video.example").

Partea importantă este să nu copiați o politică enormă dintr-o listă de verificare și să considerați treaba încheiată. Începeți cu inventarul funcționalităților. Ce pagini au nevoie de ce capabilități ale browserului? Ce încorporări au nevoie de delegare? Ce funcționalități ar fi surprinzătoare dacă ar fi solicitate?

Cum să implementați fără să stricați lucruri

Lansați acest lucru ca pe orice alt antet de producție: deliberat.

1. Inventariați utilizarea funcționalităților

Căutați în baza de cod apeluri de API-uri de browser precum getUserMedia, geolocation, requestFullscreen, PaymentRequest, Web Bluetooth, WebUSB și API-uri wake lock.

Apoi verificați încorporările terțe. Documentația pentru furnizorii video, hărți, plăți și identitate menționează adesea valorile iframe allow necesare.

2. Începeți într-un mediu cu risc redus

Adăugați un antet restrictiv în staging și testați parcursurile esențiale. Acordați atenție mesajelor din consola browserului. Browserele raportează adesea când o funcționalitate este blocată de permissions policy.

3. Folosiți politici specifice paginii acolo unde este necesar

Nu impuneți o singură politică globală dacă produsul dvs. are tipuri de pagini foarte diferite. Un blog, checkout, o pagină cu hartă și o cameră video au probabil nevoie de capabilități diferite.

Majoritatea serverelor web, framework-urilor și platformelor edge pot seta antete condițional în funcție de cale. Acest lucru este adesea mai curat decât slăbirea întregului site pentru o singură funcționalitate.

4. Verificați răspunsul real

Antetele pot fi adăugate, suprascrise, duplicate sau eliminate de CDN-uri, reverse proxy-uri, servere de aplicație și middleware. Verificați răspunsul final în browser DevTools sau cu instrumente de linie de comandă.

Testați și contextele încorporate. Faptul că o pagină de nivel superior pare corectă nu garantează că un iframe a primit delegarea intenționată.

5. Documentați excepțiile

Fiecare funcționalitate permisă ar trebui să aibă un responsabil și un motiv. Sună birocratic până peste șase luni, când nimeni nu își mai amintește de ce geolocation a fost deschis către un domeniu de furnizor care nu mai apare pe pagină.

Greșeli comune de sintaxă

Sintaxa modernă a antetului este compactă, dar este ușor să o greșiți ușor.

Folosiți paranteze goale pentru a refuza o funcționalitate:

Permissions-Policy: microphone=()

Folosiți self pentru originea curentă:

Permissions-Policy: geolocation=(self)

Folosiți origini între ghilimele pentru origini externe specifice:

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

Evitați să vă bazați pe exemple vechi Feature-Policy, cu excepția cazului în care susțineți intenționat comportament legacy. Antetul mai vechi folosea o sintaxă diferită și nu este cel în jurul căruia ar trebui să proiectați astăzi.

Amintiți-vă și că suportul browserelor variază în funcție de directivă. Un browser poate suporta antetul, dar nu o anumită directivă de funcționalitate. Este normal. Tratați antetul ca pe o măsură de defense-in-depth, nu ca pe singurul dvs. control de confidențialitate sau securitate.

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

💡 Încercați asta: Verificați dacă Permissions-Policy este livrată conform intenției cu Get Headers, care afișează anteturile brute ale răspunsului pe care le trimite serverul dvs.

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

Valoarea practică pentru confidențialitate

Valoarea pentru confidențialitate a Permissions-Policy nu este că face un site anonim sau fără trackere. Nu face asta.

Valoarea sa este că restrânge accesul la capabilități sensibile ale browserului. Locația, camera, microfonul, senzorii dispozitivului, API-urile hardware locale și fluxurile de plată sunt puternice. Majoritatea paginilor nu au nevoie de ele. Multe componente încorporate nu ar trebui să poată niciodată să le solicite.

Aceasta este o îmbunătățire reală. Reduce solicitările accidentale, limitează expunerea inutilă a capabilităților și oferă echipei dvs. un artefact concret de analizat atunci când este lansată o funcționalitate nouă.

Cea mai bună versiune a acestui antet este plictisitoare: restrictivă în mod implicit, relaxată numai acolo unde o funcționalitate vizibilă pentru utilizator o cere și testată ca parte a procesului normal de lansare.