Defaults.Exposed › Perbaikan › Content-Security-Policy (CSP)

Cara memperbaiki Content-Security-Policy (CSP)

Content Security Policy adalah aturan keamanan yang diberikan website Anda kepada browser setiap pengunjung, memberi tahu browser dengan tepat kode mana yang boleh dijalankan. Tanpanya, jika ada yang berbahaya masuk ke halaman — melalui kolom komentar, plugin yang diretas, atau skrip pihak ketiga — browser akan menjalankannya dengan bebas, termasuk kode yang diam-diam mencuri nomor kartu dan kata sandi pelanggan saat mereka mengetikkannya, dengan gembok masih menampilkan.

Intinya bagi bisnis Anda: Jika website Anda pernah dimanipulasi, kode berbahaya bisa membaca detail kartu pembayaran dan login pelanggan langsung dari checkout Anda sementara semuanya terlihat benar-benar normal — meninggalkan Anda dengan chargeback, klaim penipuan, pelanggaran data yang harus dilaporkan, dan kegagalan pemeriksaan yang digunakan tim keamanan klien besar untuk menghentikan atau membatalkan kesepakatan.

Kerugian yang dapat ditimbulkan

Kode tersembunyi masuk ke salah satu halaman Anda dan diam-diam menyalin setiap nomor kartu dan kata sandi yang dimasukkan pelanggan saat checkout, mengirimkannya ke penyerang sementara website Anda terlihat benar-benar normal — Anda baru mengetahuinya ketika keluhan penipuan datang.
Penipu memasang formulir 'bayar di sini' palsu di website Anda yang sebenarnya yang menangkap pembayaran ke akun mereka sendiri; pelanggan mengira mereka membayar Anda, menyalahkan Anda ketika barang tidak datang, dan menuntut uang mereka kembali.
Tim keamanan klien besar memindai website Anda, melihat perlindungan dasar ini tidak aktif, dan menandainya — menghentikan atau membuat Anda kehilangan kontrak sampai Anda bisa membuktikannya sudah diperbaiki.
Pelanggaran yang ditelusuri ke perlindungan standar yang hilang menjadi insiden yang harus dilaporkan: pertanyaan regulator, pemberitahuan pelanggan, dan kerugian reputasi yang biayanya jauh lebih besar dari perbaikan gratis.

Mengapa ini penting. Gembok membuktikan koneksi ke website Anda bersifat privat, tapi tidak melakukan apa pun untuk mengontrol kode apa yang berjalan setelah pengunjung berada di halaman. Content Security Policy adalah perlindungan yang melakukan itu — ia memberi tahu browser untuk mengabaikan skrip apa pun yang tidak berasal dari sumber yang Anda percaya, sehingga satu field yang dimanipulasi, iklan, atau plugin tidak bisa dijadikan alat untuk mencuri uang dan data pelanggan Anda. Ini adalah pemeriksaan yang dinilai pada scorecard Anda, bernilai poin nyata, dan salah satu hal pertama yang dicari tinjauan keamanan profesional.

Penjelasan dalam bahasa sederhana

Ketika seseorang mengunjungi website Anda, browser mereka mengunduh halaman Anda dan menjalankan kode apa pun yang ada di sana — skrip yang membuat menu turun, tombol berfungsi, formulir pembayaran terkirim, dan seterusnya. Secara default, browser mempercayai semuanya. Browser tidak punya cara untuk mengetahui kode mana yang benar-benar milik Anda dan mana yang diselundupkan orang lain.

Content Security Policy (sering disingkat CSP) adalah daftar pendek aturan yang dilampirkan website Anda ke setiap halaman, memberi tahu browser: “hanya jalankan kode dari sumber yang telah saya setujui ini, dan tolak semua yang lain.” Ini adalah perbedaan antara klub malam yang mengizinkan siapa pun masuk dan satu dengan daftar tamu di pintu.

Alasan ini begitu penting adalah bahwa website terus-menerus dimanipulasi — tidak selalu dengan meretas server Anda, tapi melalui pintu belakang yang dibiarkan terbuka oleh sebagian besar website: kolom komentar, kotak pencarian, plugin yang sudah usang, skrip pihak ketiga untuk iklan atau analitik, atau widget obrolan. Jika penyerang berhasil memasukkan bahkan satu baris kode mereka ke salah satu halaman Anda, browser menjalankannya seolah-olah itu milik Anda. Dari sana ia bisa membaca semua yang diketikkan pelanggan — nomor kartu, kata sandi, alamat — dan diam-diam mengirimkannya ke tempat lain. Content Security Policy menutup pintu itu dengan menolak untuk menjalankan apa pun dari sumber yang tidak Anda setujui.

Dampak finansial yang perlu diketahui

Ini bukan hal abstrak. Serangan yang dicegah Content Security Policy — kode yang disuntikkan ke halaman yang mencuri data dari pelanggan Anda sendiri — berada di balik beberapa pelanggaran card-skimming terbesar yang pernah tercatat. Berikut cara biasanya terjadi untuk bisnis normal:

Skimmer checkout yang tak terlihat. Penyerang memasukkan beberapa baris kode ke halaman checkout Anda melalui plugin yang rentan atau skrip pihak ketiga yang dikompromikan. Setiap nomor kartu, nama, dan CVV yang diketikkan pelanggan Anda disalin dan dikirim ke penyerang secara real time. Website Anda terlihat dan bekerja dengan sempurna; gembok ada. Anda menemukannya berminggu-minggu kemudian ketika penyedia pembayaran Anda menelepon tentang sekelompok laporan penipuan yang semuanya terkait ke toko Anda. Sekarang Anda menghadapi chargeback, audit keamanan yang dipaksakan, kemungkinan kehilangan hak pemrosesan kartu, dan pelanggaran yang mungkin secara hukum harus Anda laporkan.
Formulir pembayaran palsu. Penipu menyuntikkan kotak “bayar di sini” yang meyakinkan ke website Anda yang sebenarnya. Pelanggan memasukkan detail mereka mempercayai merek Anda; uang dan data pergi ke penyerang. Pelanggan menyalahkan Anda — dan mereka tidak salah, karena itu terjadi di website Anda.
Kontrak yang gagal. Tim keamanan calon pelanggan yang lebih besar menjalankan pemindaian otomatis pada website Anda sebagai bagian dari due diligence vendor. Content Security Policy yang hilang segera muncul sebagai kesenjangan tingkat keparahan tinggi. Bagi peninjau pengadaan atau keamanan, satu perlindungan dasar yang hilang itu terbaca sebagai “pemasok ini tidak melakukan hal-hal dasar” — dan kesepakatan terhenti sementara mereka meminta remediasi, atau diam-diam pergi ke kompetitor yang lolos.
Pelanggaran yang harus dilaporkan. Ketika pelanggaran data ditelusuri kembali ke perlindungan standar gratis yang hilang, itu berhenti menjadi nasib buruk dan mulai terlihat seperti kelalaian. Itu mengubah pertanyaan regulator, kewajiban pemberitahuan pelanggan, dan biaya — baik denda maupun kerusakan reputasi, yang bertahan lama setelah insiden ditutup.
Iklan atau widget yang dikompromikan. Banyak website memuat kode dari pihak luar — jaringan iklan, font, dukungan obrolan, analitik. Jika salah satu dari itu dilanggar, kode berbahaya langsung masuk ke halaman Anda. Content Security Policy membatasi dampak dengan hanya mengizinkan sumber luar yang spesifik yang Anda percaya, sehingga pelanggaran satu pemasok tidak secara otomatis menjadi pelanggaran Anda.

Penjelasan teknis

Content Security Policy dikirimkan sebagai satu HTTP response header — sebuah baris yang dikirimkan server web Anda dengan setiap halaman. Nilainya adalah serangkaian direktif, masing-masing menyebutkan jenis konten dan sumber yang diizinkan untuk itu. Misalnya:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self'

Dalam bahasa sederhana, artinya: secara default hanya muat hal-hal dari website saya sendiri; hanya jalankan skrip dari website saya sendiri; tidak ada plugin bergaya lama; dan jangan biarkan website lain menyematkan milik saya dalam frame.

Seperti apa “baik” itu. Pemeriksaan kami tidak hanya mencari kehadiran header — ia membaca kebijakan direktif demi direktif dan menilai seberapa kuat sebenarnya, seperti yang dilakukan peninjau keamanan. Kebijakan yang kuat:

Menetapkan baseline yang ketat (default-src 'self') dan hanya memperluas untuk pihak ketiga tepercaya yang benar-benar Anda gunakan.
Menghindari celah. Tidak menggunakan 'unsafe-inline' atau 'unsafe-eval' untuk skrip, dan tidak menggunakan sumber wildcard (*) atau skema telanjang (seperti https:) untuk skrip — ini secara efektif membuka kembali pintu yang dimaksudkan untuk ditutup kebijakan. Di mana skrip inline benar-benar diperlukan, ia menggunakan nonce atau hash sehingga hanya kode yang disetujui secara spesifik yang berjalan.
Mengunci framing dengan frame-ancestors 'self' (ini juga memblokir serangan “sematkan website Anda untuk mengelabui pelanggan Anda”) dan menonaktifkan plugin legacy dengan object-src 'none'.
Menegakkan, bukan hanya laporan. Header Content-Security-Policy-Report-Only hanya memantau; ini memberikan nol perlindungan runtime. Pemeriksaan kami memberikannya sebagian kecil kredit dan tidak pernah mencatatnya sebagai lulus. Anda hanya terlindungi setelah kebijakan menegakkan.

Kebijakan yang ada tapi mengandalkan 'unsafe-inline', 'unsafe-eval', atau wildcard masih mendapat skor buruk — karena dalam praktiknya memberikan sedikit perlindungan nyata. Tujuannya adalah kebijakan yang ketat, bukan hanya kebijakan apa pun.

Cara memperbaikinya (gratis, ~1–2 jam)

Berikan ini kepada orang IT atau siapa pun yang menjalankan website Anda — perbaikannya sendiri sepenuhnya gratis. Kami hanya pernah mengenakan biaya untuk memantau agar tetap ada dan tetap benar dari waktu ke waktu; mengaktifkannya tidak ada biaya. Alasan ini butuh satu atau dua jam alih-alih menit adalah langkah uji coba yang hati-hati yang menghentikannya secara tidak sengaja memblokir bagian website Anda sendiri.

Mulai dalam mode hanya laporan — jangan tegakkan dulu. Tambahkan header respons Content-Security-Policy-Report-Only. Ini memantau dan mencatat apa yang akan diblokir tanpa benar-benar memblokir apa pun, sehingga website langsung tetap berfungsi sementara Anda belajar apa yang benar-benar bergantung pada setiap halaman. (Penting: hanya laporan sendiri tidak memberikan perlindungan pengunjung — ini hanya langkah pertama yang aman.)
Bangun kebijakan dari apa yang benar-benar digunakan website Anda. Tinjau laporan untuk menemukan setiap sumber sah skrip, style, font, dan gambar — domain Anda sendiri, analitik Anda, penyedia pembayaran Anda, host font Anda, widget obrolan Anda — dan daftarkan sebagai sumber yang diizinkan. Titik awal yang solid adalah default-src 'self' ditambah entri eksplisit untuk pihak ketiga tepercaya yang benar-benar Anda gunakan.
Hindari celah yang mengalahkan seluruh tujuannya. Jauhi 'unsafe-inline' dan 'unsafe-eval' untuk skrip, dan hindari sumber wildcard seperti * dan skema telanjang seperti https: untuk skrip — ini membuka kembali celah yang dimaksudkan untuk ditutup kebijakan. Di mana skrip inline tidak bisa dihindari, gunakan nonce atau hash sehingga hanya kode yang disetujui secara spesifik yang berjalan.
Kunci framing dan plugin. Tambahkan frame-ancestors 'self' (ini juga menghentikan website lain menyematkan milik Anda untuk mengelabui pelanggan Anda, dan memenuhi pemeriksaan clickjacking terkait) dan object-src 'none' untuk memblokir serangan berbasis plugin legacy.
Beralih dari hanya laporan ke penegakan. Setelah laporan bersih dan website berfungsi, ubah nama header dari Content-Security-Policy-Report-Only menjadi Content-Security-Policy. Ini adalah langkah yang benar-benar memberikan perlindungan — kebijakan hanya laporan saja tidak, dan tidak akan lolos pemeriksaan.

Di mana Anda mengatur header bergantung pada platform Anda:
- Cloudflare: Rules → Transform Rules → Modify Response Header → atur Content-Security-Policy.
- Nginx: add_header Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';" always;
- Apache: Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; object-src 'none'; frame-ancestors 'self';"
- IIS (web.config): tambahkan HTTP response header kustom bernama Content-Security-Policy dengan kebijakan sebagai nilainya.
- Google Workspace / Microsoft 365: ini menjalankan email Anda, bukan website publik Anda, jadi kebijakan diatur di mana pun website Anda sebenarnya dihosting (Cloudflare atau host web di atas), bukan di konsol admin email Anda.
Periksa ulang domain Anda untuk mengonfirmasi kebijakan sekarang menampilkan sebagai diaktifkan dan menegakkan, tanpa celah yang melemahkan.

Kesalahan umum

Berhenti di hanya laporan. Kesalahan tunggal yang paling umum: kebijakan ditambahkan dalam mode hanya laporan, semua orang melanjutkan, dan website tidak pernah benar-benar terlindungi. Hanya laporan tidak memblokir apa pun. Anda harus beralih ke penegakan.
Menjangkau 'unsafe-inline' untuk membuatnya “berjalan begitu saja.” Ketika kebijakan memblokir skrip inline yang sah, perbaikan cepatnya adalah mengizinkan semua skrip inline — tapi itu membuka kembali lubang yang dimaksudkan untuk ditutup kebijakan. Gunakan nonce atau hash sebagai gantinya.
Menggunakan wildcard. * telanjang (atau https:) di script-src mengizinkan skrip dari mana saja, yang berarti kebijakan hampir tidak memberikan perlindungan nyata dan masih mendapat skor rendah.
Melupakan sumber pihak ketiga. Menegakkan kebijakan yang ketat tanpa terlebih dahulu mencantumkan layanan luar yang sah yang Anda gunakan (analitik, font, widget pembayaran) bisa merusak bagian website Anda sendiri — itulah tepatnya mengapa langkah uji coba hanya laporan ada.
Mengaturnya hanya di halaman utama. Kebijakan harus mencakup setiap halaman, terutama checkout, login, dan halaman akun — itulah yang layak diserang.
Memperlakukannya sebagai pengganti gembok. Content Security Policy dan HTTPS/HSTS melindungi hal yang berbeda. Anda menginginkan semuanya; satu tidak menutupi untuk yang lain.

FAQ

Saya tidak paham teknis — bisakah saya menangani ini sendiri?

Anda tidak perlu memahami detailnya. Ini adalah pengaturan yang ditambahkan oleh siapa pun yang menjalankan website atau hosting Anda, dan di layanan seperti Cloudflare sebagian besar dipandu. Berikan bagian 'Cara memperbaikinya' di bawah kepada mereka. Gratis; satu peringatan adalah harus diluncurkan dengan hati-hati dalam uji coba hanya-pantau terlebih dahulu agar tidak secara tidak sengaja memblokir bagian website Anda sendiri — yang persis apa yang dicakup langkah-langkahnya.

Saya sudah memiliki gembok dan sertifikat SSL — bukankah website saya sudah aman?

Gembok mengamankan pengiriman halaman Anda; ia tidak mempolisi apa yang berjalan di dalamnya. Jika kode berbahaya pernah berakhir di halaman — melalui plugin yang diretas, iklan yang dikompromikan, atau field yang disuntikkan — gembok tidak akan menghentikannya mencuri data. Content Security Policy adalah lapisan yang membatasi apa yang diizinkan untuk dijalankan sejak awal. Mereka melindungi hal yang berbeda, dan Anda menginginkan keduanya.

Bisakah mengaktifkan ini merusak website saya?

Bisa jika diaktifkan secara agresif sekaligus, karena bisa memblokir skrip sah yang benar-benar Anda gunakan. Itulah mengapa pendekatan standar adalah memulai dalam mode uji coba 'hanya laporan' yang memantau tanpa memblokir, memperbaiki apa pun yang ditandai, dan hanya kemudian menegakkan. Dilakukan dengan cara ini aman — dan langkah uji coba sudah built-in dalam perbaikan di bawah.

Kami sudah memasangnya dalam mode 'hanya laporan' — apakah kami sudah terlindungi?

Tidak, dan ini adalah rasa aman palsu yang paling umum. Mode hanya laporan memantau dan mencatat apa yang akan diblokir, tapi tidak memblokir apa pun — pengunjung tidak mendapat perlindungan nyata. Ini hanya langkah pertama yang aman. Pemeriksaan kami memberikan hanya laporan kredit kecil dibandingkan kebijakan nyata dan tidak akan mencatatnya sebagai lulus. Anda hanya terlindungi setelah beralih ke mode penegakan.

Apakah ini mempengaruhi skor kami, atau hanya saran?

Ini mempengaruhi skor Anda. Pemeriksaan Content Security Policy dinilai dan bernilai hingga 25 poin dalam kategori Keamanan Web. Kebijakan yang hilang atau lemah ditandai tingkat keparahan tinggi dan menurunkan nilai Anda — dan inilah tepatnya celah yang ditanyakan kuesioner keamanan klien.

Pengembang kami menambahkan kebijakan tapi skor masih rendah — mengapa?

Kebijakan bisa ada dan masih lemah. Pelakunya yang paling umum adalah celah seperti 'unsafe-inline' dan 'unsafe-eval' untuk skrip, atau sumber wildcard (hanya *), yang membuka kembali celah yang dimaksudkan untuk ditutup kebijakan. Pemeriksaan kami membaca kebijakan direktif demi direktif dan menilai kelemahan tersebut — kebijakan yang mengizinkan apa pun mendapat skor sedikit lebih baik dari tidak memiliki kebijakan sama sekali. Perbaikannya adalah mengencangkan aturan skrip menggunakan nonce atau hash alih-alih celah tersebut.