Kebijakan Keamanan Konten Menulis Header CSP yang Benar-Benar Bekerja

Kebanyakan pengembang tahu bahwa mereka harus menambahkan header Kebijakan Keamanan Konten ke aplikasi mereka. Sedikit yang memiliki kebijakan yang benar-benar berguna. Atau kebijakan tersebut terlalu lemah sehingga kehilangan tujuannya, atau malah menghancurkan setengah situs dan dihapus karena kekecewaan.

Panduan ini menjelaskan apa yang dilakukan oleh CSP, direktif mana yang penting, dan bagaimana menulis header yang mencegah serangan nyata tanpa mengganggu aplikasi Anda.

Apa yang Dilakukan oleh CSP

Kebijakan Keamanan Konten memberi tahu browser dari mana sumber daya yang diizinkan untuk dimuat. Skrip hanya dari domain ini. Gaya dari CDN tersebut. Gambar dari mana saja. Tidak ada skrip inline.

Ketika browser menerima header CSP, ia menerapkan aturan tersebut sebelum menjalankan apa pun. Jika serangan XSS menyisipkan skrip berbahaya ke dalam HTML Anda, CSP akan memblokirnya pada tingkat browser — bahkan jika skrip tersebut lolos dari sanitasi input Anda.

Itulah nilai inti: CSP adalah lapisan kedua pertahanan Anda ketika validasi input gagal.

Direktif yang Penting

CSP memiliki ratusan direktif, tetapi kebanyakan header produksi hanya membutuhkan enam:

frame-ancestors menggantikan header lama X-Frame-Options dan layak ditambahkan bahkan sebelum Anda memiliki penutupan lengkap CSP di tempat lain.

Mengapa unsafe-inline Menghancurkan Tujuan

Ketika Anda menambahkan 'unsafe-inline' ke script-src, Anda memberi tahu browser: jalankan setiap tag skrip yang ditemukan, terlepas dari asalnya. Ini termasuk skrip yang disisipkan oleh serangan XSS.

'unsafe-eval' lebih buruk — memungkinkan eval(), Function()dan setTimeout("string")yang merupakan vektor serangan umum bahkan dalam kode yang sehat secara umum.

Kebijakan dengan salah satu dari dua ini mencatat sumber Anda tanpa memberikan perlindungan injeksi apa pun. Penyerang tidak peduli dari mana skrip sah Anda dimuat jika mereka dapat menyisipkan skrip mereka secara inline.

Cara yang Benar: Nonce dan Hash

Jika Anda memiliki skrip inline yang sah, Anda memiliki dua pilihan yang tidak mengorbankan kebijakan Anda:

Nonce menghasilkan token unik per muatan halaman. Server menambahkannya ke header CSP dan ke atribut nonce skrip inline. Hanya skrip dengan nonce yang sesuai yang dijalankan.

<!-- CSP header -->
Content-Security-Policy: script-src 'nonce-abc123xyz'

<!-- Inline script with matching nonce -->
<script nonce="abc123xyz">
  window.analyticsId = '...';
</script>

Hash menghitung tanda tangan SHA-256 dari konten skrip yang tepat. Tambahkan hash tersebut ke script-src dan browser menjalankan skrip tersebut — tetapi tidak apa-apa selain itu.

Content-Security-Policy: script-src 'sha256-RFWPLDbv2BY+rCkDzsE+0fr8ylGr2R2faWMhq4lfEQc='

Nonce bekerja lebih baik untuk halaman dinamis di mana konten berubah per permintaan. Hash cocok untuk skrip statis yang tidak berubah antara penyebaran.

Deploy dengan Mode Laporan Pertama

Menambahkan CSP ke situs yang sudah ada tanpa pengujian adalah cara Anda menghancurkan situs di produksi. Mulai dengan header laporan saja:

Content-Security-Policy-Report-Only: default-src 'self'; script-src 'self' 'nonce-{random}'; report-uri /csp-violations

Browser menerapkan aturan dan melaporkan pelanggaran — tidak ada blokir yang terjadi. Log pelanggaran ini memberi tahu Anda persis apa yang perlu Anda tambahkan ke kebijakan sebelum Anda beralih ke mode enkripsi.

Kebanyakan penempatan CSP yang menghancurkan situs melewatkan langkah ini.

Kebijakan CSP yang Nyata untuk Aplikasi SaaS Biasa

Berikut adalah header produksi untuk aplikasi yang menggunakan CDN, Google Analytics, dan Stripe. Setiap direktif diberi annotasi:

Content-Security-Policy:
  # Tight default: only load from your own origin
  default-src 'self';

  # Scripts: your origin, GA tag manager via nonce, Stripe.js
  script-src 'self' https://www.googletagmanager.com https://js.stripe.com 'nonce-{SERVER_NONCE}';

  # Styles: your origin and Google Fonts CSS
  style-src 'self' https://fonts.googleapis.com;

  # Fonts: your origin and Google Fonts CDN
  font-src 'self' https://fonts.gstatic.com;

  # Images: your origin, CDN subdomain, and base64 data URIs
  img-src 'self' https://cdn.yourdomain.com data:;

  # Fetch/XHR: your API, GA collection endpoint, Stripe API
  connect-src 'self' https://www.google-analytics.com https://api.stripe.com;

  # Stripe renders its fields in an iframe
  frame-src https://js.stripe.com;

  # Nobody should be framing your app
  frame-ancestors 'none';

  # Block <object> and <embed> entirely
  object-src 'none';

  # Force HTTP requests to upgrade to HTTPS
  upgrade-insecure-requests;

Cara Mengatur CORS di Express, FastAPI, dan Nginx {SERVER_NONCE} dengan nilai acak kriptografi yang dihasilkan per permintaan — misalnya, base64_encode(random_bytes(16)) dalam PHP atau crypto.randomBytes(16).toString('base64') dalam Node.

Kesalahan Umum CSP

Wildcards yang terlalu luas. script-src * memungkinkan skrip dari asal mana pun. Anda mungkin sama saja tidak memiliki kebijakan skrip sama sekali.

Melupakan subdomain. 'self' hanya mencakup asal yang tepat Anda. https://api.yourdomain.com adalah asal yang berbeda dan membutuhkan entri eksplisit di bawah connect-src.

Melompati frame-ancestors. Perlindungan terhadap clickjacking independen dari perlindungan XSS. Tambahkan secara terpisah dari himpunan direktif lainnya.

Menetapkan CSP di beberapa tempat. Jika CDN dan aplikasi Anda keduanya menetapkan header CSP, perilaku menjadi tidak dapat diprediksi. Tetapkan di satu lapisan — biasanya di server asal atau reverse proxy.

adalah cara tercepat untuk membuka API Anda — tetapi akan rusak saat Anda menambahkan kredensial. Ketika report-uri tanpa handler. Pelanggaran menghasilkan permintaan POST ke endpoint Anda pada setiap muatan halaman yang terpengaruh. Atau tangani mereka atau arahkan ke layanan seperti Report URI.

Bangun Header Anda Tanpa Keraguan

Mengikuti setiap domain yang dimuat oleh halaman Anda melalui skrip, gaya, font, gambar, dan panggilan API menjadi cepat berat. Generator header CSP online generator header CSP memungkinkan Anda mengatur setiap direktif secara visual dan menghasilkan header produksi yang dapat langsung dipasang ke konfigurasi server Anda.

Gunakan sebagai titik awal, lalu audit permintaan jaringan aktual di DevTools untuk menangkap apa pun yang terlewat oleh generator tersebut.

Kebijakan CSP yang terlalu longgar hanyalah dekorasi. Yang terlalu ketat menghancurkan pengguna Anda. Mulai dengan mode laporan, ketatkan dari sana, dan gunakan nonce di mana skrip inline tidak terhindarkan. Kebijakan Anda harus membuat pekerjaan penyerang lebih sulit — bukan pekerjaan Anda.

Anda mungkin juga menyukai

Baru

Membandingkan Objek JSON: Cara Mengenali Perbedaan dalam Respons API

Baca selengkapnya "

Diterbitkan pada 30 Apr 2026

Baru

Pengubahan Kasus String: snake_case, camelCase, dan Mengapa Penting dalam API

Baca selengkapnya "

Diterbitkan pada 29 Apr 2026

Baru

Kookie HTTP: Cara Membangun dan Membaca Mereka Secara Tepat

Baca selengkapnya "

Diterbitkan pada 28 Apr 2026

Baru

CSS Grid dalam Praktik: Tata letak yang berguna tanpa kerangka kerja

Baca selengkapnya "

Diterbitkan pada 27 Apr 2026