Content Security Policy (CSP) membantu browser membatasi sumber skrip, gambar, stylesheet, koneksi API, dan konten lain yang boleh dimuat sebuah halaman. Namun, menerapkan kebijakan yang terlalu ketat secara langsung dapat merusak fitur yang masih bergantung pada skrip inline, layanan pihak ketiga, atau endpoint yang belum tercatat. Content-Security-Policy-Report-Only menyediakan cara untuk menguji kebijakan terlebih dahulu: browser melaporkan pelanggaran, tetapi tidak memblokir sumber daya hanya karena melanggar kebijakan percobaan tersebut.
Mode ini berguna bagi pengelola website yang ingin memperkuat pertahanan terhadap serangan seperti cross-site scripting (XSS) tanpa menebak semua dependensi aplikasi. Report-Only bukan pengganti kebijakan CSP yang diberlakukan, melainkan tahap observasi sebelum penegakan aturan.
Apa bedanya CSP biasa dan Report-Only?
Header Content-Security-Policy menerapkan aturan secara aktif. Jika sebuah skrip melanggar direktif yang berlaku, browser dapat menolak menjalankannya. Sebaliknya, Content-Security-Policy-Report-Only mengevaluasi aturan dan menghasilkan laporan pelanggaran, tetapi tidak menerapkan pemblokiran berdasarkan kebijakan tersebut.
Perbedaan ini penting saat kebijakan baru masih diuji. Misalnya, halaman mungkin memuat analitik, widget pembayaran, font, atau skrip dari CDN. Report-Only membantu mengidentifikasi sumber mana yang masih dibutuhkan dan mana yang tidak diharapkan. Namun, sumber daya yang diizinkan oleh kebijakan lama tetap dapat berjalan selama belum diblokir oleh kontrol lain.
Mulai dengan kebijakan percobaan yang masuk akal
Mulailah dari aturan yang jelas dan sesuaikan dengan arsitektur situs. Contoh header awal berikut hanya ilustrasi untuk pengujian; daftar sumber harus disesuaikan dengan aplikasi sebenarnya:
Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; report-uri /csp-reportDalam contoh tersebut, default-src 'self' menjadikan origin sendiri sebagai sumber bawaan, script-src 'self' menandai skrip dari origin lain sebagai pelanggaran, object-src 'none' melaporkan penggunaan elemen plugin, dan base-uri 'self' membatasi URL dasar dokumen. Karena header menggunakan mode Report-Only, browser melaporkan pelanggaran kebijakan uji tanpa memblokir sumber daya atas dasar header ini.
Jangan menyalin kebijakan contoh langsung ke situs produksi tanpa pengujian. Situs yang memakai skrip inline, font eksternal, iframe, atau API pihak ketiga mungkin menghasilkan banyak laporan. Catat kebutuhan aplikasi sebelum memperketat aturan.
Bagaimana laporan CSP dikirim?
Browser yang mendukung pelaporan dapat mengirim informasi pelanggaran ke endpoint yang dikonfigurasi. Direktif report-uri merupakan mekanisme lama yang masih berguna untuk kompatibilitas, sedangkan mekanisme report-to menggunakan konfigurasi Reporting API pada browser yang mendukungnya. Dukungan dan format pelaporan tidak seragam di semua browser, sehingga periksa kebutuhan kompatibilitas sebelum memilih satu mekanisme.
Endpoint laporan perlu menerima permintaan POST, menangani payload JSON dengan aman, dan tidak menganggap setiap laporan sebagai bukti serangan. Laporan dapat berisi URL dokumen, sumber yang melanggar, direktif terkait, dan informasi browser. Data tersebut bisa mengandung URL internal atau parameter sensitif; batasi akses, minimalkan retensi, dan hindari menyimpan data pribadi yang tidak diperlukan.
Menganalisis pelanggaran tanpa membuat pengecualian berlebihan
Setelah header dipasang, kunjungi alur penting seperti login, pencarian, formulir, pembayaran, dashboard, dan halaman dengan konten tertanam. Kelompokkan laporan berdasarkan direktif dan sumber. Bedakan sumber yang memang diperlukan dari skrip yang tidak dikenal, ekstensi browser, konten pengujian, atau laporan duplikat.
Jangan langsung menambahkan semua domain yang muncul ke daftar izin. Periksa siapa pemilik domain, mengapa halaman menghubunginya, dan apakah fungsi tersebut benar-benar diperlukan. Kebijakan yang terlalu longgar—misalnya mengizinkan semua host dengan wildcard—dapat mengurangi manfaat CSP. Bila memungkinkan, prioritaskan skrip eksternal yang jelas dan pertimbangkan nonce atau hash untuk skrip inline yang sah.
Rencana beralih ke mode enforcement
- Inventarisasi: catat sumber skrip, stylesheet, gambar, frame, dan koneksi yang benar-benar diperlukan.
- Uji alur utama: gunakan Report-Only di staging, lalu pantau juga trafik nyata secara hati-hati agar kasus penggunaan langka tidak terlewat.
- Perbaiki kebijakan: hilangkan dependensi yang tidak perlu dan buat izin sesempit mungkin. Hindari memasukkan pengecualian tanpa alasan.
- Validasi ulang: ulangi pengujian setelah perubahan aplikasi, plugin, tema, atau penyedia pihak ketiga.
- Terapkan bertahap: aktifkan header
Content-Security-Policysetelah laporan menunjukkan kebijakan cukup matang, sambil mempertahankan pemantauan dan prosedur rollback.
Kesalahan yang sering terjadi
Kesalahan umum adalah menganggap tidak adanya laporan berarti konfigurasi sempurna. Sebagian browser atau jalur aplikasi mungkin tidak mengirim laporan, endpoint bisa gagal, dan pengujian mungkin belum mencakup seluruh fitur. Kesalahan lain adalah memakai Report-Only selamanya tanpa pernah menegakkan kebijakan, atau mengabaikan laporan yang menunjukkan skrip asing.
CSP juga hanya salah satu lapisan pertahanan. Tetap perbarui perangkat lunak, lakukan escaping dan validasi input sesuai konteks, tinjau dependensi, serta amankan proses deployment. Nazuaf juga membahas Subresource Integrity untuk skrip CDN, yang melengkapi CSP dengan pemeriksaan integritas file eksternal.
Kesimpulan
Content-Security-Policy-Report-Only memungkinkan tim menguji kebijakan keamanan browser dengan mengamati pelanggaran sebelum memblokir sumber daya. Manfaat utamanya adalah mengurangi risiko gangguan saat memperkenalkan CSP, sekaligus memberi gambaran tentang dependensi yang benar-benar digunakan. Gunakan laporan sebagai bahan investigasi, bukan daftar izin otomatis, lalu beralih ke enforcement setelah pengujian yang representatif dan rencana pemulihan tersedia.