Alice membuka dokumennya. Halaman tampil, pengujian lulus, dan perubahan tampak siap digabungkan. Lalu Bob meminta dokumen yang sama menggunakan akunnya sendiri. Jika Bob menerima data Alice, fitur berjalan persis sesuai implementasi. Implementasinya yang keliru.

Itulah alasan kode buatan AI tetap membutuhkan tinjauan keamanan. Kode yang berfungsi tidak menentukan siapa yang boleh memakainya, data apa yang boleh diakses, atau apa yang harus terjadi ketika permintaan melanggar aturan. Tinjauan menghubungkan perubahan dengan persyaratan tersebut dan mencari bukti bahwa aturannya berlaku.

Tanggung jawab yang sama berlaku untuk kode buatan manusia. Bantuan AI mempercepat munculnya implementasi yang masuk akal; bantuan itu tidak menghapus kewajiban memeriksa asumsi terhadap kebutuhan aplikasi.

Sampul menggambarkan contoh sintetis pemeriksaan kepemilikan dalam artikel ini. Gambar menunjukkan keputusan akses, bukan insiden nyata atau sertifikasi.

Pengujian yang lulus bisa melewatkan aturan akses

Uji yang memastikan Alice dapat membaca dokumennya menjawab satu pertanyaan berguna. Uji itu tidak mengatakan apa pun tentang Bob, kecuali permintaan Bob juga dicoba. Jika implementasi dan pengujiannya sama-sama menganggap semua pengguna yang masuk boleh membaca semua dokumen, keduanya bisa sepakat sambil tetap melanggar aturan produk.

Autentikasi mengenali pemanggil. Otorisasi menentukan apakah pemanggil boleh menjalankan tindakan tertentu terhadap suatu sumber daya. Keduanya berkaitan, tetapi pemeriksaan sesi tidak membuktikan kepemilikan, keanggotaan tenant, atau izin membaca data.

Panduan Otorisasi OWASP menyarankan validasi izin pada setiap permintaan dan pengujian logika otorisasi. Menyembunyikan tombol atau membuat ID sulit ditebak tidak menggantikan keputusan akses di server.

Contoh kecil yang bisa Anda verifikasi

Linmas menyediakan tutorial tinjauan otorisasi lokal dengan dokumen sintetis milik Alice. Varian yang sengaja dibuat rentan mencari dokumen berdasarkan ID lalu mengembalikannya kepada pengguna terautentikasi mana pun. Ketika pemeriksaan kepemilikan diaktifkan, fixture juga memastikan pemilik yang tersimpan cocok dengan pemanggil.

Fixture memeriksa lima kasus:

  • Alice tetap dapat membaca dokumennya sendiri.
  • Bob tidak dapat membaca dokumen Alice setelah pemeriksaan kepemilikan diterapkan.
  • Pemanggil tanpa autentikasi ditolak.
  • ID dokumen dengan format salah ditolak.
  • Dokumen yang tidak ada menghasilkan respons tidak ditemukan sesuai harapan.

Periksa dan unduh fixture lengkap, lalu jalankan dari direktori tempat Anda menyimpannya menggunakan Node.js 24 atau lebih baru:

node authorization-review.mjs

Contoh ini memakai data dalam memori dan tidak memerlukan server, kredensial, atau panggilan model. Assertion mereproduksi pembacaan lintas pengguna pada varian rentan dan memverifikasi pembatasan pada varian yang diperbaiki. Sakelar pembelajaran hanya untuk fixture ini. Kode produksi harus menegakkan aturan akses pada setiap permintaan.

Bukti tersebut memiliki batas. Fixture menerima identitas pengguna sintetis dan tidak memvalidasi sesi nyata. Fixture juga tidak menguji basis data, peran tenant, dokumen bersama, atau perubahan kepemilikan serentak. Dalam aplikasi, ambil identitas dari autentikasi tepercaya dan uji model izin sebenarnya, termasuk aturan berbagi yang sah.

Ikuti perubahan di luar baris yang dihasilkan

Mulai tinjauan dari perubahan yang bisa disebutkan: diff, handler, aturan izin, atau pengaturan deployment. Ikuti data dan keputusan yang menjadi dependensinya. Handler pendek bisa bergantung pada middleware, peran basis data, cache, dan pengaturan log yang tidak tercakup dalam prompt pembuat kode.

Untuk fitur pembacaan dokumen, pertanyaan yang berguna antara lain:

  • Apakah setiap jalur ke dokumen menerapkan aturan akses yang sama, termasuk unduhan dan respons cache?
  • Bisakah pemanggil memengaruhi ID pemilik atau tenant yang dianggap tepercaya oleh server?
  • Dapatkah kesalahan, log, atau tracing membocorkan dokumen atau token akses?
  • Apakah kredensial produksi atau aturan jaringan memberi akses lebih luas daripada asumsi lingkungan uji?

Pisahkan masalah yang berbeda. Kueri SQL berparameter membantu mencegah input mengubah struktur kueri, sebagaimana dijelaskan dalam Panduan Pencegahan Injeksi SQL OWASP. Kueri itu tidak menentukan apakah Bob boleh membaca baris milik Alice. Validasi input, keamanan kueri, dan otorisasi masing-masing membutuhkan pemeriksaan yang sesuai.

Gunakan otomatisasi untuk mengumpulkan bukti

Linter, analisis statis, pemeriksaan dependency, pemindaian rahasia, dan pengujian menemukan jenis kesalahan yang berbeda. Peninjau AI dapat membantu menelusuri perubahan atau menyarankan kasus uji yang terlewat. Manfaatnya bergantung pada input, konfigurasi, dan perilaku yang benar-benar diperiksa.

Minta temuan yang menyebut kode terkait, prasyarat, kemungkinan dampak, dan perbaikan konkret. Lalu periksa klaimnya. Peringatan tanpa jalur yang bisa dicapai mungkin merupakan positif palsu; laporan bersih bisa hanya mencerminkan kurangnya konteks. Panduan penggunaan agen Copilot yang bertanggung jawab dari GitHub juga menekankan pengawasan manusia dan peninjauan keluaran.

Perhatikan materi yang diberikan kepada peninjau terhosting. Gunakan konteks yang berizin dan sudah dibersihkan, serta ikuti aturan organisasi tentang kode dan data privat. Kredensial tidak diperlukan untuk menjelaskan pemeriksaan kepemilikan.

Buktikan perbaikan dengan pengujian

Untuk contoh Alice dan Bob, tinjauan perlu meninggalkan bukti lebih dari “otorisasi sudah diperbaiki”. Catat kasus akses lintas pengguna yang gagal, perubahan yang menegakkan aturan, dan hasil pengulangan kasus tersebut. Pertahankan juga uji akses pemilik; memblokir semua pembaca bisa menyembunyikan fitur yang rusak di balik uji penolakan yang lulus.

Rekaman tinjauan yang berguna menjawab empat pertanyaan:

  1. Apa yang diperiksa? Sebutkan revisi, jalur terkait, dan asumsi yang relevan.
  2. Apa yang gagal? Jelaskan pemanggil, sumber daya, tindakan yang dicoba, dan hasil yang diamati menggunakan data sintetis atau yang disamarkan.
  3. Apa yang berubah? Tunjukkan batas yang ditegakkan dan alasan perubahan mengatasi kegagalan.
  4. Apa yang belum diverifikasi? Sebutkan pemeriksaan runtime, perbedaan deployment, atau kasus izin yang masih perlu diuji.

Untuk layanan nyata, tambahkan verifikasi melalui jalur autentikasi dan akses data sebenarnya. Ulangi pemeriksaan relevan saat batas tersebut berubah. Lulus contoh dalam memori tidak membuktikan middleware atau kredensial produksi dikonfigurasi dengan benar.

Peran Linmas

Linmas menyediakan skill tinjauan defensif dan alur tinjauan dengan cakupan terbatas. Review Capsule dapat menyimpan input yang dievaluasi, temuan, keputusan kebijakan, dan metadata eksekusi. Artefak ini membantu manusia memeriksa apa yang ditinjau dan bukti pendukungnya. Artefak tersebut bukan sertifikasi keamanan atau persetujuan rilis otomatis.

Untuk metode yang lebih luas, baca arti tinjauan keamanan untuk kode buatan AI. Untuk praktik pertama, jalankan tutorial lokal yang ditautkan, lalu terapkan pertanyaan yang sama pada satu perubahan berizin di proyek Anda.

Sebelum menggabungkan perubahan, tentukan satu tindakan yang tidak boleh dilakukan pemanggil tanpa izin. Uji bersama alur yang sah. Jika tim belum bisa menunjukkan tempat batas itu ditegakkan, tinjauan masih memiliki pertanyaan konkret yang harus dijawab.

Sumber dan catatan verifikasi

Diperbarui 29 September 2026. Skenario Alice dan Bob merupakan fixture pembelajaran sintetis Linmas, bukan insiden produksi atau klaim terukur tentang frekuensi kelemahan kode buatan AI. Sumber primer yang ditautkan diperiksa pada tanggal pembaruan.