Senario
Anda memiliki platform web berbilang tapak. Pasukan keselamatan mahukan laporan CSP, Permissions-Policy, susut nilai dan campur tangan yang berpusat supaya insiden tidak bergantung pada tangkapan skrin pengguna. Kejuruteraan mencadangkan Reporting API: mengisytiharkan titik akhir dengan Reporting-Endpoints, menerima application/reports+json, dan secara pilihan memerhati laporan dalam halaman dengan ReportingObserver. Terangkan keputusan penggunaan, pelancaran berperingkat dan metrik kejayaan.
Perkara yang dinilai oleh penemu duga
- Mengubah pengesanan awal masalah pelayar kepada hasil pengguna dan perniagaan yang boleh diukur.
- Memahami bahawa Reporting API adalah berasaskan usaha terbaik (best-effort), bukannya saluran mesej yang boleh dipercayai.
- Mengendalikan sokongan pelayar, keselamatan titik akhir, privasi dan tadbir urus data.
- Mereka bentuk pelancaran progresif, penyahduplikasian (deduplication) dan pintu kawalan pembalikan (rollback gates).
Soalan penjelasan
Sahkan jenis laporan, pelayar sasaran, bilangan tapak, garis dasar CSP/susut nilai semasa, keperluan pengekalan data dan kapasiti pengendalian amaran. Tanya sama ada titik akhir sudah mempunyai pengesahan, sama ada serpihan URL mungkin dihantar, dan sama ada matlamatnya adalah untuk mengurangkan insiden, memendekkan masa pembaikan atau bukti pematuhan.
Jawapan 30 saat
Saya akan menggunakannya sebagai isyarat diagnostik kos rendah dan tidak kritikal. Mulakan dengan mod laporan sahaja (report-only) dan sampel tapak yang kecil; terima jenis laporan yang diluluskan sahaja serta tambah had kadar (rate limits), penyahduplikasian dan penyuntingan (redaction) sambil mengekalkan log sedia ada. Ukur kadar laporan yang boleh diambil tindakan, masa dari laporan pertama hingga pembaikan, kadar positif palsu, kos titik akhir dan liputan pelayar lama. Kembangkan hanya selepas semakan kualiti data dan privasi. Tiada keputusan keselamatan yang sepatutnya bergantung pada penghantaran yang dijamin.
Penaakulan langkah demi langkah
1. Rangka masalah dan alternatif
Reporting API boleh membawa laporan CSP, Permissions-Policy, COEP, Integrity, susut nilai, ranap sistem (crash) dan campur tangan. Bandingkannya dengan SDK RUM sedia ada, log pelayan dan konsol pelayar dari segi liputan tambahan, kos klien, kepekaan data dan operasi.
2. Tentukan isyarat berdaya maju minimum (minimum viable signal)
Mulakan dengan csp-violation dan deprecation, menggunakan baris gilir logik bagi setiap jenis. Sahkan Content-Type: application/reports+json pada bahagian pelayan; hadkan saiz muatan (payload), sumber dan medan; nyahduplikasi mengikut tapak, versi dan cap jari (fingerprint). Gangguan pada titik akhir hanya sepatutnya menyebabkan kehilangan diagnostik, bukannya permintaan halaman.
3. Kendalikan kebolehpercayaan dan keserasian
Spesifikasi menyatakan bahawa penghantaran tidak dijamin; ejen pengguna boleh menggugurkan laporan disebabkan oleh keadaan rangkaian atau dasar. MDN menyatakan bahawa sokongan adalah paling kukuh pada pelayar yang lebih baharu dan mungkin tiada pada peranti lama. Bahagikan liputan mengikut versi pelayar dan kekalkan log pelayan serta ReportingObserver sebagai pelengkap. Tiada laporan yang diterima tidak pernah membuktikan bahawa tiada pelanggaran yang berlaku.
4. Tetapkan pintu kawalan privasi, keselamatan dan pelancaran
Laporan boleh merangkumi URL, ejen pengguna dan butiran dasar. Gunakan HTTPS, pengesahan atau laluan yang tidak boleh diteka, penapisan parameter pertanyaan, pengekalan terhad dan audit akses. Mulakan mod laporan sahaja pada tapak dalaman dan 1% daripada trafik; pantau beban titik akhir, medan sensitif dan kadar tindakan. Lumpuhkan konfigurasi titik akhir jika PII bocor, kos melonjak atau ribut amaran (alert storm) berlaku.
Contoh jawapan berkualiti tinggi
Saya akan meletakkan ini sebagai lapisan diagnostik awal untuk dasar pelayar dan susut nilai, bukannya sistem pengelogan baharu. Keputusan ini mempunyai tiga pintu kawalan. Pertama, nilai: ambil sampel 10 tapak wakil dalam mod laporan sahaja, sahkan bahawa laporan dapat mengesan tiket sedia ada, dan tetapkan garis dasar purata masa pengesanan. Kedua, risiko: semakan keselamatan dan privasi terhadap medan titik akhir, pengekalan data, pengasingan rentas tapak dan kawalan akses. Ketiga, operasi: lakukan ujian beban terhadap lonjakan laporan dan tetapkan kuota bagi setiap sumber, kunci penyahduplikasian dan pemantauan kadar pengguguran. Oleh kerana penghantaran adalah usaha terbaik, kekalkan RUM, log pelayan dan kaedah sandaran manual. Selepas pelancaran, tunjukkan liputan mengikut keluarga pelayar dan jejak kadar tindakan, MTTR, positif palsu, laporan bagi setiap sejuta halaman dan kos mengikut jenis laporan. Jika sesebuah pelayar mempunyai liputan yang lemah, hadkan kesimpulan kepada trafik yang diliputi sahaja. Jika titik akhir tidak berfungsi dengan betul, alih keluar pengepala respons Reporting-Endpoints untuk berbalik kepada keadaan asal tanpa mengubah permintaan halaman teras.
Kesilapan lazim
- Menganggap Reporting API sebagai baris gilir yang boleh dipercayai atau rekod audit pematuhan.
- Mengisytiharkan kejayaan berdasarkan laporan yang lebih sedikit tanpa membetulkan faktor liputan pelayar.
- Menyimpan URL mentah, parameter pertanyaan dan ejen pengguna untuk tempoh yang tidak terhad.
- Membincangkan penyepaduan SDK tanpa mengambil kira had kadar titik akhir, penyahduplikasian, kos atau pemilikan.
- Mendayakan semua tapak sekali gus tanpa mod laporan sahaja, pensampelan atau kriteria pembalikan.
Soalan susulan dan respons
“Mengapa tidak menggunakan ReportingObserver?”
Ia lebih mudah untuk eksperimen dalam halaman dan pengendalian tersuai, tetapi halaman yang ranap tidak dapat terus memerhati. Titik akhir jauh boleh menerima laporan secara bebas daripada kitaran hayat halaman. Kedua-duanya boleh saling melengkapi, tetapi tiada satu pun yang menjamin penghantaran.
“Bagaimanakah anda membuktikan bahawa produk ini berfungsi?”
Gunakan perbandingan sebelum/selepas bagi masa pengesanan, masa pembaikan, kadar tindakan dan positif palsu untuk isu yang disahkan, dibahagikan mengikut liputan pelayar. Pantau kos titik akhir dan peristiwa privasi pada masa yang sama.
“Bagaimana pula dengan pelayar yang tidak disokong?”
Anggap matriks sokongan sebagai kekangan produk, kekalkan log pelayan dan RUM, serta skopkan kesimpulan kepada trafik yang diliputi sahaja. Jangan suntik polyfill yang mahal semata-mata untuk menjadikan liputan kelihatan seragam.