Какво всъщност може да ограничи заглавката Permissions-Policy

Кратката версия

Permissions-Policy е HTTP response header, който позволява на даден сайт да ограничи достъпа до определени функции на браузъра: камера, микрофон, геолокация, fullscreen, payment, сензори и дълъг списък от по-малки APIs.

Това не е общ щит за поверителност. Тя няма да спре всяко проследяване, да блокира cookies, да предотврати network requests или да направи third-party JavaScript безопасен. Това, което може да прави добре, е по-тясно и все пак ценно: да намали възможностите на браузъра, достъпни за вашите собствени страници и за вградените frames.

Това има значение, защото съвременните уебсайтове са съшити от analytics snippets, media embeds, chat widgets, consent managers, advertising scripts, maps, payment flows и вътрешни експерименти. Повечето от тези компоненти не се нуждаят от достъп до мощни device APIs. Добрата политика прави това изрично.

Ако вече преглеждате headers в production, съчетайте тази работа с директна проверка на реалния response. Нашето ръководство за отстраняване на проблеми с redirects и HTTP headers в production разглежда навика, който е важен тук: проверявайте какво браузърът наистина получава, а не какво според конфигурационния файл трябва да се случи.

Какво контролира Permissions-Policy

Заглавката контролира достъпа до именувани функции на браузъра. Точният списък се променя с времето, защото browser APIs се променят, но често срещани directives включват:

• camera
• microphone
• geolocation
• fullscreen
• payment
• usb
• bluetooth
• accelerometer
• gyroscope
• magnetometer
• screen-wake-lock
• clipboard-read
• clipboard-write
• publickey-credentials-get
• interest-cohort в по-стари обсъждания, сега предимно историческо

Дадена directive може да позволи функция за никого, за текущия origin или за избрани origins. Например:

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

Това означава, че камерата и микрофонът са изключени за документа и неговите nested browsing contexts, докато геолокацията е позволена само за същия origin.

По-разрешаващ пример:

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

Това позволява на вашия собствен origin и на един именуван доставчик на карти да използват геолокация, а на вашия собствен origin плюс доставчик на видео — да заявяват fullscreen.

Политиката се оценява от браузъра. Ако дадена функция е забранена, JavaScript, който използва този API, би трябвало да се провали или да се държи така, сякаш функцията не е налична. Точният режим на отказ зависи от API. Понякога promise се отхвърля. Понякога дадена възможност просто не изглежда използваема.

Какво може да ограничи на вашите собствени страници

На first-party страници Permissions-Policy е най-полезна като предпазен парапет. Тя намалява blast radius на случаен или неочакван код.

Например една marketing page вероятно не се нуждае от микрофон, камера, Bluetooth, USB, motion sensors или payment APIs. Можете да забраните тези функции глобално:

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

Това не прави всеки script на страницата надежден. Но означава, че ако експеримент в tag manager, компрометирана dependency или поставен widget се опита да извика ограничен API, браузърът не би трябвало да му предостави достъп.

За екипи с много участници това е полезна настройка по подразбиране. Тя измества разговора от неясно доверие към изрична capability. Ако бъдеща функция наистина се нуждае от камерата, някой трябва да промени политиката и да обясни защо.

Това е правилният вид триене.

Какво може да ограничи в iframes

Заглавката става особено полезна около вградено съдържание.

Браузърите вече третират iframes като отделни browsing contexts, но вграденото third-party съдържание все пак може да заявява мощни функции, ако това е позволено от policy и iframe attributes. Permissions-Policy позволява на parent page да зададе таван.

Например, ако вашата страница вгражда video player, support widget и map, можете да избегнете даването на достъп на всеки frame до всяка функция. Може да позволите fullscreen само за video frame и геолокация само за map frame.

Има два слоя, които трябва да разберете:

1. HTTP Permissions-Policy header задава policy за документа.
2. iframe атрибутът allow може да делегира конкретни функции към frame, но само в рамките на това, което parent policy позволява.

Един прост iframe може да изглежда така:

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

Ако вашата header забранява fullscreen изцяло, iframe атрибутът не може да отмени тази забрана. Ако вашата header позволява fullscreen за този origin, iframe атрибутът може да го делегира.

Тази йерархия е една от причините заглавката да си струва да се използва. Тя дава на platform или security екипите начин да зададат boundaries за целия сайт, като същевременно позволява на product екипите да активират конкретни embeds, когато е нужно.

Какво не може да ограничи

Тук е мястото, където екипите понякога надценяват заглавката.

Permissions-Policy не замества content security policy. Тя не решава кои scripts могат да се зареждат. Не спира script да изпраща данни през мрежата. Не санитизира HTML. Не предотвратява XSS. Не блокира form spam. Ако проблемът е злоупотреба с формуляри, започнете с механиката, описана в защо вашата контактна форма е най-големият ви spam риск, а не с тази заглавка.

Тя също не замества управлението на cookies. Cookies, local storage, consent, third-party embeds и browser tracking protections са отделни теми. Ако преглеждате privacy controls в широк план, cookie landscape заслужава отделен преглед; практическите промени са разгледани в какво се промени за cookies през 2026 г. и какво да направите по въпроса.

Най-важното е, че Permissions-Policy не прави third-party JavaScript поверителен. Ако заредите third-party script във вашата first-party страница, той обикновено се изпълнява с привилегиите на вашата страница, при спазване на други browser constraints и вашите security headers. Забраната на достъп до камерата е добра. Тя не спира този script да чете DOM съдържание, да наблюдава потребителски действия или да прави позволени network requests.

За това са нужни други контроли: внимателен избор на vendors, CSP, sandboxed iframes, Subresource Integrity където е приложимо, data minimization и скучни, но необходими прегледи.

Разумна политика по подразбиране

Няма универсална header, която да пасва на всеки сайт, но повечето content и marketing сайтове могат да започнат ограничително.

Разумен първи вариант:

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

След това добавете обратно само това, което сайтът наистина използва.

Например:

• Магазин, който използва Payment Request API, може да се нуждае от payment=(self).
• Location finder може да се нуждае от geolocation=(self) или доверен map origin.
• Conferencing app може да се нуждае от camera=(self) и microphone=(self).
• Сайт с много видео може да се нуждае от fullscreen=(self "https://trusted-video.example").

Важното е да не копирате огромна политика от checklist и да я сметнете за приключена. Започнете с инвентаризация на функциите. Кои страници се нуждаят от кои browser capabilities? Кои embeds се нуждаят от delegation? Кои функции биха били изненадващи, ако бъдат заявени?

Как да внедрите, без да счупите нещо

Разгръщайте това като всяка друга production header: целенасочено.

1. Инвентаризирайте използването на функции

Потърсете в codebase извиквания към browser APIs като getUserMedia, geolocation, requestFullscreen, PaymentRequest, Web Bluetooth, WebUSB и wake lock APIs.

След това проверете third-party embeds. Документацията за video, maps, payment и identity providers често споменава необходимите iframe allow стойности.

2. Започнете в среда с нисък риск

Добавете restrictive header в staging и тествайте основните journeys. Обърнете внимание на browser console messages. Браузърите често съобщават, когато дадена функция е блокирана от permissions policy.

3. Използвайте page-specific policies, когато е необходимо

Не налагайте една global policy, ако продуктът ви има много различни типове страници. Blog, checkout, map page и video room вероятно се нуждаят от различни capabilities.

Повечето web servers, frameworks и edge platforms могат да задават headers условно по path. Това често е по-чисто, отколкото да отслабите целия сайт заради една функция.

4. Проверете реалния response

Headers могат да бъдат добавяни, презаписвани, дублирани или премахвани от CDNs, reverse proxies, app servers и middleware. Проверете крайния response в browser DevTools или с command-line tools.

Тествайте и embedded contexts. Top-level page, която изглежда правилна, не гарантира, че iframe е получил delegation, която сте възнамерявали.

5. Документирайте изключенията

Всяка позволена функция трябва да има owner и причина. Това звучи бюрократично до момента шест месеца по-късно, когато никой не помни защо geolocation е била отворена към vendor domain, който вече не се появява на страницата.

Чести синтактични грешки

Съвременният синтаксис на заглавката е компактен, но е лесно да се сбърка леко.

Използвайте празни скоби, за да забраните функция:

Permissions-Policy: microphone=()

Използвайте self за текущия origin:

Permissions-Policy: geolocation=(self)

Използвайте quoted origins за конкретни външни origins:

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

Избягвайте да разчитате на стари примери с Feature-Policy, освен ако умишлено поддържате legacy behavior. По-старата header използваше различен синтаксис и не е това, около което трябва да проектирате днес.

Също така помнете, че browser support варира според directive. Даден браузър може да поддържа заглавката, но не и конкретна feature directive. Това е нормално. Третирайте заглавката като defense-in-depth мярка, а не като единствения си privacy или security control.

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

💡 Опитайте това: Проверете дали вашата Permissions-Policy се доставя както е предвидено с Get Headers, който показва суровите заглавки на отговора, изпращани от вашия сървър.

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

Практическата стойност за поверителността

Стойността на Permissions-Policy за поверителността не е в това, че прави сайта анонимен или свободен от trackers. Не го прави.

Стойността ѝ е, че стеснява достъпа до чувствителни browser capabilities. Location, camera, microphone, device sensors, local hardware APIs и payment flows са мощни. Повечето страници не се нуждаят от тях. Много embedded components никога не би трябвало да могат да ги искат.

Това е реално подобрение. Намалява случайните prompts, ограничава ненужното излагане на capabilities и дава на екипа ви конкретен artifact за преглед при пускане на нова functionality.

Най-добрата версия на тази header е скучна: restrictive by default, разхлабена само там, където user-facing feature го изисква, и тествана като част от нормалния release process.