Vad Permissions-Policy-headern faktiskt kan låsa ned

Den korta versionen

Permissions-Policy är en HTTP-svarheader som låter en webbplats begränsa åtkomsten till vissa webbläsarfunktioner: kamera, mikrofon, geolokalisering, fullscreen, betalning, sensorer och en lång lista med mindre API:er.

Den är inte ett generellt integritetsskydd. Den stoppar inte all spårning, blockerar inte cookies, förhindrar inte nätverksförfrågningar och gör inte tredjeparts-JavaScript säkert. Det den kan göra väl är snävare men fortfarande värdefullt: minska de webbläsarförmågor som är tillgängliga för dina egna sidor och för inbäddade frames.

Det spelar roll eftersom moderna webbplatser sys ihop av analys-snippets, mediainbäddningar, chattwidgets, samtyckeshanterare, annonsskript, kartor, betalningsflöden och interna experiment. De flesta av dessa komponenter behöver inte åtkomst till kraftfulla enhets-API:er. En bra policy gör det explicit.

Om du redan granskar headers i produktion, kombinera detta arbete med en direkt kontroll av det faktiska svaret. Vår guide till felsökning av omdirigeringar och HTTP-headers i produktion täcker den vana som är viktig här: kontrollera vad webbläsaren faktiskt tar emot, inte vad din konfigurationsfil säger ska hända.

Vad Permissions-Policy styr

Headern styr åtkomst till namngivna webbläsarfunktioner. Den exakta listan förändras över tid eftersom webbläsar-API:er förändras, men vanliga direktiv är bland annat:

• 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 historiskt

Ett direktiv kan tillåta en funktion för ingen, för aktuell origin eller för utvalda origins. Till exempel:

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

Det betyder att kamera och mikrofon är inaktiverade för dokumentet och dess nästlade browsing contexts, medan geolokalisering endast tillåts för samma origin.

Ett mer tillåtande exempel:

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

Detta tillåter din egen origin och en namngiven kartleverantör att använda geolokalisering, och din egen origin plus en videoleverantör att begära fullscreen.

Policyn utvärderas av webbläsaren. Om en funktion inte tillåts ska JavaScript som använder det API:et misslyckas eller bete sig som om funktionen inte är tillgänglig. Det exakta felläget beror på API:et. Ibland avvisas ett promise. Ibland framstår en förmåga helt enkelt som oanvändbar.

Vad den kan låsa ned på dina egna sidor

På förstapartssidor är Permissions-Policy mest användbar som skyddsräcke. Den minskar spridningseffekten av oavsiktlig eller oväntad kod.

En marknadssida behöver till exempel sannolikt inte mikrofon, kamera, Bluetooth, USB, rörelsesensorer eller betalnings-API:er. Du kan neka dessa funktioner globalt:

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

Det gör inte varje skript på sidan pålitligt. Det betyder däremot att om ett tag manager-experiment, ett komprometterat beroende eller en inklistrad widget försöker anropa ett begränsat API, bör webbläsaren inte ge det åtkomst.

För team med många bidragsgivare är detta en användbar standard. Det flyttar samtalet från vag tillit till explicit förmåga. Om en framtida funktion verkligen behöver kameran måste någon ändra policyn och förklara varför.

Det är rätt sorts friktion.

Vad den kan låsa ned i iframes

Headern blir särskilt användbar kring inbäddat innehåll.

Webbläsare behandlar redan iframes som separata browsing contexts, men inbäddat tredjepartsinnehåll kan fortfarande begära kraftfulla funktioner om det tillåts av policy och iframe-attribut. Permissions-Policy låter den överordnade sidan sätta ett tak.

Om din sida till exempel bäddar in en videospelare, en supportwidget och en karta kan du undvika att ge varje frame åtkomst till varje funktion. Du kan tillåta fullscreen endast för videoframen och geolokalisering endast för kartframen.

Det finns två lager att förstå:

1. HTTP-headern Permissions-Policy sätter policy för dokumentet.
2. Iframe-attributet allow kan delegera specifika funktioner till en frame, men endast inom det som den överordnade policyn tillåter.

En enkel iframe kan se ut så här:

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

Om din header nekar fullscreen helt kan iframe-attributet inte åsidosätta det nekandet. Om din header tillåter fullscreen för den origin kan iframe-attributet delegera den.

Den här hierarkin är en anledning till att headern är värd att använda. Den ger plattforms- eller säkerhetsteam ett sätt att sätta webbplatsomfattande gränser, samtidigt som produktteam fortfarande kan aktivera specifika inbäddningar där det behövs.

Vad den inte kan låsa ned

Det är här team ibland överskattar headern.

Permissions-Policy ersätter inte en content security policy. Den avgör inte vilka skript som får laddas. Den stoppar inte ett skript från att skicka data över nätverket. Den sanerar inte HTML. Den förhindrar inte XSS. Den blockerar inte formulärspam. Om formulärmissbruk är problemet, börja med mekaniken som beskrivs i varför ditt kontaktformulär är din största spamrisk, inte med den här headern.

Den ersätter inte heller cookie-styrning. Cookies, local storage, samtycke, tredjepartsinbäddningar och webbläsarnas spårningsskydd är separata frågor. Om du granskar integritetskontroller brett förtjänar cookie-landskapet en egen genomgång; de praktiska förändringarna beskrivs i vad som förändrades för cookies 2026 och vad du ska göra åt det.

Viktigast av allt: Permissions-Policy gör inte tredjeparts-JavaScript privat. Om du laddar ett tredjepartsskript på din förstapartssida körs det i allmänhet med din sidas behörigheter, med förbehåll för andra webbläsarbegränsningar och dina säkerhetsheaders. Att neka kameraåtkomst är bra. Det stoppar inte skriptet från att läsa DOM-innehåll, observera användaråtgärder eller göra tillåtna nätverksförfrågningar.

För det behöver du andra kontroller: noggrant leverantörsval, CSP, sandboxade iframes, Subresource Integrity där det är tillämpligt, dataminimering och tråkiga men nödvändiga granskningar.

En rimlig standardpolicy

Det finns ingen universell header som passar alla webbplatser, men de flesta innehålls- och marknadssajter kan börja restriktivt.

Ett rimligt första steg:

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

Lägg sedan bara tillbaka det som webbplatsen faktiskt använder.

Till exempel:

• En butik som använder Payment Request API kan behöva payment=(self).
• En platssökare kan behöva geolocation=(self) eller en betrodd kart-origin.
• En konferensapp kan behöva camera=(self) och microphone=(self).
• En videotung webbplats kan behöva fullscreen=(self "https://trusted-video.example").

Det viktiga är att inte kopiera en enorm policy från en checklista och kalla det klart. Börja med din funktionsinventering. Vilka sidor behöver vilka webbläsarförmågor? Vilka inbäddningar behöver delegering? Vilka funktioner skulle vara överraskande om de begärdes?

Så inför du den utan att förstöra saker

Rulla ut detta som vilken annan produktionsheader som helst: med avsikt.

1. Inventera funktionsanvändning

Sök i din kodbas efter anrop till webbläsar-API:er som getUserMedia, geolocation, requestFullscreen, PaymentRequest, Web Bluetooth, WebUSB och wake lock-API:er.

Kontrollera sedan tredjepartsinbäddningar. Dokumentation för video-, kart-, betalnings- och identitetsleverantörer nämner ofta nödvändiga iframe-värden för allow.

2. Börja i en miljö med låg risk

Lägg till en restriktiv header i staging och testa centrala användarflöden. Var uppmärksam på meddelanden i webbläsarkonsolen. Webbläsare rapporterar ofta när en funktion blockeras av permissions policy.

3. Använd sidspecifika policies där det behövs

Tvinga inte fram en enda global policy om din produkt har mycket olika sidtyper. En blogg, kassa, kartsida och videorum behöver sannolikt olika förmågor.

De flesta webbservrar, ramverk och edge-plattformar kan sätta headers villkorligt per sökväg. Det är ofta renare än att försvaga hela webbplatsen för en enda funktion.

4. Verifiera det verkliga svaret

Headers kan läggas till, skrivas över, dupliceras eller tas bort av CDN:er, reverse proxies, appservrar och middleware. Kontrollera det slutliga svaret i webbläsarens DevTools eller med kommandoradsverktyg.

Testa också inbäddade contexts. Att en toppnivåsida ser korrekt ut garanterar inte att en iframe fick den delegering du avsåg.

5. Dokumentera undantag

Varje tillåten funktion bör ha en ägare och en anledning. Det låter byråkratiskt tills sex månader senare, när ingen minns varför geolocation öppnades för en leverantörsdomän som inte längre verkar finnas på sidan.

Vanliga syntaxmisstag

Den moderna headersyntaxen är kompakt men lätt att få lite fel.

Använd tomma parenteser för att neka en funktion:

Permissions-Policy: microphone=()

Använd self för aktuell origin:

Permissions-Policy: geolocation=(self)

Använd citerade origins för specifika externa origins:

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

Undvik att förlita dig på gamla Feature-Policy-exempel om du inte avsiktligt stöder äldre beteende. Den äldre headern använde en annan syntax och är inte vad du bör utgå från i dag.

Kom också ihåg att webbläsarstöd varierar per direktiv. En webbläsare kan stödja headern men inte ett visst funktionsdirektiv. Det är normalt. Behandla headern som en defense-in-depth-åtgärd, inte som din enda integritets- eller säkerhetskontroll.

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

💡 Prova detta: Kontrollera att din Permissions-Policy levereras som avsett med Get Headers, som visar de råa svarshuvuden som din server skickar.

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

Det praktiska integritetsvärdet

Integritetsvärdet i Permissions-Policy är inte att den gör en webbplats anonym eller fri från spårare. Det gör den inte.

Värdet är att den begränsar åtkomsten till känsliga webbläsarförmågor. Plats, kamera, mikrofon, enhetssensorer, lokala hårdvaru-API:er och betalningsflöden är kraftfulla. De flesta sidor behöver dem inte. Många inbäddade komponenter bör aldrig kunna be om dem.

Det är en verklig förbättring. Det minskar oavsiktliga prompts, begränsar onödig exponering av förmågor och ger ditt team en konkret artefakt att granska när ny funktionalitet släpps.

Den bästa versionen av den här headern är tråkig: restriktiv som standard, uppluckrad endast där en användarvänd funktion kräver det, och testad som en del av den normala releaseprocessen.