Daftar periksa keamanan Claude Code untuk spot-check cepat aplikasi web

Apa itu spot-check keamanan ringan

Spot-check keamanan ringan adalah tinjauan cepat (biasanya 30–60 menit) yang dimaksudkan untuk menangkap masalah jelas berdampak tinggi sebelum code dikirim. Ini bukan audit penuh. Anggap seperti pemeriksaan keselamatan: Anda memindai jalur yang paling sering gagal di aplikasi nyata dan mencari bukti, bukan dugaan.

Daftar periksa keamanan Claude Code ini fokus pada area yang paling sering bermasalah di aplikasi web sehari-hari:

• Asumsi autentikasi (bagaimana Anda mengetahui siapa pengguna)
• Celah otorisasi (apa yang mereka diizinkan lakukan)
• Validasi input
• Penanganan secrets
• Permukaan injeksi umum (SQL, eksekusi perintah, rendering template, redirect, unggahan)

Ini tidak berusaha membuktikan ketiadaan bug, memodel ancaman kompleks, atau menggantikan penetration testing.

"Temuan konkret" berarti setiap isu yang Anda catat memiliki bukti yang bisa ditindaklanjuti oleh developer segera. Untuk tiap temuan, tangkap:

• File dan nama fungsi/handler yang tepat
• Perilaku berisiko dalam satu kalimat
• Langkah repro minimal (request, payload, atau jalur klik)
• Mengapa itu penting (dampak) dan siapa yang bisa memicunya
• Arahan perbaikan yang aman (bukan penulisan ulang penuh)

AI adalah pembantu, bukan otoritas. Gunakan untuk mencari, merangkum, dan mengusulkan tes. Lalu verifikasi dengan membaca kode dan, bila mungkin, mereproduksi dengan request nyata. Jika model tidak bisa menunjukkan lokasi dan langkah spesifik, anggap klaim tersebut belum terbukti.

Tetapkan ruang lingkup dalam 10 menit

Tinjauan cepat hanya berhasil jika Anda mempersempit target. Sebelum meminta Claude Code melihat sesuatu, putuskan apa yang ingin Anda buktikan hari ini dan apa yang tidak Anda periksa.

Mulai dengan 1 sampai 3 user journey nyata di mana kesalahan berbiaya uang, mengekspos data, atau memberi kekuasaan. Kandidat yang baik: login, reset kata sandi, checkout, dan layar edit admin.

Selanjutnya, sebutkan aset yang harus dilindungi. Jadilah spesifik: akun pengguna, aksi pembayaran, data pribadi, operasi khusus admin.

Lalu tulis asumsi ancaman dengan kata-kata biasa. Apakah Anda mempertahankan diri dari pengguna penasaran yang mengklik, penyerang eksternal dengan skrip, atau insider dengan akses tertentu? Jawaban Anda mengubah seperti apa "cukup baik".

Terakhir, definisikan lulus dan gagal supaya spot-check berakhir dengan temuan, bukan kesan. Aturan sederhana bekerja baik:

• Lulus: setiap aksi sensitif menunjukkan pemeriksaan autentikasi dan otorisasi yang eksplisit.
• Gagal: endpoint mana pun mempercayai client untuk user ID atau peran.
• Lulus: input divalidasi di sisi server, bukan hanya di UI.
• Gagal: secrets muncul di log, konfigurasi, atau kode klien.

Jika Anda tidak bisa menjelaskan seperti apa kegagalan, ruang lingkup masih terlalu kabur.

Siapkan konteks yang Anda berikan ke Claude Code

Spot-check hanya bekerja jika model melihat tempat yang tepat. Kumpulkan bundel kecil kode dan catatan agar tinjauan bisa menghasilkan bukti, bukan tebakan.

Mulai dengan membagikan jalur kritis-keamanan: titik masuk request dan kode yang memutuskan siapa pengguna dan apa yang bisa mereka lakukan. Sertakan cukup kode di sekitarnya untuk menunjukkan aliran data.

Bundel praktis biasanya mencakup:

• Entry autentikasi: parsing session/JWT, pengaturan cookie, callback login, middleware auth
• Routes + handler: controller, metode RPC, resolver GraphQL, handler job background
• Lapisan data: query ORM, helper SQL mentah, pembangun query, migrasi untuk tabel sensitif
• Pemeriksaan kebijakan: cek peran, cek kepemilikan, feature flag, endpoint khusus admin
• Validasi: validator skema request, handler unggahan file, kode deserialisasi

Tambahkan beberapa baris catatan lingkungan supaya asumsi eksplisit: session vs JWT, di mana token disimpan (cookie atau header), perilaku reverse proxy atau API gateway, worker antrean/cron, dan endpoint "internal-only" jika ada.

Sebelum mengejar bug, minta inventaris: titik masuk, endpoint istimewa, dan datastore yang disentuh. Ini mencegah permukaan yang terlewat.

Juga sepakati format keluaran yang memaksa temuan konkret. Tabel sederhana bekerja baik: Temuan, Tingkat Keparahan, Endpoint/File Terdampak, Bukti (cuplikan atau rentang baris), Skenario Eksploitasi, Saran Perbaikan.

Alur kerja langkah-demi-langkah untuk tinjauan 30–60 menit

Batasi waktu:

• 10 menit untuk orientasi
• 15–30 menit untuk menelusuri aliran
• 10 menit untuk menulis laporan

Tujuannya bukan cakupan sempurna. Ini serangkaian kecil temuan yang dapat diuji.

Buka aplikasi sambil membaca. Klik melalui UI dan perhatikan request yang muncul. Catatan harus menunjuk endpoint, parameter, dan sumber data tertentu.

Alur kerja yang muat dalam satu sesi:

1. Gambarkan titik masuk dan batas kepercayaan. Catat route publik, route yang butuh login, route admin, webhook, unggahan, dan callback pihak ketiga. Tandai di mana data berpindah dari yang dikontrol pengguna ke yang dipercaya server.
2. Untuk tiap endpoint penting, tulis apa yang membuktikan identitas dan di mana itu terjadi. Jika cek berada di "middleware," konfirmasi setiap route benar-benar menggunakannya.
3. Lakukan hal yang sama untuk otorisasi. Pilih satu aksi berisiko (melihat data pengguna lain, mengubah peran, mengekspor, menghapus) dan telusuri keputusan izin sampai ke query database.
4. Telusuri input pengguna ke sink. Ikuti satu parameter dari request ke SQL/ORM, rendering template, eksekusi perintah, pengambilan URL (SSRF), redirect, dan path file.
5. Pindai aliran secrets saat Anda menelusuri. Cari token di log, kode sisi klien, pesan error, dump environment, dan pola penyimpanan lemah.

Kebiasaan berguna: untuk setiap "terlihat baik," tulis apa yang akan Anda lakukan untuk memecahnya. Jika Anda tidak bisa menggambarkan upaya pemecahan, kemungkinan besar Anda belum memverifikasinya.

Spot-check autentikasi: buktikan siapa pengguna itu

Autentikasi adalah tempat aplikasi memutuskan, "request ini milik orang ini." Spot-check cepat bukan membaca setiap baris. Ini menemukan tempat identitas ditetapkan, lalu memeriksa jalan pintas dan jalur kegagalan.

Temukan batas kepercayaan: di mana identitas pertama kali dibuat atau diterima? Bisa berupa cookie session, token bearer JWT, API key, atau mTLS di edge. Minta Claude Code menunjukkan file dan fungsi tepat yang mengubah "anonim" menjadi user id, dan mencantumkan setiap jalur lain yang dapat melakukan hal yang sama.

Pemeriksaan autentikasi yang layak dipindai:

• Identifikasi semua entry auth (web login, token API, auth mobile, auth layanan internal) dan pastikan mereka menyatu pada satu model identitas konsisten.
• Periksa login dan reset kata sandi untuk rate limit, penguncian, dan user enumeration (pesan error atau timing berbeda untuk akun yang ada vs tidak ada).
• Inspeksi session dan cookie: HttpOnly, Secure, SameSite, expiry, rotasi saat login dan perubahan privilege, dan invalidasi logout (server-side, bukan hanya “hapus cookie”).
• Tinjau MFA dan recovery agar jalur pemulihan tidak lebih lemah daripada MFA (mis. reset lewat email yang melewati MFA).
• Tinjau logging kegagalan auth: berguna untuk operasional, tetapi jangan bocorkan detail yang membantu penyerang (tidak ada petunjuk "user ada", tidak ada dump token).

Contoh praktis: jika email reset mengembalikan "akun tidak ditemukan," itu masalah enumerasi cepat. Bahkan dengan pesan generik, perbedaan timing bisa bocorkan fakta yang sama, jadi periksa waktu respons juga.

Spot-check otorisasi: buktikan pengguna diizinkan

Otorisasi adalah pertanyaan yang paling merusak ketika salah: "Apakah pengguna ini diizinkan melakukan aksi ini pada resource ini?" Spot-check cepat harus sengaja mencoba memecah asumsi itu.

Tulis peran dan izin dengan bahasa sederhana. Buat manusiawi:

• Pemilik bisa mengundang anggota
• Anggota bisa mengubah profil mereka sendiri
• Support bisa melihat detail billing tapi tidak mengubah paket
• Admin bisa menghapus proyek

Lalu verifikasi setiap aksi sensitif menerapkan otorisasi di server, bukan hanya di UI. Tombol bisa disembunyikan, route bisa diblokir di klien, tetapi penyerang masih bisa memanggil API langsung.

Pemeriksaan cepat yang biasanya menemukan masalah nyata:

• Temukan endpoint/mutasi yang membuat, menghapus, mengekspor, mengubah peran, atau mengakses billing
• Untuk masing-masing, temukan cek izin di sisi server (bukan frontend)
• Cari ID yang dikontrol pengguna (projectId, userId, orgId) dan konfirmasi cek kepemilikan
• Pastikan path khusus admin gagal tertutup jika peran tidak ada
• Periksa batas tenant: orgId/accountId harus berasal dari konteks session, bukan hanya dari input request

Bau klasik IDOR sederhana: request seperti GET /projects/{id} di mana {id} dikontrol pengguna, dan server memuatnya tanpa memverifikasi bahwa itu milik user atau tenant saat ini.

Prompt yang memaksa jawaban nyata:

"Untuk endpoint ini, tunjukkan kode tepat yang memutuskan akses, dan daftar kondisi spesifik yang memungkinkan pengguna dari orgId berbeda mengaksesnya. Jika tidak ada, jelaskan mengapa dengan nama file dan fungsi."

Validasi input: jaga data buruk agar tidak masuk

Sebagian besar masalah cepat pada web app bermula dari celah: aplikasi menerima input yang developer tidak harapkan. Anggap "input" sebagai apa pun yang bisa dipengaruhi pengguna atau sistem lain, bahkan jika terasa tidak berbahaya.

Mulai dengan memberi nama input untuk endpoint yang Anda spot-check:

• Nilai query dan path URL
• Field body request (termasuk JSON bersarang)
• Header (header auth, content type, forwarded IP)
• Cookie
• Unggahan file (nama, ukuran, tipe, metadata)

Validasi harus terjadi dekat dengan tempat data masuk ke aplikasi, bukan jauh di dalam logika bisnis. Periksa dasar: tipe (string vs number), panjang maksimal, wajib vs opsional, dan format (email, UUID, tanggal).

Untuk nilai yang diketahui seperti peran, status, atau arah sortir, gunakan allowlist. Ini lebih sulit dilanggar daripada "blok beberapa nilai buruk."

Periksa juga penanganan error. Jika aplikasi menolak input, jangan memantulkan nilai mentah kembali di respon, log, atau UI. Itu cara bug validasi kecil berubah jadi kebocoran data atau pembantu injeksi.

Rencana mini "input buruk" untuk endpoint berisiko (login, search, upload, aksi admin):

• String terlalu panjang (10.000+ karakter)
• Tipe salah (array bukannya string)
• Nilai enum tak terduga
• Karakter khusus yang bisa mengubah makna
• Nilai kosong untuk field wajib

Contoh: parameter sort yang menerima sembarang string bisa menjadi fragmen SQL nanti. Allowlist seperti "date" atau "price" mencegah kelas kesalahan itu sejak awal.

Permukaan injeksi umum untuk dipindai cepat

Sebagian besar tinjauan cepat menemukan masalah di beberapa tempat yang sama: di mana pun input pengguna diinterpretasikan sebagai kode, query, path, atau URL. Bagian ini tempat Anda berburu momen "input menyeberangi batas kepercayaan."

Telusuri data dari titik masuk (query params, header, cookie, unggahan, form admin) ke tempat akhirnya dipakai.

Target pemindaian cepat

Perhatikan pola ini dan minta situs pemanggilan dan contoh payload untuk masing-masing:

• SQL injection: query yang dibangun dengan string, ORDER BY dinamis, dan builder IN (...) yang menggabungkan nilai user
• XSS: rendering HTML, template, preview markdown, editor rich text yang mengasumsikan "sanitize nanti"
• Command injection: panggilan shell untuk pemrosesan gambar, alat PDF, backup, atau langkah "convert" yang melewatkan flag yang dikontrol pengguna
• SSRF: pengambil URL untuk webhook, preview link, fitur import-dari-URL, dan pengecekan status internal yang menerima URL pengguna
• Path traversal: endpoint download file, ekstraksi zip, dan pipeline unggahan yang kemudian membaca file berdasarkan nama

Juga awasi deserialisasi dan template injection. Apa pun yang mengurai JSON, YAML, atau string bertemplat dari pengguna bisa menyembunyikan perilaku berisiko, terutama bila mendukung tipe kustom, ekspresi, atau rendering di sisi server.

Jika sebuah fitur menerima URL, nama file, atau teks berformat, anggap bisa disalahgunakan sampai Anda membuktikan sebaliknya dengan jalur kode dan tes.

Penanganan secrets: temukan kebocoran dan penyimpanan lemah

Masalah secrets sering terlihat jelas setelah Anda tahu tempat mencarinya. Fokus pada tempat secrets berada dan di mana mereka bisa tersalin secara tidak sengaja.

Tempat umum secrets muncul:

• Variabel environment dan file konfigurasi aplikasi
• Output CI dan log build (termasuk log deploy yang gagal)
• Bundle klien dan build mobile (apa pun yang dikirim ke pengguna)
• Endpoint debug, halaman health, dan alat admin
• Halaman error, stack trace, dan event analytics

Lalu paksa jawaban konkret: jika sebuah secret terekspos hari ini, apa yang terjadi selanjutnya? Sistem yang baik punya jalur rotasi (kunci baru diterbitkan), pencabutan (kunci lama dinonaktifkan), dan cara untuk redeploy cepat. Jika jawabannya "kami akan mengubahnya nanti," anggap itu temuan.

Least privilege adalah kemenangan cepat lainnya. Insiden memburuk karena kunci terlalu kuat. Cari user database yang bisa drop table, token pihak ketiga yang bisa mengelola akun, atau API key yang dibagi antar lingkungan. Utamakan satu kunci per layanan, per lingkungan, dengan seperangkat izin terkecil.

Prompt spot-check cepat yang bisa Anda tempel ke Claude Code:

• "Cari token hard-coded, password, dan private key. Sebutkan path file tepat dan pola string yang cocok."
• "Temukan kode yang melog header request, cookie, env var, atau object error penuh. Tunjukkan baris log dan field sensitif yang bisa tampil."
• "Periksa apakah secrets bisa berakhir di snapshot, export, atau artefak build. Identifikasi apa yang tertangkap dan di mana disimpan."

Akhirnya, konfirmasi guardrail: blokir secrets dari source control (pre-commit/CI checks), dan pastikan backup atau snapshot tidak menyertakan kredensial plaintext. Jika platform Anda mendukung snapshot dan rollback, verifikasi secrets di-inject saat runtime, bukan dibakar ke image yang disimpan.

Prompt yang memaksa temuan konkret (pola copy-paste)

Prompt kabur menghasilkan jawaban kabur. Paksa model berkomitmen pada bukti: lokasi tepat, jejak yang bisa Anda ikuti, repro yang bisa dijalankan, dan apa yang membuat klaim itu salah.

Gunakan satu pola per kali, lalu minta revisi setelah Anda konfirmasi atau tolak detail.

• Bukti tingkat file: "Cari repo untuk auth, session, token, dan middleware. Sebutkan file, fungsi, dan rentang baris tepat yang terlibat. Kutip cuplikan relevan. Jika tidak bisa menunjuk kode, katakan 'no evidence found'."
• Jejak dari input ke sink: "Pilih satu input yang dikontrol pengguna (header, query, body, cookie). Tunjukkan aliran data langkah demi langkah dari titik masuk sampai digunakan (SQL, HTML, shell, template, redirect, path file). Daftar setiap fungsi di rantai."
• Langkah repro: "Berikan repro minimal dengan curl (method, bentuk URL, header, body). Sertakan kode status yang diharapkan dan contoh response sukses/gagal. Nyatakan asumsi (peran, keadaan auth)."
• Kontrol false-positive: "Apa yang akan membantah temuan ini? Daftarkan 2–3 pengecekan: flags config, urutan middleware, validasi allowlist, query parameterized, escaping framework. Jika ada, jelaskan kenapa risiko berubah."
• Perbaikan paling kecil + tes: "Usulkan perubahan terkecil yang memblokir isu tanpa merusak kasus valid. Lalu tulis satu tes untuk ditambahkan (nama, tujuan, input, hasil yang diharapkan). Jika ada tradeoff, jelaskan."

Jika keluaran masih terasa kabur, sempitkan:

"Jawab hanya dengan: path file, nama fungsi, baris berisiko, dan satu-kalimat dampak."

Contoh realistis: mengubah firasat menjadi isu terverifikasi

Endpoint update profil sering menyembunyikan bug kontrol akses. Berikut kasus kecil yang bisa Anda jalankan melalui checklist ini.

Scenario: endpoint API memperbarui profil pengguna:

PATCH /api/profile?accountId=123 dengan JSON seperti { "displayName": "Sam" }.

Anda minta Claude Code menemukan handler, menelusuri bagaimana accountId dipakai, dan membuktikan apakah server menegakkan kepemilikan.

Yang sering muncul:

• Authn: request membutuhkan session atau token, jadi terkesan terlindungi.
• Authz: handler mempercayai accountId dari query string dan memperbarui akun itu tanpa memeriksa bahwa itu cocok dengan pengguna yang login.
• Validasi input: displayName dipangkas, tapi accountId tidak divalidasi sebagai integer.
• Permukaan injeksi: SQL dibangun dengan konkatenasi string seperti "... WHERE account_id=" + accountId.

Penulisan yang baik bersifat konkret:

• Keparahan: Tinggi (IDOR + kemungkinan SQL injection)
• Bukti: request dengan login valid mengubah pengguna lain saat accountId diubah; SQL dibangun dari input tak tepercaya
• Perbaikan: abaikan accountId dari klien, gunakan account id dari user terautentikasi di server; parameterize query
• Tes: coba update akun lain dan harapkan 403; tolak accountId non-numerik

Setelah patch, cek kembali cepat:

• Coba request sama dengan accountId berbeda dan konfirmasi gagal.
• Konfirmasi log menunjukkan server menggunakan id terautentikasi, bukan query param.
• Konfirmasi query menggunakan placeholder/param, bukan string building.
• Jalankan satu tes negatif untuk input cacat (huruf, angka sangat besar).

Perangkap umum yang membuat spot-check melewatkan isu nyata

Cara tercepat melewatkan kerentanan adalah mempercayai apa yang tampak dilindungi UI. Tombol yang disembunyikan atau dinonaktifkan bukan cek izin. Jika server menerima request itu, siapa pun bisa memutarnya ulang dengan user ID berbeda, peran berbeda, atau panggilan API langsung.

Kegagalan umum lain adalah permintaan yang kabur. "Lakukan review keamanan" biasanya menghasilkan laporan generik. Spot-check butuh ruang lingkup ketat (endpoint mana, peran mana, data mana) dan format keluaran ketat (nama file, fungsi, baris berisiko, repro minimal).

Aturan yang sama berlaku untuk keluaran AI: jangan terima klaim tanpa petunjuk. Jika temuan tidak menyertakan lokasi kode konkret dan langkah demi-langkah untuk memicunya, anggap belum terbukti.

Cara cepat spot-check meleset

Perangkap ini sering muncul:

• Menganggap "admin-only" karena itu halaman admin, bukan karena server menegakkannya
• Meminta hasil review luas alih-alih "tunjukkan request tepat yang mem-bypass X"
• Menerima "mungkin SQL injection" tanpa titik konstruksi query dan jalur input
• Mengabaikan titik masuk kurang jelas seperti webhook, job terjadwal, alat import, dan aksi admin internal
• Menambal gejala (menambah filter atau regex) sementara akar masalah adalah validasi atau otorisasi yang hilang

Jika Anda mendapati diri terus menambahkan filter setelah tiap edge case baru, berhenti. Perbaikan biasanya lebih awal dan sederhana: validasi input di boundary, dan buat cek otorisasi eksplisit dan terpusat sehingga setiap jalur kode menggunakannya.

Pemeriksaan cepat yang bisa dijalankan sebelum rilis

Ini tidak menggantikan review penuh, tapi menangkap kesalahan yang sering lolos saat semua orang lelah. Fokus pada apa yang bisa Anda buktikan cepat: request yang bisa dikirim, halaman yang bisa dimuat, baris log yang bisa ditemukan.

Lima spot-check cepat yang biasanya berbuah:

• Gesekan autentikasi: Coba 10 kali login gagal berturut-turut. Apakah ada rate limit, penguncian, atau setidaknya perlambatan? Bisa tahu apakah email ada dari pesan error atau timing?
• Otorisasi dengan swap ID: Pilih resource nyata (order, invoice, profil). Ubah ID di URL, body JSON, atau variabel GraphQL. Apakah Anda mendapatkan data yang bukan milik Anda, bahkan "hanya metadata"?
• Garda input: Untuk field kunci (email, nama, search, unggahan file), coba string sangat panjang, Unicode aneh, dan tipe tak terduga (angka bukannya string). Apakah Anda menegakkan batas panjang dan allowlist bila perlu?
• Eksposur secrets: Cari di log terbaru dan bundle klien untuk token, API key, JWT, atau "Authorization: Bearer". Periksa halaman error juga. "Hanya di staging" sering menjadi "sudah rilis".
• Permukaan injeksi: Cari konkatenasi string ke SQL, filter, rendering template, perintah shell, atau URL redirect. Jika input mencapai salah satu ini tanpa validasi ketat, anggap berisiko sampai terbukti sebaliknya.

Tuliskan 3 perbaikan teratas yang bisa Anda kirim minggu ini, bukan daftar keinginan. Contoh: (1) tambahkan rate limiting ke login dan reset kata sandi, (2) tegakkan cek kepemilikan server-side pada endpoint "get by id", (3) batasi panjang input dan tolak karakter tak terduga untuk field search.

Langkah selanjutnya: jadikan checklist ini bagian dari proses build

Spot-check hanya berbuah jika hasilnya mengubah apa yang Anda kirim. Perlakukan checklist ini sebagai langkah kecil yang berulang dalam build, bukan misi penyelamatan sekali saja.

Ubah setiap temuan menjadi item backlog yang sulit disalahpahami:

• Fix: apa yang akan berubah di kode atau konfigurasi
• Test: bagaimana Anda akan membuktikan sudah diperbaiki (satu request, satu unit test, satu langkah QA)
• Owner: satu orang bertanggung jawab
• Target date: rilis berikutnya atau hari tertentu
• Evidence: file/endpoint dan request atau payload tepat yang menunjukkan isu

Pilih ritme yang cocok dengan risiko dan ukuran tim Anda. Untuk banyak tim, setiap rilis adalah yang terbaik. Jika rilis sering, lakukan review 30–60 menit bulanan dan pengecekan lebih singkat sebelum pengiriman.

Permudah pengulangan dengan membuat paket prompt yang dapat digunakan ulang dan template checklist. Pertahankan prompt fokus pada keluaran konkret: tunjukkan route, penjaga, request yang gagal, dan perilaku yang diharapkan. Simpan paket itu di tempat tim Anda sudah bekerja supaya tidak terlewat.

Jika Anda membangun aplikasi lewat chat, masukkan checklist ke dalam perencanaan. Tambahkan catatan singkat "asumsi keamanan" untuk autentikasi/otorisasi, input, dan secrets, lalu jalankan spot-check segera setelah versi kerja pertama.

Platform seperti Koder.ai dapat cocok dengan kebiasaan ini karena memungkinkan iterasi cepat sambil menjaga titik pemeriksaan review. Menggunakan snapshot dan rollback di sekitar perubahan berisiko mempermudah pengiriman perbaikan keamanan tanpa tersendat saat perubahan mengganggu perilaku.