Skenario
Anda mengelola platform web multi-situs. Tim keamanan menginginkan laporan CSP, Permissions-Policy, depresiasi, dan intervensi yang terpusat agar insiden tidak bergantung pada tangkapan layar pengguna. Tim rekayasa mengusulkan Reporting API: mendeklarasikan endpoint dengan Reporting-Endpoints, menerima application/reports+json, dan secara opsional mengamati laporan di dalam halaman dengan ReportingObserver. Jelaskan keputusan adopsi, peluncuran bertahap, dan metrik keberhasilannya.
Apa yang dinilai oleh pewawancara
- Mengubah deteksi dini masalah browser menjadi hasil yang terukur bagi pengguna dan bisnis.
- Memahami bahwa Reporting API bersifat best-effort, bukan saluran pesan yang dapat diandalkan.
- Menangani dukungan browser, keamanan endpoint, privasi, dan tata kelola data.
- Merancang peluncuran progresif, deduplikasi, dan gerbang pembatalan (rollback gates).
Pertanyaan klarifikasi
Konfirmasikan jenis laporan, browser target, jumlah situs, baseline CSP/depresiasi saat ini, persyaratan retensi, dan kapasitas penanganan peringatan (alert). Tanyakan apakah endpoint sudah memiliki autentikasi, apakah fragmen URL dapat dikirim, dan apakah tujuannya adalah mengurangi insiden, mempercepat waktu perbaikan, atau bukti kepatuhan.
Jawaban 30 detik
Saya akan mengadopsinya sebagai sinyal diagnostik berbiaya rendah dan non-kritis. Mulai dengan mode report-only dan sampel situs kecil; terima hanya jenis laporan yang disetujui dan tambahkan batas laju (rate limits), deduplikasi, serta penyuntingan (redaction) sembari mempertahankan log yang ada. Ukur tingkat laporan yang dapat ditindaklanjuti, waktu dari laporan pertama hingga perbaikan, tingkat positif palsu, biaya endpoint, dan cakupan browser lama. Lakukan perluasan hanya setelah tinjauan kualitas data dan privasi. Tidak boleh ada keputusan keamanan yang bergantung pada pengiriman yang terjamin.
Penalaran langkah demi langkah
1. Membingkai masalah dan alternatif
Reporting API dapat memuat laporan CSP, Permissions-Policy, COEP, Integrity, depresiasi, crash, dan intervensi. Bandingkan dengan SDK RUM yang ada, log server, dan konsol browser berdasarkan cakupan inkremental, biaya klien, sensitivitas data, dan operasional.
2. Menentukan sinyal layak minimum (minimum viable signal)
Mulai dengan csp-violation dan deprecation, menggunakan antrean logis per tipe. Validasi Content-Type: application/reports+json di sisi server; batasi ukuran payload, sumber, dan kolom data; deduplikasi berdasarkan situs, versi, dan sidik jari (fingerprint). Pemadaman endpoint hanya boleh menghilangkan diagnostik, bukan permintaan halaman.
3. Menangani keandalan dan kompatibilitas
Spesifikasi menyatakan bahwa pengiriman tidak dijamin; agen pengguna (user agent) dapat membuang laporan karena kondisi jaringan atau kebijakan. MDN mencatat bahwa dukungan paling kuat ada pada browser yang lebih baru dan mungkin tidak tersedia pada perangkat lama. Segmentasikan cakupan berdasarkan versi browser dan pertahankan log server serta ReportingObserver sebagai pelengkap. Tidak adanya laporan yang diterima bukan berarti tidak ada pelanggaran sama sekali.
4. Menetapkan gerbang privasi, keamanan, dan peluncuran
Laporan dapat mencakup URL, user agent, dan rincian kebijakan. Gunakan HTTPS, autentikasi atau jalur yang tidak dapat ditebak, pemfilteran parameter kueri, retensi terbatas, dan audit akses. Mulai mode report-only pada situs internal dan 1% dari lalu lintas; pantau beban endpoint, kolom sensitif, dan tingkat keterlaksanaan. Nonaktifkan konfigurasi endpoint jika terjadi kebocoran PII, lonjakan biaya, atau badai peringatan (alert storm).
Contoh jawaban berkualitas tinggi
Saya akan memosisikan ini sebagai lapisan diagnostik dini untuk kebijakan browser dan depresiasi, bukan sebagai sistem pencatatan log baru. Keputusan ini memiliki tiga gerbang. Pertama, nilai: ambil sampel 10 situs representatif dalam mode report-only, verifikasi bahwa laporan berhasil menemukan tiket yang ada, dan buat baseline waktu rata-rata untuk deteksi. Kedua, risiko: tinjauan keamanan dan privasi terhadap kolom endpoint, retensi, isolasi lintas situs, dan kontrol akses. Ketiga, operasional: lakukan uji beban pada lonjakan laporan dan tetapkan kuota per sumber, kunci deduplikasi, dan pemantauan tingkat pembuangan (drop-rate). Karena pengiriman bersifat best-effort, pertahankan RUM, log server, dan fallback manual. Setelah peluncuran, tampilkan cakupan berdasarkan kelompok browser dan lacak tingkat keterlaksanaan, MTTR, positif palsu, laporan per sejuta halaman, dan biaya berdasarkan jenis laporan. Jika browser memiliki cakupan yang lemah, batasi kesimpulan hanya pada lalu lintas yang tercakup. Jika endpoint mengalami gangguan, hapus header respons Reporting-Endpoints untuk melakukan rollback tanpa mengubah permintaan halaman inti.
Kesalahan umum
- Memperlakukan Reporting API sebagai antrean yang andal atau catatan audit kepatuhan.
- Menyatakan keberhasilan dari jumlah laporan yang lebih sedikit tanpa mengoreksi cakupan browser.
- Menyimpan URL mentah, parameter kueri, dan user agent tanpa batas waktu.
- Membahas integrasi SDK tanpa batas laju endpoint, deduplikasi, biaya, atau kepemilikan.
- Mengaktifkan semua situs sekaligus tanpa mode report-only, pengambilan sampel, atau kriteria rollback.
Pertanyaan lanjutan dan tanggapan
“Mengapa tidak menggunakan ReportingObserver?”
Ini lebih mudah untuk eksperimen dalam halaman dan penanganan khusus, tetapi halaman yang mengalami crash tidak dapat terus mengamati. Endpoint jarak jauh dapat menerima laporan secara independen dari masa pakai halaman. Keduanya dapat saling melengkapi, tetapi tidak ada yang menjamin pengiriman.
“Bagaimana Anda membuktikan bahwa produk ini berfungsi?”
Gunakan perbandingan sebelum/sesudah dari waktu deteksi, waktu perbaikan, tingkat keterlaksanaan, dan positif palsu untuk masalah yang terkonfirmasi, yang disegmentasikan berdasarkan cakupan browser. Pantau biaya endpoint dan peristiwa privasi secara bersamaan.
“Bagaimana dengan browser yang tidak didukung?”
Perlakukan matriks dukungan sebagai batasan produk, pertahankan log server dan RUM, dan batasi kesimpulan hanya pada lalu lintas yang didukung. Jangan menyuntikkan polyfill yang mahal hanya untuk membuat cakupan terlihat seragam.