Lompat ke konten utama

Generator Content-Security-Policy

Mulai dari melaporkan, tegakkan setelah laporannya bersih

Susun header CSP untuk Nginx, Apache, atau PHP dengan tiga tingkat ketat. Defaultnya mode laporan, karena CSP yang salah mematikan bagian situs tanpa menampilkan pesan apa pun kepada pengunjung.

Mulai dari melaporkan, tegakkan setelah laporannya bersih.
Kosongkan bila belum siap menampung laporan.

Satu per baris, selain domain sendiri.
Untuk fetch, XHR, dan WebSocket.
Video, peta, dan iframe lainnya.
Pencegah clickjacking, pengganti X-Frame-Options yang lebih baik.

Pasang sebagai header HTTP di server web, bukan sebagai tag meta — sebagian arahan tidak berlaku bila dipasang lewat meta.

Seluruh perhitungan berjalan di browser Anda. Alamat IP, nama interface, dan password yang Anda masukkan tidak pernah dikirim ke server CoreNet.

Kenapa defaultnya mode laporan

CSP yang salah tidak menampilkan pesan apa pun kepada pengunjung. Tombol berhenti bekerja, gambar tidak muncul, pembayaran gagal — dan satu-satunya jejaknya ada di konsol browser yang tidak pernah dibuka siapa pun.

Content-Security-Policy-Report-Only memberi daftar lengkap apa yang akan diblokir, tanpa memblokir apa pun. Biarkan berjalan beberapa hari, baca laporannya, tambahkan sumber sah yang muncul di sana, baru ganti nama headernya.

Urutan itu bukan kehati-hatian berlebihan. Pada situs yang sudah berjalan, CSP yang langsung ditegakkan hampir selalu mematikan sesuatu.

Soal unsafe-inline

Tool ini tidak pernah menghasilkan 'unsafe-inline' pada script-src di tingkat ketat maupun sedang. Alasannya lugas: ia mematikan justru bagian CSP yang menghentikan XSS. Kebijakan yang memuatnya sebagian besar hanya menghasilkan rasa aman.

Tingkat longgar menyediakannya untuk situs lama, tetapi dengan pernyataan terus terang di dalam outputnya: script apa pun yang berhasil disisipkan ke halaman akan tetap berjalan.

Jalan keluarnya bukan mengetatkan header, melainkan memindahkan script sebaris ke file .js tersendiri. Setelah itu tingkat ketat dapat dipakai tanpa ada yang rusak.

Kenapa style-src tetap memuat unsafe-inline

Itu kompromi yang disengaja. Hampir semua framework menyisipkan gaya sebaris, dan yang paling buruk dapat dilakukan gaya adalah mengubah tampilan — bukan menjalankan kode. Menutupnya menghasilkan banyak kerusakan dengan sedikit perlindungan.

Tiga arahan yang tidak pernah salah

object-src 'none' — Flash dan applet Java sudah mati; <object> tinggal menjadi jalur masuk yang tidak dipakai siapa pun untuk keperluan sah.

base-uri 'self' — tanpa ini, sebuah tag <base> yang disisipkan penyerang dapat mengalihkan seluruh jalur relatif di halaman ke server lain, termasuk script.

frame-ancestors 'none' — mencegah situs lain membingkai halaman Anda. Pengganti X-Frame-Options yang lebih baik dan lebih luwes.

Pasang sebagai header, bukan meta

Arahan frame-ancestors dan report-uri diabaikan sepenuhnya bila CSP dipasang lewat tag <meta>. Pasang sebagai header HTTP di server web.

Menyiapkan penampung laporan

Bila alamat laporan diisi, siapkan penampungnya lebih dulu. Situs yang ramai dapat mengirim ribuan laporan per jam pada hari pertama — sebagian besar dari ekstensi browser pengunjung, bukan dari masalah di situs Anda.

Pertanyaan yang sering diajukan

Apakah CSP menggantikan sanitasi input? Tidak. CSP adalah lapisan kedua — yang menahan akibat ketika lapisan pertama bocor. Sanitasi dan escape tetap wajib.

Bagaimana dengan Google Analytics dan iklan? Keduanya butuh domainnya disebut di script-src. Mode laporan akan menunjukkan persisnya domain mana yang diperlukan, dan itu cara paling andal menemukannya.

Nonce atau hash? Nonce bila halaman dihasilkan server dan dapat menyisipkan nilai baru setiap permintaan. Hash bila script sebarisnya tetap. Yang tidak boleh: nonce bernilai tetap — itu sama saja dengan unsafe-inline.

Lanjut ke