Temu Duga Frontend: Bagaimanakah Anda Mereka Bentuk Permissions Policy yang Selamat untuk Ciri Terbenam?

Soalan dan skop

Anda memiliki papan pemuka yang membenamkan meet.example untuk panggilan, video.example untuk main balik, dan beberapa bingkai iklan. Bingkai mesyuarat memerlukan microphone dan camera; bingkai video memerlukan fullscreen; iklan tidak memerlukan sebarang ciri ini. Halaman menggunakan HTTPS, asal bingkai diketahui, dan pelayar masih mesti meminta persetujuan media daripada pengguna apabila dasar membenarkannya.

Skopnya ialah komposisi dan diagnosis dasar di sisi pelayar. Pengesahan (authentication), CSP, dan kebenaran pelayan (server authorization) kekal sebagai kawalan berasingan. Andaikan pengepala respons ditetapkan oleh pelayan papan pemuka dan setiap bingkai rentas asal mempunyai atribut allow yang eksplisit.

Perkara yang diuji oleh penemu duga

Penemu duga mahu anda memisahkan tiga pintu kawalan: dasar respons, delegasi bingkai, dan kebenaran masa jalanan (runtime permission) pengguna. Senarai izin pengepala sahaja tidak memberikan akses kepada bingkai rentas asal, dan atribut allow tidak boleh meluaskan pengepala yang menafikan ciri tersebut.

Mereka juga menguji sama ada anda mengelakkan kemudahan kad liar (wildcard). Jawapan yang kukuh bermula daripada () untuk ciri sensitif, menamakan asal yang tepat, mengendalikan navigasi bersarang, dan menerangkan perkara yang dilakukan oleh UI apabila API tidak tersedia. Jawapan yang lemah menulis *, menunggu gesaan kebenaran, dan menganggap ciri tersebut selamat.

Soalan untuk dijelaskan sebelum menjawab

• Apakah asal tepat yang boleh dilayari oleh bingkai mesyuarat dan video? Navigasi ke asal yang berbeza mungkin memerlukan destinasi tersebut dalam dasar bingkai, atau ciri tersebut mesti dinafikan selepas navigasi.
• Adakah bingkai mesyuarat membuka bingkai bersarang? Jika ya, tentukan sama ada delegasi boleh diteruskan dan uji asal bersarang tersebut dan bukannya menganggap kebenaran bingkai pertama diwarisi selama-lamanya.
• Pelayar dan webview terbenam manakah yang disokong? Sintaks dasar boleh jadi betul manakala persekitaran masa jalanan yang lebih lama mendedahkan permukaan kegagalan yang berbeza.
• Adakah panggilan kamera atau mikrofon wajib? Jika ia pilihan, UI boleh menawarkan laluan teks sahaja apabila dasar atau kebenaran pengguna dinafikan.

Rangka kerja jawapan 30 saat

"Saya akan menetapkan kamera dan mikrofon secara lalai kepada () dan memberikannya hanya kepada asal mesyuarat dalam dasar respons. Saya akan memberikan skrin penuh hanya kepada asal video. Setiap iframe rentas asal akan mengulangi ciri yang dimaksudkan dalam atribut allow miliknya, kerana pengepala dan dasar bingkai kedua-duanya diperlukan. Bingkai akan mengesan penafian dasar secara berasingan daripada penafian pengguna, memaparkan sandaran (fallback), dan tidak sekali-kali menganggap gesaan kebenaran sebagai kebenaran masuk (authorization). Saya akan menguji kes same-origin, cross-origin, navigasi, bingkai bersarang, ketiadaan pengepala, dan sandaran pelayar sebelum pelancaran."

Jawapan mendalam langkah demi langkah

Langkah 1: Mulakan dengan inventori nafi-secara-lalai (deny-by-default)

Senaraikan setiap ciri yang dikawal dasar yang digunakan oleh halaman dan asal pemiliknya. Jangan buat kesimpulan kebenaran daripada nama produk "meeting". Kamera dan mikrofon adalah dua ciri yang bebas. Skrin penuh adalah ciri lain. Iklan ialah kelas akses sifar yang jelas.

Gunakan pengepala eksplisit seperti:

Permissions-Policy: camera=(self "https://meet.example"), microphone=(self "https://meet.example"), fullscreen=(self "https://video.example")

Senarai asal yang tepat menghalang bingkai yang tidak berkaitan daripada menerima kebenaran. Jika papan pemuka itu sendiri tidak boleh mengakses sesuatu ciri, alih keluar self dan berikan hanya kepada asal bingkai yang diperlukan, kemudian sahkan dasar induk masih membenarkan delegasi.

Langkah 2: Delegasikan pada setiap sempadan iframe

Bingkai mesyuarat hanya menerima dua cirinya, dan bingkai video hanya menerima skrin penuh:

<iframe src="https://meet.example/room" allow="camera; microphone"></iframe>
<iframe src="https://video.example/player" allow="fullscreen"></iframe>
<iframe src="https://ad.example/slot" allow=""></iframe>

Bagi bingkai rentas asal, meninggalkan allow akan menyekat ciri tersebut walaupun pengepala respons menyenaraikan asal tersebut. Sebaliknya, menambahkan allow="camera" pada iklan tidak mengatasi camera=() atau asal yang tidak terdapat dalam pengepala.

Langkah 3: Layani dasar dan persetujuan pengguna sebagai keadaan yang berbeza

Permissions-Policy menentukan sama ada dokumen boleh menggunakan ciri tersebut. Permissions API dan gesaan media mewakili kebenaran yang diberikan oleh pengguna. Ciri yang disekat mungkin gagal sebelum gesaan muncul. Bingkai harus memetakan "dasar dinafikan", "pengguna menafikan", "tidak disokong", dan "peranti sibuk" kepada telemetri dan teks pemulihan yang berbeza.

Jangan jadikan semakan sisi klien sebagai sempadan keselamatan. Halaman yang membenamkan mengawal delegasi, manakala aplikasi masih mengesahkan panggilan dan memberi kebenaran keahlian bilik pada pelayan.

Langkah 4: Kendalikan navigasi dan bingkai bersarang secara eksplisit

Jika bingkai mesyuarat boleh menavigasi ke asal sokongan, sertakan destinasi tersebut dalam dasar allow hanya jika ia dipercayai dan memerlukan ciri yang sama. Asal src awal bingkai dan asal navigasi kemudiannya tidak boleh ditukar ganti. Untuk bingkai bersarang, sahkan dasar berkesan pada setiap sempadan dan nafikan secara lalai apabila pemilikan tidak jelas.

Langkah 5: Lancarkan dengan ujian yang boleh diperhatikan

Hantar pengepala dalam diagnostik report-only atau kohort laluan kecil apabila platform membenarkannya, kemudian bandingkan pelanggaran dasar, hasil gesaan, penyiapan panggilan, dan penggunaan sandaran. Uji bingkai same-origin, bingkai cross-origin yang dibenarkan, bingkai cross-origin yang tidak disenaraikan, atribut allow yang tiada, subdomain yang diubah, dan navigasi bingkai. Pastikan iklan tidak pernah mencapai gesaan dan bingkai mesyuarat yang dinafikan menawarkan sembang teks.

Contoh jawapan berkualiti tinggi

"Saya akan menulis dasar daripada model ancaman. Kamera dan mikrofon bermula sebagai kebenaran kosong, kemudian pengepala menyenaraikan hanya meet.example; skrin penuh hanya menyenaraikan video.example. Kedua-dua bingkai rentas asal membawa atribut allow yang sepadan, manakala bingkai iklan tidak membawa apa-apa. Pelayar masih mengawal persetujuan pengguna, jadi kod mesyuarat membezakan sekatan dasar daripada penafian pengguna dan menawarkan sandaran teks sahaja. Saya tidak akan meletakkan pengesahan kebenaran dalam pengepala ini: pelayan masih menyemak bilik dan pengguna.

Sebelum mendayakannya secara global, saya akan melaksanakan matriks: asal yang dibenarkan dan tidak disenaraikan, subdomain tapak-sama (same-site) tetapi rentas-asal (cross-origin), ketiadaan allow, navigasi bingkai, bingkai bersarang, pelayar yang tidak disokong, dan pengepala yang tiada. Telemetri merekodkan ciri, asal bingkai, hasil dasar, hasil pengguna, dan sandaran tanpa merakam media. Sebarang gesaan yang tidak dijangka daripada iklan atau sebarang akses yang berjaya selepas navigasi ke asal yang tidak dipercayai akan menghentikan pelancaran."

Kesilapan lazim

• Menggunakan * untuk kamera dan mikrofon → mana-mana bingkai yang layak boleh meminta ciri berkuasa → mulakan dengan () dan tambah asal yang tepat.
• Menambah hanya pengepala HTTP → iframe rentas asal masih memerlukan delegasi kontena → tetapkan atribut allow yang sepadan.
• Menambah hanya allow → bingkai tidak boleh meluaskan dasar induk → semak kedua-dua respons dan setiap sempadan bingkai.
• Menganggap ketiadaan gesaan sebagai pepijat pelayar → penafian dasar boleh berlaku sebelum persetujuan pengguna → laporkan keadaan dasar, persetujuan, sokongan, dan peranti secara berasingan.
• Menganggap subdomain adalah same-origin → same-site tidak bermakna same-origin → senaraikan setiap asal dan uji navigasi.

Soalan susulan dan jawapan

Soalan susulan 1: Mengapakah ciri disekat walaupun pengepala menyenaraikan asal mesyuarat?

Semak atribut allow milik iframe, skema dan port yang tepat, serta sama ada bingkai telah menavigasi. Bagi bingkai rentas asal, senarai izin pengepala dan dasar kontena bersilang; satu kebenaran yang tiada akan menyekat ciri tersebut.

Soalan susulan 2: Patutkah anda meninggalkan pengepala dan bergantung pada allow?

Tidak. Dasar respons yang eksplisit memberikan pemilik halaman sempadan peringkat teratas dan menghalang pemberian kebenaran yang tidak disengajakan apabila bingkai baharu ditambah. Meninggalkannya boleh membiarkan tetapan lalai yang permisif untuk sesetengah ciri, yang menjadikan pembenaman pihak ketiga kemudiannya satu regresi dasar.

Soalan susulan 3: Bingkai mesyuarat menavigasi ke domain sokongan. Apakah yang berubah?

Nilai semula destinasi sebagai asal baharu. Berikan kamera atau mikrofon di sana hanya selepas kepercayaan, pengesahan, dan pengendalian data disemak; jika tidak, navigasi harus kehilangan keupayaan tersebut dan UI harus menerangkan sandaran.

Soalan susulan 4: Bolehkah Permissions Policy menggantikan kebenaran pihak pelayan (server-side authorization)?

Tidak. Ia mengawal ketersediaan ciri pelayar dalam sesuatu dokumen. Ia tidak membuktikan identiti pengguna, keahlian bilik, atau sama ada sesuatu permintaan boleh menyertai panggilan. Kekalkan semakan tersebut pada pelayan dan layani dasar tersebut sebagai sempadan pelayar berprivilese paling rendah.