CSP Headers: Cara Kerja, Contoh, dan Implementasinya

Website dapat terlihat normal, tetapi tetap memiliki celah keamanan yang memungkinkan script berbahaya dijalankan di browser pengunjung. Untuk mengurangi risiko tersebut, CSP Headers adalah mekanisme keamanan yang dapat digunakan untuk mengatur resource apa saja yang boleh dimuat dan dijalankan oleh browser.

Dengan Content Security Policy (CSP), website dapat menentukan sumber script, CSS, iframe, dan resource lainnya yang dipercaya. Jika ada resource yang tidak sesuai kebijakan, browser akan langsung memblokirnya sebelum dijalankan. Pada artikel ini, Anda akan mengetahui tentang apa itu CSP Headers, cara kerjanya, direktif yang sering digunakan, contoh implementasi, serta tips penerapannya untuk meningkatkan keamanan website.

Ringkasan Cepat

• CSP adalah header keamanan yang memberi aturan ke browser: resource apa yang boleh dimuat dan dieksekusi.
• Efektif menurunkan risiko XSS, clickjacking (via frame-ancestors), dan injeksi resource dari pihak ketiga.
• Implementasi terbaik dimulai dari Report-Only, audit pelanggaran, lalu diperketat bertahap.
• Tantangan umum di WordPress: inline script/style dari theme/plugin, sehingga perlu strategi nonce/hash atau refactor.

Apa Itu CSP Header dan Fungsinya untuk Keamanan Website?

Content Security Policy atau CSP adalah HTTP header yang memberi instruksi kepada browser tentang sumber konten mana yang boleh dimuat atau dijalankan di sebuah halaman.

Cara memahaminya cukup sederhana. CSP bekerja seperti daftar aturan yang menentukan resource mana saja yang boleh masuk. Jika ada script dari domain yang tidak diizinkan, browser akan langsung menolaknya sebelum script tersebut sempat berjalan dan menimbulkan risiko keamanan.

CSP berperan sebagai lapisan keamanan tambahan di sisi client. Artinya, CSP tidak menghapus bug di dalam kode, tetapi membantu membuat proses eksploitasi menjadi jauh lebih sulit dilakukan.

Beberapa masalah utama yang disasar CSP antara lain:

• XSS atau Cross Site Scripting
  Injeksi script yang dieksekusi di browser korban.
• Data injection
  Pemuatan script atau asset dari sumber yang tidak tepercaya.
• Clickjacking
  Website dipasang dalam iframe di situs lain untuk menipu pengguna.
• Supply chain attack
  Third party script berubah menjadi berbahaya dan berisiko menyerang pengguna.

Hal penting yang perlu diingat, CSP bukan pengganti sanitasi input. CSP lebih tepat dipahami sebagai sabuk pengaman tambahan yang membantu mengurangi dampak ketika ada celah keamanan di sisi client.

Cara Kerja CSP di Browser

Alurnya sederhana: server mengirim header CSP → browser membaca policy → setiap resource yang ingin dimuat dibandingkan dengan policy → yang tidak cocok diblokir.

Contoh Sederhana

script-src 'self' https://apis.google.com

Policy ini memberi tahu browser: “Hanya jalankan script dari domain Anda sendiri dan dari apis.google.com. Yang lain, tolak.”

Tiga Cara Mengirim CSP

• Header Content-Security-Policy cara yang disarankan. Policy langsung ditegakkan oleh browser
• Header Content-Security-Policy-Report-Only untuk testing. Policy tidak ditegakkan, tapi pelanggaran tetap dilaporkan. Cocok untuk transisi sebelum enforcing penuh
• Meta tag di HTML bisa dipakai, tapi fiturnya lebih terbatas dibanding header

Direktif CSP yang Paling Sering Dipakai

Strategi yang paling aman: mulai dari default-src sebagai baseline, lalu tambahkan direktif spesifik untuk resource yang memang perlu dibuka.

Direktif Inti untuk Resource

Setiap direktif mengatur satu “kelas resource” tertentu:

• default-src
  Fallback untuk semua direktif fetch yang tidak ditentukan secara eksplisit
• script-src
  Mengontrol dari mana script boleh dimuat dan dieksekusi
• style-src
  Mengontrol stylesheet
• img-src
  Mengontrol gambar
• font-src
  Mengontrol font
• connect-src
  Mengontrol koneksi fetch, XHR, WebSocket
• frame-src
  Mengontrol iframe yang dimuat halaman

Contoh baseline paling umum:

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

Contoh yang lebih ketat, buka sedikit demi sedikit:

Content-Security-Policy: default-src 'none'; img-src 'self';

Mulai dari 'none', lalu buka hanya yang benar-benar dibutuhkan.

Direktif Proteksi: Yang Paling “Worth It” untuk Diterapkan Cepat

1. frame-ancestors
Cegah Clickjacking Menggantikan X-Frame-Options dengan cara yang lebih modern dan fleksibel.

Content-Security-Policy: frame-ancestors 'none';

2. form-action
Batasi Tujuan Submit Form Mencegah form di halamanmu diarahkan ke domain lain untuk keperluan phishing.

Content-Security-Policy: form-action 'self';

3. object-src
Blokir Legacy Executable Mencegah injeksi konten berbahaya lewat tag <object> yang sudah jarang dipakai tapi masih bisa dieksploitasi.

Content-Security-Policy: object-src 'none';

4. upgrade-insecure-request
Paksa HTTPS Memaksa semua resource dimuat lewat HTTPS, meski URL-nya ditulis dengan HTTP.

Content-Security-Policy: upgrade-insecure-requests;

CSP Report-Only vs Enforcing: Strategi Implementasi yang Aman

Satu aturan yang tidak boleh dilanggar yaitu jangan langsung pasang CSP enforcing di production. Risiko memblokir resource yang legitimate jauh lebih besar dari yang Anda kira.

Mulai dari Report-Only → lihat apa yang akan rusak → perbaiki → baru enforce.

Langkah implementasi yang realistis:

1. Pasang CSP di Report-Only
2. Kumpulkan violation dari console dan endpoint (kalau ada)
3. Audit resource yang legitimate
4. Perketat sedikit demi sedikit
5. Setelah stabil, pindah ke enforcing

Pro tip dari tim: jangan mulai dari “strictest possible” di produksi. CSP itu seperti pintu akses kantor, kalau salah setting, karyawan sendiri yang tidak bisa masuk.

Kesalahan Paling Umum Saat Pasang CSP

CSP yang dipasang dengan cara yang salah bisa memberikan rasa aman yang palsu policy-nya ada, tapi proteksinya minimal.

Ini 5 kesalahan yang paling sering terjadi:

1. Memakai unsafe-inline untuk cepat beres
Ini sering “memperbaiki” masalah UI, tapi melemahkan proteksi XSS.

2. Memakai unsafe-eval karena library lama
Ini membuka pintu bagi kelas serangan tertentu.

3. Allowlist kebanyakan domain
Kalau policy Anda mengizinkan terlalu banyak sumber, attacker punya lebih banyak permukaan.

4. Tidak mendata third-party script
Tag manager, pixel, chat widget, font, CDN, semuanya harus diinventaris.

5. Tidak pakai Report-Only
Langsung enforcing dan akhirnya “web error” di user.

CCSP di WordPress: Penyebab Error dan Cara Mengatasinya

WordPress dan CSP yang terlalu ketat sering menjadi kombinasi yang cukup menantang. Penyebabnya bukan semata karena konfigurasi CSP keliru, tetapi karena ekosistem WordPress memang banyak bergantung pada theme, plugin, dan page builder yang menyisipkan inline CSS atau JavaScript.

Ketika CSP diterapkan tanpa unsafe-inline, beberapa fungsi penting bisa ikut terblokir. Hal ini terjadi karena banyak elemen di WordPress belum dirancang dengan CSP ketat sebagai prioritas utama.

Di WordPress, sumber masalah CSP yang paling sering muncul antara lain:

• Theme menyisipkan inline CSS atau JavaScript
• Plugin page builder menambahkan kode inline
• Plugin tracking memuat script dinamis

Jika ingin tetap menerapkan aturan yang ketat tanpa unsafe-inline, ada dua pendekatan yang umum digunakan:

• Nonce based CSP
  Server membuat nonce unik untuk setiap request, lalu script tertentu diberi atribut nonce agar diizinkan berjalan.
• Hash based CSP
  Script inline yang masih diperlukan diberi hash agar dapat dikenali dan diizinkan oleh browser.

Namun, penerapan nonce atau hash di WordPress bisa cukup rumit karena banyak kode inline dibuat secara dinamis oleh plugin.

Untuk banyak site WordPress, pendekatan yang lebih praktis adalah memulai dari aturan proteksi yang tidak terlalu mengganggu, seperti:

• frame-ancestors
• object-src
• base-uri
• form-action

Setelah itu, jalankan mode Report Only untuk script-src dan style-src. Langkah ini membantu melihat potensi pelanggaran CSP tanpa langsung memblokir fungsi penting di website.

Agar penerapan CSP lebih stabil, kurangi penggunaan third party script yang tidak perlu, rapikan proses enqueue script, lalu pertimbangkan nonce atau hash hanya jika benar benar dibutuhkan.

CSP untuk WordPress sebaiknya dipahami sebagai proses bertahap. Manfaat keamanan yang besar tetap bisa diperoleh dari beberapa direktif proteksi dasar, tanpa harus langsung menerapkan aturan yang terlalu ketat dan berisiko mengganggu fungsi website.

Tabel: contoh policy CSP (basic vs medium vs strict)

Catatan: contoh di atas adalah konsep level penerapan, bukan policy final satu baris.

Checklist Penerapan CSP untuk Website Produksi

Inventaris resource, pasang Report-Only, audit pelanggaran, perketat bertahap, dokumentasikan.

Checklist cepat:

1. List semua sumber: CDN, fonts, analytics, tag manager, embed
2. Pasang Report-Only
3. Kumpulkan violation (console dan endpoint)
4. Putuskan: allowlist vs hapus dependency
5. Tambahkan direktif proteksi: frame-ancestors, object-src, form-action
6. Perketat script-src/style-src bertahap
7. Uji halaman kritikal (checkout/login/contact)
8. Dokumentasi siapa menambah domain apa (biar tidak liar)

Keamanan WordPress Lebih Optimal dengan Hosting dan Support yang Tepat

Meskipun CSP membantu memperkuat keamanan dari sisi browser, perlindungan WordPress tetap membutuhkan fondasi server yang rapi. Mulai dari pembaruan berkala, konfigurasi yang aman, hingga dukungan teknis yang siap membantu ketika terjadi kendala.

Untuk menjaga keamanan dan stabilitas situs bisnis, WordPress Hosting dari Rumahweb dapat menjadi pilihan yang praktis. Dengan dukungan tim teknis terspesialisasi selama 24/7, layanan ini membantu memastikan infrastruktur website tetap optimal, aman, dan didukung dokumentasi tutorial yang lengkap.

FAQ

Kesimpulan

CSP (Content Security Policy) adalah salah satu security header paling berguna untuk mengurangi risiko XSS dan injeksi konten. Cara kerjanya sederhana: Anda menentukan sumber resource yang dipercaya, lalu browser akan menegakkan aturan tersebut.

CSP sering diposisikan sebagai lapisan defense-in-depth, terutama jika diterapkan bertahap menggunakan mode Report-Only sebelum benar-benar di-enforce.

Kalau baru mulai menerapkan CSP, pendekatan paling aman adalah memblokir framing dan object terlebih dahulu, lalu audit penggunaan script melalui Report-Only sebelum memperketat policy sedikit demi sedikit. CSP yang baik bukan yang paling ketat, tetapi yang tetap aman dan mudah di-maintain.

Referensi

• OWASP CSP Cheat Sheet
• Chrome Developers (CSP)
• MDN (default-src directive)