Mitä Permissions-Policy-otsakkeella voi oikeasti lukita

Lyhyt versio

Permissions-Policy on HTTP-vastausotsake, jonka avulla sivusto voi rajoittaa pääsyä tiettyihin selainominaisuuksiin: kameraan, mikrofoniin, geolokaatioon, koko näytön tilaan, maksamiseen, antureihin ja pitkään joukkoon pienempiä API-rajapintoja.

Se ei ole yleinen yksityisyyssuoja. Se ei pysäytä kaikkea seurantaa, estä evästeitä, estä verkkopyyntöjä tai tee kolmannen osapuolen JavaScriptistä turvallista. Se, minkä se tekee hyvin, on kapeampaa mutta silti arvokasta: se vähentää selainkyvykkyyksiä, jotka ovat omien sivujesi ja upotettujen kehysten käytettävissä.

Tällä on merkitystä, koska modernit verkkosivustot koostuvat analytiikkakatkelmista, mediaupotuksista, chat-widgeteistä, suostumustenhallinnasta, mainosskripteistä, kartoista, maksupoluista ja sisäisistä kokeiluista. Useimmat näistä komponenteista eivät tarvitse pääsyä tehokkaisiin laite-API-rajapintoihin. Hyvä käytäntö tekee tämän selväksi.

Jos tarkistat jo otsakkeita tuotannossa, yhdistä tämä työ suoraan todellisen vastauksen tarkistamiseen. Oppaamme uudelleenohjausten ja HTTP-otsakkeiden virheenkorjaukseen tuotannossa käsittelee tässä olennaista tapaa: tarkista, mitä selain todella vastaanottaa, älä sitä mitä asetustiedoston mukaan pitäisi tapahtua.

Mitä Permissions-Policy hallitsee

Otsake hallitsee pääsyä nimettyihin selainominaisuuksiin. Tarkka luettelo muuttuu ajan myötä, koska selain-API:t muuttuvat, mutta yleisiä direktiivejä ovat esimerkiksi:

• camera
• microphone
• geolocation
• fullscreen
• payment
• usb
• bluetooth
• accelerometer
• gyroscope
• magnetometer
• screen-wake-lock
• clipboard-read
• clipboard-write
• publickey-credentials-get
• interest-cohort vanhemmissa keskusteluissa, nykyisin enimmäkseen historiallinen

Direktiivi voi sallia ominaisuuden ei kenellekään, nykyiselle originille tai valituille origineille. Esimerkiksi:

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

Tämä tarkoittaa, että kamera ja mikrofoni on poistettu käytöstä dokumentilta ja sen sisäkkäisiltä selauskonteksteilta, kun taas geolokaatio on sallittu vain samalle originille.

Sallivampi esimerkki:

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

Tämä sallii oman originisi ja yhden nimetyn karttapalveluntarjoajan käyttää geolokaatiota, ja oman originisi sekä videopalveluntarjoajan pyytää koko näytön tilaa.

Selain arvioi käytännön. Jos ominaisuus on kielletty, kyseistä API:a käyttävän JavaScriptin pitäisi epäonnistua tai käyttäytyä niin kuin ominaisuus ei olisi saatavilla. Tarkka epäonnistumistapa riippuu API:sta. Joskus promise hylätään. Joskus kyvykkyys ei yksinkertaisesti näytä olevan käytettävissä.

Mitä se voi lukita omilla sivuillasi

Ensimmäisen osapuolen sivuilla Permissions-Policy on hyödyllisimmillään suojakaiteena. Se pienentää vahingossa tai odottamatta mukaan tulevan koodin vaikutusalaa.

Markkinointisivu ei esimerkiksi todennäköisesti tarvitse mikrofonia, kameraa, Bluetoothia, USB:tä, liikeantureita tai maksu-API:ja. Voit kieltää nämä ominaisuudet yleisesti:

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

Tämä ei tee kaikista sivun skripteistä luotettavia. Se tarkoittaa, että jos taginhallinnan kokeilu, vaarantunut riippuvuus tai liitetty widget yrittää kutsua rajoitettua API:a, selaimen ei pitäisi myöntää sille pääsyä.

Tiimeille, joissa on paljon osallistujia, tämä on hyödyllinen oletus. Se siirtää keskustelun epämääräisestä luottamuksesta eksplisiittisiin kyvykkyyksiin. Jos tuleva ominaisuus todella tarvitsee kameraa, jonkun on muutettava käytäntöä ja selitettävä miksi.

Se on oikeanlaista kitkaa.

Mitä se voi lukita iframe-kehyksissä

Otsakkeesta tulee erityisen hyödyllinen upotetun sisällön yhteydessä.

Selaimet käsittelevät iframe-kehyksiä jo erillisinä selauskonteksteina, mutta upotettu kolmannen osapuolen sisältö voi silti pyytää tehokkaita ominaisuuksia, jos käytäntö ja iframe-attribuutit sen sallivat. Permissions-Policy antaa yläsivulle mahdollisuuden asettaa ylärajan.

Jos sivusi esimerkiksi upottaa videosoittimen, tukiwidgetin ja kartan, sinun ei tarvitse antaa jokaiselle kehykselle pääsyä jokaiseen ominaisuuteen. Voit sallia koko näytön tilan vain videokehykselle ja geolokaation vain karttakehykselle.

On ymmärrettävä kaksi kerrosta:

1. HTTP Permissions-Policy -otsake asettaa käytännön dokumentille.
2. iframe-kehyksen allow-attribuutti voi delegoida tiettyjä ominaisuuksia kehykseen, mutta vain sen rajoissa, mitä ylätason käytäntö sallii.

Yksinkertainen iframe voisi näyttää tältä:

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

Jos otsakkeesi kieltää koko näytön tilan kokonaan, iframe-attribuutti ei voi ohittaa tätä kieltoa. Jos otsakkeesi sallii koko näytön tilan kyseiselle originille, iframe-attribuutti voi delegoida sen.

Tämä hierarkia on yksi syy siihen, miksi otsaketta kannattaa käyttää. Se antaa alusta- tai tietoturvatiimeille tavan asettaa sivustonlaajuisia rajoja, mutta sallii silti tuotetiimien ottaa tietyt upotukset käyttöön siellä missä niitä tarvitaan.

Mitä se ei voi lukita

Tässä tiimit joskus yliarvioivat otsakkeen.

Permissions-Policy ei korvaa Content Security Policyä. Se ei päätä, mitkä skriptit saavat latautua. Se ei estä skriptiä lähettämästä dataa verkon yli. Se ei puhdista HTML:ää. Se ei estä XSS:ää. Se ei estä lomakespämmiä. Jos ongelmana on lomakkeiden väärinkäyttö, aloita mekanismeista, jotka on kuvattu artikkelissa miksi yhteydenottolomakkeesi on suurin spämmiriskisi, älä tästä otsakkeesta.

Se ei myöskään korvaa evästeiden hallintaa. Evästeet, local storage, suostumus, kolmannen osapuolen upotukset ja selainten seurantasuojaus ovat erillisiä asioita. Jos tarkastelet yksityisyyskontrolleja laajemmin, evästekenttä ansaitsee oman läpikäyntinsä; käytännön muutokset käsitellään artikkelissa mikä muuttui evästeissä vuonna 2026 ja mitä sille kannattaa tehdä.

Tärkeintä on, että Permissions-Policy ei tee kolmannen osapuolen JavaScriptistä yksityistä. Jos lataat kolmannen osapuolen skriptin ensimmäisen osapuolen sivullesi, se toimii yleensä sivusi oikeuksilla muiden selainrajoitteiden ja tietoturvaotsakkeidesi puitteissa. Kameran käytön kieltäminen on hyvä asia. Se ei estä kyseistä skriptiä lukemasta DOM-sisältöä, seuraamasta käyttäjän toimia tai tekemästä sallittuja verkkopyyntöjä.

Tätä varten tarvitset muita kontrolleja: huolellista toimittajavalintaa, CSP:tä, sandboxattuja iframe-kehyksiä, Subresource Integrityä soveltuvissa kohdissa, datan minimointia sekä tylsiä mutta välttämättömiä katselmointeja.

Järkevä oletuskäytäntö

Ei ole olemassa yleispätevää otsaketta, joka sopii jokaiselle sivustolle, mutta useimmat sisältö- ja markkinointisivustot voivat aloittaa rajoittavasti.

Kohtuullinen ensimmäinen versio:

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

Lisää sitten takaisin vain se, mitä sivusto todella käyttää.

Esimerkiksi:

• Kauppa, joka käyttää Payment Request API:a, voi tarvita payment=(self).
• Sijaintihakutoiminto voi tarvita geolocation=(self) tai luotetun kartta-originin.
• Neuvottelusovellus voi tarvita camera=(self) ja microphone=(self).
• Videopainotteinen sivusto voi tarvita fullscreen=(self "https://trusted-video.example").

Tärkeintä ei ole kopioida valtavaa käytäntöä tarkistuslistasta ja todeta työtä valmiiksi. Aloita ominaisuusinventaarista. Mitkä sivut tarvitsevat mitäkin selainkyvykkyyksiä? Mitkä upotukset tarvitsevat delegointia? Mitkä ominaisuudet olisivat yllättäviä, jos niitä pyydettäisiin?

Miten ottaa käyttöön rikkomatta asioita

Ota tämä käyttöön kuten mikä tahansa muu tuotanto-otsake: harkitusti.

1. Inventoi ominaisuuksien käyttö

Etsi koodikannastasi selain-API-kutsuja, kuten getUserMedia, geolocation, requestFullscreen, PaymentRequest, Web Bluetooth, WebUSB ja wake lock -API:t.

Tarkista sitten kolmannen osapuolen upotukset. Video-, kartta-, maksu- ja identiteettipalveluntarjoajien dokumentaatio mainitsee usein vaaditut iframe-kehyksen allow-arvot.

2. Aloita vähäriskisessä ympäristössä

Lisää rajoittava otsake staging-ympäristöön ja testaa keskeiset käyttäjäpolut. Kiinnitä huomiota selaimen konsoliviesteihin. Selaimet raportoivat usein, kun ominaisuus estetään permissions policy -käytännöllä.

3. Käytä tarvittaessa sivukohtaisia käytäntöjä

Älä pakota yhtä globaalia käytäntöä, jos tuotteessasi on hyvin erilaisia sivutyyppejä. Blogi, kassasivu, karttasivu ja videohuone tarvitsevat todennäköisesti eri kyvykkyyksiä.

Useimmat verkkopalvelimet, sovelluskehykset ja edge-alustat voivat asettaa otsakkeita ehdollisesti polun perusteella. Se on usein siistimpää kuin koko sivuston heikentäminen yhden ominaisuuden vuoksi.

4. Varmista todellinen vastaus

CDN:t, reverse proxyt, sovelluspalvelimet ja middleware voivat lisätä, ylikirjoittaa, kahdentaa tai poistaa otsakkeita. Tarkista lopullinen vastaus selaimen DevToolsissa tai komentorivityökaluilla.

Testaa myös upotetut kontekstit. Se, että ylätason sivu näyttää oikealta, ei takaa että iframe sai tarkoittamasi delegoinnin.

5. Dokumentoi poikkeukset

Jokaisella sallitulla ominaisuudella pitäisi olla omistaja ja syy. Tämä kuulostaa byrokraattiselta siihen asti, kunnes kuuden kuukauden päästä kukaan ei muista, miksi geolocation avattiin toimittajan domainille, jota ei enää näy sivulla.

Yleiset syntaksivirheet

Moderni otsakesyntaksi on tiivis, mutta siinä on helppo mennä hieman pieleen.

Käytä tyhjiä sulkeita ominaisuuden kieltämiseen:

Permissions-Policy: microphone=()

Käytä self nykyiselle originille:

Permissions-Policy: geolocation=(self)

Käytä lainausmerkeissä olevia origineja tietyille ulkoisille origineille:

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

Vältä tukeutumista vanhoihin Feature-Policy-esimerkkeihin, ellet tarkoituksella tue legacy-käyttäytymistä. Vanhempi otsake käytti eri syntaksia, eikä sen ympärille kannata enää suunnitella.

Muista myös, että selaintuki vaihtelee direktiivikohtaisesti. Selain voi tukea otsaketta mutta ei tiettyä ominaisuusdirektiiviä. Se on normaalia. Käsittele otsaketta defense-in-depth-toimenpiteenä, älä ainoana yksityisyys- tai tietoturvakontrollinasi.

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

💡 Kokeile tätä: Varmista Get Headers-työkalulla, että Permissions-Policy toimitetaan tarkoitetulla tavalla, sillä se näyttää palvelimesi lähettämät raakamuotoiset vastausotsakkeet.

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

Käytännön yksityisyysarvo

Permissions-Policy-otsakkeen yksityisyysarvo ei ole siinä, että se tekisi sivustosta anonyymin tai seurannasta vapaan. Se ei tee niin.

Sen arvo on siinä, että se kaventaa pääsyä arkaluonteisiin selainkyvykkyyksiin. Sijainti, kamera, mikrofoni, laitteen anturit, paikallisen laitteiston API:t ja maksupolut ovat voimakkaita. Useimmat sivut eivät tarvitse niitä. Monien upotettujen komponenttien ei pitäisi koskaan voida edes pyytää niitä.

Se on todellinen parannus. Se vähentää tahattomia lupakehotteita, rajoittaa tarpeetonta kyvykkyyksien paljastumista ja antaa tiimillesi konkreettisen artefaktin tarkistettavaksi, kun uusia toiminnallisuuksia julkaistaan.

Paras versio tästä otsakkeesta on tylsä: oletuksena rajoittava, löysennetty vain siellä missä käyttäjälle näkyvä ominaisuus sitä vaatii, ja testattu osana normaalia julkaisuprosessia.