Mit tud ténylegesen zárolni a Permissions-Policy fejléc

A rövid változat

A Permissions-Policy egy HTTP-válaszfejléc, amellyel egy webhely korlátozhatja bizonyos böngészőfunkciók elérését: kamera, mikrofon, geolokáció, teljes képernyő, fizetés, szenzorok és számos kisebb API.

Nem általános adatvédelmi pajzs. Nem állít meg minden követést, nem blokkolja a sütiket, nem akadályozza meg a hálózati kéréseket, és nem teszi biztonságossá a harmadik féltől származó JavaScriptet. Amit jól tud, az szűkebb, de továbbra is értékes: csökkenti a saját oldalak és a beágyazott frame-ek számára elérhető böngészőképességeket.

Ez azért számít, mert a modern webhelyek analitikai részletekből, médiabeágyazásokból, chat widgetekből, hozzájáruláskezelőkből, hirdetési scriptekből, térképekből, fizetési folyamatokból és belső kísérletekből állnak össze. Ezek többségének nincs szüksége erős eszköz-API-khoz való hozzáférésre. Egy jó szabályzat ezt egyértelművé teszi.

Ha már éles környezetben vizsgálja a fejléceket, kapcsolja össze ezt a munkát a tényleges válasz közvetlen ellenőrzésével. A debugging redirects and HTTP headers in production című útmutatónk azt a szokást mutatja be, amely itt fontos: azt ellenőrizze, amit a böngésző valóban megkap, ne azt, aminek a konfigurációs fájl szerint történnie kellene.

Mit vezérel a Permissions-Policy

A fejléc névvel azonosított böngészőfunkciókhoz való hozzáférést vezérel. A pontos lista idővel változik, mert a böngésző-API-k is változnak, de a gyakori direktívák közé tartoznak:

• camera
• microphone
• geolocation
• fullscreen
• payment
• usb
• bluetooth
• accelerometer
• gyroscope
• magnetometer
• screen-wake-lock
• clipboard-read
• clipboard-write
• publickey-credentials-get
• interest-cohort régebbi beszélgetésekben, ma már többnyire történeti jelentőségű

Egy direktíva engedélyezhet egy funkciót senkinek, az aktuális originnek, vagy kiválasztott origineknek. Például:

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

Ez azt jelenti, hogy a kamera és a mikrofon le van tiltva a dokumentum és annak beágyazott böngészési kontextusai számára, míg a geolokáció csak ugyanannak az originnek engedélyezett.

Egy megengedőbb példa:

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

Ez lehetővé teszi, hogy a saját originje és egy megnevezett térképszolgáltató használja a geolokációt, valamint hogy a saját originje és egy videószolgáltató teljes képernyőt kérjen.

A szabályzatot a böngésző értékeli ki. Ha egy funkció nincs engedélyezve, az adott API-t használó JavaScriptnek hibáznia kell, vagy úgy kell viselkednie, mintha a képesség nem lenne elérhető. A pontos hibamód az API-tól függ. Néha egy promise elutasításra kerül. Néha egy képesség egyszerűen nem tűnik használhatónak.

Mit tud zárolni a saját oldalain

Első féltől származó oldalakon a Permissions-Policy leginkább védőkorlátként hasznos. Csökkenti a véletlen vagy váratlan kód hatókörét.

Egy marketingoldalnak például valószínűleg nincs szüksége mikrofonra, kamerára, Bluetoothra, USB-re, mozgásérzékelőkre vagy fizetési API-kra. Ezeket a funkciókat globálisan letilthatja:

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

Ez nem tesz minden scriptet megbízhatóvá az oldalon. Azt viszont jelenti, hogy ha egy tag manager-kísérlet, kompromittált függőség vagy bemásolt widget megpróbál meghívni egy korlátozott API-t, a böngészőnek nem szabad hozzáférést adnia hozzá.

Sok közreműködővel dolgozó csapatoknak ez hasznos alapértelmezés. A beszélgetést a homályos bizalomtól az explicit képességek felé mozdítja. Ha egy jövőbeli funkciónak valóban szüksége van a kamerára, valakinek módosítania kell a szabályzatot, és el kell magyaráznia, miért.

Ez a megfelelő fajta súrlódás.

Mit tud zárolni iframe-ekben

A fejléc különösen hasznossá válik beágyazott tartalmak körül.

A böngészők eleve külön böngészési kontextusként kezelik az iframe-eket, de a beágyazott, harmadik féltől származó tartalom továbbra is kérhet erős funkciókat, ha a szabályzat és az iframe-attribútumok ezt engedik. A Permissions-Policy lehetővé teszi, hogy a szülőoldal felső korlátot állítson be.

Ha például az oldala beágyaz egy videólejátszót, egy támogatási widgetet és egy térképet, elkerülheti, hogy minden frame minden funkcióhoz hozzáférést kapjon. Engedélyezheti a teljes képernyőt csak a videó frame számára, a geolokációt pedig csak a térkép frame számára.

Két réteget érdemes megérteni:

1. A HTTP Permissions-Policy fejléc szabályzatot állít be a dokumentumra.
2. Az iframe allow attribútuma konkrét funkciókat delegálhat egy frame-nek, de csak azon belül, amit a szülő szabályzata megenged.

Egy egyszerű iframe így nézhet ki:

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

Ha a fejléce teljesen tiltja a teljes képernyőt, az iframe attribútuma nem írhatja felül ezt a tiltást. Ha a fejléce engedélyezi a teljes képernyőt az adott origin számára, az iframe attribútuma delegálhatja azt.

Ez a hierarchia az egyik ok, amiért érdemes használni a fejlécet. Lehetőséget ad a platform- vagy biztonsági csapatoknak arra, hogy webhelyszintű határokat állítsanak be, miközben a termékcsapatok továbbra is engedélyezhetnek konkrét beágyazásokat ott, ahol szükséges.

Mit nem tud zárolni

Itt szokták a csapatok néha túlbecsülni a fejlécet.

A Permissions-Policy nem helyettesíti a content security policyt. Nem dönti el, mely scriptek töltődhetnek be. Nem akadályozza meg, hogy egy script adatokat küldjön a hálózaton. Nem tisztítja meg a HTML-t. Nem akadályozza meg az XSS-t. Nem blokkolja az űrlapspamet. Ha az űrlapokkal való visszaélés a probléma, kezdje a why your contact form is your biggest spam liability című cikkben leírt mechanikával, ne ezzel a fejléccel.

Nem helyettesíti a sütik szabályozását sem. A sütik, a local storage, a hozzájárulás, a harmadik féltől származó beágyazások és a böngésző követésvédelmei külön kérdések. Ha szélesebb körben vizsgálja az adatvédelmi kontrollokat, a sütik világa saját áttekintést érdemel; a gyakorlati változásokat a what changed for cookies in 2026 and what to do about it című cikk tárgyalja.

A legfontosabb, hogy a Permissions-Policy nem teszi priváttá a harmadik féltől származó JavaScriptet. Ha harmadik féltől származó scriptet tölt be az első féltől származó oldalára, az általában az oldala jogosultságaival fut, más böngészőkorlátok és a biztonsági fejlécei mellett. A kamera-hozzáférés tiltása jó. De ettől a script még olvashat DOM-tartalmat, megfigyelhet felhasználói műveleteket, vagy indíthat engedélyezett hálózati kéréseket.

Ehhez más kontrollokra van szükség: gondos beszállítóválasztásra, CSP-re, sandboxolt iframe-ekre, ahol alkalmazható Subresource Integrityre, adatminimalizálásra, valamint unalmas, de szükséges felülvizsgálatokra.

Egy észszerű alapértelmezett szabályzat

Nincs olyan univerzális fejléc, amely minden webhelyhez illik, de a legtöbb tartalmi és marketingwebhely korlátozó beállítással indulhat.

Egy észszerű első kör:

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

Ezután csak azt adja vissza, amit a webhely ténylegesen használ.

Például:

• Egy Payment Request API-t használó áruháznak szüksége lehet a payment=(self) beállításra.
• Egy helykeresőnek szüksége lehet a geolocation=(self) beállításra vagy egy megbízható térképes originre.
• Egy konferenciaalkalmazásnak szüksége lehet a camera=(self) és microphone=(self) beállításokra.
• Egy videóközpontú webhelynek szüksége lehet a fullscreen=(self "https://trusted-video.example") beállításra.

A lényeg nem az, hogy bemásoljon egy óriási szabályzatot egy ellenőrzőlistáról, és késznek nyilvánítsa. Kezdje a funkcióleltárral. Mely oldalaknak mely böngészőképességekre van szükségük? Mely beágyazások igényelnek delegálást? Mely funkciók kérése lenne meglepő?

Hogyan vezesse be anélkül, hogy dolgokat törne el

Úgy vezesse be, mint bármely más éles fejlécet: megfontoltan.

1. Készítsen leltárt a funkcióhasználatról

Keressen a kódbázisban olyan böngésző-API-hívásokat, mint a getUserMedia, geolocation, requestFullscreen, PaymentRequest, Web Bluetooth, WebUSB és wake lock API-k.

Ezután ellenőrizze a harmadik féltől származó beágyazásokat. A videó-, térkép-, fizetési és identitásszolgáltatók dokumentációja gyakran említi a szükséges iframe allow értékeket.

2. Kezdje alacsony kockázatú környezetben

Adjon hozzá korlátozó fejlécet staging környezetben, és tesztelje az alapvető felhasználói útvonalakat. Figyeljen a böngészőkonzol üzeneteire. A böngészők gyakran jelzik, ha egy funkciót a permissions policy blokkol.

3. Használjon oldalspecifikus szabályzatokat, ahol szükséges

Ne erőltessen egyetlen globális szabályzatot, ha a termékének nagyon eltérő oldaltípusai vannak. Egy blognak, pénztárnak, térképes oldalnak és videószobának valószínűleg eltérő képességekre van szüksége.

A legtöbb webszerver, keretrendszer és edge platform útvonal alapján feltételesen tud fejléceket beállítani. Ez gyakran tisztább megoldás, mint az egész webhely gyengítése egyetlen funkció miatt.

4. Ellenőrizze a valódi választ

A fejléceket CDN-ek, reverse proxyk, alkalmazásszerverek és middleware-ek hozzáadhatják, felülírhatják, duplikálhatják vagy eltávolíthatják. Ellenőrizze a végső választ a böngésző DevTools eszközeiben vagy parancssori eszközökkel.

Tesztelje a beágyazott kontextusokat is. Attól, hogy egy felső szintű oldal helyesnek tűnik, még nem garantált, hogy egy iframe megkapta a szándékolt delegálást.

5. Dokumentálja a kivételeket

Minden engedélyezett funkciónak legyen gazdája és oka. Ez bürokratikusnak hangzik egészen addig, amíg hat hónappal később senki sem emlékszik, miért lett megnyitva a geolocation egy olyan beszállítói domain felé, amely már nem is jelenik meg az oldalon.

Gyakori szintaktikai hibák

A modern fejlécszintaxis tömör, de könnyű kissé elrontani.

Használjon üres zárójeleket egy funkció tiltásához:

Permissions-Policy: microphone=()

Használja a self értéket az aktuális originhez:

Permissions-Policy: geolocation=(self)

Használjon idézőjeles origineket konkrét külső originekhez:

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

Ne támaszkodjon régi Feature-Policy példákra, kivéve ha szándékosan legacy viselkedést támogat. A régebbi fejléc más szintaxist használt, és ma nem erre érdemes tervezni.

Azt is tartsa észben, hogy a böngészőtámogatás direktívánként eltér. Egy böngésző támogathatja a fejlécet, de egy adott funkciódirektívát nem. Ez normális. A fejlécet defense-in-depth intézkedésként kezelje, ne az egyetlen adatvédelmi vagy biztonsági kontrollként.

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

💡 Próbálja ki ezt: Ellenőrizze a Get Headers segítségével, hogy a Permissions-Policy a szándékolt módon kerül-e kézbesítésre, amely megjeleníti a szervere által küldött nyers válaszfejléceket.

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

A gyakorlati adatvédelmi érték

A Permissions-Policy adatvédelmi értéke nem az, hogy anonimmá vagy követőmentessé tesz egy webhelyet. Nem teszi azzá.

Az értéke abban áll, hogy szűkíti az érzékeny böngészőképességekhez való hozzáférést. A helyadatok, a kamera, a mikrofon, az eszközszenzorok, a helyi hardver-API-k és a fizetési folyamatok erős képességek. A legtöbb oldalnak nincs szüksége rájuk. Sok beágyazott komponensnek soha nem szabadna kérnie őket.

Ez valódi javulás. Csökkenti a véletlen engedélykéréseket, korlátozza a szükségtelen képességkitettséget, és konkrét ellenőrizhető artefaktumot ad a csapatának, amikor új funkcionalitás kerül ki.

Ennek a fejlécnek a legjobb változata unalmas: alapértelmezetten korlátozó, csak ott lazított, ahol egy felhasználói funkció megköveteli, és a normál kiadási folyamat részeként tesztelt.