Hvad Permissions-Policy-headeren faktisk kan låse ned for

Den korte version

Permissions-Policy er en HTTP-svarheader, der lader et site begrænse adgangen til visse browserfunktioner: kamera, mikrofon, geolokation, fullscreen, betaling, sensorer og en lang liste af mindre API'er.

Den er ikke et generelt privatlivsskjold. Den stopper ikke al sporing, blokerer ikke cookies, forhindrer ikke netværksanmodninger og gør ikke tredjeparts-JavaScript sikkert. Det, den kan gøre godt, er mere snævert og stadig værdifuldt: reducere de browserfunktioner, der er tilgængelige for dine egne sider og for indlejrede frames.

Det betyder noget, fordi moderne websites er sat sammen af analytics-snippets, medieindlejringer, chat-widgets, consent managers, annoncescripts, kort, betalingsflows og interne eksperimenter. De fleste af disse komponenter har ikke brug for adgang til kraftfulde device-API'er. En god policy gør det eksplicit.

Hvis du allerede gennemgår headers i produktion, så kombiner dette arbejde med et direkte tjek af det faktiske svar. Vores guide til fejlfinding af redirects og HTTP-headers i produktion dækker den vane, der betyder noget her: inspicér, hvad browseren faktisk modtager, ikke hvad din konfigurationsfil siger, der burde ske.

Hvad Permissions-Policy kontrollerer

Headeren kontrollerer adgangen til navngivne browserfunktioner. Den præcise liste ændrer sig over tid, fordi browser-API'er ændrer sig, men almindelige 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 ældre diskussioner, nu mest historisk

Et direktiv kan tillade en funktion for ingen, for den aktuelle origin eller for udvalgte origins. For eksempel:

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

Det betyder, at kamera og mikrofon er deaktiveret for dokumentet og dets indlejrede browsing contexts, mens geolokation kun er tilladt for samme origin.

Et mere tilladende eksempel:

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

Dette tillader din egen origin og én navngiven kortudbyder at bruge geolokation, og din egen origin plus en videoudbyder at anmode om fullscreen.

Policyen evalueres af browseren. Hvis en funktion ikke er tilladt, bør JavaScript, der bruger det API, fejle eller opføre sig, som om funktionen ikke er tilgængelig. Den præcise fejltilstand afhænger af API'et. Nogle gange afvises et promise. Nogle gange fremstår en capability blot som ikke brugbar.

Hvad den kan låse ned for på dine egne sider

På førstepartssider er Permissions-Policy mest nyttig som et værn. Den reducerer konsekvensområdet for utilsigtet eller uventet kode.

En marketingside har for eksempel sandsynligvis ikke brug for mikrofon, kamera, Bluetooth, USB, bevægelsessensorer eller betalings-API'er. Du kan afvise disse funktioner globalt:

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

Det gør ikke alle scripts på siden troværdige. Det betyder, at hvis et tag manager-eksperiment, en kompromitteret dependency eller en indsat widget forsøger at kalde et begrænset API, bør browseren ikke give adgang.

For teams med mange bidragydere er dette en nyttig standard. Det flytter samtalen fra vag tillid til eksplicit capability. Hvis en fremtidig funktion reelt har brug for kameraet, skal nogen ændre policyen og forklare hvorfor.

Det er den rigtige slags friktion.

Hvad den kan låse ned for i iframes

Headeren bliver især nyttig omkring indlejret indhold.

Browsere behandler allerede iframes som separate browsing contexts, men indlejret tredjepartsindhold kan stadig anmode om kraftfulde funktioner, hvis det er tilladt af policy og iframe-attributter. Permissions-Policy lader forældresiden sætte et loft.

Hvis din side for eksempel indlejrer en videoafspiller, en support-widget og et kort, kan du undgå at give alle frames adgang til alle funktioner. Du kan tillade fullscreen kun for videoframen og geolokation kun for kortframen.

Der er to lag at forstå:

1. HTTP-headeren Permissions-Policy sætter policy for dokumentet.
2. Iframe-attributten allow kan delegere specifikke funktioner til en frame, men kun inden for det, som forælderpolicyen tillader.

En simpel iframe kan se sådan ud:

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

Hvis din header afviser fullscreen helt, kan iframe-attributten ikke tilsidesætte den afvisning. Hvis din header tillader fullscreen for den origin, kan iframe-attributten delegere den.

Dette hierarki er én grund til, at headeren er værd at bruge. Den giver platform- eller sikkerhedsteams en måde at sætte grænser for hele sitet, samtidig med at produktteams stadig kan aktivere specifikke indlejringer, hvor det er nødvendigt.

Hvad den ikke kan låse ned for

Det er her, teams nogle gange overvurderer headeren.

Permissions-Policy erstatter ikke en content security policy. Den afgør ikke, hvilke scripts der må indlæses. Den stopper ikke et script fra at sende data over netværket. Den saniterer ikke HTML. Den forhindrer ikke XSS. Den blokerer ikke form-spam. Hvis misbrug af formularer er problemet, så begynd med mekanismerne beskrevet i hvorfor din kontaktformular er din største spamrisiko, ikke med denne header.

Den erstatter heller ikke cookie-governance. Cookies, local storage, consent, tredjepartsindlejringer og browseres sporingsbeskyttelse er separate emner. Hvis du gennemgår privatlivskontroller bredt, fortjener cookie-landskabet sin egen gennemgang; de praktiske ændringer er dækket i hvad der ændrede sig for cookies i 2026, og hvad du skal gøre ved det.

Vigtigst af alt gør Permissions-Policy ikke tredjeparts-JavaScript privat. Hvis du indlæser et tredjepartsscript på din førstepartsside, kører det som regel med din sides privilegier, underlagt andre browserbegrænsninger og dine sikkerhedsheaders. Det er godt at afvise kameraadgang. Det stopper ikke scriptet fra at læse DOM-indhold, observere brugerhandlinger eller lave tilladte netværksanmodninger.

Til det har du brug for andre kontroller: omhyggelig leverandørudvælgelse, CSP, sandboxed iframes, Subresource Integrity hvor det er relevant, dataminimering og kedelige, men nødvendige gennemgange.

En fornuftig standardpolicy

Der findes ingen universel header, der passer til alle sites, men de fleste indholds- og marketingsites kan starte restriktivt.

Et rimeligt første bud:

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

Tilføj derefter kun det igen, som sitet faktisk bruger.

For eksempel:

• En butik, der bruger Payment Request API, kan have brug for payment=(self).
• En lokationsfinder kan have brug for geolocation=(self) eller en betroet kort-origin.
• En konferenceapp kan have brug for camera=(self) og microphone=(self).
• Et videotungt site kan have brug for fullscreen=(self "https://trusted-video.example").

Det vigtige er ikke at kopiere en enorm policy fra en tjekliste og kalde arbejdet færdigt. Start med din funktionsoversigt. Hvilke sider har brug for hvilke browser-capabilities? Hvilke indlejringer har brug for delegering? Hvilke funktioner ville være overraskende, hvis de blev anmodet om?

Sådan implementerer du uden at ødelægge noget

Rul dette ud som enhver anden produktionsheader: bevidst.

1. Kortlæg brugen af funktioner

Søg i din kodebase efter browser-API-kald som getUserMedia, geolocation, requestFullscreen, PaymentRequest, Web Bluetooth, WebUSB og wake lock-API'er.

Tjek derefter tredjepartsindlejringer. Dokumentation for video-, kort-, betalings- og identitetsudbydere nævner ofte påkrævede iframe-allow-værdier.

2. Start i et miljø med lav risiko

Tilføj en restriktiv header i staging, og test de centrale brugerrejser. Hold øje med beskeder i browserkonsollen. Browsere rapporterer ofte, når en funktion blokeres af permissions policy.

3. Brug sidespecifikke policies, hvor det er nødvendigt

Tving ikke én global policy igennem, hvis dit produkt har meget forskellige sidetyper. En blog, checkout, kortside og videorum har sandsynligvis brug for forskellige capabilities.

De fleste webservere, frameworks og edge-platforme kan sætte headers betinget efter path. Det er ofte renere end at svække hele sitet for én funktion.

4. Verificér det reelle svar

Headers kan tilføjes, overskrives, duplikeres eller fjernes af CDNs, reverse proxies, appservere og middleware. Tjek det endelige svar i browserens DevTools eller med kommandolinjeværktøjer.

Test også indlejrede contexts. At en top-level side ser korrekt ud, garanterer ikke, at en iframe modtog den delegering, du havde tænkt dig.

5. Dokumentér undtagelser

Alle tilladte funktioner bør have en ejer og en begrundelse. Det lyder bureaukratisk indtil seks måneder senere, hvor ingen kan huske, hvorfor geolocation blev åbnet for et leverandørdomæne, der ikke længere optræder på siden.

Almindelige syntaksfejl

Den moderne header-syntaks er kompakt, men let at få en smule forkert.

Brug tomme parenteser til at afvise en funktion:

Permissions-Policy: microphone=()

Brug self for den aktuelle origin:

Permissions-Policy: geolocation=(self)

Brug origins i anførselstegn for specifikke eksterne origins:

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

Undgå at basere dig på gamle Feature-Policy-eksempler, medmindre du bevidst understøtter legacy-adfærd. Den ældre header brugte en anden syntaks og er ikke det, du bør designe efter i dag.

Husk også, at browserunderstøttelse varierer efter direktiv. En browser kan understøtte headeren, men ikke et bestemt funktionsdirektiv. Det er normalt. Betragt headeren som et defense-in-depth-tiltag, ikke som din eneste privatlivs- eller sikkerhedskontrol.

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

💡 Prøv dette: Bekræft, at din Permissions-Policy leveres som tilsigtet med Get Headers, som viser de rå svarheaders, din server sender.

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

Den praktiske privatlivsværdi

Privatlivsværdien af Permissions-Policy er ikke, at den gør et site anonymt eller fri for trackere. Det gør den ikke.

Dens værdi er, at den indsnævrer adgangen til følsomme browser-capabilities. Lokation, kamera, mikrofon, device-sensorer, lokale hardware-API'er og betalingsflows er kraftfulde. De fleste sider har ikke brug for dem. Mange indlejrede komponenter bør aldrig kunne bede om dem.

Det er en reel forbedring. Det reducerer utilsigtede prompts, begrænser unødvendig eksponering af capabilities og giver dit team en konkret artefakt at gennemgå, når ny funktionalitet releases.

Den bedste version af denne header er kedelig: restriktiv som standard, kun løsnet hvor en brugerrettet funktion kræver det, og testet som en del af den normale releaseproces.