Шта заглавље Permissions-Policy заиста може да ограничи

Кратка верзија

Permissions-Policy је HTTP заглавље одговора које омогућава сајту да ограничи приступ одређеним функцијама прегледача: камери, микрофону, геолокацији, приказу преко целог екрана, плаћању, сензорима и дугачкој листи мањих API-ја.

То није општи штит за приватност. Неће зауставити свако праћење, блокирати cookies, спречити мрежне захтеве нити учинити JavaScript треће стране безбедним. Оно што може добро да уради уже је, али и даље вредно: да смањи могућности прегледача доступне вашим сопственим страницама и уграђеним оквирима.

То је важно зато што су модерни веб-сајтови састављени од аналитичких исечака, медијских embed-ова, chat widget-а, менаџера сагласности, рекламних скрипти, мапа, токова плаћања и интерних експеримената. Већини тих компоненти није потребан приступ моћним API-јима уређаја. Добра policy то јасно исказује.

Ако већ прегледате заглавља у продукцији, упарите овај рад са директном провером стварног одговора. Наш водич за отклањање проблема са преусмеравањима и HTTP заглављима у продукцији покрива навику која је овде важна: проверите шта прегледач заиста прима, а не шта ваша конфигурациона датотека каже да би требало да се деси.

Шта Permissions-Policy контролише

Заглавље контролише приступ именованим функцијама прегледача. Тачна листа се временом мења јер се API-ји прегледача мењају, али уобичајене директиве укључују:

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

Директива може да дозволи функцију никоме, тренутном origin-у или изабраним origin-има. На пример:

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

То значи да су камера и микрофон онемогућени за документ и његове угнежђене контексте прегледања, док је геолокација дозвољена само за исти origin.

Пример који дозвољава више:

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

Ово омогућава вашем origin-у и једном именованом добављачу мапа да користе геолокацију, а вашем origin-у и добављачу видеа да затраже приказ преко целог екрана.

Policy процењује прегледач. Ако функција није дозвољена, JavaScript који користи тај API треба да не успе или да се понаша као да функција није доступна. Тачан начин неуспеха зависи од API-ја. Понекад се promise одбија. Понекад могућност једноставно не изгледа употребљиво.

Шта може да ограничи на вашим сопственим страницама

На first-party страницама, Permissions-Policy је најкориснији као заштитна ограда. Смањује домет случајног или неочекиваног кода.

Маркетиншкој страници, на пример, вероватно нису потребни микрофон, камера, Bluetooth, USB, сензори покрета или API-ји за плаћање. Те функције можете глобално да забраните:

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

То не чини сваку скрипту на страници поузданом. Али значи да, ако експеримент у tag manager-у, компромитована зависност или налепљени widget покуша да позове ограничени API, прегледач не би требало да му одобри приступ.

За тимове са много сарадника, ово је корисна подразумевана вредност. Разговор помера са нејасног поверења на експлицитну могућност. Ако некој будућој функцији заиста буде потребна камера, неко мора да промени policy и објасни зашто.

То је права врста трења.

Шта може да ограничи у iframe-овима

Заглавље постаје нарочито корисно око уграђеног садржаја.

Прегледачи већ третирају iframe-ове као одвојене контексте прегледања, али уграђени садржај треће стране и даље може да тражи моћне функције ако су дозвољене policy-јем и iframe атрибутима. Permissions-Policy омогућава надређеној страници да постави горњу границу.

На пример, ако ваша страница уграђује видео плејер, widget за подршку и мапу, можете да избегнете да сваком оквиру дате приступ свакој функцији. Можда ћете дозволити приказ преко целог екрана само за видео оквир, а геолокацију само за оквир са мапом.

Постоје два слоја која треба разумети:

1. HTTP заглавље Permissions-Policy поставља policy за документ.
2. iframe атрибут allow може да делегира одређене функције оквиру, али само у оквиру онога што надређени policy дозвољава.

Једноставан iframe може да изгледа овако:

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

Ако ваше заглавље у потпуности забрањује приказ преко целог екрана, iframe атрибут не може да поништи ту забрану. Ако ваше заглавље дозвољава приказ преко целог екрана за тај origin, iframe атрибут може да га делегира.

Ова хијерархија је један од разлога због којих заглавље вреди користити. Даје платформским или безбедносним тимовима начин да поставе границе за цео сајт, а тимовима за производ и даље омогућава да укључе конкретне embed-ове тамо где су потребни.

Шта не може да ограничи

Овде тимови понекад прецењују заглавље.

Permissions-Policy не замењује content security policy. Не одлучује које скрипте смеју да се учитају. Не спречава скрипту да шаље податке преко мреже. Не санира HTML. Не спречава XSS. Не блокира spam преко формулара. Ако је проблем злоупотреба формулара, почните од механике описане у тексту зашто је ваш контакт формулар ваша највећа spam одговорност, а не од овог заглавља.

Такође не замењује управљање cookies. Cookies, local storage, сагласност, embed-ови треће стране и заштите прегледача од праћења одвојена су питања. Ако широко прегледате контроле приватности, област cookies заслужује засебан пролаз; практичне промене су обрађене у тексту шта се променило за cookies у 2026. и шта да урадите поводом тога.

Најважније, Permissions-Policy не чини JavaScript треће стране приватним. Ако учитате скрипту треће стране у своју first-party страницу, она углавном ради са привилегијама ваше странице, уз друга ограничења прегледача и ваша безбедносна заглавља. Забрана приступа камери је добра. Али не спречава ту скрипту да чита DOM садржај, посматра радње корисника или шаље дозвољене мрежне захтеве.

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

Разумна подразумевана policy

Не постоји универзално заглавље које одговара сваком сајту, али већина садржајних и маркетиншких сајтова може да почне рестриктивно.

Разуман први пролаз:

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

Затим вратите само оно што сајт заиста користи.

На пример:

• Продавници која користи Payment Request API можда је потребно payment=(self).
• Проналазачу локација можда је потребно geolocation=(self) или поуздан origin мапе.
• Апликацији за конференције можда су потребни camera=(self) и microphone=(self).
• Сајту са много видеа можда је потребно fullscreen=(self "https://trusted-video.example").

Важно је да не копирате огроман policy из checklist-а и прогласите посао завршеним. Почните од пописа функција. Којим страницама су потребне које могућности прегледача? Којим embed-овима је потребно делегирање? Које функције би биле изненађујуће ако би биле затражене?

Како да примените без кварења ствари

Уводите ово као и свако друго продукционо заглавље: промишљено.

1. Попишите употребу функција

Претражите codebase за позиве API-ја прегледача као што су getUserMedia, geolocation, requestFullscreen, PaymentRequest, Web Bluetooth, WebUSB и wake lock API-ји.

Затим проверите embed-ове треће стране. Документација за видео, мапе, плаћање и добављаче идентитета често помиње потребне iframe allow вредности.

2. Почните у окружењу ниског ризика

Додајте рестриктивно заглавље у staging и тестирајте кључна корисничка путовања. Обратите пажњу на поруке у конзоли прегледача. Прегледачи често пријављују када је функција блокирана permissions policy-јем.

3. Користите policy-је специфичне за странице где је потребно

Не форсирајте један глобални policy ако ваш производ има веома различите типове страница. Blog, checkout, страница са мапом и видео соба вероватно требају различите могућности.

Већина веб сервера, framework-а и edge платформи може условно да поставља заглавља по путањи. То је често чистије него да се цео сајт ослаби због једне функције.

4. Проверите стварни одговор

Заглавља могу да додају, препишу, дуплирају или уклоне CDNs, reverse proxies, app servers и middleware. Проверите коначни одговор у browser DevTools или помоћу алата из командне линије.

Тестирајте и уграђене контексте. То што вршна страница изгледа исправно не гарантује да је iframe добио делегирање које сте намеравали.

5. Документујте изузетке

Свака дозвољена функција треба да има власника и разлог. Ово звучи бирократски док шест месеци касније нико не памти зашто је geolocation отворен ка домену добављача који се више не појављује на страници.

Уобичајене синтаксне грешке

Модерна синтакса заглавља је компактна, али је лако мало погрешити.

Користите празне заграде да забраните функцију:

Permissions-Policy: microphone=()

Користите self за тренутни origin:

Permissions-Policy: geolocation=(self)

Користите origin-е под наводницима за конкретне спољне origin-е:

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

Избегавајте ослањање на старе Feature-Policy примере осим ако намерно подржавате legacy понашање. Старије заглавље је користило другачију синтаксу и није оно око чега данас треба да пројектујете.

Такође имајте на уму да подршка у прегледачима варира по директиви. Прегледач може да подржава заглавље, али не и одређену директиву функције. То је нормално. Третирајте заглавље као меру defense-in-depth, а не као једину контролу приватности или безбедности.

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

💡 Испробајте ово: Проверите да ли се ваша Permissions-Policy испоручује како је предвиђено помоћу Get Headers, који приказује сировa заглавља одговора која ваш сервер шаље.

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

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

Вредност Permissions-Policy за приватност није у томе што сајт чини анонимним или без tracker-а. Не чини.

Његова вредност је у томе што сужава приступ осетљивим могућностима прегледача. Локација, камера, микрофон, сензори уређаја, локални hardware API-ји и токови плаћања су моћни. Већини страница нису потребни. Многе уграђене компоненте никада не би требало да могу да их затраже.

То је стварно побољшање. Смањује случајне prompt-ове, ограничава непотребно излагање могућности и даје вашем тиму конкретан артефакт за ревизију када нова функционалност буде испоручена.

Најбоља верзија овог заглавља је досадна: рестриктивна по подразумеваној вредности, ублажена само тамо где то захтева функција окренута кориснику и тестирана као део нормалног процеса објављивања.