Ano talaga ang kayang i-lock down ng Permissions-Policy header

Ang maikling bersyon

Ang Permissions-Policy ay isang HTTP response header na nagbibigay-daan sa isang site na limitahan ang access sa ilang feature ng browser: camera, microphone, geolocation, fullscreen, payment, sensors, at mahabang listahan ng mas maliliit na API.

Hindi ito pangkalahatang panangga sa privacy. Hindi nito pipigilan ang lahat ng tracking, haharangin ang cookies, pipigilan ang network requests, o gagawing ligtas ang third-party JavaScript. Ang kaya nitong gawin nang maayos ay mas makitid ngunit mahalaga pa rin: bawasan ang mga browser capability na available sa sarili mong mga page at sa mga embedded frame.

Mahalaga iyon dahil ang mga modernong website ay pinagdudugtong-dugtong mula sa analytics snippets, media embeds, chat widgets, consent managers, advertising scripts, maps, payment flows, at internal experiments. Karamihan sa mga component na iyon ay hindi nangangailangan ng access sa makapangyarihang device APIs. Ginagawa itong malinaw ng isang magandang policy.

Kung sinusuri mo na ang mga header sa production, ipares ang gawaing ito sa direktang pag-check ng aktuwal na response. Sinasaklaw ng aming gabay sa pag-debug ng redirects at HTTP headers sa production ang ugaling mahalaga rito: inspeksyunin kung ano talaga ang natatanggap ng browser, hindi kung ano ang sinasabi ng configuration file mo na dapat mangyari.

Ano ang kinokontrol ng Permissions-Policy

Kinokontrol ng header ang access sa pinangalanang mga feature ng browser. Nagbabago ang eksaktong listahan sa paglipas ng panahon dahil nagbabago ang browser APIs, ngunit kabilang sa karaniwang directives ang:

• camera
• microphone
• geolocation
• fullscreen
• payment
• usb
• bluetooth
• accelerometer
• gyroscope
• magnetometer
• screen-wake-lock
• clipboard-read
• clipboard-write
• publickey-credentials-get
• interest-cohort sa mas lumang mga talakayan, na ngayon ay kadalasang historikal na lamang

Maaaring pahintulutan ng isang directive ang isang feature para sa wala, para sa kasalukuyang origin, o para sa mga napiling origin. Halimbawa:

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

Ibig sabihin nito, naka-disable ang camera at microphone para sa document at sa mga nested browsing context nito, habang pinapayagan ang geolocation para sa parehong origin lamang.

Isang mas permissive na halimbawa:

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

Pinapayagan nito ang sarili mong origin at isang pinangalanang map provider na gumamit ng geolocation, at ang sarili mong origin kasama ang isang video provider na humiling ng fullscreen.

Ang policy ay sinusuri ng browser. Kung hindi pinapayagan ang isang feature, dapat mabigo ang JavaScript na gumagamit ng API na iyon o kumilos na parang hindi available ito. Nakadepende sa API ang eksaktong paraan ng pagkabigo. Minsan nagre-reject ang isang promise. Minsan ang isang capability ay simpleng hindi lumilitaw na magagamit.

Ano ang kaya nitong i-lock down sa sarili mong mga page

Sa mga first-party page, pinakakapaki-pakinabang ang Permissions-Policy bilang guardrail. Binabawasan nito ang blast radius ng aksidente o hindi inaasahang code.

Halimbawa, malamang na hindi kailangan ng isang marketing page ang microphone, camera, Bluetooth, USB, motion sensors, o payment APIs. Maaari mong i-deny ang mga feature na iyon sa buong site:

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

Hindi nito ginagawang mapagkakatiwalaan ang bawat script sa page. Ang ibig sabihin nito ay kung may tag manager experiment, compromised dependency, o pasted widget na susubok tumawag ng restricted API, hindi ito dapat bigyan ng browser ng access.

Para sa mga team na maraming contributor, kapaki-pakinabang na default ito. Inililipat nito ang usapan mula sa malabong trust patungo sa malinaw na capability. Kung talagang kailangan ng isang future feature ang camera, may kailangang magbago ng policy at magpaliwanag kung bakit.

Iyon ang tamang uri ng friction.

Ano ang kaya nitong i-lock down sa mga iframe

Lalong nagiging kapaki-pakinabang ang header sa paligid ng embedded content.

Itinuturing na ng mga browser ang mga iframe bilang magkakahiwalay na browsing context, ngunit maaari pa ring humiling ng makapangyarihang feature ang embedded third-party content kung pinapayagan ng policy at iframe attributes. Hinahayaan ng Permissions-Policy ang parent page na magtakda ng ceiling.

Halimbawa, kung nag-e-embed ang page mo ng video player, support widget, at map, maaari mong iwasang bigyan ang bawat frame ng access sa bawat feature. Maaari mong payagan ang fullscreen para lamang sa video frame at geolocation para lamang sa map frame.

May dalawang layer na kailangang maunawaan:

1. Itinatakda ng HTTP Permissions-Policy header ang policy para sa document.
2. Maaaring mag-delegate ang iframe allow attribute ng partikular na features sa isang frame, ngunit sa loob lamang ng pinapayagan ng parent policy.

Maaaring ganito ang isang simpleng iframe:

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

Kung ganap na dine-deny ng header mo ang fullscreen, hindi maaaring i-override ng iframe attribute ang denial na iyon. Kung pinapayagan ng header mo ang fullscreen para sa origin na iyon, maaaring i-delegate ito ng iframe attribute.

Ang hierarchy na ito ay isa sa mga dahilan kung bakit sulit gamitin ang header. Binibigyan nito ang platform o security teams ng paraan para magtakda ng site-wide boundaries, habang pinapayagan pa rin ang product teams na i-enable ang partikular na embeds kung kinakailangan.

Ano ang hindi nito kayang i-lock down

Dito minsan nasosobrahan ang pagtantya ng mga team sa header.

Hindi pinapalitan ng Permissions-Policy ang content security policy. Hindi nito pinapasya kung aling scripts ang maaaring mag-load. Hindi nito pinipigilan ang isang script na magpadala ng data sa network. Hindi nito sina-sanitize ang HTML. Hindi nito pinipigilan ang XSS. Hindi nito hinaharang ang form spam. Kung form abuse ang problema, magsimula sa mechanics na inilalarawan sa kung bakit ang contact form mo ang pinakamalaking spam liability mo, hindi sa header na ito.

Hindi rin nito pinapalitan ang cookie governance. Magkakahiwalay na isyu ang cookies, local storage, consent, third-party embeds, at browser tracking protections. Kung malawakang sinusuri mo ang privacy controls, kailangan ng cookie landscape ng sarili nitong pagsusuri; saklaw ang mga praktikal na pagbabago sa kung ano ang nagbago para sa cookies noong 2026 at ano ang gagawin tungkol dito.

Pinakamahalaga, hindi ginagawa ng Permissions-Policy na private ang third-party JavaScript. Kung nag-load ka ng third-party script sa first-party page mo, karaniwan itong tumatakbo gamit ang mga pribilehiyo ng page mo, na napapailalim sa iba pang browser constraints at security headers mo. Mabuti ang pag-deny ng camera access. Hindi nito pinipigilan ang script na iyon na basahin ang DOM content, obserbahan ang mga kilos ng user, o gumawa ng pinapayagang network requests.

Para roon, kailangan mo ng ibang controls: maingat na vendor selection, CSP, sandboxed iframes, Subresource Integrity kung naaangkop, data minimization, at nakababagot ngunit kinakailangang reviews.

Isang matinong default policy

Walang universal header na angkop sa bawat site, ngunit maaaring magsimula nang restrictive ang karamihan sa content at marketing sites.

Isang makatuwirang unang hakbang:

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

Pagkatapos, ibalik lamang ang talagang ginagamit ng site.

Halimbawa:

• Maaaring kailanganin ng isang store na gumagamit ng Payment Request API ang payment=(self).
• Maaaring kailanganin ng isang location finder ang geolocation=(self) o isang trusted map origin.
• Maaaring kailanganin ng isang conferencing app ang camera=(self) at microphone=(self).
• Maaaring kailanganin ng isang video-heavy site ang fullscreen=(self "https://trusted-video.example").

Ang mahalagang bahagi ay huwag kumopya ng napakalaking policy mula sa checklist at ituring na tapos na. Magsimula sa feature inventory mo. Aling mga page ang nangangailangan ng aling browser capabilities? Aling embeds ang nangangailangan ng delegation? Aling mga feature ang nakakagulat kung hihilingin ang mga ito?

Paano mag-deploy nang hindi nakakasira ng mga bagay

I-roll out ito tulad ng anumang production header: sinasadya at maingat.

1. I-inventory ang paggamit ng feature

Hanapin sa codebase mo ang mga browser API call gaya ng getUserMedia, geolocation, requestFullscreen, PaymentRequest, Web Bluetooth, WebUSB, at wake lock APIs.

Pagkatapos, i-check ang third-party embeds. Madalas binabanggit sa documentation para sa video, maps, payment, at identity providers ang kinakailangang iframe allow values.

2. Magsimula sa low-risk environment

Magdagdag ng restrictive header sa staging at subukan ang core journeys. Bigyang-pansin ang browser console messages. Madalas mag-report ang mga browser kapag may feature na na-block ng permissions policy.

3. Gumamit ng page-specific policies kung kinakailangan

Huwag ipilit ang isang global policy kung may magkakaibang uri ng page ang product mo. Malamang na magkakaiba ang kinakailangang capabilities ng blog, checkout, map page, at video room.

Karamihan sa web servers, frameworks, at edge platforms ay maaaring magtakda ng headers nang conditionally ayon sa path. Madalas mas malinis iyon kaysa pahinain ang buong site para sa isang feature.

4. I-verify ang tunay na response

Maaaring idagdag, i-overwrite, i-duplicate, o alisin ang headers ng CDNs, reverse proxies, app servers, at middleware. I-check ang final response sa browser DevTools o gamit ang command-line tools.

Subukan din ang embedded contexts. Ang paglitaw na tama ng top-level page ay hindi garantiya na natanggap ng isang iframe ang delegation na nilayon mo.

5. I-document ang exceptions

Dapat may owner at dahilan ang bawat pinapayagang feature. Mukha itong burukratiko hanggang makalipas ang anim na buwan, kapag wala nang nakakaalala kung bakit binuksan ang geolocation sa isang vendor domain na hindi na lumilitaw sa page.

Karaniwang pagkakamali sa syntax

Compact ang modernong header syntax ngunit madaling magkamali nang kaunti.

Gumamit ng empty parentheses para i-deny ang isang feature:

Permissions-Policy: microphone=()

Gamitin ang self para sa kasalukuyang origin:

Permissions-Policy: geolocation=(self)

Gumamit ng quoted origins para sa partikular na external origins:

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

Iwasang umasa sa lumang Feature-Policy examples maliban kung sinasadya mong suportahan ang legacy behavior. Gumamit ang mas lumang header ng ibang syntax at hindi iyon ang dapat mong pagbasehan ng design ngayon.

Tandaan din na nag-iiba ang browser support ayon sa directive. Maaaring suportahan ng isang browser ang header ngunit hindi ang partikular na feature directive. Normal iyon. Tratuhin ang header bilang defense-in-depth measure, hindi bilang nag-iisa mong privacy o security control.

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

💡 Subukan ito: I-verify na naihahatid ang iyong Permissions-Policy ayon sa inaasahan gamit ang Get Headers, na nagpapakita ng mga raw response header na ipinapadala ng iyong server.

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

Ang praktikal na halaga nito sa privacy

Ang halaga ng Permissions-Policy sa privacy ay hindi dahil ginagawa nitong anonymous o tracker-free ang isang site. Hindi nito ginagawa iyon.

Ang halaga nito ay pinapaliit nito ang access sa sensitibong browser capabilities. Makapangyarihan ang location, camera, microphone, device sensors, local hardware APIs, at payment flows. Hindi kailangan ng karamihan sa pages ang mga ito. Maraming embedded component ang hindi dapat kailanman makapaghiling ng mga ito.

Tunay na improvement iyon. Binabawasan nito ang aksidenteng prompts, nililimitahan ang hindi kinakailangang capability exposure, at binibigyan ang team mo ng konkretong artifact na rerepasuhin kapag may bagong functionality na inilabas.

Ang pinakamahusay na bersyon ng header na ito ay boring: restrictive by default, pinaluluwag lamang kung kinakailangan ng user-facing feature, at sinusubukan bilang bahagi ng normal na release process.