Privacy & Security

Što zaglavlje Permissions-Policy doista može ograničiti

Praktičan vodič kroz značajke preglednika koje možete ograničiti, ono što ne možete kontrolirati i kako uvesti zaglavlje bez narušavanja korisne funkcionalnosti.

The Wux Webtools Team The Wux Webtools Team 9 min čitanja Pomoć AI, pregledano od strane ljudi
A browser interface with feature toggles limiting access for a page and embedded frames.
Sadržaj
  1. Kratka verzija
  2. Što Permissions-Policy kontrolira
  3. Što može ograničiti na vašim vlastitim stranicama
  4. Što može ograničiti u iframeovima
  5. Što ne može ograničiti
  6. Razumna zadana politika
  7. Kako uvesti bez kvarenja funkcionalnosti
  8. 1. Inventarizirajte upotrebu značajki
  9. 2. Počnite u okruženju niskog rizika
  10. 3. Upotrijebite politike specifične za stranice gdje je potrebno
  11. 4. Provjerite stvarni odgovor
  12. 5. Dokumentirajte iznimke
  13. Česte sintaksne pogreške
  14. Praktična vrijednost za privatnost

Kratka verzija

Permissions-Policy je zaglavlje HTTP odgovora koje web-mjestu omogućuje ograničavanje pristupa određenim značajkama preglednika: kameri, mikrofonu, geolokaciji, prikazu preko cijelog zaslona, plaćanju, senzorima i dugom popisu manjih API-ja.

To nije opći štit privatnosti. Neće zaustaviti svako praćenje, blokirati kolačiće, spriječiti mrežne zahtjeve niti učiniti JavaScript trećih strana sigurnim. Ono što može dobro učiniti uže je, ali i dalje vrijedno: smanjiti mogućnosti preglednika dostupne vašim vlastitim stranicama i ugrađenim okvirima.

To je važno jer su moderna web-mjesta sastavljena od analitičkih isječaka, medijskih ugradnji, chat widgeta, alata za upravljanje privolama, oglašivačkih skripti, karata, tokova plaćanja i internih eksperimenata. Većini tih komponenti nije potreban pristup moćnim API-jima uređaja. Dobra politika to jasno izražava.

Ako već pregledavate zaglavlja u produkciji, uparite taj rad s izravnom provjerom stvarnog odgovora. Naš vodič za otklanjanje pogrešaka u preusmjeravanjima i HTTP zaglavljima u produkciji pokriva naviku koja je ovdje važna: provjerite što preglednik doista prima, a ne što vaša konfiguracijska datoteka kaže da bi se trebalo dogoditi.

Što Permissions-Policy kontrolira

Zaglavlje kontrolira pristup imenovanim značajkama preglednika. Točan se popis s vremenom mijenja jer se API-ji preglednika mijenjaju, ali uobičajene direktive uključuju:

  • camera
  • microphone
  • geolocation
  • fullscreen
  • payment
  • usb
  • bluetooth
  • accelerometer
  • gyroscope
  • magnetometer
  • screen-wake-lock
  • clipboard-read
  • clipboard-write
  • publickey-credentials-get
  • interest-cohort u starijim raspravama, danas uglavnom povijesno

Direktiva može dopustiti značajku nikome, trenutačnom izvoru ili odabranim izvorima. Na primjer:

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

To znači da su kamera i mikrofon onemogućeni za dokument i njegove ugniježđene kontekste pregledavanja, dok je geolokacija dopuštena samo za isti izvor.

Primjer s više dopuštenja:

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

Time se vašem vlastitom izvoru i jednom imenovanom pružatelju karata dopušta upotreba geolokacije, a vašem vlastitom izvoru i pružatelju videozapisa zahtjev za prikaz preko cijelog zaslona.

Politiku procjenjuje preglednik. Ako značajka nije dopuštena, JavaScript koji koristi taj API trebao bi ne uspjeti ili se ponašati kao da značajka nije dostupna. Točan način neuspjeha ovisi o API-ju. Ponekad se promise odbije. Ponekad se mogućnost jednostavno ne prikazuje kao upotrebljiva.

Što može ograničiti na vašim vlastitim stranicama

Na stranicama prve strane, Permissions-Policy je najkorisniji kao zaštitna ograda. Smanjuje doseg slučajnog ili neočekivanog koda.

Marketinškoj stranici, primjerice, vjerojatno nisu potrebni mikrofon, kamera, Bluetooth, USB, senzori pokreta ili API-ji za plaćanje. Te značajke možete globalno zabraniti:

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

To ne čini svaku skriptu na stranici pouzdanom. Znači da, ako eksperiment u tag manageru, kompromitirana ovisnost ili zalijepljeni widget pokuša pozvati ograničeni API, preglednik mu ne bi trebao odobriti pristup.

Za timove s mnogo suradnika to je korisna zadana postavka. Razgovor pomiče s nejasnog povjerenja na izričitu mogućnost. Ako buduća značajka doista treba kameru, netko mora promijeniti politiku i objasniti zašto.

To je prava vrsta trenja.

Što može ograničiti u iframeovima

Zaglavlje postaje osobito korisno oko ugrađenog sadržaja.

Preglednici već tretiraju iframeove kao odvojene kontekste pregledavanja, ali ugrađeni sadržaj trećih strana i dalje može zatražiti moćne značajke ako su dopuštene politikom i atributima iframea. Permissions-Policy roditeljskoj stranici omogućuje postavljanje gornje granice.

Na primjer, ako vaša stranica ugrađuje videoplayer, widget za podršku i kartu, možete izbjeći davanje svakom okviru pristupa svakoj značajki. Možete dopustiti prikaz preko cijelog zaslona samo video okviru, a geolokaciju samo okviru s kartom.

Treba razumjeti dva sloja:

  1. HTTP zaglavlje Permissions-Policy postavlja politiku za dokument.
  2. Atribut iframea allow može delegirati određene značajke okviru, ali samo unutar onoga što roditeljska politika dopušta.

Jednostavan iframe mogao bi izgledati ovako:

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

Ako vaše zaglavlje u potpunosti zabranjuje prikaz preko cijelog zaslona, atribut iframea ne može nadjačati tu zabranu. Ako vaše zaglavlje dopušta prikaz preko cijelog zaslona za taj izvor, atribut iframea može ga delegirati.

Ta je hijerarhija jedan od razloga zašto se zaglavlje isplati koristiti. Platformskim ili sigurnosnim timovima daje način postavljanja granica za cijelo web-mjesto, a proizvodnim timovima i dalje omogućuje uključivanje određenih ugradnji ondje gdje su potrebne.

Što ne može ograničiti

Ovdje timovi ponekad precjenjuju zaglavlje.

Permissions-Policy ne zamjenjuje content security policy. Ne odlučuje koje se skripte smiju učitati. Ne sprječava skriptu da šalje podatke preko mreže. Ne sanira HTML. Ne sprječava XSS. Ne blokira neželjenu poštu iz obrazaca. Ako je problem zloupotreba obrazaca, počnite s mehanikom opisanom u zašto je vaš kontaktni obrazac vaša najveća odgovornost za spam, a ne s ovim zaglavljem.

Također ne zamjenjuje upravljanje kolačićima. Kolačići, local storage, privola, ugradnje trećih strana i zaštite preglednika od praćenja odvojena su pitanja. Ako široko pregledavate kontrole privatnosti, okruženje kolačića zaslužuje vlastiti pregled; praktične promjene obrađene su u što se promijenilo za kolačiće u 2026. i što učiniti u vezi s tim.

Najvažnije, Permissions-Policy ne čini JavaScript trećih strana privatnim. Ako učitate skriptu treće strane u svoju stranicu prve strane, ona općenito radi s privilegijama vaše stranice, uz druga ograničenja preglednika i vaša sigurnosna zaglavlja. Zabraniti pristup kameri je dobro. To tu skriptu ne sprječava da čita DOM sadržaj, promatra radnje korisnika ili šalje dopuštene mrežne zahtjeve.

Za to su vam potrebne druge kontrole: pažljiv odabir dobavljača, CSP, sandboxed iframes, Subresource Integrity gdje je primjenjiv, minimizacija podataka i dosadni, ali nužni pregledi.

Razumna zadana politika

Ne postoji univerzalno zaglavlje koje odgovara svakom web-mjestu, ali većina sadržajnih i marketinških web-mjesta može početi restriktivno.

Razuman prvi pokušaj:

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

Zatim vratite samo ono što web-mjesto stvarno koristi.

Na primjer:

  • Trgovina koja koristi Payment Request API možda treba payment=(self).
  • Pronalazač lokacija možda treba geolocation=(self) ili pouzdani izvor karte.
  • Aplikacija za konferencije možda treba camera=(self) i microphone=(self).
  • Web-mjesto s mnogo videozapisa možda treba fullscreen=(self "https://trusted-video.example").

Važno je ne kopirati golemu politiku s kontrolnog popisa i smatrati posao dovršenim. Počnite s inventarom značajki. Kojim su stranicama potrebne koje mogućnosti preglednika? Kojim je ugradnjama potrebna delegacija? Koje bi značajke bile iznenađujuće kad bi bile zatražene?

Kako uvesti bez kvarenja funkcionalnosti

Uvedite ovo kao i svako drugo produkcijsko zaglavlje: promišljeno.

1. Inventarizirajte upotrebu značajki

Pretražite bazu koda za pozive API-ja preglednika kao što su getUserMedia, geolocation, requestFullscreen, PaymentRequest, Web Bluetooth, WebUSB i wake lock API-ji.

Zatim provjerite ugradnje trećih strana. Dokumentacija za pružatelje videa, karata, plaćanja i identiteta često spominje potrebne vrijednosti iframe atributa allow.

2. Počnite u okruženju niskog rizika

Dodajte restriktivno zaglavlje u stagingu i testirajte ključna korisnička putovanja. Obratite pozornost na poruke u konzoli preglednika. Preglednici često prijavljuju kada je značajka blokirana politikom dopuštenja.

3. Upotrijebite politike specifične za stranice gdje je potrebno

Nemojte forsirati jednu globalnu politiku ako vaš proizvod ima vrlo različite vrste stranica. Blog, naplata, stranica s kartom i video soba vjerojatno trebaju različite mogućnosti.

Većina web-poslužitelja, frameworka i edge platformi može uvjetno postavljati zaglavlja po putanji. To je često čišće nego oslabiti cijelo web-mjesto zbog jedne značajke.

4. Provjerite stvarni odgovor

Zaglavlja mogu dodati, prebrisati, duplicirati ili ukloniti CDN-ovi, reverse proxyji, aplikacijski poslužitelji i middleware. Provjerite konačni odgovor u pregledničkom DevTools ili alatima naredbenog retka.

Testirajte i ugrađene kontekste. To što stranica najviše razine izgleda ispravno ne jamči da je iframe primio delegaciju koju ste namjeravali.

5. Dokumentirajte iznimke

Svaka dopuštena značajka trebala bi imati vlasnika i razlog. To zvuči birokratski sve do šest mjeseci poslije, kada se nitko ne sjeća zašto je geolocation otvoren prema domeni dobavljača koja se više ne pojavljuje na stranici.

Česte sintaksne pogreške

Moderna sintaksa zaglavlja je sažeta, ali lako ju je malo pogrešno napisati.

Za zabranu značajke upotrijebite prazne zagrade:

Permissions-Policy: microphone=()

Upotrijebite self za trenutačni izvor:

Permissions-Policy: geolocation=(self)

Upotrijebite citirane izvore za određene vanjske izvore:

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

Izbjegavajte oslanjanje na stare primjere za Feature-Policy, osim ako namjerno podržavate naslijeđeno ponašanje. Starije zaglavlje koristilo je drukčiju sintaksu i nije ono oko čega biste danas trebali dizajnirati.

Također imajte na umu da podrška preglednika varira po direktivi. Preglednik može podržavati zaglavlje, ali ne i određenu direktivu značajke. To je normalno. Tretirajte zaglavlje kao mjeru obrane u dubinu, a ne kao svoju jedinu kontrolu privatnosti ili sigurnosti.

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

💡 Isprobajte ovo: Provjerite isporučuje li se vaša Permissions-Policy kako je predviđeno pomoću Get Headers, koji prikazuje sirova zaglavlja odgovora koja vaš poslužitelj šalje.

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

Praktična vrijednost za privatnost

Vrijednost Permissions-Policy za privatnost nije u tome da web-mjesto čini anonimnim ili bez praćenja. Ne čini to.

Njegova je vrijednost u tome što sužava pristup osjetljivim mogućnostima preglednika. Lokacija, kamera, mikrofon, senzori uređaja, lokalni hardverski API-ji i tokovi plaćanja moćni su. Većina stranica ih ne treba. Mnogim ugrađenim komponentama nikada ne bi trebalo biti dopušteno tražiti ih.

To je stvarno poboljšanje. Smanjuje slučajne upite, ograničava nepotrebno izlaganje mogućnosti i vašem timu daje konkretan artefakt za pregled kada se isporučuje nova funkcionalnost.

Najbolja verzija ovog zaglavlja je dosadna: restriktivna prema zadanim postavkama, olabavljena samo ondje gdje to zahtijeva značajka vidljiva korisniku i testirana kao dio uobičajenog procesa izdavanja.

Često postavljana pitanja

Je li Permissions-Policy isto što i Feature-Policy?
Ne. Permissions-Policy je moderna zamjena za starije zaglavlje Feature-Policy. Neki stariji članci i isječci još uvijek koriste sintaksu Feature-Policy, ali nove implementacije trebaju koristiti Permissions-Policy.
Može li Permissions-Policy zaustaviti praćenje trećih strana?
Ne samostalno. Može blokirati pristup određenim značajkama preglednika, ali ne sprječava učitavanje skripti, postavljanje kolačića ondje gdje je dopušteno, čitanje sadržaja stranice ili slanje mrežnih zahtjeva. Koristite ga uz CSP, kontrole privole, minimizaciju podataka i pažljivo upravljanje dobavljačima.
Treba li svako web-mjesto zabraniti kameru i mikrofon?
Uglavnom da. Ako vaše web-mjesto ne nudi snimanje videa, konferencije, provjeru identiteta ili drugu značajku kojoj je očito potrebno snimanje medija, zabrana kamere i mikrofona razumna je zadana postavka.
Može li atribut allow u iframeu nadjačati zaglavlje?
Ne. Politika roditeljskog dokumenta postavlja gornju granicu. Atribut iframea allow može delegirati značajku samo ako roditeljska politika dopušta tu značajku za izvor okvira.
Hoće li nepodržane direktive pokvariti stare preglednike?
Općenito, nepodržane direktive se ignoriraju. I dalje biste trebali testirati važna korisnička putovanja u svim preglednicima koje podržavate jer se ponašanje pojedinih API-ja i izvještavanje u konzoli mogu razlikovati.

Izvori i daljnje čitanje

  1. MDN Web Docs: Permissions-Policy header
  2. W3C: Permissions Policy specification
  3. web.dev: Permissions Policy
  4. Chrome Developers: Controlling browser features with Permissions Policy
O autoru
The Wux Webtools Team

Zadnje ažurirano:

Nastavite čitati