Co nagłówek Permissions-Policy może naprawdę zablokować

Wersja skrócona

Permissions-Policy to nagłówek odpowiedzi HTTP, który pozwala witrynie ograniczyć dostęp do wybranych funkcji przeglądarki: kamery, mikrofonu, geolokalizacji, trybu pełnoekranowego, płatności, sensorów oraz długiej listy mniejszych API.

Nie jest to ogólna tarcza prywatności. Nie zatrzyma całego śledzenia, nie zablokuje cookies, nie zapobiegnie żądaniom sieciowym ani nie sprawi, że JavaScript podmiotów trzecich stanie się bezpieczny. To, co potrafi robić dobrze, jest węższe, ale nadal wartościowe: ogranicza możliwości przeglądarki dostępne dla własnych stron i osadzonych ramek.

Ma to znaczenie, ponieważ nowoczesne witryny są składane z fragmentów analityki, osadzeń multimedialnych, widgetów czatu, menedżerów zgód, skryptów reklamowych, map, przepływów płatności i wewnętrznych eksperymentów. Większość tych komponentów nie potrzebuje dostępu do zaawansowanych API urządzenia. Dobra polityka jasno to określa.

Jeśli już przeglądasz nagłówki w produkcji, połącz tę pracę z bezpośrednim sprawdzeniem rzeczywistej odpowiedzi. Nasz przewodnik po debugowaniu przekierowań i nagłówków HTTP w produkcji opisuje nawyk, który ma tu znaczenie: sprawdzaj, co przeglądarka naprawdę otrzymuje, a nie to, co według pliku konfiguracyjnego powinno się wydarzyć.

Co kontroluje Permissions-Policy

Nagłówek kontroluje dostęp do nazwanych funkcji przeglądarki. Dokładna lista zmienia się z czasem, ponieważ zmieniają się API przeglądarek, ale typowe dyrektywy obejmują:

• camera
• microphone
• geolocation
• fullscreen
• payment
• usb
• bluetooth
• accelerometer
• gyroscope
• magnetometer
• screen-wake-lock
• clipboard-read
• clipboard-write
• publickey-credentials-get
• interest-cohort w starszych dyskusjach, dziś głównie historycznie

Dyrektywa może dopuścić funkcję dla nikogo, dla bieżącego originu albo dla wybranych originów. Na przykład:

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

Oznacza to, że kamera i mikrofon są wyłączone dla dokumentu oraz jego zagnieżdżonych kontekstów przeglądania, natomiast geolokalizacja jest dozwolona tylko dla tego samego originu.

Bardziej liberalny przykład:

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

Pozwala to własnemu originowi i jednemu wskazanemu dostawcy map używać geolokalizacji, a własnemu originowi oraz dostawcy wideo żądać trybu pełnoekranowego.

Politykę ocenia przeglądarka. Jeśli funkcja jest niedozwolona, JavaScript korzystający z tego API powinien zakończyć się błędem albo zachowywać się tak, jakby funkcja była niedostępna. Dokładny tryb niepowodzenia zależy od API. Czasem promise zostanie odrzucony. Czasem dana możliwość po prostu nie będzie wyglądała na używalną.

Co można zablokować na własnych stronach

Na stronach first-party Permissions-Policy jest najbardziej przydatny jako ogranicznik bezpieczeństwa. Zmniejsza zakres skutków przypadkowego lub nieoczekiwanego kodu.

Na przykład strona marketingowa prawdopodobnie nie potrzebuje mikrofonu, kamery, Bluetooth, USB, sensorów ruchu ani API płatności. Możesz globalnie zabronić tych funkcji:

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

Nie sprawia to, że każdy skrypt na stronie jest godny zaufania. Oznacza natomiast, że jeśli eksperyment w menedżerze tagów, przejęta zależność albo wklejony widget spróbuje wywołać ograniczone API, przeglądarka nie powinna przyznać mu dostępu.

Dla zespołów z wieloma współtwórcami to użyślne ustawienie domyślne. Przenosi rozmowę z niejasnego zaufania na jawnie określone możliwości. Jeśli przyszła funkcja naprawdę potrzebuje kamery, ktoś musi zmienić politykę i wyjaśnić dlaczego.

To właściwy rodzaj tarcia.

Co można zablokować w iframe

Nagłówek staje się szczególnie przydatny przy treściach osadzonych.

Przeglądarki już traktują iframe jako osobne konteksty przeglądania, ale osadzone treści podmiotów trzecich nadal mogą żądać zaawansowanych funkcji, jeśli pozwalają na to polityka i atrybuty iframe. Permissions-Policy pozwala stronie nadrzędnej ustawić górny limit.

Na przykład jeśli Twoja strona osadza odtwarzacz wideo, widget wsparcia i mapę, możesz uniknąć dawania każdej ramce dostępu do każdej funkcji. Możesz dopuścić tryb pełnoekranowy tylko dla ramki wideo, a geolokalizację tylko dla ramki mapy.

Trzeba rozumieć dwie warstwy:

1. Nagłówek HTTP Permissions-Policy ustawia politykę dla dokumentu.
2. Atrybut allow w iframe może delegować konkretne funkcje do ramki, ale tylko w granicach tego, na co pozwala polityka rodzica.

Prosty iframe może wyglądać tak:

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

Jeśli Twój nagłówek całkowicie zabrania trybu pełnoekranowego, atrybut iframe nie może unieważnić tego zakazu. Jeśli nagłówek dopuszcza tryb pełnoekranowy dla tego originu, atrybut iframe może go delegować.

Ta hierarchia jest jednym z powodów, dla których warto używać nagłówka. Daje zespołom platformowym lub bezpieczeństwa sposób na ustawienie granic dla całej witryny, a jednocześnie pozwala zespołom produktowym włączać konkretne osadzenia tam, gdzie są potrzebne.

Czego nie da się zablokować

W tym miejscu zespoły czasem przeceniają ten nagłówek.

Permissions-Policy nie zastępuje content security policy. Nie decyduje, które skrypty mogą się ładować. Nie zatrzymuje skryptu przed wysyłaniem danych przez sieć. Nie sanityzuje HTML. Nie zapobiega XSS. Nie blokuje spamu z formularzy. Jeśli problemem są nadużycia formularzy, zacznij od mechaniki opisanej w tekście dlaczego formularz kontaktowy jest Twoim największym ryzykiem spamowym, a nie od tego nagłówka.

Nie zastępuje też zarządzania cookies. Cookies, local storage, zgody, osadzenia podmiotów trzecich i przeglądarkowe ochrony przed śledzeniem to osobne kwestie. Jeśli szerzej przeglądasz kontrole prywatności, krajobraz cookies zasługuje na osobny przegląd; praktyczne zmiany opisano w tekście co zmieniło się dla cookies w 2026 roku i co z tym zrobić.

Co najważniejsze, Permissions-Policy nie sprawia, że JavaScript podmiotów trzecich staje się prywatny. Jeśli ładujesz skrypt podmiotu trzeciego na własnej stronie first-party, zwykle działa on z uprawnieniami Twojej strony, z zastrzeżeniem innych ograniczeń przeglądarki i Twoich nagłówków bezpieczeństwa. Odmowa dostępu do kamery jest dobra. Nie powstrzymuje jednak takiego skryptu przed odczytywaniem zawartości DOM, obserwowaniem działań użytkownika ani wykonywaniem dozwolonych żądań sieciowych.

Do tego potrzebujesz innych kontroli: starannego wyboru dostawców, CSP, sandboxed iframes, Subresource Integrity tam, gdzie ma zastosowanie, minimalizacji danych oraz nudnych, ale koniecznych przeglądów.

Rozsądna polityka domyślna

Nie istnieje uniwersalny nagłówek pasujący do każdej witryny, ale większość stron treściowych i marketingowych może zacząć restrykcyjnie.

Rozsądne pierwsze podejście:

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

Następnie dodawaj z powrotem tylko to, czego witryna faktycznie używa.

Na przykład:

• Sklep używający Payment Request API może potrzebować payment=(self).
• Wyszukiwarka lokalizacji może potrzebować geolocation=(self) albo zaufanego originu map.
• Aplikacja konferencyjna może potrzebować camera=(self) i microphone=(self).
• Witryna mocno oparta na wideo może potrzebować fullscreen=(self "https://trusted-video.example").

Najważniejsze jest to, aby nie kopiować ogromnej polityki z checklisty i nie uznawać sprawy za zakończoną. Zacznij od inwentaryzacji funkcji. Które strony potrzebują których możliwości przeglądarki? Które osadzenia wymagają delegowania? Żądanie których funkcji byłoby zaskakujące?

Jak wdrożyć bez psucia rzeczy

Wdrażaj to tak jak każdy inny nagłówek produkcyjny: celowo.

1. Zinwentaryzuj użycie funkcji

Przeszukaj bazę kodu pod kątem wywołań API przeglądarki, takich jak getUserMedia, geolocation, requestFullscreen, PaymentRequest, Web Bluetooth, WebUSB i API wake lock.

Następnie sprawdź osadzenia podmiotów trzecich. Dokumentacja dostawców wideo, map, płatności i tożsamości często wspomina wymagane wartości iframe allow.

2. Zacznij w środowisku niskiego ryzyka

Dodaj restrykcyjny nagłówek w stagingu i przetestuj kluczowe ścieżki. Zwracaj uwagę na komunikaty w konsoli przeglądarki. Przeglądarki często zgłaszają, kiedy funkcja jest blokowana przez permissions policy.

3. W razie potrzeby używaj polityk specyficznych dla stron

Nie wymuszaj jednej globalnej polityki, jeśli produkt ma bardzo różne typy stron. Blog, checkout, strona mapy i pokój wideo prawdopodobnie potrzebują różnych możliwości.

Większość serwerów WWW, frameworków i platform edge potrafi ustawiać nagłówki warunkowo według ścieżki. To często czystsze niż osłabianie całej witryny dla jednej funkcji.

4. Zweryfikuj rzeczywistą odpowiedź

Nagłówki mogą być dodawane, nadpisywane, duplikowane albo usuwane przez CDN-y, reverse proxies, serwery aplikacyjne i middleware. Sprawdź końcową odpowiedź w browser DevTools albo narzędziami wiersza poleceń.

Przetestuj też konteksty osadzone. To, że strona najwyższego poziomu wygląda poprawnie, nie gwarantuje, że iframe otrzymał delegowanie, które zamierzałeś nadać.

5. Dokumentuj wyjątki

Każda dozwolona funkcja powinna mieć właściciela i powód. Brzmi to biurokratycznie do momentu, gdy sześć miesięcy później nikt nie pamięta, dlaczego geolocation otwarto dla domeny dostawcy, która nie pojawia się już na stronie.

Typowe błędy składni

Nowoczesna składnia nagłówka jest zwarta, ale łatwo pomylić się w drobnym szczególe.

Użyj pustych nawiasów, aby zabronić funkcji:

Permissions-Policy: microphone=()

Użyj self dla bieżącego originu:

Permissions-Policy: geolocation=(self)

Użyj originów w cudzysłowie dla konkretnych zewnętrznych originów:

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

Unikaj opierania się na starych przykładach Feature-Policy, chyba że celowo wspierasz zachowanie legacy. Starszy nagłówek używał innej składni i nie na nim należy dziś projektować rozwiązanie.

Pamiętaj też, że obsługa w przeglądarkach różni się w zależności od dyrektywy. Przeglądarka może obsługiwać nagłówek, ale nie konkretną dyrektywę funkcji. To normalne. Traktuj nagłówek jako środek defense-in-depth, a nie jako jedyną kontrolę prywatności lub bezpieczeństwa.

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

💡 Wypróbuj to: Sprawdź, czy Twoja Permissions-Policy jest dostarczana zgodnie z zamierzeniem za pomocą Get Headers, które pokazuje surowe nagłówki odpowiedzi wysyłane przez Twój serwer.

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

Praktyczna wartość dla prywatności

Wartość Permissions-Policy dla prywatności nie polega na tym, że czyni witrynę anonimową albo wolną od trackerów. Nie czyni.

Jego wartość polega na zawężeniu dostępu do wrażliwych możliwości przeglądarki. Lokalizacja, kamera, mikrofon, sensory urządzenia, lokalne API sprzętowe i przepływy płatności są potężne. Większość stron ich nie potrzebuje. Wiele osadzonych komponentów nigdy nie powinno móc o nie prosić.

To realna poprawa. Ogranicza przypadkowe monity, zmniejsza niepotrzebną ekspozycję możliwości i daje zespołowi konkretny artefakt do przeglądu, gdy trafia do produkcji nowa funkcjonalność.

Najlepsza wersja tego nagłówka jest nudna: restrykcyjna domyślnie, poluzowana tylko tam, gdzie wymaga tego funkcja widoczna dla użytkownika, i testowana jako część normalnego procesu wydawniczego.