Apa itu Content Security Policy (CSP)?

CSP adalah mekanisme keamanan browser yang membatasi sumber script, style, image, dan resource lain yang boleh dimuat oleh aplikasi web.

Mengapa CSP penting untuk SaaS?

SaaS sering memakai banyak integrasi pihak ketiga, sehingga CSP membantu mengurangi risiko XSS, penyisipan script berbahaya, dan kebocoran data dari resource yang tidak tepercaya.

Apakah CSP cukup untuk mencegah XSS?

Tidak. CSP sangat membantu, tetapi harus dipasangkan dengan sanitasi input, escaping output, code review, dan praktik frontend yang aman.

Bagaimana cara mulai menerapkan CSP?

Mulailah dari mode report-only, inventarisasi semua resource yang dipakai, lalu terapkan policy ketat secara bertahap sambil memantau pelanggaran.

Apakah CSP cocok untuk startup di Indonesia?

Ya. CSP cocok untuk startup maupun enterprise di Indonesia karena bisa diterapkan bertahap tanpa mengganggu pengembangan jika direncanakan dengan baik.

Panduan Content Security Policy untuk SaaS Indonesia

Informasi waktu: Artikel ini dibuat otomatis pada 17 Juni 2026 pukul 00.07 (Asia/Jakarta, 2026-06-16T17:07:36.794Z).

Apa itu Content Security Policy dan kenapa penting untuk SaaS?

Content Security Policy (CSP) adalah lapisan keamanan di browser yang membatasi dari mana aplikasi web boleh memuat script, style, image, font, frame, dan resource lain. Untuk SaaS, CSP sangat penting karena aplikasi modern hampir selalu bergantung pada banyak komponen: framework frontend, analytics, tag manager, widget chat, payment gateway, CDN, dan kadang script internal yang tersebar di beberapa domain.

Tanpa CSP, satu celah XSS saja bisa memberi penyerang kesempatan menjalankan script di browser pengguna, mencuri token, mengubah tampilan UI, atau menyisipkan flow login palsu. Di konteks SaaS Indonesia, risiko ini makin relevan karena banyak tim produk bergerak cepat, mengandalkan third-party integration, dan sering menambah script baru tanpa inventarisasi yang rapi.

CSP bukan pengganti secure coding, tetapi ia memberi batas eksplisit pada browser. Dengan begitu, bahkan jika ada bug di frontend, dampaknya bisa diperkecil.

Bagaimana CSP bekerja di browser?

CSP dikirim lewat header HTTP, misalnya Content-Security-Policy, atau kadang lewat meta tag, meski header jauh lebih disarankan. Browser membaca policy tersebut lalu menolak resource yang tidak sesuai aturan.

Contoh sederhana:

Content-Security-Policy: default-src 'self'; script-src 'self' https://cdn.example.com; object-src 'none'; base-uri 'self'

Policy di atas berarti aplikasi hanya boleh memuat resource default dari domain sendiri, script dari domain sendiri dan CDN tertentu, tidak boleh memakai plugin lama seperti object, dan hanya boleh mengubah base URL dari origin sendiri.

Prinsipnya sederhana: mulai dari kebijakan paling ketat yang masih kompatibel dengan aplikasi, lalu longgarkan hanya jika ada kebutuhan nyata.

Key takeaways

CSP membantu membatasi dampak XSS dan injeksi script di aplikasi SaaS.
Mulai implementasi dari mode report-only agar tim bisa melihat pelanggaran tanpa memutus aplikasi.
Inventarisasi semua third-party script, CDN, dan endpoint sebelum menulis policy.
CSP efektif jika dipadukan dengan sanitasi input, escaping output, dan review keamanan frontend.
Untuk SaaS di Indonesia, pendekatan bertahap lebih aman daripada policy yang terlalu longgar sejak awal.

Apa saja directive CSP yang paling penting?

Tidak semua directive harus dipakai sejak hari pertama, tetapi beberapa sangat penting untuk hampir semua SaaS:

default-src: fallback untuk resource yang tidak disebutkan secara spesifik.
script-src: mengatur sumber JavaScript, ini biasanya paling sensitif.
style-src: mengatur sumber CSS, termasuk inline style jika memang diperlukan.
img-src: membatasi sumber gambar, termasuk data URI bila dibutuhkan.
connect-src: mengatur endpoint API, websocket, dan telemetry.
frame-src atau child-src: untuk iframe dan embedded content.
font-src: untuk font yang dimuat dari CDN atau domain sendiri.
object-src: sebaiknya none untuk mencegah plugin lama.
base-uri: mencegah manipulasi base tag.
frame-ancestors: membatasi siapa yang boleh menampilkan aplikasi dalam iframe.

Untuk banyak produk SaaS, script-src, connect-src, dan frame-ancestors adalah tiga directive yang paling sering menentukan tingkat keamanan nyata.

Bagaimana memulai implementasi CSP tanpa merusak aplikasi?

Langkah paling aman adalah memakai Content-Security-Policy-Report-Only terlebih dahulu. Mode ini tidak memblokir resource, tetapi mengirim laporan saat ada pelanggaran. Dengan begitu, tim frontend dan backend bisa melihat script mana yang masih bergantung pada sumber tak terduga.

Alur yang disarankan:

Buat inventaris semua resource yang dipakai aplikasi.
Terapkan policy report-only di staging, lalu di production secara bertahap.
Kumpulkan laporan pelanggaran dan kelompokkan berdasarkan fitur.
Hapus dependency yang tidak perlu, misalnya script marketing yang sudah tidak dipakai.
Ubah policy menjadi enforcement setelah stabil.

Banyak tim di Jakarta atau kota besar lain di Indonesia bekerja dengan release cepat dan banyak stakeholder. Karena itu, pendekatan bertahap biasanya jauh lebih realistis daripada langsung memasang policy ketat yang memblokir fitur penting.

Contoh CSP yang masuk akal untuk SaaS modern

Tidak ada satu policy yang cocok untuk semua aplikasi, tetapi contoh berikut bisa menjadi titik awal:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://cdn.example.com;
  style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
  img-src 'self' data: https://images.example.com;
  connect-src 'self' https://api.example.com wss://realtime.example.com;
  font-src 'self' https://fonts.gstatic.com;
  frame-src https://www.youtube.com;
  object-src 'none';
  base-uri 'self';
  frame-ancestors 'none';
  upgrade-insecure-requests;

Ada beberapa catatan penting. Pertama, unsafe-inline pada style sering muncul karena framework atau library tertentu, tetapi sebaiknya diminimalkan. Kedua, frame-ancestors 'none' sangat berguna jika aplikasi tidak boleh di-embed oleh pihak lain. Ketiga, upgrade-insecure-requests membantu mendorong trafik ke HTTPS, tetapi pastikan semua resource memang mendukung HTTPS.

Jika aplikasi memakai inline script, pertimbangkan nonce atau hash daripada membuka unsafe-inline untuk script. Ini jauh lebih aman.

Apa kesalahan paling umum saat menerapkan CSP?

Kesalahan yang paling sering terjadi adalah terlalu cepat menambahkan banyak pengecualian. Akibatnya, policy terlihat ada, tetapi nilainya kecil karena hampir semua domain diizinkan.

Kesalahan lain yang umum:

Mengandalkan * pada script-src atau connect-src.
Membiarkan unsafe-inline untuk script tanpa alasan kuat.
Tidak memantau report CSP sehingga pelanggaran tidak pernah dibaca.
Lupa memperbarui policy saat menambah vendor baru.
Mengira CSP bisa menggantikan sanitasi input dan output encoding.

Untuk SaaS yang berkembang cepat, masalah terbesar biasanya bukan teknis semata, melainkan governance: siapa yang berhak menambah script baru, bagaimana proses review-nya, dan kapan policy harus diperbarui.

Bagaimana CSP berhubungan dengan arsitektur frontend?

CSP sebaiknya dipandang sebagai bagian dari arsitektur, bukan sekadar header tambahan. Saat frontend dibangun dengan micro-frontend, banyak widget, atau integrasi lintas domain, policy keamanan harus dirancang bersamaan dengan arsitektur aplikasi.

Misalnya, jika tim memakai beberapa domain untuk asset, API, dan realtime service, maka domain-domain itu harus terdokumentasi. Jika produk memakai tag manager untuk marketing, perlu ada proses approval agar script yang masuk tidak mengacaukan policy atau membuka risiko baru.

Di APLINDO, pendekatan yang sering dipakai untuk SaaS engineering adalah menggabungkan CSP dengan review dependency, hardening header lain seperti HSTS dan X-Content-Type-Options, serta pengujian keamanan di pipeline CI/CD. Untuk perusahaan yang butuh bantuan lebih lanjut, model seperti Fractional CTO atau konsultasi compliance juga membantu menyatukan aspek engineering dan governance tanpa harus membangun tim keamanan penuh sejak awal.

Kapan perlu bantuan audit atau review profesional?

Jika aplikasi Anda sudah melayani data sensitif, transaksi, atau pengguna enterprise, CSP sebaiknya tidak disusun sendirian oleh satu developer tanpa review. Audit profesional berguna untuk memeriksa apakah policy benar-benar efektif, apakah ada celah dari third-party script, dan apakah konfigurasi header selaras dengan arsitektur aplikasi.

Untuk konteks Indonesia, ini juga penting ketika perusahaan harus menyesuaikan diri dengan kebutuhan internal, kontrak enterprise, atau kerangka compliance tertentu. Namun, perlu diingat: CSP dan hardening teknis tidak otomatis menjamin kepatuhan penuh atau hasil legal tertentu. Tetap lakukan audit profesional sesuai kebutuhan bisnis dan regulasi.

Kesimpulan

CSP adalah salah satu kontrol keamanan paling praktis untuk SaaS modern. Ia tidak menggantikan secure coding, tetapi sangat efektif untuk mengurangi dampak serangan berbasis browser, terutama XSS dan injeksi script. Bagi startup dan enterprise di Indonesia, implementasi terbaik biasanya dimulai dari inventaris resource, mode report-only, lalu enforcement bertahap.

Jika Anda sedang membangun atau mengeraskan frontend SaaS, jadikan CSP bagian dari desain arsitektur sejak awal. Dengan begitu, tim bisa bergerak cepat tanpa mengorbankan keamanan dasar aplikasi.