Analisis CSP

Analisis Content-Security-Policy (CSP) dan Content-Security-Policy-Report-Only untuk URL apa pun. Deteksi arahan berisiko (unsafe-inline, wildcard), strategi nonce/hash yang hilang, pola usang, dan berikan rekomendasi yang dapat ditindaklanjuti untuk memperkuat pertahanan XSS. Mendukung pengalihan, inspeksi header mentah, penyaringan, temuan, dan ekspor JSON/PDF.

Loading…

Tentang Analisis CSP

Tempelkan URL untuk memeriksa header CSP-nya dan lihat dengan cepat apakah kebijakan tersebut benar-benar melindungi Anda dari XSS dan injeksi. Alat analisis ini menyoroti izin berbahaya (seperti unsafe-inline atau wildcard yang luas), menjelaskan apa yang hilang (strategi nonce/hash, pembatasan frame), dan membantu Anda beralih ke CSP yang praktis dan dapat diterapkan dengan aman menggunakan report-only.

Fitur

  • Deteksi dan jelaskan header Content-Security-Policy dan Content-Security-Policy-Report-Only.
  • Tandai kesalahan umum CSP: unsafe-inline, unsafe-eval, wildcard luas, dan sumber yang terlalu permisif.
  • Panduan untuk eksekusi skrip/gaya yang lebih aman melalui strategi berbasis nonce dan hash.
  • Identifikasi arahan yang hilang yang sering penting dalam pengerasan dunia nyata (misalnya, frame-ancestors, object-src, base-uri).
  • Wawasan Report-Only: pahami apa yang akan diblokir dan cara menerapkan CSP tanpa mengganggu produksi.
  • Ikuti pengalihan (hingga 10) untuk menganalisis kebijakan respons akhir yang diterapkan browser.
  • Tampilan header mentah untuk output server yang tepat dan debugging.
  • Temuan + kartu skor dengan penyaringan "hanya masalah".
  • Ekspor analisis ke JSON atau PDF untuk audit, tiket, dan tinjauan keamanan.
  • Termasuk kesadaran header usang untuk menangkap kebijakan lama dan kebutuhan migrasi.

🧭 Cara penggunaan for csp-analyzer

1

Masukkan URL untuk dianalisis

Tempelkan URL halaman yang ingin Anda periksa (seringkali beranda atau shell aplikasi Anda).

2

Aktifkan pengalihan jika diperlukan

Biarkan "Ikuti Pengalihan" diaktifkan agar alat analisis mencapai tujuan akhir HTTPS/www/lokal di mana CSP asli dikembalikan.

3

Tinjau kartu skor dan temuan

Mulai dengan temuan untuk mengidentifikasi risiko kritis (unsafe-inline, wildcard, pembatasan yang hilang) dan pahami arahan mana yang memengaruhi skor.

4

Periksa header mentah saat debugging

Nyalakan "Tampilkan Header Mentah" untuk memverifikasi nama/nilai header yang tepat (berguna jika ada beberapa header CSP atau proxy/CDN memodifikasinya).

5

Ekspor laporan untuk alur kerja keamanan Anda

Unduh JSON untuk otomatisasi atau PDF untuk audit keamanan dan tiket rekayasa.

Spesifikasi teknis

Model permintaan

Alat ini melakukan inspeksi header URL dan berfokus pada analisis header keamanan, termasuk kebijakan CSP dan report-only.

PengaturanPerilakuDefault
Ikuti PengalihanMengikuti rantai pengalihan untuk menganalisis kebijakan efektif yang dikembalikan oleh URL akhirDiaktifkan
Maks. PengalihanBatas pengalihan untuk mencegah perulangan10
Batas WaktuBatas waktu permintaan15000 ms
User-AgentMengidentifikasi agen pengguna permintaanEncode64Bot/1.0 (+https://encode64.com)
Jaringan pribadiMemblokir akses ke rentang jaringan pribadi untuk keamananDinonaktifkan (jaringan pribadi tidak diizinkan)

Header CSP yang diperiksa

Penganalisis memeriksa kebijakan yang menegakkan dan tidak menegakkan, lalu menampilkannya dalam bentuk yang mudah dibaca.

HeaderMakna
Content-Security-PolicyKebijakan penegakan yang diterapkan oleh peramban
Content-Security-Policy-Report-OnlyKebijakan non-blokir yang melaporkan pelanggaran (berguna untuk peluncuran dan penyesuaian)
Situs dapat mengeluarkan beberapa header CSP. Peramban menerapkan aturan kombinasi/preseden yang bisa rumit—header mentah membantu memastikan apa yang dikirim.

Apa yang dicari oleh analisis

Temuan didasarkan pada pemeriksaan pengerasan CSP praktis dan kesalahan penyebaran umum.

AreaContoh temuan
Kekuatan kebijakan skrippenggunaan unsafe-inline / unsafe-eval, sumber wildcard, strategi nonce/hash yang hilang
Kekuatan kebijakan gayagaya unsafe-inline, sumber yang terlalu luas, jalur migrasi ke nonce/hash yang hilang jika memungkinkan
Resistensi pembingkaian dan clickjackingPembatasan bingkai yang hilang atau lemah (sering melalui frame-ancestors)
Pola warisan / usangDirektif atau pola lama yang harus dimodernisasi
Kesiapan peluncuranVisibilitas kehadiran Report-Only dan titik akhir pelaporan

Baris perintah

Gunakan perintah ini untuk memeriksa header CSP dengan cepat. Berguna untuk memvalidasi apa yang dilaporkan oleh analis.

macOS / Linux

Ambil header respons (cari CSP)

curl -I https://example.com

Periksa Content-Security-Policy dan Content-Security-Policy-Report-Only di header respons.

Ikuti pengalihan sambil memeriksa header

curl -IL https://example.com

Memastikan Anda melihat header CSP dari tujuan akhir (HTTPS, www, rute app shell).

Tampilkan hanya header CSP (pencocokan tidak peka huruf)

curl -I https://example.com | grep -i "content-security-policy"

Dengan cepat mengisolasi header CSP dan report-only dari keseluruhan set header.

Windows (PowerShell)

Periksa header CSP

$r = Invoke-WebRequest -Uri https://example.com -Method Head; $r.Headers['Content-Security-Policy']; $r.Headers['Content-Security-Policy-Report-Only']

Menampilkan header CSP yang memberlakukan dan report-only jika ada.

Terapkan kebijakan baru di Report-Only terlebih dahulu, tinjau laporan pelanggaran, lalu perketat dan tegakkan. Penyesuaian CSP bersifat iteratif untuk aplikasi modern.

Kasus penggunaan

Perkuat situs terhadap XSS

Gunakan CSP untuk mengurangi dampak kerentanan injeksi dengan membatasi dari mana skrip/gaya dapat dimuat dan bagaimana kode inline ditangani.

  • Identifikasi unsafe-inline/unsafe-eval dan rencanakan migrasi ke nonce/hash
  • Batasi sumber script-src/style-src ke asal tepercaya
  • Tambahkan arahan defensif yang hilang (base-uri, object-src, frame-ancestors)

Luncurkan CSP dengan aman menggunakan Report-Only

Perkenalkan CSP secara bertahap tanpa mengganggu produksi dengan memulai dari Content-Security-Policy-Report-Only dan mengulangi pelanggaran.

  • Deteksi kehadiran kebijakan report-only
  • Pahami apa yang akan diblokir sebelum diberlakukan
  • Ekspor laporan untuk rencana peluncuran dan tiket Anda

Debug skrip, iframe, atau widget pihak ketiga yang rusak

CSP yang terlalu ketat dapat memblokir analitik, embed, atau koneksi API. Gunakan analis untuk melihat apa yang diizinkan oleh kebijakan dan di mana Anda mungkin memerlukan sumber eksplisit.

  • Konfirmasi sumber script/img/connect/frame yang diizinkan
  • Deteksi wildcard yang terlalu luas ditambahkan sebagai perbaikan cepat
  • Ganti izin luas dengan domain yang ditargetkan

Tinjauan keamanan / bukti kepatuhan

Hasilkan laporan konsisten tentang postur CSP saat ini untuk tinjauan keamanan, kuesioner klien, atau kepatuhan internal.

  • Unduh JSON untuk melacak perubahan dari waktu ke waktu
  • Unduh PDF untuk artefak audit dan berbagi

❓ Frequently Asked Questions

❓Apa itu CSP dan dari apa ia melindungi?

Content Security Policy (CSP) adalah lapisan keamanan yang diterapkan browser yang membatasi dari mana sumber daya dapat dimuat dan bagaimana skrip/gaya dieksekusi. Utamanya digunakan untuk mengurangi dampak cross-site scripting (XSS) dan serangan injeksi.

❓Apa perbedaan antara CSP dan CSP Report-Only?

Content-Security-Policy bersifat ditegakkan (dapat memblokir). Content-Security-Policy-Report-Only tidak memblokir; ia melaporkan pelanggaran sehingga Anda dapat menyempurnakan kebijakan sebelum menegakkannya.

❓Mengapa unsafe-inline dianggap berbahaya?

unsafe-inline mengizinkan skrip/gaya sebaris, yang melemahkan kemampuan CSP untuk menghentikan kode yang disuntikkan. Pendekatan yang lebih aman menggunakan nonce atau hash untuk hanya mengizinkan blok sebaris yang diketahui sambil tetap memblokir injeksi tak terduga.

❓Apakah saya perlu nonce atau hash?

Jika aplikasi Anda menggunakan skrip atau gaya sebaris, nonce/hash adalah cara modern untuk menjaga CSP tetap efektif tanpa mengganggu fungsionalitas. Mereka mengizinkan blok sebaris tertentu sambil mencegah injeksi sembarangan.

❓Dapatkah CDN atau proksi mengubah header CSP saya?

Ya. Lapisan tepi dapat menambahkan, menggabungkan, atau menimpa header. Jika sesuatu tampak tidak konsisten, aktifkan header mentah dan ikuti pengalihan untuk memverifikasi header respons akhir.

❓Apakah CSP adalah pengganti untuk memperbaiki bug XSS?

Tidak. CSP adalah kontrol pertahanan berlapis. Anda masih perlu pengkodean keluaran yang tepat, templating yang aman, dan validasi masukan. CSP mengurangi radius ledakan jika ada yang lolos.

❓Apakah aman menempelkan URL di sini?

Alat ini membuat permintaan sisi-server ke URL yang diberikan dan memblokir target jaringan pribadi. Hindari menaruh rahasia di URL (seperti token dalam string kueri) dan utamakan URL publik yang Anda percayai.

Pro Tips

Best Practice

Mulai dengan Content-Security-Policy-Report-Only, kumpulkan pelanggaran, lalu perketat dan tegakkan. CSP bersifat iteratif untuk aplikasi nyata.

Best Practice

Ganti unsafe-inline dengan strategi nonce atau hash. Pertahankan kebijakan eksplisit dan minimal.

Best Practice

Tambahkan frame-ancestors untuk mengurangi risiko clickjacking dan hindari mengandalkan hanya header lawas.

Best Practice

Hindari wildcard luas sebagai perbaikan cepat. Utamakan domain tertarget untuk skrip/gambar/koneksi dan tinjau kebutuhan pihak ketiga.

CI Tip

Ekspor laporan JSON dan lacak perubahan CSP di CI sehingga Anda dapat mendeteksi kemunduran saat header diubah oleh pembaruan CDN/aplikasi.

Additional Resources

Content Security Policy (MDN)
Documentation
Header Content-Security-Policy (MDN)
Documentation
Content-Security-Policy-Report-Only (MDN)
Documentation
Panduan XSS (OWASP)
Documentation
Lembar Contekan CSP (OWASP)
Documentation

Other Tools