Content Security Policy (CSP) adalah lapisan keamanan tambahan yang digunakan pada situs web untuk mendeteksi dan meredmit jenis serangan tertentu, termasuk Cross-Site Scripting (XSS) dan injeksi data. Dengan membatasi sumber daya seperti skrip, gambar, dan gaya yang dapat dimuat dan dieksekusi oleh peramban pengguna, CSP memberikan kontrol penuh kepada pengembang web terhadap aset yang diizinkan berjalan di domain mereka.
Secara mendasar, CSP bekerja melalui mekanisme pengiriman header HTTP Content-Security-Policy atau tag meta HTML dari peladen ke peramban. Peladen menginstruksikan peramban mengenai domain mana yang sah untuk mengambil data atau menjalankan kode skrip. Jika ada skrip berbahaya pihak ketiga yang mencoba menyusup ke halaman web tanpa izin dari kebijakan yang ditetapkan, peramban akan langsung memblokir eksekusi tersebut dan melaporkannya ke titik akhir pelaporan yang ditentukan.
Anatomi Direktif Content Security Policy
Kebijakan CSP dibangun menggunakan sekumpulan direktif yang masing-masing mengatur aturan untuk jenis sumber daya tertentu. Pemahaman yang akurat mengenai direktif ini sangat krusial agar aplikasi web tetap berfungsi secara normal tanpa mengorbankan aspek keamanan sistem secara keseluruhan.
Direktif utama yang paling sering digunakan mencakup default-src sebagai kebijakan fallback, script-src untuk mengatur sumber skrip JavaScript, serta style-src untuk lembar gaya CSS. Penggunaan nilai yang terlalu longgar seperti unsafe-inline atau unsafe-eval harus dihindari sebisa mungkin karena membuka celah keamanan yang dapat dimanfaatkan oleh penyerang untuk menjalankan kode arbitrer.
| Direktif CSP | Fungsi Utama | Contoh Nilai Aman |
|---|---|---|
| default-src | Kebijakan dasar untuk semua jenis sumber daya | 'self' https://api.domain.com |
| script-src | Menentukan sumber eksekusi skrip JavaScript | 'self' https://trustedscripts.com |
| style-src | Mengatur sumber pemuatan file CSS dan gaya | 'self' 'unsafe-inline' |
| img-src | Membatasi sumber muat file gambar | 'self' data: https://images.com |
| connect-src | Mengontrol target koneksi (AJAX, WebSockets) | 'self' https://api.domain.com |
Implementasi Header HTTP dan Meta Tag
Penerapan CSP dapat dilakukan melalui konfigurasi peladen web seperti Nginx, Apache, atau melalui pengaturan aplikasi backend di Node.js, PHP, serta kerangka kerja modern lainnya. Pendekatan melalui header HTTP jauh lebih dianjurkan dibandingkan menggunakan tag meta HTML karena beberapa direktif seperti frame-ancestors dan report-uri tidak didukung sepenuhnya melalui elemen meta.
Sebagai contoh implementasi pada peladen Nginx, pengembang dapat menambahkan baris konfigurasi add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://apis.google.com;"; pada blok server. Konfigurasi ini memastikan bahwa peramban hanya akan mengeksekusi skrip yang berasal dari domain asal dan domain resmi Google, sementara skrip dari sumber eksternal lainnya akan ditolak secara otomatis.
Mode Pelaporan dan Pengujian CSP
Mengubah kebijakan keamanan secara langsung pada situs web produksi tanpa pengujian yang memadai dapat melumpuhkan fungsi situs jika ada sumber daya sah yang terblokir. Oleh karena itu, pengembang dianjurkan menggunakan mode pengujian terlebih dahulu melalui header Content-Security-Policy-Report-Only sebelum menerapkan kebijakan pengetatan secara permanen.
Dalam mode pelaporan ini, peramban tetap menjalankan seluruh sumber daya seperti biasa tetapi mengirimkan laporan JSON ke URL yang ditentukan pada direktif report-uri atau report-to setiap kali terjadi pelanggaran kebijakan. Dengan cara ini, tim keamanan dapat memantau potensi kesalahan konfigurasi, mendeteksi upaya serangan nyata, dan menyempurnakan aturan kebijakan tanpa mengganggu pengalaman pengguna akhir.
Mitos dan Fakta Implementasi CSP
Banyak pengembang mengira bahwa penerapan Content Security Policy secara otomatis menutup seluruh celah keamanan aplikasi web. Faktanya, CSP adalah mekanisme pertahanan mendalam (defense-in-depth) yang dirancang untuk memitigasi dampak dari kerentanan seperti XSS, bukan untuk memperbaiki akar permasalahan kode yang tidak aman di sisi backend.
Mitos lain menyatakan bahwa CSP terlalu rumit dan merusak fungsionalitas situs web pihak ketiga seperti analitik dan widget iklan. Fakta di lapangan menunjukkan bahwa dengan perencanaan direktif yang matang, penggunaan nonce, atau hash, integrasi layanan pihak ketiga tetap dapat berjalan secara aman dan terisolasi tanpa menurunkan performa maupun tingkat perlindungan sistem secara keseluruhan.