Co může hlavička Permissions-Policy skutečně uzamknout

Stručná verze

Permissions-Policy je hlavička HTTP odpovědi, která webu umožňuje omezit přístup k určitým funkcím prohlížeče: kameře, mikrofonu, geolokaci, režimu fullscreen, platbám, senzorům a dlouhému seznamu menších API.

Není to obecný štít pro ochranu soukromí. Nezastaví veškeré sledování, nezablokuje cookies, nezabrání síťovým požadavkům ani neudělá JavaScript třetích stran bezpečným. To, co umí dobře, je užší, ale stále cenné: omezit schopnosti prohlížeče dostupné vašim vlastním stránkám a vloženým rámcům.

To je důležité, protože moderní weby jsou poskládané z analytických snippetů, mediálních embedů, chatovacích widgetů, správců souhlasů, reklamních skriptů, map, platebních toků a interních experimentů. Většina těchto komponent nepotřebuje přístup k výkonným API zařízení. Dobrá policy to výslovně stanoví.

Pokud už kontrolujete hlavičky v produkci, spojte tuto práci s přímou kontrolou skutečné odpovědi. Náš průvodce laděním přesměrování a HTTP hlaviček v produkci popisuje návyk, který je zde podstatný: ověřujte, co prohlížeč skutečně obdrží, ne co by se podle konfiguračního souboru mělo stát.

Co Permissions-Policy řídí

Hlavička řídí přístup k pojmenovaným funkcím prohlížeče. Přesný seznam se v čase mění, protože se mění API prohlížečů, ale běžné direktivy zahrnují:

• camera
• microphone
• geolocation
• fullscreen
• payment
• usb
• bluetooth
• accelerometer
• gyroscope
• magnetometer
• screen-wake-lock
• clipboard-read
• clipboard-write
• publickey-credentials-get
• interest-cohort ve starších diskusích, dnes převážně historicky

Direktiva může povolit funkci nikomu, aktuálnímu originu nebo vybraným originům. Například:

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

To znamená, že kamera a mikrofon jsou pro dokument a jeho vnořené browsing contexts zakázané, zatímco geolokace je povolena pouze pro stejný origin.

O něco volnější příklad:

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

Ten umožňuje vašemu vlastnímu originu a jednomu pojmenovanému poskytovateli map používat geolokaci a vašemu vlastnímu originu plus poskytovateli videa požádat o fullscreen.

Policy vyhodnocuje prohlížeč. Pokud je funkce zakázaná, JavaScript používající dané API by měl selhat nebo se chovat tak, jako by funkce nebyla dostupná. Přesný způsob selhání závisí na API. Někdy se promise odmítne. Jindy se schopnost jednoduše nejeví jako použitelná.

Co může uzamknout na vašich vlastních stránkách

Na first-party stránkách je Permissions-Policy nejužitečnější jako pojistka. Snižuje dopad náhodného nebo neočekávaného kódu.

Marketingová stránka například pravděpodobně nepotřebuje mikrofon, kameru, Bluetooth, USB, pohybové senzory ani platební API. Tyto funkce můžete globálně zakázat:

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

To neznamená, že každý skript na stránce je důvěryhodný. Znamená to ale, že pokud se experiment ve správci tagů, kompromitovaná závislost nebo vložený widget pokusí zavolat omezené API, prohlížeč by mu přístup neměl udělit.

Pro týmy s mnoha přispěvateli je to užitečné výchozí nastavení. Posouvá debatu od vágní důvěry k explicitním schopnostem. Pokud budoucí funkce skutečně potřebuje kameru, někdo musí policy změnit a vysvětlit proč.

To je správný druh tření.

Co může uzamknout v iframech

Hlavička je obzvlášť užitečná u vloženého obsahu.

Prohlížeče už dnes zacházejí s iframy jako se samostatnými browsing contexts, ale vložený obsah třetích stran může stále požadovat výkonné funkce, pokud mu to policy a atributy iframe dovolí. Permissions-Policy umožňuje nadřazené stránce nastavit strop.

Pokud například vaše stránka vkládá video přehrávač, widget podpory a mapu, nemusíte každému rámci dávat přístup ke každé funkci. Fullscreen můžete povolit pouze video rámci a geolokaci pouze mapovému rámci.

Je třeba rozumět dvěma vrstvám:

1. HTTP hlavička Permissions-Policy nastavuje policy pro dokument.
2. Atribut iframe allow může delegovat konkrétní funkce na rámec, ale pouze v mezích toho, co povoluje nadřazená policy.

Jednoduchý iframe může vypadat takto:

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

Pokud vaše hlavička fullscreen zcela zakazuje, atribut iframe toto odmítnutí nemůže přepsat. Pokud vaše hlavička fullscreen pro daný origin povoluje, atribut iframe jej může delegovat.

Tato hierarchie je jedním z důvodů, proč se hlavičku vyplatí používat. Platformním nebo bezpečnostním týmům dává možnost nastavit hranice pro celý web a zároveň produktovým týmům umožňuje zapnout konkrétní embedy tam, kde jsou potřeba.

Co uzamknout nemůže

Tady týmy někdy schopnosti hlavičky přeceňují.

Permissions-Policy nenahrazuje content security policy. Nerozhoduje, které skripty se mohou načíst. Nezabrání skriptu odesílat data po síti. Nesanitizuje HTML. Nezabrání XSS. Neblokuje spam ve formulářích. Pokud je problémem zneužívání formulářů, začněte mechanikou popsanou v článku proč je váš kontaktní formulář největším spamovým rizikem, ne touto hlavičkou.

Nenahrazuje ani správu cookies. Cookies, local storage, souhlas, embedy třetích stran a ochrany prohlížečů proti sledování jsou samostatná témata. Pokud kontrolujete ochranu soukromí šířeji, prostředí cookies si zaslouží vlastní revizi; praktické změny jsou popsané v článku co se změnilo u cookies v roce 2026 a co s tím dělat.

Nejdůležitější je, že Permissions-Policy neudělá JavaScript třetích stran soukromým. Pokud načtete skript třetí strany do své first-party stránky, obecně běží s oprávněními vaší stránky, s výhradou dalších omezení prohlížeče a vašich bezpečnostních hlaviček. Zakázat přístup ke kameře je dobré. Nezabrání to ale skriptu číst obsah DOM, sledovat akce uživatele nebo provádět povolené síťové požadavky.

K tomu potřebujete jiné kontroly: pečlivý výběr dodavatelů, CSP, sandboxované iframy, Subresource Integrity tam, kde je použitelné, minimalizaci dat a nudné, ale nezbytné revize.

Rozumná výchozí policy

Neexistuje univerzální hlavička, která by seděla každému webu, ale většina obsahových a marketingových webů může začít restriktivně.

Rozumný první návrh:

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

Potom vraťte zpět jen to, co web skutečně používá.

Například:

• Obchod používající Payment Request API může potřebovat payment=(self).
• Vyhledávač poboček může potřebovat geolocation=(self) nebo důvěryhodný mapový origin.
• Konferenční aplikace může potřebovat camera=(self) a microphone=(self).
• Web s velkým množstvím videa může potřebovat fullscreen=(self "https://trusted-video.example").

Důležité není zkopírovat obrovskou policy z checklistu a prohlásit ji za hotovou. Začněte inventurou funkcí. Které stránky potřebují které schopnosti prohlížeče? Které embedy potřebují delegaci? Které funkce by bylo překvapivé požadovat?

Jak nasadit bez rozbití věcí

Zavádějte to jako jakoukoli jinou produkční hlavičku: promyšleně.

1. Zmapujte používání funkcí

Prohledejte codebase na volání API prohlížeče, jako jsou getUserMedia, geolocation, requestFullscreen, PaymentRequest, Web Bluetooth, WebUSB a wake lock API.

Potom zkontrolujte embedy třetích stran. Dokumentace poskytovatelů videa, map, plateb a identity často uvádí požadované hodnoty iframe allow.

2. Začněte v prostředí s nízkým rizikem

Přidejte restriktivní hlavičku ve stagingu a otestujte hlavní cesty. Všímejte si zpráv v konzoli prohlížeče. Prohlížeče často hlásí, když je funkce zablokována permissions policy.

3. Tam, kde je to nutné, používejte policy podle stránek

Nenuťte jednu globální policy, pokud má váš produkt velmi odlišné typy stránek. Blog, checkout, stránka s mapou a video místnost budou pravděpodobně potřebovat různé schopnosti.

Většina webových serverů, frameworků a edge platforem umí nastavovat hlavičky podmíněně podle cesty. To je často čistší než oslabit celý web kvůli jedné funkci.

4. Ověřte skutečnou odpověď

Hlavičky mohou být přidány, přepsány, zdvojeny nebo odstraněny přes CDN, reverse proxy, aplikační servery a middleware. Zkontrolujte finální odpověď v browser DevTools nebo pomocí nástrojů příkazové řádky.

Otestujte také vložené kontexty. To, že top-level stránka vypadá správně, nezaručuje, že iframe dostal delegaci, kterou jste zamýšleli.

5. Dokumentujte výjimky

Každá povolená funkce by měla mít vlastníka a důvod. Zní to byrokraticky až do chvíle o šest měsíců později, kdy si nikdo nepamatuje, proč byl geolocation otevřen doméně dodavatele, která se už na stránce neobjevuje.

Časté syntaktické chyby

Moderní syntaxe hlavičky je kompaktní, ale snadno se v ní udělá drobná chyba.

Pro zakázání funkce použijte prázdné závorky:

Permissions-Policy: microphone=()

Pro aktuální origin použijte self:

Permissions-Policy: geolocation=(self)

Pro konkrétní externí originy použijte originy v uvozovkách:

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

Nespoléhejte se na staré příklady Feature-Policy, pokud záměrně nepodporujete legacy chování. Starší hlavička používala jinou syntaxi a není to něco, podle čeho byste dnes měli návrh stavět.

Pamatujte také, že podpora v prohlížečích se liší podle direktivy. Prohlížeč může podporovat hlavičku, ale ne konkrétní direktivu funkce. To je normální. Berte hlavičku jako opatření defense-in-depth, ne jako jedinou kontrolu ochrany soukromí nebo bezpečnosti.

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

💡 Vyzkoušejte: Ověřte, že se vaše Permissions-Policy doručuje podle očekávání, pomocí Get Headers, který zobrazuje surové hlavičky odpovědi odesílané vaším serverem.

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

Praktická hodnota pro soukromí

Hodnota Permissions-Policy pro soukromí nespočívá v tom, že by web udělala anonymním nebo bez trackerů. To neudělá.

Její hodnota je v tom, že zužuje přístup k citlivým schopnostem prohlížeče. Poloha, kamera, mikrofon, senzory zařízení, API místního hardwaru a platební toky jsou mocné. Většina stránek je nepotřebuje. Mnoho vložených komponent by o ně nikdy nemělo mít možnost požádat.

To je skutečné zlepšení. Omezuje náhodné výzvy, snižuje zbytečné vystavení schopností a dává vašemu týmu konkrétní artefakt k revizi při vydávání nové funkcionality.

Nejlepší verze této hlavičky je nudná: ve výchozím stavu restriktivní, uvolněná jen tam, kde to vyžaduje funkce viditelná pro uživatele, a testovaná jako součást běžného release procesu.