Pertanyaan dan ruang lingkup
Anda mengelola sebuah dasbor yang menyematkan meet.example untuk panggilan, video.example untuk pemutaran, dan beberapa frame iklan. Frame rapat membutuhkan microphone dan camera; frame video membutuhkan fullscreen; iklan tidak memerlukan fitur-fitur ini. Halaman menggunakan HTTPS, origin frame sudah diketahui, dan peramban harus tetap meminta persetujuan media kepada pengguna saat kebijakan mengizinkannya.
Ruang lingkupnya adalah komposisi dan diagnosis kebijakan di sisi peramban. Otentikasi, CSP, dan otorisasi server tetap menjadi kontrol yang terpisah. Asumsikan header respons diatur oleh server dasbor dan setiap frame lintas-asal memiliki atribut allow yang eksplisit.
Apa yang sedang diuji oleh pewawancara
Pewawancara ingin Anda memisahkan tiga gerbang: kebijakan respons, delegasi frame, dan izin runtime pengguna. Allowlist header saja tidak memberikan akses ke frame lintas-asal, dan atribut allow tidak dapat memperluas header yang menolak fitur tersebut.
Mereka juga menguji apakah Anda menghindari kemudahan wildcard. Jawaban yang kuat dimulai dari () untuk fitur-fitur sensitif, menyebutkan origin yang tepat, menangani navigasi bertingkat, dan menjelaskan apa yang dilakukan UI saat API tidak tersedia. Jawaban yang lemah menuliskan *, menunggu prompt izin, dan menyebut fitur tersebut sudah aman.
Pertanyaan untuk diklarifikasi sebelum menjawab
- Ke origin mana saja frame rapat dan video dapat bernavigasi secara tepat? Navigasi ke origin yang berbeda mungkin memerlukan destinasi tersebut dalam kebijakan frame, atau fitur tersebut harus ditolak setelah navigasi.
- Apakah frame rapat membuka frame bertingkat (nested frames)? Jika ya, tentukan apakah delegasi dapat dilanjutkan dan uji origin bertingkat tersebut alih-alih mengasumsikan izin frame pertama diwarisi selamanya.
- Peramban dan webview tersemat mana saja yang didukung? Sintaks kebijakan bisa saja benar sementara runtime yang lebih lama menampilkan permukaan kegagalan yang berbeda.
- Apakah panggilan kamera atau mikrofon bersifat wajib? Jika opsional, UI dapat menawarkan jalur khusus teks ketika kebijakan atau izin pengguna ditolak.
Kerangka jawaban 30 detik
“Saya akan menetapkan kamera dan mikrofon secara default ke () dan hanya memberikannya ke origin rapat dalam kebijakan respons. Saya akan memberikan izin fullscreen hanya ke origin video. Setiap iframe lintas-asal akan mengulang fitur yang dimaksud dalam atribut allow miliknya, karena header dan kebijakan frame keduanya diperlukan. Frame akan mendeteksi penolakan kebijakan secara terpisah dari penolakan pengguna, merender fallback, dan tidak pernah memperlakukan prompt izin sebagai otorisasi. Saya akan menguji kasus same-origin, cross-origin, navigasi, nested-frame, missing-header, dan fallback peramban sebelum peluncuran.”
Jawaban mendalam langkah demi langkah
Langkah 1: Mulai dengan inventaris deny-by-default
Buat daftar setiap fitur yang dikontrol kebijakan yang digunakan oleh halaman dan origin pemiliknya. Jangan menyimpulkan izin dari nama produk "meeting". Kamera dan mikrofon adalah dua fitur independen. Layar penuh adalah fitur lainnya. Iklan adalah kelas tanpa akses (zero-access) yang eksplisit.
Gunakan header eksplisit seperti:
Permissions-Policy: camera=(self "https://meet.example"), microphone=(self "https://meet.example"), fullscreen=(self "https://video.example")Daftar origin yang tepat mencegah frame yang tidak terkait menerima izin. Jika dasbor itu sendiri tidak boleh mengakses fitur tersebut, hapus self dan berikan izin hanya ke origin frame yang diperlukan, lalu verifikasi bahwa kebijakan induk masih mengizinkan delegasi.
Langkah 2: Delegasikan pada setiap batas iframe
Frame rapat hanya menerima dua fiturnya, dan frame video hanya menerima layar 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>Untuk frame lintas-asal, menghilangkan allow akan memblokir fitur tersebut meskipun header respons mencantumkan origin tersebut. Sebaliknya, menambahkan allow="camera" ke iklan tidak akan menimpa camera=() atau origin yang tidak ada dalam header.
Langkah 3: Perlakukan kebijakan dan izin pengguna sebagai status yang berbeda
Permissions-Policy memutuskan apakah dokumen boleh menggunakan fitur tersebut. Permissions API dan prompt media mewakili izin yang diberikan pengguna. Fitur yang diblokir dapat gagal sebelum prompt muncul. Frame harus memetakan “kebijakan ditolak”, “pengguna menolak”, “tidak didukung”, dan “perangkat sibuk” ke telemetri dan teks pemulihan yang berbeda.
Jangan jadikan pemeriksaan sisi klien sebagai batas keamanan. Halaman penyemat mengontrol delegasi, sementara aplikasi tetap mengotentikasi panggilan dan mengotorisasi keanggotaan ruangan di server.
Langkah 4: Tangani navigasi dan frame bertingkat secara eksplisit
Jika frame rapat dapat bernavigasi ke origin dukungan, sertakan destinasi tersebut dalam kebijakan allow hanya jika origin tersebut tepercaya dan membutuhkan fitur yang sama. Origin src awal frame dan origin navigasi setelahnya tidak dapat dipertukarkan. Untuk frame bertingkat, verifikasi kebijakan efektif di setiap batas dan tolak secara default jika kepemilikannya tidak jelas.
Langkah 5: Luncurkan dengan pengujian yang dapat diobservasi
Kirim header dalam diagnostik report-only atau kohort rute kecil jika platform mengizinkannya, lalu bandingkan pelanggaran kebijakan, hasil prompt, penyelesaian panggilan, dan penggunaan fallback. Uji frame same-origin, frame cross-origin yang diizinkan, frame cross-origin yang tidak terdaftar, atribut allow yang hilang, subdomain yang berubah, dan navigasi frame. Pastikan iklan tidak pernah memicu prompt dan frame rapat yang ditolak menawarkan obrolan teks.
Contoh jawaban berkualitas tinggi
“Saya akan menulis kebijakan berdasarkan model ancaman. Kamera dan mikrofon dimulai sebagai izin kosong, lalu header hanya mencantumkan meet.example; fullscreen hanya mencantumkan video.example. Kedua frame lintas-asal membawa atribut allow yang cocok, sedangkan frame iklan tidak membawa apa pun. Peramban tetap mengontrol persetujuan pengguna, sehingga kode rapat membedakan pemblokiran kebijakan dari penolakan pengguna dan menawarkan fallback khusus teks. Saya tidak akan menempatkan otorisasi dalam header ini: server tetap memeriksa ruangan dan pengguna.
Sebelum mengaktifkannya secara global, saya akan menguji matriks: origin yang diizinkan dan tidak terdaftar, subdomain same-site tetapi cross-origin, allow yang dihilangkan, navigasi frame, frame bertingkat, peramban yang tidak didukung, dan header yang hilang. Telemetri mencatat fitur, origin frame, hasil kebijakan, hasil pengguna, dan fallback tanpa merekam media. Setiap prompt yang tidak terduga dari iklan atau akses yang berhasil setelah navigasi ke origin yang tidak tepercaya akan menghentikan peluncuran.”
Kesalahan umum
- Menggunakan
*untuk kamera dan mikrofon → frame mana pun yang memenuhi syarat dapat meminta fitur yang berkuasa penuh → mulai dengan()dan tambahkan origin yang tepat. - Hanya menambahkan header HTTP → iframe lintas-asal masih memerlukan delegasi container → atur atribut
allowyang cocok. - Hanya menambahkan
allow→ frame tidak dapat memperluas kebijakan induk → periksa respons dan setiap batas frame. - Menganggap prompt yang tidak muncul sebagai bug peramban → penolakan kebijakan dapat terjadi sebelum izin pengguna → laporkan status kebijakan, izin, dukungan, dan perangkat secara terpisah.
- Mengasumsikan subdomain adalah same-origin → same-site tidak berarti same-origin → cantumkan setiap origin dan uji navigasi.
Pertanyaan lanjutan dan tanggapan
Pertanyaan lanjutan 1: Mengapa fitur diblokir padahal header mencantumkan origin rapat?
Periksa atribut allow milik iframe, skema dan port yang tepat, serta apakah frame telah bernavigasi. Untuk frame lintas-asal, allowlist header dan kebijakan container saling beririsan (intersect); satu izin yang hilang akan memblokir fitur.
Pertanyaan lanjutan 2: Haruskah Anda menghilangkan header dan hanya mengandalkan allow?
Tidak. Kebijakan respons yang eksplisit memberi pemilik halaman batasan tingkat atas dan mencegah pemberian izin yang tidak disengaja saat frame baru ditambahkan. Menghilangkannya dapat membiarkan default yang permisif untuk beberapa fitur, yang membuat penyematan pihak ketiga di kemudian hari menjadi regresi kebijakan.
Pertanyaan lanjutan 3: Frame rapat bernavigasi ke domain dukungan. Apa yang berubah?
Evaluasi ulang destinasi sebagai origin baru. Berikan izin kamera atau mikrofon di sana hanya setelah kepercayaan, otentikasi, dan penanganan data ditinjau; jika tidak, navigasi harus kehilangan kemampuan tersebut dan UI harus menjelaskan fallback-nya.
Pertanyaan lanjutan 4: Bisakah Permissions Policy menggantikan otorisasi sisi server?
Tidak. Kebijakan ini mengontrol ketersediaan fitur peramban dalam sebuah dokumen. Kebijakan ini tidak membuktikan identitas pengguna, keanggotaan ruangan, atau apakah suatu permintaan boleh bergabung dalam panggilan. Tetap simpan pemeriksaan tersebut di server dan perlakukan kebijakan sebagai batas keamanan hak akses terendah (least-privilege) di peramban.