Perintah dan konteks
Reporting API memberi browser mekanisme umum untuk laporan CSP, Permissions-Policy, Integrity-Policy, COEP, depresiasi, dan intervensi. Laporan dapat dibaca di dalam halaman dengan ReportingObserver atau di-POST oleh browser ke endpoint jarak jauh (remote). Wawancara ini menguji apakah Anda dapat mengubah sinyal browser menjadi observabilitas yang andal tanpa menyalin data pengguna ke dalam log jangka panjang.
Hal yang dievaluasi pewawancara
- Apakah Anda membedakan batas keandalan antara observer di dalam halaman dan endpoint remote.
- Apakah Anda merancang
Reporting-Endpoints, perutean jenis laporan, sampling, dan deduplikasi. - Apakah Anda menangani risiko privasi dalam URL, user agent, dan parameter bisnis.
- Apakah Anda menghubungkan peluncuran mode report-only, peringatan (alerts), perbaikan, dan verifikasi regresi.
Pertanyaan untuk diklarifikasi terlebih dahulu
Konfirmasikan apakah tujuannya adalah migrasi kebijakan keamanan, peningkatan depresiasi browser, atau petunjuk crash. Klarifikasi dukungan browser, halaman lintas-asal (cross-origin), retensi, kepatuhan, kapasitas lonjakan (burst) endpoint, dan apakah URL mentah boleh dikirim ke pihak ketiga.
Jawaban 30 detik
Saya akan menggunakan empat lapisan: pengumpulan, transportasi, pemrosesan, dan tata kelola. Mulai kebijakan dalam mode report-only, rute jenis laporan melalui Reporting-Endpoints, gunakan observer untuk debugging langsung, dan gunakan laporan remote untuk agregasi di luar siklus hidup halaman. Server menerapkan batas laju (rate limit), deduplikasi, redaksi, dan sampling sebelum peringatan dan uji regresi. Pengiriman tidak dijamin, sehingga ini tidak dapat menggantikan pemantauan kesalahan yang sebenarnya.
Pembahasan mendalam langkah demi langkah
1. Memilih jalur pengumpulan
ReportingObserver cocok untuk pengembangan dan diagnosis dalam halaman dengan opsi types dan buffered. Endpoint remote menerima POST application/reports+json dari user agent; endpoint ini dapat menyimpan petunjuk setelah halaman mengalami crash dan lebih baik untuk agregasi produksi. Kedua jalur tetap memerlukan penanganan kompatibilitas browser dan kehilangan data.
2. Merancang endpoint dan perutean
Deklarasikan endpoint bernama dengan Reporting-Endpoints, lalu pilih tujuan dari direktif pelaporan CSP, COEP, atau Permissions-Policy. Rute berdasarkan type ke dalam pipeline keamanan, depresiasi, dan keandalan. Sediakan endpoint default untuk laporan seperti crash dan deprecation yang tidak memiliki header khusus. Validasi tipe konten dan ukuran body saat penyerapan (ingestion).
3. Mengontrol derau dan privasi
Deduplikasi berdasarkan situs, versi, jenis laporan, dan fingerprint kesalahan; batasi laju setiap sumber; dan hapus parameter kueri, pengidentifikasi akun, serta jalur sensitif sebelum agregasi. Simpan hanya bidang diagnostik, terapkan retensi singkat, dan audit akses. Sesuaikan sampling berdasarkan tingkat keparahan dan delta versi baru agar satu masalah kompatibilitas tidak menjadi badai peringatan (alert storm).
4. Menutup loop tata kelola
Tetapkan baseline dalam mode report-only sebelum memperketat kebijakan. Hubungkan laporan depresiasi baru dengan versi browser dan batch rilis, lalu verifikasi perbaikan dengan regresi otomatis atau laporan pengujian yang dihasilkan WebDriver. Pantau keberhasilan endpoint, latensi, drop, dan waktu perbaikan. Pertahankan jalur terdegradasi yang tidak dapat memblokir halaman.
Contoh jawaban yang kuat
Pertama-tama saya akan membatasi tujuan pengumpulan dan batas data. Untuk migrasi kebijakan, saya akan mulai dalam mode report-only, mengirim laporan CSP, Permissions-Policy, dan depresiasi ke endpoint yang terkontrol melalui Reporting-Endpoints, dan merutekannya berdasarkan jenis. ReportingObserver digunakan untuk diagnosis langsung; fakta produksi berasal dari agregasi remote, dengan catatan eksplisit bahwa browser tidak menjamin pengiriman.
Server memvalidasi application/reports+json, memberlakukan batas ukuran dan laju, serta mendeduplikasi berdasarkan situs, versi, jenis, dan fingerprint. Server menghapus parameter kueri URL dan pengidentifikasi akun, hanya menyimpan dimensi user-agent tingkat versi, dan menerapkan retensi singkat dengan audit akses. Peringatan menggunakan tingkat keparahan, delta rilis, dan halaman yang terdampak untuk sampling. Setelah perbaikan, uji regresi mengonfirmasi bahwa tingkat laporan menurun. Pipeline tidak boleh memblokir eksekusi halaman atau menggantikan pemantauan kesalahan frontend dan pemantauan pengguna nyata (real-user monitoring).
Kesalahan umum
- Hanya menggunakan
ReportingObserverdan kehilangan petunjuk saat halaman mengalami crash. - Menulis URL mentah, parameter kueri, atau user agent lengkap ke dalam log jangka panjang.
- Mengasumsikan endpoint menjamin pengiriman tanpa memantau drop, pelambatan (throttling), dan perbedaan browser.
- Memperlakukan temuan report-only sebagai kebijakan pemblokiran tanpa baseline atau peluncuran bertahap.
Pertanyaan lanjutan dan tanggapan
Bagaimana Anda memilih antara observer dalam halaman dan endpoint remote?
Observer mudah didebug dan diproses dengan kode halaman, tetapi bergantung pada halaman yang tetap hidup. Endpoint remote melakukan agregasi secara independen dan menyimpan petunjuk produksi atau crash. Keduanya dapat berjalan bersamaan, dengan kunci deduplikasi yang mencegah penghitungan ganda.
Bagaimana Anda mencegah sistem pelaporan membocorkan informasi pengguna?
Terapkan allowlist bidang, redaksi URL, batas ukuran, dan kontrol laju saat penyerapan. Pertahankan dimensi versi alih-alih pengidentifikasi lengkap, gunakan retensi singkat dengan enkripsi dan audit, serta batasi akses lintas tim.
Mengapa volume laporan bisa tiba-tiba melonjak?
Bagi berdasarkan rilis, browser, situs, jenis, dan fingerprint untuk memisahkan regresi baru, kesalahan konfigurasi kebijakan, lalu lintas bot, dan percobaan ulang (retries). Periksa throttling dan sampling endpoint sebelum melakukan eskalasi atau me-rollback rilis.