Bagaimana Anda akan menggunakan CHIPS untuk mengisolasi sesi pada widget lintas-situs yang disematkan?

Pertanyaan dan skenario

Widget ini dilayani oleh support.example dan disematkan oleh situs tingkat atas seperti shop-a.example dan shop-b.example. Widget harus mempertahankan sesi di seluruh halaman produk, checkout, dan bantuan di bawah shop-a.example, sementara shop-b.example menerima status yang terisolasi. Desain harus memperhitungkan cookie pihak ketiga yang dibatasi, peramban lama, logout, pengalihan agen, dan banyak tab.

Apa yang sedang diuji oleh pewawancara

• Apakah kandidat memahami bahwa CHIPS mengunci cookie berdasarkan situs tingkat atas dan asal yang disematkan (embedded origin)?
• Dapatkah mereka membedakan status persisten per situs dari status pihak ketiga yang tidak dipartisi (unpartitioned) yang memerlukan izin pengguna?
• Dapatkah mereka menghubungkan desain cookie, sesi server, CSRF, perlindungan replay, dan logout ke dalam satu alur data?
• Apakah mereka mencakup deteksi kapabilitas, fallback lawas, kunci cache, dan observabilitas?

Pertanyaan klarifikasi untuk diajukan terlebih dahulu

Konfirmasikan HTTPS, apakah widget harus mengidentifikasi satu orang di seluruh situs tingkat atas, apakah subdomain berbagi sesi, dan apakah halaman login tingkat atas dapat diterima. Klarifikasikan sensitivitas data, masa berlaku sesi, server push, dan peramban target. Jika bisnis benar-benar membutuhkan identitas lintas-situs, CHIPS saja bukanlah mekanismenya; gunakan login atau otorisasi eksplisit.

Kerangka jawaban 30 detik

Saya akan mendefinisikan sesi sebagai milik satu situs tingkat atas. Widget menetapkan cookie aman dengan Partitioned, dan server menyelesaikan status menggunakan situs tingkat atas dan sesi widget; subdomain dari satu situs berbagi partisi tersebut, sementara situs lain mendapatkan partisi yang berbeda. Cookie tersebut bukanlah kredensial identitas lintas-situs. Login lintas-situs menggunakan alur otorisasi tingkat atas. Jika CHIPS tidak tersedia, jalankan tanpa status persisten atau minta pengguna untuk mengotorisasi secara eksplisit. Verifikasi logout, CSRF, isolasi cache, dan perilaku multi-tab secara menyeluruh (end-to-end).

Pembahasan mendalam langkah demi langkah

1. Tentukan batasan kepercayaan (trust boundary). Perlakukan situs penyemat sebagai konteks partisi, bukan sebagai keputusan otorisasi yang diturunkan dari string Origin. Pertahankan allowlist dan validasi asal pesan, tenant, dan status sesi.
2. Tetapkan cookie yang dipartisi. Gunakan Secure, nilai SameSite yang sesuai, dan Partitioned; utamakan awalan __Host saat mengikat ke host saat ini. Kunci cookie logis mencakup asal yang disematkan dan situs tingkat atas, sehingga widget yang sama tidak dapat membaca satu cookie di dua situs tingkat atas.
3. Rancang sesi server. Simpan hanya pengidentifikasi buram (opaque identifier) acak di dalam cookie. Sesi server mencatat tenant, situs tingkat atas, waktu pembuatan, masa kedaluwarsa, dan versi pencabutan. Periksa kembali pengikatan (binding) pada setiap permintaan alih-alih hanya memercayai pemartisian peramban.
4. Tangani subdomain dan cache. Subdomain dapat menggunakan kembali satu partisi tingkat atas, tetapi kunci cache HTML, skrip, dan API harus menyertakan variasi tenant atau sesi. Gunakan caching privat atau kebijakan Vary yang eksplisit untuk respons yang dipersonalisasi; jangan pernah biarkan CDN melayani status satu situs ke situs lain.
5. Rancang login dan otorisasi. Ketika orang yang sama harus dikenali, buka halaman login tingkat atas dan kembalikan kode otorisasi satu kali pakai yang berumur pendek. Jangan pernah menaruh token yang berumur panjang di URL, postMessage, atau cookie yang tidak dipartisi.
6. Sediakan fallback dan observabilitas. Jalankan dalam mode tanpa sesi atau minta otorisasi eksplisit jika dukungan tidak tersedia; jangan memulihkan cookie pihak ketiga global secara diam-diam. Lacak rasio hit cookie partisi, keberhasilan otorisasi, dan alasan pembuatan atau pencabutan sesi tanpa mencatat nilai cookie atau token ke log.

Contoh jawaban berkualitas tinggi

Saya akan menggunakan CHIPS untuk batasan mempertahankan status widget dalam satu situs tingkat atas. support.example menetapkan cookie dengan Secure, SameSite=None, dan Partitioned; ini hanya menyimpan pengidentifikasi sesi buram. Sesi server mengikat tenant, situs tingkat atas, masa kedaluwarsa, dan versi pencabutan. Subdomain di bawah shop-a.example menggunakan kembali satu partisi, sementara shop-b.example secara alami menerima status lain.

Identitas lintas-situs tidak bergantung pada cookie tersebut. Widget membuka halaman tingkat atas untuk login, mendapatkan kode otorisasi satu kali pakai setelah tindakan pengguna, dan menukarnya dengan sesi berumur pendek di partisi saat ini melalui saluran pesan yang tervalidasi. Jika peramban lama atau kebijakan memblokir cookie yang dipartisi, widget menawarkan pengalaman tanpa sesi atau otorisasi eksplisit alih-alih beralih ke cookie pihak ketiga global. Uji dua situs tingkat atas, subdomain, logout, masa kedaluwarsa, tab bersamaan, caching, CSRF, pesan palsu, dan pengaturan privasi. Referensi utama adalah dokumentasi CHIPS dan Storage Access API dari MDN serta penjelasan CHIPS dari Privacy Sandbox.

Kesalahan umum

• Memperlakukan cookie Partitioned sebagai kredensial single-sign-on lintas-situs, yang menggagalkan isolasi.
• Mengotorisasi dari Origin saja sambil mengabaikan pengikatan tenant, pencabutan, CSRF, dan replay.
• Menggunakan cookie pihak ketiga yang tidak dipartisi secara diam-diam saat CHIPS tidak tersedia, yang menyebabkan kebocoran atau pemblokiran.
• Menghilangkan variasi cache CDN, Service Worker, atau proksi dan melayani respons terpersonalisasi dari satu situs ke situs lain.
• Menaruh token yang berumur panjang di URL, postMessage, atau cookie yang dapat dibaca frontend.

Pertanyaan lanjutan dan tanggapan

Kapan Anda akan menggunakan CHIPS versus Storage Access API?

Gunakan CHIPS untuk status tersemat independen per situs tingkat atas. Gunakan Storage Access API ketika ada kebutuhan yang dapat dibenarkan untuk status pihak ketiga yang tidak dipartisi dan pengguna dapat memberikan izin, seperti masuk (sign-in) eksplisit. Batasan privasi keduanya berbeda, sehingga yang satu bukan merupakan pengganti diam-diam untuk yang lain.

Bagaimana Anda membuktikan dua situs tingkat atas tidak dapat berbagi sesi?

Sematkan widget di kedua situs pada peramban yang sama dan catat pengidentifikasi sesi, pengikatan tenant server, dan hit cache. Menghapus cookie satu situs, logout, membuka tab baru, dan berpindah subdomain tidak boleh mengubah status situs lainnya.

Bagaimana jika produk bersikeras untuk mengenali satu orang di seluruh situs?

Tingkatkan persyaratannya ke otorisasi identitas eksplisit: login tingkat atas, kode satu kali pakai berumur pendek, pertukaran server, dan sesi yang dapat dicabut. Catat persetujuan dan kegagalan alih-alih membuat saluran pelacakan lintas-situs yang tersembunyi.