Setiap kali pengguna membuka sebuah website, browser menjalankan ratusan baris kode JavaScript, memuat stylesheet eksternal, dan mengunduh gambar dari berbagai sumber. Di balik layar, seorang penyerang bisa menyuntikkan skrip berbahaya yang mencuri data login, membajak sesi pengguna, atau mengarahkan korban ke situs phishing. Tanpa mekanisme pertahanan yang tepat, semua ini bisa terjadi dalam hitungan detik.
3| 4| 5| 6|Di sinilah Content Security Policy (CSP) berperan. CSP adalah lapisan keamanan tambahan yang membantu mendeteksi dan memitigasi berbagai jenis serangan berbasis injeksi konten, termasuk Cross-Site Scripting (XSS) dan data injection. Berdasarkan laporan OWASP Top 10 (2021), injection masih menempati posisi ketiga sebagai kategori risiko keamanan aplikasi web paling kritis, dan XSS termasuk di dalamnya.
7| 8| 9| 10|Artikel ini membahas secara lengkap apa itu Content Security Policy, bagaimana cara kerjanya, directive penting yang perlu diketahui, serta langkah praktis menerapkannya di website. Cocok untuk developer web, pemilik website, dan siapa pun yang ingin memperkuat pertahanan aplikasi web dari serangan injeksi konten.
11| 12| 13| 14|
18|Apa Itu Content Security Policy (CSP)?
23| 24| 25| 26|Content Security Policy (CSP) adalah standar keamanan web yang memungkinkan pemilik website mendeklarasikan sumber daya mana saja yang boleh dimuat dan dieksekusi oleh browser. CSP bekerja melalui HTTP response header atau elemen <meta> HTML yang dikirim server ke browser pengunjung.
Secara sederhana, CSP berfungsi seperti daftar putih (whitelist) yang memberitahu browser: “Hanya izinkan skrip dari domain ini, hanya muat gambar dari sumber itu, dan tolak semua yang lain.” Jika ada konten yang mencoba dimuat dari sumber yang tidak diizinkan, browser akan memblokirnya secara otomatis.
31| 32| 33| 34|Menurut Mozilla Developer Network (MDN), CSP dirancang khusus untuk mengurangi risiko serangan XSS dengan membatasi asal-usul (origin) sumber daya yang bisa dieksekusi di halaman web. Standar ini pertama kali diperkenalkan sebagai W3C Candidate Recommendation dan kini didukung oleh semua browser modern, termasuk Chrome, Firefox, Safari, dan Edge.
35| 36| 37| 38|CSP bukan pengganti dari praktik keamanan lain seperti input validation atau output encoding. CSP adalah lapisan pertahanan tambahan (defense in depth) yang memastikan bahwa meskipun penyerang berhasil menyuntikkan kode berbahaya, browser tetap bisa memblokir eksekusinya. Ini menjadikan CSP sebagai salah satu kontrol keamanan paling efektif dalam arsitektur web modern.
39| 40| 41| 42|Mengapa CSP Penting untuk Keamanan Web?
43| 44| 45| 46|Serangan XSS secara konsisten masuk dalam daftar kerentanan web paling berbahaya setiap tahunnya. OWASP Top 10 (2021) menempatkan injection di peringkat ketiga kategori risiko tertinggi, dan XSS adalah salah satu bentuk paling umum dari injection. Dampak serangan XSS bisa sangat serius, mulai dari pencurian cookie sesi, pengambilalihan akun, hingga defacement website.
47| 48| 49| 50|Baca juga: Cross-Site Scripting (XSS) – Jenis, Eksploitasi, dan Mitigasi Lengkap untuk memahami lebih dalam tentang ancaman XSS dan cara pencegahannya.
51| 52| 53| 54|Menurut laporan Verizon Data Breach Investigations Report (DBIR) 2025, serangan berbasis aplikasi web menyumbang lebih dari 30 persen dari total insiden keamanan yang tercatat. Banyak dari insiden ini melibatkan eksploitasi kerentanan XSS yang sebenarnya bisa dicegah dengan implementasi CSP yang tepat.
55| 56| 57| 58|Beberapa keuntungan utama menerapkan CSP antara lain:
59| 60| 61| 62|-
63|
- Mencegah XSS Reflected dan Stored dengan membatasi sumber skrip yang boleh dieksekusi. 64|
- Memblokir injeksi konten seperti iframe berbahaya, gambar dari sumber tidak dikenal, atau stylesheet eksternal mencurigakan. 65|
- Mengurangi risiko clickjacking melalui directive
frame-ancestors.
66| - Mendeteksi serangan melalui mode report-only yang mengirim laporan pelanggaran ke endpoint monitoring. 67|
- Mematuhi standar keamanan seperti NIST SP 800-53 dan PCI DSS yang merekomendasikan penggunaan CSP. 68|
CSP juga menjadi bagian penting dari ekosistem security headers modern. Baca juga: Apa Itu Security Headers? Panduan Lengkap HTTP Security Headers untuk Web Developer untuk memahami bagaimana CSP bekerja bersama header keamanan lainnya.
73| 74| 75| 76|Bagaimana Cara Kerja Content Security Policy?
77| 78| 79| 80|Cara kerja CSP cukup sederhana namun sangat efektif. Server web mengirimkan header Content-Security-Policy dalam respons HTTP. Browser kemudian membaca kebijakan tersebut dan membandingkan setiap permintaan sumber daya dengan aturan yang ditetapkan. Jika sumber daya berasal dari lokasi yang tidak diizinkan, browser akan memblokirnya.
88|Dua Mode CSP: Enforcement dan Report-Only
93| 94| 95| 96|CSP memiliki dua mode operasi yang bisa digunakan secara bersamaan:
97| 98| 99| 100|1. Mode Enforcement (Header: Content-Security-Policy) – Browser akan memblokir semua sumber daya yang melanggar kebijakan. Mode ini adalah mode produksi yang benar-benar melindungi pengguna. Setiap pelanggaran akan dicatat di browser console.
101| 102| 103| 104|2. Mode Report-Only (Header: Content-Security-Policy-Report-Only) – Browser tidak memblokir sumber daya yang melanggar, tetapi mengirimkan laporan pelanggaran ke endpoint yang ditentukan. Mode ini sangat berguna saat tahap pengujian sebelum menerapkan kebijakan penuh di produksi.
105| 106| 107| 108|Kombinasi kedua mode ini memungkinkan developer menguji kebijakan CSP secara bertahap tanpa risiko merusak fungsionalitas website. Setelah laporan menunjukkan tidak ada pelanggaran, mode enforcement bisa diaktifkan dengan aman.
109| 110| 111| 112|Proses Validasi di Browser
113| 114| 115| 116|Ketika browser menerima halaman dengan CSP, proses validasi terjadi dalam urutan berikut:
117| 118| 119| 120|-
121|
- Browser membaca header CSP dari respons HTTP server. 122|
- Browser mem-parsing setiap directive dan nilai sumber yang diizinkan. 123|
- Saat halaman mencoba memuat skrip, stylesheet, gambar, font, atau sumber daya lain, browser memeriksa apakah sumber tersebut sesuai dengan directive CSP. 124|
- Jika sumber diizinkan, browser melanjutkan pemuatan normal. 125|
- Jika sumber ditolak, browser memblokir permintaan dan mencatat pelanggaran di console. 126|
- Jika directive
report-uriataureport-todikonfigurasi, browser mengirim laporan pelanggaran ke endpoint.
127|
Apa Saja Directive CSP yang Paling Penting?
132| 133| 134| 135|CSP memiliki puluhan directive yang bisa dikonfigurasi. Namun, beberapa directive jauh lebih penting untuk keamanan dibanding yang lain. Berikut adalah directive CSP paling kritis yang harus dipahami setiap developer web:
136| 137| 138| 139|default-src – Fallback untuk Semua Sumber Daya
140| 141| 142| 143|Directive default-src berfungsi sebagai nilai default untuk semua directive yang tidak ditentukan secara eksplisit. Jika sebuah directive spesifik tidak dikonfigurasi, browser akan menggunakan nilai dari default-src. Contoh:
Content-Security-Policy: default-src 'self'Konfigurasi di atas memberitahu browser bahwa semua sumber daya hanya boleh dimuat dari origin yang sama dengan website (self). Ini adalah titik awal yang baik untuk kebijakan CSP yang ketat.
152| 153| 154| 155|script-src – Mengontrol JavaScript
156| 157| 158| 159|script-src adalah directive paling penting karena mengontrol dari mana JavaScript boleh dimuat dan dieksekusi. Directive ini adalah pertahanan utama melawan XSS. Contoh kebijakan yang umum digunakan:
Content-Security-Policy: script-src 'self' https://cdn.example.comNilai khusus seperti 'unsafe-inline' dan 'unsafe-eval' SEBAIKNYA DIHINDARI karena melemahkan perlindungan CSP terhadap XSS. Sebagai gantinya, gunakan nonce (nilai acak satu kali) atau hash untuk mengizinkan inline script tertentu.
style-src – Mengontrol CSS
172| 173| 174| 175|style-src mengontrol sumber stylesheet CSS. Sama seperti script, hindari 'unsafe-inline' kecuali benar-benar diperlukan. Gunakan nonce atau hash untuk inline style yang legitimate.
img-src, font-src, media-src – Media dan Aset
180| 181| 182| 183|Directive ini mengontrol sumber gambar, font, dan media (audio/video). Directive ini biasanya lebih longgar karena risiko keamanannya lebih rendah dibanding script dan style. Namun tetap penting untuk membatasi sumber ke domain terpercaya.
184| 185| 186| 187|frame-ancestors – Mencegah Clickjacking
188| 189| 190| 191|frame-ancestors menentukan domain mana yang boleh menampilkan halaman dalam iframe. Directive ini menggantikan header lama X-Frame-Options dan memberikan kontrol yang lebih granular. Contoh:
Content-Security-Policy: frame-ancestors 'none'Nilai 'none' sepenuhnya mencegah halaman ditampilkan dalam iframe, melindungi dari serangan clickjacking.
connect-src – Membatasi Koneksi API dan WebSocket
204| 205| 206| 207|connect-src membatasi URL yang bisa dijangkau melalui fetch API, XMLHttpRequest, WebSocket, dan EventSource. Directive ini penting untuk mencegah exfiltration data ke server penyerang.
form-action – Mencegah Form Hijacking
212| 213| 214| 215|form-action membatasi URL tujuan dari form submission. Ini mencegah penyerang mengubah action form untuk mengirim data pengguna ke server jahat. Contoh:
Content-Security-Policy: form-action 'self' https://api.example.comBagaimana Cara Menerapkan CSP di Website?
224| 225| 226| 227|Menerapkan CSP membutuhkan pendekatan bertahap. Langsung menggunakan kebijakan ketat bisa merusak fungsionalitas website. Berdasarkan panduan OWASP CSP Cheat Sheet dan pengalaman industri, berikut adalah langkah-langkah implementasi yang direkomendasikan:
228| 229| 230| 231|Langkah 1: Inventarisasi Sumber Daya
232| 233| 234| 235|Sebelum menulis kebijakan, identifikasi semua sumber daya yang digunakan website: CDN untuk JavaScript, penyedia font, layanan analytics, API endpoint, dan widget pihak ketiga. Gunakan browser DevTools untuk melihat semua permintaan jaringan yang terjadi saat halaman dimuat.
236| 237| 238| 239|Langkah 2: Mulai dengan Mode Report-Only
240| 241| 242| 243|Terapkan CSP dalam mode report-only terlebih dahulu. Gunakan header Content-Security-Policy-Report-Only dan arahkan laporan ke endpoint monitoring. Biarkan berjalan selama beberapa hari untuk mengumpulkan data pelanggaran.
Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report-endpointLangkah 3: Analisis Laporan Pelanggaran
252| 253| 254| 255|Periksa laporan pelanggaran yang masuk. Setiap laporan menunjukkan sumber daya yang akan diblokir jika mode enforcement diaktifkan. Evaluasi setiap pelanggaran: apakah sumber daya tersebut legitimate atau memang seharusnya diblokir?
256| 257| 258| 259|Langkah 4: Sempurnakan Kebijakan
260| 261| 262| 263|Berdasarkan hasil analisis, tambahkan sumber daya legitimate ke daftar putih kebijakan. Gunakan nilai spesifik seperti domain lengkap, bukan wildcard. Pertimbangkan penggunaan nonce atau hash untuk inline script yang tidak bisa dihindari.
264| 265| 266| 267|Langkah 5: Aktifkan Mode Enforcement
268| 269| 270| 271|Setelah yakin kebijakan sudah akurat, ganti header ke Content-Security-Policy untuk mengaktifkan mode blokir penuh. Tetap pertahankan endpoint pelaporan untuk memonitor pelanggaran yang mungkin terjadi pada skenario edge case.
Contoh Implementasi di Berbagai Web Server
276| 277| 278| 279|Berikut adalah contoh konfigurasi CSP di web server populer:
280| 281| 282| 283|Nginx:
284| 285| 286|add_header Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; frame-ancestors 'none'; form-action 'self';" always;Apache (.htaccess):
291| 292| 293|Header always set Content-Security-Policy "default-src 'self'; script-src 'self' https://cdn.example.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'; frame-ancestors 'none'; form-action 'self';"
301|Apa Tantangan dalam Mengimplementasikan CSP?
306| 307| 308| 309|Meskipun CSP sangat efektif, implementasinya tidak selalu mudah. Berikut adalah tantangan umum yang sering dihadapi developer dan cara mengatasinya:
310| 311| 312| 313|Inline Script dan Style
314| 315| 316| 317|Banyak website menggunakan inline script untuk event handler seperti onclick atau blok <script> di dalam HTML. CSP memblokir inline script secara default karena tidak bisa membedakan inline script legitimate dengan yang disuntikkan penyerang. Solusinya adalah dengan menggunakan nonce (nilai acak yang unik per permintaan) atau hash kriptografis dari konten script yang diizinkan.
Third-Party Script dan Widget
322| 323| 324| 325|Widget media sosial, analytics seperti Google Analytics, dan layanan pihak ketiga sering memuat script tambahan dari berbagai domain. Ini menyulitkan pembuatan kebijakan CSP yang ketat. Solusinya adalah dengan membatasi hanya domain spesifik yang diperlukan dan menghindari wildcard. Untuk layanan yang sering berubah domain, pertimbangkan menggunakan CSP strict-dynamic.
326| 327| 328| 329|Kompatibilitas Browser
330| 331| 332| 333|Meskipun browser modern mendukung CSP dengan baik, beberapa directive seperti report-to masih relatif baru dan tidak didukung semua browser. Directive report-uri yang lebih lama masih bisa digunakan sebagai fallback. Selalu uji kebijakan di berbagai browser sebelum deployment.
Baca juga: Walkthrough TryHackMe OWASP Top 10 Lanjutan: Panduan Lengkap Eksploitasi Kerentanan Web untuk melihat bagaimana kerentanan seperti XSS dieksploitasi dalam praktik dan mengapa CSP sangat penting sebagai pertahanan.
338| 339| 340| 341|Pertanyaan yang Sering Diajukan (FAQ)
342| 343| 344| 345|Apakah CSP bisa sepenuhnya mencegah XSS?
346| 347| 348| 349|CSP bukan solusi tunggal untuk mencegah XSS. CSP adalah lapisan pertahanan tambahan yang sangat efektif, tetapi harus dikombinasikan dengan praktik keamanan lain seperti input validation, output encoding, dan penggunaan framework yang aman. CSP berfungsi sebagai jaring pengaman: jika pertahanan lain gagal, CSP tetap bisa memblokir eksekusi script berbahaya.
350| 351| 352| 353|Apakah CSP mempengaruhi performa website?
354| 355| 356| 357|Dampak performa CSP sangat minimal. Browser memproses kebijakan CSP dalam hitungan mikrodetik saat memuat halaman. Proses ini terjadi secara paralel dan tidak memblokir rendering halaman. Justru, CSP bisa sedikit meningkatkan performa karena mencegah pemuatan sumber daya yang tidak perlu dari domain tidak dikenal.
358| 359| 360| 361|Bagaimana cara mengecek CSP di website saya?
362| 363| 364| 365|Gunakan browser DevTools (tab Network atau Application) untuk melihat response header. Tools online seperti Google CSP Evaluator (csp-evaluator.withgoogle.com) bisa menganalisis kebijakan CSP dan memberikan rekomendasi perbaikan. Scanner keamanan seperti Mozilla Observatory juga mengevaluasi CSP sebagai bagian dari penilaian keamanan website.
366| 367| 368| 369|Apakah WordPress bisa menggunakan CSP?
370| 371| 372| 373|Ya, WordPress bisa menggunakan CSP melalui konfigurasi server (Nginx atau Apache) atau plugin keamanan. Beberapa plugin seperti Wordfence dan Sucuri menyediakan fitur untuk menambahkan header keamanan termasuk CSP. Cara paling efektif adalah dengan menambahkan header CSP langsung di konfigurasi web server.
374| 375| 376| 377|Apa perbedaan CSP dengan security headers lainnya?
378| 379| 380| 381|CSP adalah salah satu dari beberapa security headers. Header lain seperti Strict-Transport-Security (HSTS) memaksa HTTPS, X-Frame-Options mencegah clickjacking, dan X-Content-Type-Options mencegah MIME sniffing. CSP adalah header paling komprehensif karena bisa mencakup fungsionalitas beberapa header sekaligus melalui directive seperti frame-ancestors yang setara dengan X-Frame-Options.
Kesimpulan
386| 387| 388| 389|Content Security Policy (CSP) adalah salah satu kontrol keamanan web paling kuat yang tersedia untuk developer saat ini. Dengan mendefinisikan secara eksplisit sumber daya mana yang boleh dimuat dan dieksekusi, CSP memberikan perlindungan yang signifikan terhadap serangan XSS, data injection, dan clickjacking. Laporan terbaru dari OWASP dan Verizon DBIR terus menempatkan kerentanan injeksi sebagai ancaman utama, menjadikan CSP sebagai investasi keamanan yang sangat berharga.
390| 391| 392| 393|Implementasi CSP memang membutuhkan perencanaan dan pengujian yang teliti. Pendekatan bertahap mulai dari mode report-only, analisis laporan pelanggaran, hingga aktivasi mode enforcement adalah strategi yang direkomendasikan oleh para ahli keamanan. Dengan alat seperti Google CSP Evaluator dan Mozilla Observatory, developer memiliki sumber daya yang memadai untuk membangun kebijakan CSP yang kuat tanpa merusak pengalaman pengguna.
394| 395| 396| 397|Keamanan web adalah tanggung jawab berkelanjutan. CSP bukanlah solusi yang bisa diatur sekali lalu dilupakan. Kebijakan perlu ditinjau secara berkala seiring perubahan pada website, penambahan layanan pihak ketiga, atau pembaruan standar keamanan. Namun, dengan fondasi CSP yang kuat, website memiliki pertahanan yang jauh lebih kokoh terhadap ancaman yang terus berkembang.
398| 399| 400| 401| 409|