Perkara yang sebenarnya boleh dikunci oleh header Permissions-Policy

Ringkasan ringkas

Permissions-Policy ialah header respons HTTP yang membolehkan tapak mengehadkan akses kepada ciri pelayar tertentu: kamera, mikrofon, geolokasi, fullscreen, pembayaran, sensor, dan senarai panjang API yang lebih kecil.

Ia bukan perisai privasi umum. Ia tidak akan menghentikan semua penjejakan, menyekat kuki, menghalang permintaan rangkaian, atau menjadikan JavaScript pihak ketiga selamat. Perkara yang boleh dilakukannya dengan baik adalah lebih sempit tetapi tetap bernilai: mengurangkan keupayaan pelayar yang tersedia kepada halaman anda sendiri dan kepada frame terbenam.

Ini penting kerana laman web moden digabungkan daripada coretan analitik, benaman media, widget sembang, pengurus persetujuan, skrip pengiklanan, peta, aliran pembayaran, dan eksperimen dalaman. Kebanyakan komponen tersebut tidak memerlukan akses kepada API peranti yang berkuasa. Dasar yang baik menjadikannya jelas.

Jika anda sudah menyemak header dalam produksi, padankan kerja ini dengan semakan langsung terhadap respons sebenar. Panduan kami untuk menyahpepijat redirect dan header HTTP dalam produksi merangkumi tabiat yang penting di sini: periksa perkara yang benar-benar diterima oleh pelayar, bukan perkara yang dikatakan oleh fail konfigurasi anda sepatutnya berlaku.

Perkara yang dikawal oleh Permissions-Policy

Header ini mengawal akses kepada ciri pelayar yang dinamakan. Senarai tepat berubah dari semasa ke semasa kerana API pelayar berubah, tetapi arahan lazim termasuk:

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

Sesuatu arahan boleh membenarkan ciri untuk tiada sesiapa, untuk origin semasa, atau untuk origin terpilih. Contohnya:

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

Ini bermakna kamera dan mikrofon dilumpuhkan untuk dokumen dan konteks pelayaran bersarangnya, manakala geolokasi hanya dibenarkan untuk origin yang sama.

Contoh yang lebih permisif:

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

Ini membenarkan origin anda sendiri dan satu penyedia peta yang dinamakan untuk menggunakan geolokasi, serta origin anda sendiri bersama penyedia video untuk meminta fullscreen.

Dasar ini dinilai oleh pelayar. Jika sesuatu ciri tidak dibenarkan, JavaScript yang menggunakan API tersebut sepatutnya gagal atau berkelakuan seolah-olah tidak tersedia. Mod kegagalan tepat bergantung pada API. Kadangkala promise ditolak. Kadangkala sesuatu keupayaan hanya kelihatan tidak boleh digunakan.

Perkara yang boleh dikunci pada halaman anda sendiri

Pada halaman pihak pertama, Permissions-Policy paling berguna sebagai pagar keselamatan. Ia mengurangkan kesan letupan daripada kod yang tidak sengaja atau tidak dijangka.

Halaman pemasaran, sebagai contoh, mungkin tidak memerlukan mikrofon, kamera, Bluetooth, USB, sensor gerakan, atau API pembayaran. Anda boleh menafikan ciri tersebut secara global:

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

Itu tidak menjadikan setiap skrip pada halaman boleh dipercayai. Ia bermakna jika eksperimen tag manager, dependency yang dikompromi, atau widget yang ditampal cuba memanggil API yang disekat, pelayar tidak sepatutnya memberikan akses kepadanya.

Bagi pasukan dengan ramai penyumbang, ini ialah lalai yang berguna. Ia mengalihkan perbualan daripada kepercayaan yang kabur kepada keupayaan yang jelas. Jika ciri masa depan benar-benar memerlukan kamera, seseorang perlu mengubah dasar dan menjelaskan sebabnya.

Itulah jenis geseran yang betul.

Perkara yang boleh dikunci dalam iframe

Header ini menjadi sangat berguna khususnya untuk kandungan terbenam.

Pelayar sudah menganggap iframe sebagai konteks pelayaran berasingan, tetapi kandungan pihak ketiga yang terbenam masih boleh meminta ciri yang berkuasa jika dibenarkan oleh dasar dan atribut iframe. Permissions-Policy membolehkan halaman induk menetapkan had maksimum.

Sebagai contoh, jika halaman anda membenamkan pemain video, widget sokongan, dan peta, anda boleh mengelakkan daripada memberikan setiap frame akses kepada setiap ciri. Anda mungkin membenarkan fullscreen hanya untuk frame video dan geolokasi hanya untuk frame peta.

Ada dua lapisan yang perlu difahami:

1. Header HTTP Permissions-Policy menetapkan dasar untuk dokumen.
2. Atribut allow iframe boleh mewakilkan ciri tertentu kepada frame, tetapi hanya dalam lingkungan yang dibenarkan oleh dasar induk.

Iframe ringkas mungkin kelihatan seperti ini:

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

Jika header anda menafikan fullscreen sepenuhnya, atribut iframe tidak boleh mengatasi penafian itu. Jika header anda membenarkan fullscreen untuk origin tersebut, atribut iframe boleh mewakilkannya.

Hierarki ini ialah salah satu sebab header ini berbaloi digunakan. Ia memberikan pasukan platform atau keselamatan cara untuk menetapkan sempadan seluruh tapak, sambil tetap membenarkan pasukan produk mengaktifkan benaman tertentu apabila diperlukan.

Perkara yang tidak boleh dikunci

Di sinilah pasukan kadangkala terlebih menganggarkan header ini.

Permissions-Policy tidak menggantikan content security policy. Ia tidak menentukan skrip mana yang boleh dimuatkan. Ia tidak menghentikan skrip daripada menghantar data melalui rangkaian. Ia tidak membersihkan HTML. Ia tidak mencegah XSS. Ia tidak menyekat spam borang. Jika penyalahgunaan borang ialah masalahnya, mulakan dengan mekanik yang diterangkan dalam sebab borang hubungan anda ialah liabiliti spam terbesar anda, bukan dengan header ini.

Ia juga tidak menggantikan tadbir urus kuki. Kuki, local storage, persetujuan, benaman pihak ketiga, dan perlindungan penjejakan pelayar ialah isu berasingan. Jika anda menyemak kawalan privasi secara meluas, landskap kuki memerlukan semakan tersendiri; perubahan praktikal dibincangkan dalam perkara yang berubah untuk kuki pada 2026 dan apa yang perlu dilakukan mengenainya.

Paling penting, Permissions-Policy tidak menjadikan JavaScript pihak ketiga peribadi. Jika anda memuatkan skrip pihak ketiga ke dalam halaman pihak pertama anda, secara amnya ia berjalan dengan keistimewaan halaman anda, tertakluk kepada kekangan pelayar lain dan header keselamatan anda. Menafikan akses kamera adalah baik. Ia tidak menghentikan skrip itu daripada membaca kandungan DOM, memerhati tindakan pengguna, atau membuat permintaan rangkaian yang dibenarkan.

Untuk itu, anda memerlukan kawalan berbeza: pemilihan vendor yang teliti, CSP, iframe bersandbox, Subresource Integrity jika berkenaan, peminimuman data, dan semakan yang membosankan tetapi perlu.

Dasar lalai yang munasabah

Tiada header universal yang sesuai untuk setiap tapak, tetapi kebanyakan tapak kandungan dan pemasaran boleh bermula secara ketat.

Percubaan pertama yang munasabah:

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

Kemudian tambah semula hanya perkara yang benar-benar digunakan oleh tapak.

Contohnya:

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

Bahagian pentingnya bukan menyalin dasar yang sangat besar daripada senarai semak dan menganggapnya selesai. Mulakan dengan inventori ciri anda. Halaman mana memerlukan keupayaan pelayar yang mana? Benaman mana memerlukan perwakilan? Ciri mana yang akan mengejutkan jika diminta?

Cara melaksanakan tanpa merosakkan perkara lain

Laksanakan ini seperti mana-mana header produksi lain: secara sengaja.

1. Inventori penggunaan ciri

Cari panggilan API pelayar dalam codebase anda seperti getUserMedia, geolocation, requestFullscreen, PaymentRequest, Web Bluetooth, WebUSB, dan API wake lock.

Kemudian semak benaman pihak ketiga. Dokumentasi untuk penyedia video, peta, pembayaran, dan identiti sering menyebut nilai allow iframe yang diperlukan.

2. Mulakan dalam persekitaran berisiko rendah

Tambah header yang ketat dalam staging dan uji perjalanan teras. Beri perhatian kepada mesej konsol pelayar. Pelayar sering melaporkan apabila sesuatu ciri disekat oleh permissions policy.

3. Gunakan dasar khusus halaman apabila perlu

Jangan paksa satu dasar global jika produk anda mempunyai jenis halaman yang sangat berbeza. Blog, checkout, halaman peta, dan bilik video mungkin memerlukan keupayaan yang berbeza.

Kebanyakan pelayan web, framework, dan platform edge boleh menetapkan header secara bersyarat mengikut path. Itu selalunya lebih bersih daripada melemahkan seluruh tapak untuk satu ciri.

4. Sahkan respons sebenar

Header boleh ditambah, ditimpa, diduplikasi, atau dibuang oleh CDN, reverse proxy, pelayan aplikasi, dan middleware. Semak respons akhir dalam browser DevTools atau dengan alat command-line.

Uji juga konteks terbenam. Halaman aras atas yang kelihatan betul tidak menjamin iframe menerima perwakilan yang anda maksudkan.

5. Dokumentasikan pengecualian

Setiap ciri yang dibenarkan harus mempunyai pemilik dan sebab. Ini kedengaran birokratik sehinggalah enam bulan kemudian, apabila tiada siapa ingat mengapa geolocation dibuka kepada domain vendor yang tidak lagi muncul pada halaman.

Kesilapan sintaks lazim

Sintaks header moden adalah padat tetapi mudah sedikit tersilap.

Gunakan tanda kurung kosong untuk menafikan ciri:

Permissions-Policy: microphone=()

Gunakan self untuk origin semasa:

Permissions-Policy: geolocation=(self)

Gunakan origin bertanda petik untuk origin luaran tertentu:

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

Elakkan bergantung pada contoh Feature-Policy lama melainkan anda sengaja menyokong tingkah laku legasi. Header lama menggunakan sintaks berbeza dan bukan sesuatu yang patut anda jadikan asas reka bentuk hari ini.

Ingat juga bahawa sokongan pelayar berbeza mengikut arahan. Pelayar mungkin menyokong header ini tetapi tidak menyokong arahan ciri tertentu. Itu perkara biasa. Anggap header ini sebagai langkah defense-in-depth, bukan sebagai satu-satunya kawalan privasi atau keselamatan anda.

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

💡 Cuba ini: Sahkan bahawa Permissions-Policy anda dihantar seperti yang dimaksudkan dengan Get Headers, yang memaparkan pengepala respons mentah yang dihantar oleh pelayan anda.

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

Nilai privasi praktikal

Nilai privasi Permissions-Policy bukanlah bahawa ia menjadikan tapak tanpa nama atau bebas penjejak. Ia tidak begitu.

Nilainya ialah ia menyempitkan akses kepada keupayaan pelayar yang sensitif. Lokasi, kamera, mikrofon, sensor peranti, API perkakasan tempatan, dan aliran pembayaran adalah berkuasa. Kebanyakan halaman tidak memerlukannya. Banyak komponen terbenam tidak sepatutnya boleh memintanya sama sekali.

Itu ialah peningkatan sebenar. Ia mengurangkan prompt yang tidak disengajakan, mengehadkan pendedahan keupayaan yang tidak perlu, dan memberikan pasukan anda artifak konkrit untuk disemak apabila fungsi baharu dihantar.

Versi terbaik header ini adalah membosankan: ketat secara lalai, dilonggarkan hanya apabila ciri yang berhadapan pengguna memerlukannya, dan diuji sebagai sebahagian daripada proses keluaran biasa.