Permissions-Policy Mempersempit Akses Fitur Browser

Dokumen web dapat berada dekat dengan kapabilitas browser yang kuat. Bergantung pada dukungan browser, konteks, izin pengguna, dan policy, kode dapat meminta akses ke fitur seperti geolocation, camera, microphone, atau fullscreen. Dokumen yang disematkan juga dapat mewarisi akses ke sebagian fitur dari halaman yang memuatnya.

Permissions-Policy menambahkan lapisan pembatasan yang dikendalikan server. Response dapat menyatakan origin mana yang memenuhi syarat untuk memakai fitur tertentu pada dokumen dan frame tree-nya. Policy ini tidak memberikan izin pengguna dan tidak membuat sebuah origin menjadi tepercaya. Fungsinya adalah menghapus kapabilitas dari konteks yang tidak memerlukannya.

Policy adalah batas atas, bukan pemberian izin

Response header dapat membatasi fitur hanya untuk origin dokumen sendiri:

Permissions-Policy: geolocation=(self)

Fitur juga dapat dinonaktifkan untuk dokumen beserta turunannya:

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

Deklarasi tersebut menetapkan batas policy. Ia tidak melewati prompt browser, kontrol sistem operasi, persyaratan secure context, atau otorisasi aplikasi. Jika penggunaan camera diizinkan oleh policy, browser tetap dapat meminta izin pengguna sebelum API berhasil.

Perbedaan ini penting dalam tinjauan keamanan. Policy yang permisif tidak sama dengan request kapabilitas yang berhasil, sedangkan policy restriktif dapat menghentikan request sebelum izin pengguna menjadi relevan.

Frame yang disematkan memerlukan delegasi eksplisit

Frame pihak ketiga sering menjadi titik tempat batas kapabilitas menjadi kabur. Halaman dapat menyematkan antarmuka pembayaran, dukungan, analytics, media, atau kolaborasi. Sebagian besar frame tersebut tidak memerlukan semua fitur browser yang tersedia bagi aplikasi tingkat atas.

Response tingkat atas dapat menyebut origin untuk sebuah fitur:

Permissions-Policy: microphone=(self "https://calls.example")

Iframe juga dapat membawa atribut allow yang mempersempit fitur untuk frame tersebut:

<iframe
  src="https://calls.example/room"
  allow="microphone"
></iframe>

Izin efektif dibatasi oleh rangkaian policy di sekelilingnya. Atribut iframe tidak dapat memperluas akses melewati pembatasan yang ditetapkan response policy milik ancestor. Perlakukan delegasi sebagai kontrak eksplisit: halaman penyemat menentukan fitur dan konteks penerima, bukan mengandalkan akses ambient yang luas.

Pencocokan origin juga perlu diperhatikan. Origin yang disebut adalah batas keamanan, bukan label untuk seluruh layanan milik organisasi yang sama. Scheme, host, dan port ikut menentukan identitas origin. Perubahan deployment karena itu perlu disertai peninjauan policy saat layanan yang disematkan berpindah origin.

Default berbeda antarfitur

Tidak ada asumsi aman bahwa setiap fitur yang dikendalikan memiliki default allowlist yang sama. Definisi fitur dapat berbeda dan dukungan browser dapat bervariasi. Policy sebaiknya dibangun dari fitur spesifik yang dipakai aplikasi, bukan disalin dari kumpulan header yang tidak terkait.

Hal ini juga membuat deny list raksasa rapuh. Daftar panjang dapat terlihat lengkap tetapi tetap melewatkan fitur yang penting bagi aplikasi atau menyebut directive yang tidak didukung browser target. Policy yang lebih kecil dan terikat pada inventaris penggunaan kapabilitas lebih mudah diuji dan dirawat.

Untuk batas bernilai tinggi, uji perilaku pada browser yang didukung aplikasi. Keberadaan header saja tidak membuktikan bahwa fitur tertentu dikendalikan sesuai maksud.

Policy tidak menggantikan izin pengguna

Pertimbangkan geolocation. Situs dapat mengirim:

Permissions-Policy: geolocation=(self)

Konfigurasi itu membatasi kelayakan ke origin yang sama. JavaScript pada origin tersebut tetap mengikuti model izin geolocation milik browser. Header tidak menyetujui request lokasi secara diam-diam.

Arah sebaliknya juga penting. Pengguna mungkin pernah memberi izin geolocation kepada sebuah origin, tetapi embedding policy tetap dapat membuat fitur itu tidak tersedia pada konteks dokumen tertentu. Izin browser dan document policy menjawab pertanyaan yang berbeda.

Pemisahan ini mendukung defense in depth. Persetujuan pengguna mengatur apakah konteks yang memiliki kapabilitas boleh menerima akses sensitif. Document policy mempersempit konteks mana yang memiliki kapabilitas untuk meminta akses tersebut.

Policy bukan sandbox

Permissions-Policy bukan mekanisme isolasi umum untuk konten berbahaya. Ia tidak menggantikan atribut iframe sandbox, Content Security Policy, pemisahan origin, autentikasi, atau otorisasi.

Frame yang tidak mendapat akses camera masih dapat memiliki kemampuan lain melalui origin, kredensial, konteks DOM, akses jaringan, atau konfigurasi embedding. Desain keamanan harus menangani jalur tersebut secara terpisah.

Demikian pula, mengizinkan sebuah fitur tidak memvalidasi kode yang menggunakannya. Jika origin yang disematkan terkompromi, kapabilitas yang didelegasikan dapat berguna bagi penyerang dalam batas policy browser dan izin pengguna. Delegasikan hanya fitur yang diperlukan fungsi tersebut.

Rollout dimulai dari inventaris kapabilitas

Mulai dari jalur aplikasi yang memanggil fitur browser yang dikendalikan. Catat origin tingkat atas, origin yang disematkan, fitur yang diperlukan, dan dukungan browser yang diharapkan. Susun policy dari inventaris tersebut.

Baseline restriktif dapat berbentuk:

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

Aplikasi yang memerlukan salah satu fitur dapat membuka hanya batas yang diperlukan. Sebagai contoh, halaman lokasi first-party dapat memakai geolocation=(self) sambil tetap menonaktifkan camera dan microphone.

Uji alur tingkat atas dan embedded setelah deployment. Sertakan kasus positif, saat fitur yang memang diperlukan tetap bekerja, serta kasus negatif, saat frame yang tidak terkait tidak dapat memakainya. Periksa juga response akhir setelah pemrosesan CDN, reverse proxy, dan middleware aplikasi agar policy yang diuji sama dengan policy yang diterima browser.

Policy yang berguna cukup sempit untuk menyatakan maksud arsitektur dan cukup kecil agar tetap akurat. Saat kebutuhan kapabilitas berubah, perbarui inventaris dan header secara bersamaan agar delegasi lama tidak bertahan sebagai privilege yang tersembunyi.