Pengertian Content Security Policy (CSP) dan Cara Kerjanya

Content Security Policy (CSP) adalah header keamanan yang memberi tahu browser sumber daya apa saja yang boleh dimuat dan dijalankan sebuah halaman web, terutama JavaScript. Dengan kebijakan ini, skrip yang disisipkan penyerang lewat celah XSS dapat diblokir meskipun celahnya masih ada. Berikut penjelasan pengertian CSP, cara kerjanya, direktif yang penting, dan langkah menerapkannya tanpa merusak situs.

Apa Itu Content Security Policy?

Menurut dokumentasi MDN, CSP adalah seperangkat instruksi dari situs kepada browser yang membatasi apa yang boleh dilakukan kode situs tersebut. Kegunaan utamanya adalah bertahan dari cross-site scripting (XSS), tetapi CSP juga membantu melawan clickjacking dan memaksa penggunaan HTTPS. Kebijakan ini dikirim sebagai header HTTP Content-Security-Policy pada semua respons, atau untuk situs statis dan aplikasi satu halaman bisa lewat elemen meta, dengan catatan tidak semua fitur didukung di jalur meta.

Sebuah kebijakan terdiri dari direktif yang dipisahkan titik koma, masing-masing berisi nama dan nilai. Contoh paling sederhana adalah mengizinkan sumber daya hanya dari origin sendiri:

Content-Security-Policy: default-src 'self'

Bagaimana Cara Kerja CSP?

Browser membaca header lalu menolak memuat atau menjalankan apa pun yang tidak sesuai kebijakan. Pelanggaran dicatat di konsol dan dapat dilaporkan ke server. Efek sampingnya penting dipahami: begitu default-src atau script-src ada, MDN menyebut hal berikut diblokir secara bawaan:

• blok script inline, kecuali dilindungi nonce atau hash;
• atribut event inline seperti onclick;
• URL berawalan javascript:;
• eval(), new Function(), dan string yang dipakai di setTimeout() atau setInterval().

Karena itu kode yang menjalankan JavaScript secara inline perlu dipindahkan ke berkas skrip atau dilindungi nonce dan hash. Ini juga alasan CSP kuat melawan XSS, sebab banyak serangan XSS bergantung pada skrip inline. Penjelasan celahnya ada di artikel tentang XSS.

Direktif CSP yang Perlu Diketahui

• default-src: kebijakan cadangan untuk jenis sumber daya yang tidak punya direktif sendiri.
• script-src: sumber JavaScript yang diizinkan.
• object-src: mengatur elemen object dan embed. Nilai 'none' memblokirnya sepenuhnya.
• base-uri: membatasi elemen base. Nilai 'none' memblokirnya.
• frame-ancestors: menentukan halaman mana yang boleh menyematkan halaman Anda dalam frame, sehingga melindungi dari clickjacking. MDN menyarankan 'none' kecuali penyematan memang dibutuhkan, dan direktif ini menggantikan X-Frame-Options.
• upgrade-insecure-requests: meningkatkan URL HTTP menjadi HTTPS untuk subresource dan pengiriman form. Ini tidak menggantikan HSTS.

Nonce, Hash, dan Strict CSP

Daftar domain yang diizinkan (allow-list) sulit dibuat dengan benar dan sering memuat domain yang bisa disalahgunakan. Karena itu MDN menyarankan strict CSP yang memakai nonce atau hash.

Nonce adalah nilai acak yang dibuat server untuk setiap respons, dicantumkan di kebijakan, dan ditambahkan ke tiap tag skrip tepercaya. Browser hanya menjalankan skrip yang nonce-nya cocok. Karena harus berganti pada setiap respons, nonce cocok untuk halaman yang dirender dinamis. Hash menghitung sidik jari SHA-256, SHA-384, atau SHA-512 dari isi skrip dan cocok untuk situs statis, walau setiap perubahan skrip menuntut hash dihitung ulang.

Bentuk strict CSP yang umum menurut MDN:

Content-Security-Policy: script-src 'nonce-{RANDOM}'; object-src 'none'; base-uri 'none'

Dibaca dari kiri ke kanan, kebijakan itu berarti: hanya skrip dengan nonce yang cocok yang boleh berjalan, elemen object dan embed ditutup, dan elemen base tidak dapat dipakai untuk membelokkan URL relatif halaman ke tempat lain. Skrip inline buatan penyerang tidak punya nonce yang benar, sehingga browser menolaknya. Nonce harus tidak dapat ditebak dan dibuat baru untuk setiap respons, sebab nonce yang statis sama saja dengan tidak ada perlindungan.

Nilai 'strict-dynamic' memungkinkan skrip tepercaya memuat skrip lain tanpa nonce tersendiri, yang memudahkan penggunaan layanan pihak ketiga. Kompromi yang dicatat MDN adalah perlindungan melemah bila skrip tepercaya membuat elemen skrip dari masukan yang dikendalikan penyerang.

Menerapkan CSP Tanpa Merusak Situs

Memasang kebijakan ketat secara langsung sering membuat fitur situs berhenti bekerja. Alur yang lebih aman:

1. Mulai dengan header Content-Security-Policy-Report-Only. Header ini tidak memblokir apa pun, tetapi mengirim laporan pelanggaran. MDN mencatat header ini tidak dapat dikirim lewat elemen meta.
2. Siapkan titik penerima laporan dengan Reporting-Endpoints dan direktif report-to. MDN menyarankan tetap memasang report-uri yang sudah deprecated sampai dukungan report-to merata.
3. Pelajari laporan, pindahkan skrip inline ke berkas atau beri nonce, lalu perbaiki sumber yang sah.
4. Setelah laporan bersih, aktifkan kebijakan yang sebenarnya. Kedua header dapat dipakai bersamaan, sehingga Anda bisa menguji kebijakan yang lebih ketat sambil yang lama tetap berlaku.

Hindari 'unsafe-inline' dan 'unsafe-eval' bila memungkinkan, karena keduanya membuka kembali jalur yang justru ingin ditutup CSP. Setelah header dipasang, tinjau kembali celah pada konfigurasi server lain lewat panduan security misconfiguration.

Batas Kemampuan CSP

MDN menegaskan CSP adalah pertahanan berlapis, bukan pengganti sanitasi input. OWASP juga menyarankannya sebagai defense in depth yang disesuaikan per aplikasi dan memperingatkan agar tidak mengandalkan kebijakan generik sendirian. Encoding keluaran dan sanitasi tetap menjadi pertahanan utama.

Perhatikan juga bahwa CSP tidak melindungi dari semua hal. Kebijakan tidak memperbaiki logika aplikasi yang salah, tidak menggantikan kontrol akses, dan tidak menolong bila pengguna sendiri memasukkan data sensitif ke situs palsu. Anggaplah ia sebagai jaring pengaman yang bekerja ketika lapisan sebelumnya gagal.

Pertanyaan yang Sering Diajukan

Apakah CSP bisa menggantikan WAF?

Tidak. CSP bekerja di browser pengunjung dan membatasi apa yang dijalankan halaman, sedangkan WAF memfilter lalu lintas di sisi server. Keduanya melengkapi satu sama lain.

Mengapa 'unsafe-inline' sebaiknya dihindari?

Karena ia mengizinkan JavaScript inline, salah satu vektor XSS paling umum, sehingga banyak manfaat CSP hilang. MDN menyebut nilai ini diabaikan bila ekspresi nonce atau hash hadir.

Apakah CSP bisa dipasang lewat tag meta saja?

Bisa untuk kasus sederhana, tetapi header HTTP lebih disarankan karena mendukung seluruh fitur. Mode report-only dan sejumlah direktif tidak tersedia lewat meta.

Bagaimana cara mengetahui CSP merusak halaman?

Buka konsol developer browser, yang akan mencatat setiap pelanggaran, dan pantau laporan pelanggaran yang masuk ke endpoint pelaporan Anda selama masa uji.

Kesimpulan

CSP memberi browser aturan yang jelas tentang apa yang boleh dijalankan sebuah halaman, dan itu mengurangi dampak XSS secara nyata bila dipasang dengan nonce atau hash, bukan daftar domain yang longgar. Terapkan bertahap lewat mode report-only, lalu kunci. Jika Anda ingin memperdalam keamanan aplikasi web secara terstruktur, kursus Linuxhackingid menyediakan jalur belajar yang dapat Anda ikuti.