Panduan Content Security Policy (CSP) 2026: Perisai Anti-XSS untuk Aplikasi SaaS

Apa itu Content Security Policy (CSP)?

Content Security Policy (CSP) adalah mekanisme keamanan di level browser yang membatasi dari mana browser boleh memuat skrip, style, gambar, font, dan resource lainnya. CSP dikirim sebagai header HTTP Content-Security-Policy atau via meta tag, namun header adalah opsi paling lengkap. Tujuan utamanya adalah menekan dampak serangan cross-site scripting (XSS) dengan prinsip allowlist sumber yang tegas.

Kenapa CSP penting untuk SaaS?

• Defense-in-depth: Ketika ada celah XSS, CSP membatasi kemampuan payload berbahaya untuk berjalan.
• Mengurangi risiko supply-chain: Skrip pihak ketiga dibatasi agar tidak memuat dari domain tak dikenal.
• Kontrol yang terukur: Anda dapat memperketat aturan per-jenis resource (skrip, style, image, frame, connect).

Ringkasnya, CSP bukan pengganti sanitasi input—tetapi “sabuk pengaman” tambahan saat terjadi kegagalan di lapisan lain.

Struktur dasar kebijakan CSP

Kebijakan CSP terdiri dari beberapa direktif yang dipisah dengan titik koma. Contoh sederhana:

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

Direktif yang paling sering dipakai:

• default-src: aturan default untuk semua jenis resource.
• script-src: sumber skrip yang diizinkan (kunci untuk mitigasi XSS).
• style-src, img-src, font-src, connect-src: mengatur masing-masing jenis asset.
• object-src: biasanya disetel ke 'none' untuk memblokir plugin lama.

Strategi implementasi bertahap (tanpa mematikan produksi)

1) Mulai dengan Report-Only

Gunakan Content-Security-Policy-Report-Only untuk mengamati pelanggaran tanpa memblokir resource. Kumpulkan laporan dan pahami aset mana yang “legal” sebelum menegakkan kebijakan.

2) Inventarisasi sumber skrip

Catat semua domain CDN, analytics, dan widget pihak ketiga. Sering kali masalah CSP terbesar adalah dependensi “tak terlihat” dari tim marketing.

3) Kurangi inline script

Inline script dan eval() adalah pintu besar XSS. Idealnya, migrasikan ke file JS terpisah. Jika perlu inline, gunakan nonce atau hash yang spesifik.

Contoh kebijakan CSP yang lebih ketat

Content-Security-Policy:
  default-src 'self';
  script-src 'self' 'nonce-{{RANDOM_NONCE}}' https://cdn.example.com;
  style-src 'self' https://fonts.googleapis.com;
  font-src 'self' https://fonts.gstatic.com;
  img-src 'self' data: https://images.example.com;
  connect-src 'self' https://api.example.com;
  frame-ancestors 'none';
  object-src 'none';

Catatan: nonce harus dibuat per request dan hanya dipakai pada skrip yang dipercaya.

Checklist praktis untuk tim DevSecOps

1. Mulai dari report-only selama 1–2 minggu.
2. Audit dependency pihak ketiga (tag manager, live chat, analytics).
3. Batasi inline script dan unsafe-eval seminimal mungkin.
4. Tambah frame-ancestors untuk mencegah clickjacking.
5. Gunakan laporan pelanggaran untuk memperbaiki kebijakan secara iteratif.

Kesalahan umum saat mengadopsi CSP

• Terlalu longgar: Menambahkan unsafe-inline dan unsafe-eval membuat CSP kehilangan manfaat.
• Lupa aset dinamis: Script yang dimuat dari domain baru sering memicu error setelah CSP ditegakkan.
• Tanpa monitoring: Tanpa laporan, tim akan “buta” terhadap pelanggaran yang terjadi.

Referensi resmi

Untuk pendalaman, lihat dokumentasi resmi di MDN CSP Guide, praktik mitigasi di OWASP CSP Cheat Sheet, serta panduan implementasi di web.dev CSP.

Penutup

CSP adalah investasi keamanan yang dampaknya langsung terasa di aplikasi SaaS: risiko XSS turun, sumber eksternal lebih terkontrol, dan tim punya visibilitas terhadap resource yang dipakai di produksi. Mulai dari report-only, rapikan skrip, lalu kunci kebijakan secara bertahap agar hasilnya stabil dan aman.