Apa yang sebenarnya dapat dikunci oleh header Permissions-Policy

Versi singkat

Permissions-Policy adalah header respons HTTP yang memungkinkan sebuah situs membatasi akses ke fitur browser tertentu: kamera, mikrofon, geolokasi, fullscreen, pembayaran, sensor, dan daftar panjang API yang lebih kecil.

Ini bukan perisai privasi umum. Ini tidak akan menghentikan semua pelacakan, memblokir cookie, mencegah permintaan jaringan, atau membuat JavaScript pihak ketiga aman. Yang dapat dilakukannya dengan baik lebih sempit tetapi tetap bernilai: mengurangi kapabilitas browser yang tersedia bagi halaman Anda sendiri dan frame yang disematkan.

Hal itu penting karena situs web modern tersusun dari potongan analytics, sematan media, widget chat, pengelola consent, skrip iklan, peta, alur pembayaran, dan eksperimen internal. Sebagian besar komponen tersebut tidak memerlukan akses ke API perangkat yang kuat. Kebijakan yang baik membuat hal itu eksplisit.

Jika Anda sudah meninjau header di produksi, padukan pekerjaan ini dengan pemeriksaan langsung terhadap respons yang sebenarnya. Panduan kami tentang debugging redirect dan header HTTP di produksi membahas kebiasaan yang penting di sini: periksa apa yang benar-benar diterima browser, bukan apa yang menurut file konfigurasi Anda seharusnya terjadi.

Apa yang dikontrol Permissions-Policy

Header ini mengontrol akses ke fitur browser bernama. Daftar persisnya berubah seiring waktu karena API browser berubah, tetapi directive yang umum mencakup:

• camera
• microphone
• geolocation
• fullscreen
• payment
• usb
• bluetooth
• accelerometer
• gyroscope
• magnetometer
• screen-wake-lock
• clipboard-read
• clipboard-write
• publickey-credentials-get
• interest-cohort dalam diskusi lama, kini sebagian besar bersifat historis

Sebuah directive dapat mengizinkan fitur untuk tidak siapa pun, untuk origin saat ini, atau untuk origin tertentu. Contohnya:

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

Ini berarti kamera dan mikrofon dinonaktifkan untuk dokumen dan konteks browsing bertingkat di dalamnya, sementara geolokasi hanya diizinkan untuk origin yang sama.

Contoh yang lebih permisif:

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

Ini mengizinkan origin Anda sendiri dan satu penyedia peta bernama untuk menggunakan geolokasi, serta origin Anda sendiri ditambah satu penyedia video untuk meminta fullscreen.

Kebijakan dievaluasi oleh browser. Jika sebuah fitur tidak diizinkan, JavaScript yang menggunakan API tersebut seharusnya gagal atau berperilaku seolah tidak tersedia. Mode kegagalan yang tepat bergantung pada API. Terkadang sebuah promise ditolak. Terkadang sebuah kapabilitas sekadar tampak tidak dapat digunakan.

Apa yang dapat dikunci pada halaman Anda sendiri

Pada halaman first-party, Permissions-Policy paling berguna sebagai pagar pengaman. Ini mengurangi radius dampak dari kode yang tidak disengaja atau tidak terduga.

Halaman marketing, misalnya, kemungkinan tidak memerlukan mikrofon, kamera, Bluetooth, USB, sensor gerak, atau API pembayaran. Anda dapat menolak fitur-fitur tersebut secara global:

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

Itu tidak membuat setiap skrip di halaman menjadi tepercaya. Namun, itu berarti jika eksperimen tag manager, dependency yang kompromi, atau widget yang ditempel mencoba memanggil API yang dibatasi, browser seharusnya tidak memberinya akses.

Untuk tim dengan banyak kontributor, ini adalah default yang berguna. Ini menggeser percakapan dari kepercayaan yang samar menjadi kapabilitas yang eksplisit. Jika fitur masa depan benar-benar membutuhkan kamera, seseorang harus mengubah kebijakan dan menjelaskan alasannya.

Itulah jenis friksi yang tepat.

Apa yang dapat dikunci di iframe

Header ini menjadi sangat berguna di sekitar konten yang disematkan.

Browser sudah memperlakukan iframe sebagai konteks browsing yang terpisah, tetapi konten pihak ketiga yang disematkan tetap dapat meminta fitur yang kuat jika diizinkan oleh kebijakan dan atribut iframe. Permissions-Policy memungkinkan halaman induk menetapkan batas atas.

Misalnya, jika halaman Anda menyematkan pemutar video, widget dukungan, dan peta, Anda dapat menghindari memberi setiap frame akses ke setiap fitur. Anda mungkin mengizinkan fullscreen hanya untuk frame video dan geolokasi hanya untuk frame peta.

Ada dua lapisan yang perlu dipahami:

1. Header HTTP Permissions-Policy menetapkan kebijakan untuk dokumen.
2. Atribut iframe allow dapat mendelegasikan fitur tertentu ke sebuah frame, tetapi hanya dalam batas yang diizinkan oleh kebijakan induk.

Iframe sederhana mungkin terlihat seperti ini:

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

Jika header Anda sepenuhnya menolak fullscreen, atribut iframe tidak dapat menimpa penolakan itu. Jika header Anda mengizinkan fullscreen untuk origin tersebut, atribut iframe dapat mendelegasikannya.

Hierarki ini adalah salah satu alasan header ini layak digunakan. Ini memberi tim platform atau keamanan cara untuk menetapkan batasan seluruh situs, sambil tetap memungkinkan tim produk mengaktifkan sematan tertentu saat diperlukan.

Apa yang tidak dapat dikunci

Di sinilah tim terkadang melebih-lebihkan header ini.

Permissions-Policy tidak menggantikan content security policy. Ini tidak menentukan skrip mana yang boleh dimuat. Ini tidak menghentikan skrip mengirim data melalui jaringan. Ini tidak membersihkan HTML. Ini tidak mencegah XSS. Ini tidak memblokir spam formulir. Jika penyalahgunaan formulir adalah masalahnya, mulailah dengan mekanisme yang dijelaskan dalam mengapa formulir kontak Anda adalah liabilitas spam terbesar Anda, bukan dengan header ini.

Ini juga tidak menggantikan tata kelola cookie. Cookie, local storage, consent, sematan pihak ketiga, dan proteksi pelacakan browser adalah isu yang terpisah. Jika Anda meninjau kontrol privasi secara luas, lanskap cookie membutuhkan pemeriksaan tersendiri; perubahan praktisnya dibahas dalam apa yang berubah untuk cookie pada 2026 dan apa yang harus dilakukan.

Yang paling penting, Permissions-Policy tidak membuat JavaScript pihak ketiga menjadi privat. Jika Anda memuat skrip pihak ketiga ke halaman first-party Anda, skrip itu umumnya berjalan dengan privilese halaman Anda, tunduk pada batasan browser lain dan header keamanan Anda. Menolak akses kamera itu baik. Namun, itu tidak menghentikan skrip tersebut membaca konten DOM, mengamati tindakan pengguna, atau membuat permintaan jaringan yang diizinkan.

Untuk itu, Anda memerlukan kontrol yang berbeda: pemilihan vendor yang cermat, CSP, iframe dengan sandbox, Subresource Integrity jika berlaku, minimisasi data, dan peninjauan yang membosankan tetapi perlu.

Kebijakan default yang masuk akal

Tidak ada header universal yang cocok untuk setiap situs, tetapi sebagian besar situs konten dan marketing dapat memulai dengan ketat.

Langkah awal yang wajar:

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

Kemudian tambahkan kembali hanya yang benar-benar digunakan situs.

Contohnya:

• Toko yang menggunakan Payment Request API mungkin memerlukan payment=(self).
• Pencari lokasi mungkin memerlukan geolocation=(self) atau origin peta tepercaya.
• Aplikasi konferensi mungkin memerlukan camera=(self) dan microphone=(self).
• Situs yang banyak menggunakan video mungkin memerlukan fullscreen=(self "https://trusted-video.example").

Bagian pentingnya adalah tidak menyalin kebijakan yang sangat besar dari checklist lalu menganggapnya selesai. Mulailah dengan inventaris fitur Anda. Halaman mana yang membutuhkan kapabilitas browser apa? Sematan mana yang membutuhkan delegasi? Fitur mana yang akan mengejutkan jika diminta?

Cara menerapkan tanpa merusak apa pun

Luncurkan ini seperti header produksi lainnya: secara sengaja.

1. Inventarisasi penggunaan fitur

Cari di codebase Anda panggilan API browser seperti getUserMedia, geolocation, requestFullscreen, PaymentRequest, Web Bluetooth, WebUSB, dan API wake lock.

Kemudian periksa sematan pihak ketiga. Dokumentasi untuk penyedia video, peta, pembayaran, dan identitas sering menyebut nilai iframe allow yang diperlukan.

2. Mulai di lingkungan berisiko rendah

Tambahkan header yang ketat di staging dan uji perjalanan inti. Perhatikan pesan konsol browser. Browser sering melaporkan saat sebuah fitur diblokir oleh permissions policy.

3. Gunakan kebijakan spesifik halaman jika perlu

Jangan memaksakan satu kebijakan global jika produk Anda memiliki tipe halaman yang sangat berbeda. Blog, checkout, halaman peta, dan ruang video kemungkinan membutuhkan kapabilitas yang berbeda.

Sebagian besar web server, framework, dan edge platform dapat menetapkan header secara kondisional berdasarkan path. Itu sering lebih rapi daripada melemahkan seluruh situs demi satu fitur.

4. Verifikasi respons sebenarnya

Header dapat ditambahkan, ditimpa, digandakan, atau dihapus oleh CDN, reverse proxy, app server, dan middleware. Periksa respons final di browser DevTools atau dengan command-line tools.

Uji juga konteks yang disematkan. Halaman tingkat atas yang tampak benar tidak menjamin bahwa iframe menerima delegasi yang Anda maksudkan.

5. Dokumentasikan pengecualian

Setiap fitur yang diizinkan harus memiliki pemilik dan alasan. Ini terdengar birokratis sampai enam bulan kemudian, ketika tidak ada yang ingat mengapa geolocation dibuka untuk domain vendor yang tidak lagi muncul di halaman.

Kesalahan sintaks umum

Sintaks header modern ringkas tetapi mudah sedikit keliru.

Gunakan tanda kurung kosong untuk menolak sebuah fitur:

Permissions-Policy: microphone=()

Gunakan self untuk origin saat ini:

Permissions-Policy: geolocation=(self)

Gunakan origin dalam tanda kutip untuk origin eksternal tertentu:

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

Hindari mengandalkan contoh Feature-Policy lama kecuali Anda memang sengaja mendukung perilaku legacy. Header yang lebih lama menggunakan sintaks berbeda dan bukan sesuatu yang seharusnya menjadi dasar desain Anda hari ini.

Ingat juga bahwa dukungan browser bervariasi menurut directive. Sebuah browser mungkin mendukung header ini tetapi tidak mendukung directive fitur tertentu. Itu normal. Perlakukan header ini sebagai langkah defense-in-depth, bukan sebagai satu-satunya kontrol privasi atau keamanan Anda.

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

💡 Coba ini: Verifikasi bahwa Permissions-Policy Anda dikirimkan sebagaimana mestinya dengan Get Headers, yang menampilkan header respons mentah yang dikirim server Anda.

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

Nilai privasi praktisnya

Nilai privasi Permissions-Policy bukan karena membuat situs menjadi anonim atau bebas tracker. Tidak demikian.

Nilainya adalah mempersempit akses ke kapabilitas browser yang sensitif. Lokasi, kamera, mikrofon, sensor perangkat, API perangkat keras lokal, dan alur pembayaran adalah hal yang kuat. Sebagian besar halaman tidak membutuhkannya. Banyak komponen yang disematkan seharusnya tidak pernah dapat memintanya.

Itu adalah perbaikan nyata. Ini mengurangi prompt yang tidak disengaja, membatasi paparan kapabilitas yang tidak perlu, dan memberi tim Anda artefak konkret untuk ditinjau saat fungsionalitas baru dirilis.

Versi terbaik dari header ini terasa membosankan: ketat secara default, dilonggarkan hanya ketika fitur yang terlihat oleh pengguna membutuhkannya, dan diuji sebagai bagian dari proses rilis normal.