Hva Permissions-Policy-headeren faktisk kan låse ned

Kortversjonen

Permissions-Policy er en HTTP-responsheader som lar et nettsted begrense tilgang til bestemte nettleserfunksjoner: kamera, mikrofon, geolokasjon, fullskjerm, betaling, sensorer og en lang liste med mindre API-er.

Den er ikke et generelt personvernskjold. Den stopper ikke all sporing, blokkerer ikke cookies, hindrer ikke nettverksforespørsler og gjør ikke tredjeparts JavaScript trygt. Det den kan gjøre godt, er smalere og fortsatt verdifullt: redusere nettleserkapasitetene som er tilgjengelige for dine egne sider og for innebygde rammer.

Det betyr noe fordi moderne nettsteder er satt sammen av analysesnutter, medieinnbygginger, chat-widgets, samtykkebehandlere, annonseringsskript, kart, betalingsflyter og interne eksperimenter. De fleste av disse komponentene trenger ikke tilgang til kraftige enhets-API-er. En god policy gjør dette eksplisitt.

Hvis du allerede gjennomgår headere i produksjon, bør du kombinere dette arbeidet med en direkte kontroll av den faktiske responsen. Vår veiledning til feilsøking av redirects og HTTP-headere i produksjon dekker vanen som er viktig her: inspiser hva nettleseren faktisk mottar, ikke hva konfigurasjonsfilen din sier at skal skje.

Hva Permissions-Policy kontrollerer

Headeren kontrollerer tilgang til navngitte nettleserfunksjoner. Den eksakte listen endres over tid fordi nettleser-API-er endres, men vanlige direktiver omfatter:

• camera
• microphone
• geolocation
• fullscreen
• payment
• usb
• bluetooth
• accelerometer
• gyroscope
• magnetometer
• screen-wake-lock
• clipboard-read
• clipboard-write
• publickey-credentials-get
• interest-cohort i eldre diskusjoner, nå stort sett historisk

Et direktiv kan tillate en funksjon for ingen, for gjeldende opphav eller for utvalgte opphav. For eksempel:

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

Dette betyr at kamera og mikrofon er deaktivert for dokumentet og dets nestede nettleserkontekster, mens geolokasjon bare er tillatt for samme opphav.

Et mer tillatende eksempel:

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

Dette lar ditt eget opphav og én navngitt kartleverandør bruke geolokasjon, og ditt eget opphav pluss en videoleverandør be om fullskjerm.

Policyen evalueres av nettleseren. Hvis en funksjon ikke er tillatt, skal JavaScript som bruker det API-et feile eller oppføre seg som om funksjonen er utilgjengelig. Den eksakte feilmodusen avhenger av API-et. Noen ganger avvises et promise. Andre ganger fremstår en kapasitet ganske enkelt som ikke brukbar.

Hva den kan låse ned på dine egne sider

På førstepartssider er Permissions-Policy mest nyttig som et rekkverk. Den reduserer skadeomfanget fra utilsiktet eller uventet kode.

En markedsføringsside trenger for eksempel sannsynligvis ikke mikrofon, kamera, Bluetooth, USB, bevegelsessensorer eller betalings-API-er. Du kan nekte disse funksjonene globalt:

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

Det gjør ikke alle skript på siden pålitelige. Det betyr at hvis et tag manager-eksperiment, en kompromittert avhengighet eller en innlimt widget prøver å kalle et begrenset API, bør nettleseren ikke gi den tilgang.

For team med mange bidragsytere er dette en nyttig standard. Det flytter samtalen fra vag tillit til eksplisitt kapasitet. Hvis en fremtidig funksjon faktisk trenger kameraet, må noen endre policyen og forklare hvorfor.

Det er riktig type friksjon.

Hva den kan låse ned i iframes

Headeren blir særlig nyttig rundt innebygd innhold.

Nettlesere behandler allerede iframes som separate nettleserkontekster, men innebygd tredjepartsinnhold kan fortsatt be om kraftige funksjoner hvis det er tillatt av policy og iframe-attributter. Permissions-Policy lar foreldresiden sette et tak.

Hvis siden din for eksempel bygger inn en videospiller, en support-widget og et kart, kan du unngå å gi hver ramme tilgang til alle funksjoner. Du kan tillate fullskjerm bare for videorammen og geolokasjon bare for kartrammen.

Det er to lag å forstå:

1. HTTP-headeren Permissions-Policy setter policy for dokumentet.
2. iframe-attributtet allow kan delegere bestemte funksjoner til en ramme, men bare innenfor det foreldrepolicyen tillater.

En enkel iframe kan se slik ut:

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

Hvis headeren din nekter fullskjerm fullstendig, kan ikke iframe-attributtet overstyre det avslaget. Hvis headeren din tillater fullskjerm for det opphavet, kan iframe-attributtet delegere den.

Dette hierarkiet er én grunn til at headeren er verdt å bruke. Den gir plattform- eller sikkerhetsteam en måte å sette grenser for hele nettstedet på, samtidig som produktteam fortsatt kan aktivere bestemte innbygginger der det trengs.

Hva den ikke kan låse ned

Det er her team noen ganger overvurderer headeren.

Permissions-Policy erstatter ikke en content security policy. Den avgjør ikke hvilke skript som kan lastes. Den stopper ikke et skript fra å sende data over nettverket. Den sanerer ikke HTML. Den hindrer ikke XSS. Den blokkerer ikke skjemasøppel. Hvis skjemamisbruk er problemet, bør du starte med mekanismene beskrevet i hvorfor kontaktskjemaet ditt er din største spamrisiko, ikke med denne headeren.

Den erstatter heller ikke cookie-styring. Cookies, local storage, samtykke, tredjepartsinnbygginger og nettlesernes sporingsbeskyttelse er separate temaer. Hvis du gjennomgår personvernkontroller bredt, fortjener cookie-landskapet en egen runde; de praktiske endringene er dekket i hva som endret seg for cookies i 2026, og hva du bør gjøre med det.

Viktigst av alt: Permissions-Policy gjør ikke tredjeparts JavaScript privat. Hvis du laster et tredjepartsskript inn på førstepartssiden din, kjører det vanligvis med sidens privilegier, underlagt andre nettleserbegrensninger og sikkerhetsheaderne dine. Å nekte kameratilgang er bra. Det stopper ikke skriptet fra å lese DOM-innhold, observere brukerhandlinger eller sende tillatte nettverksforespørsler.

Til det trenger du andre kontroller: nøye leverandørvalg, CSP, sandboxed iframes, Subresource Integrity der det er relevant, dataminimering og kjedelige, men nødvendige, gjennomganger.

En fornuftig standardpolicy

Det finnes ingen universell header som passer alle nettsteder, men de fleste innholds- og markedsføringsnettsteder kan starte restriktivt.

Et rimelig første utkast:

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

Legg deretter bare tilbake det nettstedet faktisk bruker.

For eksempel:

• En butikk som bruker Payment Request API, kan trenge payment=(self).
• En lokasjonsfinner kan trenge geolocation=(self) eller et betrodd kartopphav.
• En konferanseapp kan trenge camera=(self) og microphone=(self).
• Et videotungt nettsted kan trenge fullscreen=(self "https://trusted-video.example").

Det viktige er ikke å kopiere en enorm policy fra en sjekkliste og anse seg ferdig. Start med funksjonsoversikten din. Hvilke sider trenger hvilke nettleserkapasiteter? Hvilke innbygginger trenger delegering? Hvilke funksjoner ville vært overraskende hvis de ble etterspurt?

Slik tar du den i bruk uten å ødelegge ting

Rull dette ut som enhver annen produksjonsheader: bevisst.

1. Kartlegg funksjonsbruk

Søk i kodebasen etter kall til nettleser-API-er som getUserMedia, geolocation, requestFullscreen, PaymentRequest, Web Bluetooth, WebUSB og wake lock-API-er.

Sjekk deretter tredjepartsinnbygginger. Dokumentasjon for video-, kart-, betalings- og identitetsleverandører nevner ofte nødvendige iframe-verdier for allow.

2. Start i et miljø med lav risiko

Legg til en restriktiv header i staging og test kjerneflyter. Følg med på meldinger i nettleserkonsollen. Nettlesere rapporterer ofte når en funksjon blokkeres av permissions policy.

3. Bruk sidespesifikke policyer der det er nødvendig

Ikke tving én global policy hvis produktet ditt har svært ulike sidetyper. En blogg, checkout, kartside og videorom trenger sannsynligvis ulike kapasiteter.

De fleste webservere, rammeverk og edge-plattformer kan sette headere betinget etter sti. Det er ofte ryddigere enn å svekke hele nettstedet for én funksjon.

4. Verifiser den reelle responsen

Headere kan legges til, overskrives, dupliseres eller fjernes av CDN-er, reverse proxies, applikasjonsservere og middleware. Sjekk den endelige responsen i nettleserens DevTools eller med kommandolinjeverktøy.

Test også innebygde kontekster. At en toppnivåside ser riktig ut, garanterer ikke at en iframe mottok delegeringen du hadde tenkt.

5. Dokumenter unntak

Hver tillatte funksjon bør ha en eier og en begrunnelse. Dette høres byråkratisk ut inntil seks måneder senere, når ingen husker hvorfor geolocation ble åpnet for et leverandørdomene som ikke lenger vises på siden.

Vanlige syntaksfeil

Den moderne headersyntaksen er kompakt, men lett å få litt feil.

Bruk tomme parenteser for å nekte en funksjon:

Permissions-Policy: microphone=()

Bruk self for gjeldende opphav:

Permissions-Policy: geolocation=(self)

Bruk opphav i anførselstegn for bestemte eksterne opphav:

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

Unngå å basere deg på gamle Feature-Policy-eksempler med mindre du bevisst støtter eldre atferd. Den eldre headeren brukte en annen syntaks og er ikke det du bør designe rundt i dag.

Husk også at nettleserstøtte varierer etter direktiv. En nettleser kan støtte headeren, men ikke et bestemt funksjonsdirektiv. Det er normalt. Behandle headeren som et tiltak for defense-in-depth, ikke som din eneste personvern- eller sikkerhetskontroll.

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

💡 Prøv dette: Kontroller at Permissions-Policy-en din leveres som tiltenkt med Get Headers, som viser de rå responsheaderne serveren din sender.

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

Den praktiske personvernverdien

Personvernverdien av Permissions-Policy er ikke at den gjør et nettsted anonymt eller fritt for sporere. Det gjør den ikke.

Verdien er at den snevrer inn tilgangen til sensitive nettleserkapasiteter. Plassering, kamera, mikrofon, enhetssensorer, lokale maskinvare-API-er og betalingsflyter er kraftige. De fleste sider trenger dem ikke. Mange innebygde komponenter bør aldri kunne be om dem.

Det er en reell forbedring. Det reduserer utilsiktede forespørsler, begrenser unødvendig eksponering av kapasiteter og gir teamet ditt et konkret artefakt å gjennomgå når ny funksjonalitet lanseres.

Den beste versjonen av denne headeren er kjedelig: restriktiv som standard, åpnet bare der en brukerrettet funksjon krever det, og testet som en del av den normale utgivelsesprosessen.