Review CSP dan Security Header untuk Website Production
CSP membatasi pemuatan resource browser setelah ada cacat injection; CSP tidak melakukan sanitasi input. Kebijakan produksi harus mencerminkan aset nyata, kode inline, widget pihak ketiga, dan penanganan laporan.
Terapkan dua tahap
Mulai dari report-only, kelompokkan pelanggaran per directive, hapus perilaku inline yang tidak perlu, lalu enforce. Contoh: beri nonce pada setiap script yang dirender server, bukan menambah unsafe-inline. Contoh lain: izinkan frame pembayaran lewat frame-src, bukan https: yang terlalu luas.
Checklist deployment header
| Header | Tujuan | Verifikasi |
|---|---|---|
| CSP | pembatasan script dan frame | script injeksi diblokir |
| HSTS | preferensi HTTPS | redirect dan max-age |
| X-Content-Type-Options | kontrol MIME sniffing | aset salah label ditolak |
| frame-ancestors | kontrol clickjacking | frame asing ditolak |
Panduan CSP OWASP dan MDN CSP menjelaskan directive.
Aturan keputusan: kebijakan enforcement harus diuji terhadap alur pengguna penting sebelum rollout.
Perbaikan
Ganti inline handler, buat nonce tiap respons, sempitkan source, dan simpan laporan tanpa payload sensitif. CSP adalah defense in depth, bukan pengganti encoding output. Pengujian web dapat memvalidasi kontrol browser.
Bergerak dari observasi ke enforcement
Deploy kebijakan report-only lebih dulu lalu kelompokkan pelanggaran menurut route, directive, browser, dan alur pengguna. Hapus perilaku inline yang tidak dipakai daripada menambah allowance tidak aman. Respons dinamis dapat memakai nonce acak setiap respons; script statis dapat memakai hash yang dipelihara. Baseline sempit sering memuat default-src ‘self’, object-src ‘none’, serta keputusan base-uri dan frame-ancestors yang sengaja, tetapi tiap directive harus sesuai kebutuhan aplikasi.
Verifikasi header pada halaman normal, error, dan route terautentikasi. Uji script eksternal injeksi, inline event handler, frame asing, aset salah label, dan alur kritis. Jaga laporan bebas data request sensitif. Owner: pemilik platform web. Lulus: aset yang diharapkan berfungsi dan perilaku terlarang diblokir di browser target. Gagal: pengecualian luas menutupi pelanggaran atau alur kritis rusak. Pengecualian mencantumkan directive, route terdampak, alasan, kontrol kompensasi, owner, persetujuan, dan kedaluwarsa.
Capture konfigurasi
Catat header yang benar-benar dideploy, bukan ringkasan singkat pada ticket. Untuk halaman dinamis, tunjukkan nonce berbeda pada dua respons dan hanya muncul pada elemen yang dimaksud. Untuk halaman statis, simpan hash script serta proses perubahannya. Uji header lewat CDN, origin, cache, error, dan jalur terautentikasi agar respons alternatif tanpa perlindungan tidak terlewat.
Bukti kebijakan browser
Output yang diharapkan: route, header CSP penuh, mode report-only atau enforce, metode nonce atau hash, versi browser, directive terblokir, hasil alur. Bukti ini menghubungkan directive browser dengan hasil alur yang tercatat.
Kegagalan teruji: Halaman bertemplate memantulkan inline handler. Enforcement harus memblokir handler itu sementara script disetujui dengan nonce tetap dimuat.
Kasus tepi: Perubahan script pihak ketiga dapat membuat hash statis tidak valid. Perlakukan alur rusak sebagai sinyal review, bukan alasan menambah unsafe-inline.
Uji penutupan: Muat halaman error dan route terautentikasi setelah CDN purge. Penutupan lulus bila keduanya memberi kebijakan yang dimaksud dan framing ditolak.
Buku besar rollout kebijakan
Mulai dari inventory route, bukan header hasil salin. Catat script, style, frame, worker, font, gambar, form, dan domain pihak ketiga yang dipakai alur kritis. Pelanggaran report-only harus mengidentifikasi directive dan route, lalu diklasifikasikan sebagai aset perlu, kode usang, gejala injection, atau bug kebijakan. Jangan menyetujui host wildcard karena muncul satu laporan tidak dikenal. Setiap source tambahan perlu owner fitur bernama dan tanggal review penghapusan.
Pembuatan nonce memerlukan entropi dari kriptografi sisi server dan nilai baru untuk setiap respons. Jangan memakai ulang nonce cache antar pengunjung. Kebijakan hash memerlukan build step yang berubah ketika byte script berubah, termasuk output minifier. Uji halaman dengan script injeksi sengaja dan periksa console browser atau endpoint laporan untuk eksekusi yang diblokir. Untuk perlindungan frame, uji embedding same-origin yang diizinkan bila perlu serta embedding lintas origin yang bermusuhan.
Untuk tiap pengecualian kebijakan, catat fitur, source expression, owner, dan kondisi penghapusan. Uji ulang kebijakan setelah perubahan template atau bundler. Output diharapkan adalah tidak ada eksekusi inline baru dan tidak ada pelanggaran report-only dari alur disetujui.
Laporan CSP adalah input browser tidak tepercaya. Simpan hanya field untuk mengelompokkan directive, kategori document URI, kategori blocked URI, dan keluarga user agent; jangan menerima body laporan sebagai diagnostik tepercaya. Batasi laju pengumpulan laporan dan autentikasi endpoint laporan internal bila deployment mendukungnya. Review volume laporan setelah enforcement karena penurunan mendadak dapat berarti collector gagal, bukan kebijakan berhasil. Owner kebijakan perlu menghapus source yang tidak lagi dipakai bundle saat ini secara berkala.
Pemeriksaan akhir membandingkan header enforcement dari respons terdeploy dengan perilaku bundle yang disetujui. Output diharapkan: script dan style yang disetujui dimuat tanpa memperluas source eksekusi. Kasus tepi: cache menyajikan HTML lama dengan aset baru; uji kedua versi saat rollout. Tutup hanya setelah collector laporan dan pemeriksaan browser menunjukkan kebijakan sesuai jalur aplikasi saat ini.