Petunjuk dan konteks
Sebuah penyedia identitas disematkan dalam iframe di banyak situs pelanggan. Pengguna yang telah masuk seharusnya dapat melihat informasi akun, tetapi peramban dapat mempartisi atau memblokir cookie pihak ketiga. Rancang alur kerja menggunakan Storage Access API tanpa mengubah setiap sematan menjadi saluran pelacakan tersembunyi.
Asumsikan iframe dapat menavigasi ke halaman first-party miliknya sendiri, situs tingkat atas mengontrol izin iframe, dan pengguna dapat menolak permintaan izin. Jawaban harus mencakup persetujuan, CSRF, fallback, dan keluar (logout).
Hal yang diuji oleh pewawancara
- Apakah Anda mengetahui bahwa akses penyimpanan dibatasi oleh izin dan dicakup pada tingkat bingkai (frame-scoped), bukan sekadar tombol pengaktif cookie universal.
- Apakah Anda mewajibkan aktivasi pengguna dan alasan produk yang jelas sebelum meminta akses.
- Apakah Anda memisahkan status bootstrap terpartisi dari status sesi tanpa partisi.
- Apakah penolakan izin tetap menyisakan jalur fungsional dalam kondisi keluar (signed-out) atau berbasis pengalihan (redirect).
Pertanyaan klarifikasi sebelum menjawab
- Apakah widget memerlukan kontinuitas sesi lintas-situs, atau dapatkah pengalihan mengembalikan kode otorisasi? Pengalihan dapat menghindari permintaan akses cookie yang disematkan.
- Apakah pengguna pernah mengunjungi penyedia identitas sebagai first-party dan menyetel cookie-nya? Beberapa peramban mewajibkan hubungan tersebut sebelum memberikan akses.
- Asal (origin) tingkat atas mana saja yang boleh menyematkan bingkai? Hal ini menentukan daftar izin (allowlist)
Permissions-Policy. - Data apa yang ditampilkan sebelum persetujuan diberikan? Tampilan pra-akses tidak boleh membocorkan identitas akun.
Kerangka jawaban 30 detik
"Saya memperlakukan Storage Access API sebagai kapabilitas yang dimediasi pengguna, bukan sebagai sakelar cookie fallback. Iframe dimulai dengan status terpartisi atau buram, meminta izin hanya setelah ada klik yang menjelaskan manfaatnya dengan jelas, dan memeriksa promise yang dikembalikan. Situs tingkat atas mengirimkan daftar izin Permissions-Policy yang sempit. Jika ditolak, saya menggunakan pengalihan first-party atau pengalaman keluar. Setiap permintaan yang mengubah status tetap memiliki perlindungan CSRF, dan widget dapat mencabut sesinya lalu kembali ke status netral yang sama."
Pembahasan mendalam langkah demi langkah
1. Memisahkan status dan model ancaman
Sebelum akses diberikan, iframe mungkin memiliki penyimpanan terpartisi atau tidak memiliki cookie sama sekali. Iframe tidak boleh menyimpulkan identitas pengguna dari status tersebut. Setelah requestStorageAccess() berhasil, dokumen yang disematkan dapat mengakses cookie first-party tanpa partisi sesuai dengan kebijakan peramban.
Kapabilitas ini terbatas pada dokumen dan konteks penyematan. Hal ini bukan bukti bahwa situs tingkat atas tepercaya, juga bukan pengganti pemeriksaan asal, pertahanan CSRF, catatan persetujuan, dan semantik keluar.
2. Membatasi permintaan di balik niat pengguna
Tampilkan widget netral dalam keadaan keluar. Tombol seperti "Masuk untuk menampilkan detail akun" menciptakan aktivasi pengguna. Di dalam handler tersebut, panggil API dan tangani penolakan sebagai cabang alur yang wajar. Jangan meminta akses saat halaman dimuat atau menggunakan bingkai tersembunyi untuk memanipulasi aktivasi pengguna.
Aplikasi harus menjelaskan data mana yang akan tersedia dan mengingat keputusan tersebut hanya sejauh yang diizinkan oleh kebijakan peramban. Permintaan dapat ditolak karena peramban memblokir cookie pihak ketiga, pengguna belum pernah berinteraksi dengan situs sebagai first-party, bingkai tidak memiliki izin kebijakan, atau konteks tidak memenuhi syarat.
3. Mengonfigurasi batasan penyematan
Respons tingkat atas memiliki kendali atas kebijakan. Izinkan hanya origin identitas dan hanya pada rute yang menyematkan widget:
Permissions-Policy: storage-access=(self "https://id.example")Iframe harus disajikan dengan origin dan pengaturan sandbox yang diharapkan. Bingkai yang di-sandbox membutuhkan kapabilitas same-origin yang sesuai, dan ketidakcocokan origin harus ditutup demi keamanan (fail closed). Perlakukan kebijakan sebagai daftar izin, bukan sebagai cara untuk memberikan akses kepada setiap pihak ketiga.
4. Menetapkan alur first-party dan tersemat
Jika peramban memerlukan interaksi first-party, widget akan membuka halaman first-party pada origin identitas. Pengguna masuk di sana, penyedia identitas menyetel cookie first-party miliknya, dan hasil berumur pendek yang terikat pada origin dikembalikan ke sematan. Hasil tersebut tidak boleh berupa bearer token yang dapat digunakan kembali di dalam URL.
Kembali ke iframe, minta akses penyimpanan setelah adanya gestur pengguna, lalu baca sesi melalui origin identitas. Server tetap memeriksa origin tingkat atas, status sesi, dan token CSRF. Izin yang berhasil diberikan tidak mengabaikan otorisasi akun.
5. Merancang penolakan, keluar, dan pengukuran
Ketika akses ditolak, jaga agar widget tetap berguna: tampilkan tautan masuk, gunakan alur pengalihan dan kembali, atau tawarkan halaman akun first-party. Jangan melakukan pengulangan prompt izin. Keluar akan menghapus sesi identitas dan mengatur ulang iframe ke status netralnya; proses ini juga harus membatalkan tampilan akun yang di-cache.
Ukur keberhasilan pemberian izin, alasan penolakan jika tersedia, penyelesaian pengalihan, dan kesalahan tampilan akun berdasarkan peramban dan origin penyemat. Jangan pernah mencatat nilai cookie atau data akun. Produk harus dapat menghapus jalur API di kemudian hari tanpa kehilangan alur pengalihan.
Contoh jawaban berkualitas tinggi
Saya akan memulai dengan iframe anonim yang hanya menampilkan elemen antarmuka untuk masuk. Setelah pengguna mengklik, iframe meminta akses penyimpanan dan menangani penolakan secara eksplisit. Halaman penyemat mengirimkan daftar izin Permissions-Policy yang sempit untuk origin identitas. Jika peramban memerlukan interaksi first-party, saya mengalihkan ke situs identitas, membuat sesinya di sana, dan mengembalikan hasil yang terikat pada origin tanpa menyertakan bearer token di dalam URL.
Setelah izin diberikan, iframe membaca sesi first-party, tetapi pemeriksaan origin, perlindungan CSRF, otorisasi, dan keluar tetap berlaku. Jika akses ditolak, produk menggunakan masuk berbasis pengalihan atau tampilan keluar dan tidak pernah mengulang prompt izin. Saya mengukur izin yang diberikan, penolakan, penyelesaian pengalihan, dan kegagalan berdasarkan peramban dan origin, sambil tetap menjaga fungsionalitas fallback.
Kesalahan umum
- Kesalahan: Memanggil API saat halaman dimuat → Penyebab kegagalan: peramban memerlukan niat pengguna dan pengguna tidak dapat memahami prompt yang muncul tiba-tiba → Solusi: minta izin hanya setelah aktivasi yang disertai penjelasan.
- Kesalahan: Menganggap keberhasilan sebagai izin cookie global → Penyebab kegagalan: akses dibatasi pada cakupan tertentu serta bergantung pada kebijakan dan peramban → Solusi: periksa promise untuk setiap konteks yang disematkan.
- Kesalahan: Mengizinkan setiap origin di dalam
Permissions-Policy→ Penyebab kegagalan: ini memperluas permukaan pelacakan dan akses data → Solusi: masukkan origin identitas ke daftar izin hanya pada rute tertentu. - Kesalahan: Menaruh token sesi di dalam URL pengalihan → Penyebab kegagalan: URL bocor melalui riwayat penelusuran, log, dan referrer → Solusi: gunakan hasil berumur pendek, sekali pakai, dan terikat pada origin.
- Kesalahan: Mengulang-ulang prompt setelah penolakan → Penyebab kegagalan: ini menciptakan pengalaman yang menjengkelkan bagi pengguna dan tetap tidak dapat memaksa pemberian izin → Solusi: beralih ke pengalihan atau fallback tampilan keluar.
Pertanyaan lanjutan dan tanggapan
Bisakah cookie terpartisi menggantikan Storage Access API?
Cookie terpartisi dapat mendukung sesi bootstrap khusus untuk sematan, tetapi tidak memberikan kontinuitas lintas-situs yang sama seperti sesi first-party tanpa partisi. Pilih status terpartisi jika isolasi dapat diterima; gunakan login berbasis pengalihan jika kontinuitas itu penting dan permintaan akses tidak diinginkan.
Bagaimana jika iframe berada dalam sandbox?
Pastikan sandbox mempertahankan origin dan kapabilitas yang diperlukan oleh alur kerja tersebut. Jika sandbox membuat origin menjadi buram atau memblokir API, tutup demi keamanan (fail closed) dan gunakan pengalihan first-party. Jangan melemahkan sandbox secara global hanya untuk membuat satu sematan berfungsi.
Apakah akses penyimpanan yang telah diberikan menghilangkan risiko CSRF?
Tidak. Iframe dapat mengirim cookie setelah akses diberikan, sehingga endpoint yang mengubah status tetap memerlukan pertahanan CSRF, validasi origin, pengaturan cookie SameSite jika berlaku, dan otorisasi. Izin penyimpanan hanya mengubah aksesibilitas, bukan niat permintaan.