Review Keamanan Kode AI: Jebakan yang Sering Lolos

Di episode kemarin kita memastikan aplikasi berjalan utuh lewat E2E test. Tapi ada pertanyaan yang lebih menyeramkan: aplikasinya jalan, tapi apakah aman? Kode yang ditulis AI terlihat rapi dan modern, tapi kerapian bukan jaminan keamanan. Episode 15 ini tentang review keamanan, kebiasaan memeriksa kode AI sebelum celahnya ditemukan orang yang berniat jahat.

Kenapa Kode AI Rawan Masalah Keamanan

AI belajar dari jutaan contoh kode di internet, dan internet penuh dengan kode yang berjalan tapi tidak aman. AI meniru pola yang paling umum, bukan pola yang paling aman. Ditambah lagi, AI dioptimasi untuk membuat kode yang jalan, bukan kode yang tahan serangan. Kalau kamu tidak memintanya secara eksplisit, AI tidak akan menambahkan pengamanan yang tidak kamu minta.

Masalahnya makin besar karena kode AI terlihat meyakinkan. Variabelnya rapi, komentarnya jelas, strukturnya modern. Otak kita mudah tertipu: "kelihatannya profesional, pasti aman". Padahal celah keamanan tidak terlihat dari kerapian. Ia bersembunyi di satu baris yang luput: input yang tidak dibersihkan, kunci yang tertulis di tempat terbuka, validasi yang hanya ada di tampilan. Tugasmu sebagai programmer bukan memusuhi AI, tapi menjadi penjaga gerbang terakhir sebelum kode itu tayang.

Jebakan 1: SQL Injection

Ini celah klasik yang masih hidup sampai sekarang. Terjadi saat input pengguna disambung langsung ke perintah database tanpa dibersihkan. AI sering menulis pola berbahaya ini karena polanya pendek dan terlihat sederhana.

// BERBAHAYA: input pengguna disambung langsung ke query
const query = "SELECT * FROM users WHERE email = '" + email + "'";
// Penyerang mengisi email dengan: ' OR '1'='1
// Hasilnya: ia login sebagai siapa saja tanpa password

Perbaikannya adalah memakai parameterized query, yaitu query yang datanya dikirim terpisah dari perintahnya, sehingga database tidak akan pernah menganggap input pengguna sebagai perintah.

// AMAN: data dikirim sebagai parameter, bukan disambung
const query = "SELECT * FROM users WHERE email = ?";
db.query(query, [email]);

Setiap kali AI membuatkan kode database, tanyakan satu hal: apakah input pengguna pernah disambung langsung ke query? Kalau ya, minta dia tulis ulang dengan parameter.

Jebakan 2: XSS, Lupa Escape Output

XSS terjadi saat teks yang diketik pengguna ditampilkan kembali ke halaman tanpa dibersihkan. Browser tidak bisa membedakan "teks komentar" dan "perintah JavaScript" kalau keduanya ditulis mentah ke halaman. AI sering lupa bagian ini karena di contoh-contoh tutorial, datanya selalu data baik-baik saja.

Aturan praktisnya: setiap data yang berasal dari pengguna harus di-escape sebelum ditampilkan. Di React, ini otomatis kalau kamu memakai kurung kurawal biasa, tapi hilang perlindungannya saat kamu memakai dangerouslySetInnerHTML. Di template lain, cari fungsi escape bawaan framework-mu. Kalau AI memakai cara render yang mematikan perlindungan otomatis, tanyakan kenapa dan minta alternatif yang aman.

Jebakan 3: Secret dan API Key Tertulis di Kode

Ini jebakan yang paling memalukan sekaligus paling sering terjadi. AI menulis kode seperti ini dengan santai, karena di contoh latihnya memang begitu:

// BERBAHAYA: kunci API tertulis langsung di kode
const API_KEY = "sk-abcdef1234567890";
const DB_PASSWORD = "admin123";

Begitu kode ini di-push ke GitHub, kunci itu bukan lagi rahasiamu. Bot pemindai bisa menemukannya dalam hitungan menit, dan tagihan API bisa membengkak dipakai orang lain. Aturannya keras: secret tidak pernah tertulis di kode. Simpan di file .env yang tidak ikut di-commit, lalu baca lewat variabel environment.

// AMAN: kunci dibaca dari environment, file .env tidak di-commit
const API_KEY = process.env.API_KEY;

Setelah memisahkan secret, cek satu hal lagi: pastikan file .env masuk ke .gitignore. Secret yang rapi di kode tapi tetap ter-upload ke repo sama saja bohong.

Jebakan 4: Validasi Input yang Lemah

AI hampir selalu membuat validasi di frontend: form menolak email kosong, tombol nonaktif kalau input salah. Terlihat aman, tapi validasi frontend itu seperti gembok yang kuncinya ditempel di pintunya. Siapa pun bisa membuka developer tools, mematikan JavaScript, atau mengirim request langsung ke API-mu melewati form.

Aturannya: validasi yang menentukan keamanan harus ada di backend. Frontend boleh memvalidasi untuk kenyamanan pengguna, tapi backend tidak boleh percaya begitu saja pada data yang masuk. Contohnya, kalau form pendaftaran membatasi umur minimal 17 tahun, backend pun harus menolak data umur di bawah 17 tahun walau request-nya dikirim manual. Setiap kali AI membuatkan endpoint, tanyakan: "kalau seseorang mengirim data langsung ke endpoint ini tanpa lewat form, apa yang terjadi?" Kalau jawabannya "lolos", validasinya belum cukup.

Untuk melatih matamu, biasakan membaca kode AI dengan kacamata penyerang selama 30 detik per fungsi: "kalau saya berniat jahat, input apa yang akan saya kirim ke sini?" Pertanyaan sederhana ini menangkap banyak masalah yang lolos dari pembacaan biasa, karena pembacaan biasa berasumsi semua pengguna itu baik-baik saja. Penyerang tidak pernah baik-baik saja.

Checklist Review Keamanan 10 Menit

Kamu tidak perlu jadi ahli keamanan untuk menangkap 80 persen masalah umum. Cukup luangkan 10 menit setiap AI selesai menulis kode, dan jalankan checklist ini. Pertama, cari semua query database: apakah ada input yang disambung langsung? Kedua, cari semua tempat data pengguna ditampilkan: apakah sudah di-escape? Ketiga, cari kata "key", "secret", "password", "token" di seluruh kode: apakah ada yang tertulis langsung? Keempat, cek file .gitignore: apakah .env sudah dikecualikan? Kelima, untuk setiap endpoint penting, tanyakan apakah validasinya juga ada di backend, bukan cuma di frontend.

Kalau checklist manual terasa berat, delegasikan putaran pertamanya ke AI dengan prompt audit seperti ini. Tempelkan kode yang mau diperiksa di bagian akhirnya.

Lakukan audit keamanan pada kode di bawah ini.
Fokus pada empat hal:
1. SQL injection: adakah input pengguna yang disambung langsung ke query?
2. XSS: adakah data pengguna yang ditampilkan tanpa escape?
3. Secret bocor: adakah API key, password, atau token tertulis langsung?
4. Validasi: adakah validasi yang hanya ada di frontend untuk data sensitif?
Untuk tiap temuan, sebutkan file dan barisnya, jelaskan risikonya
dengan bahasa sederhana, dan berikan kode perbaikannya.

[kode yang mau diaudit ditempel di sini]

Satu peringatan jujur: AI yang mengaudit kode AI bisa melewatkan hal yang sama dua kali. Anggap hasil audit AI sebagai putaran pertama, bukan vonis akhir. Putaran keduanya tetap matamu sendiri dengan checklist di atas, terutama sebelum aplikasi dipakai orang banyak atau menangani data asli.

Latihan Minggu Ini

Latihanmu minggu ini tiga langkah. Pertama, pilih satu fitur di aplikasimu yang menerima input pengguna, misalnya form komentar, pencarian, atau login. Kedua, jalankan checklist 10 menit di atas pada kode fitur itu, lalu minta AI melakukan audit dengan prompt yang sudah kamu salin. Ketiga, catat temuannya: berapa yang kamu temukan sendiri, berapa yang ditemukan AI, dan adakah yang lolos dari keduanya? Catatan itu akan membuka matamu soal seberapa buta kita terhadap kode yang terlihat rapi.

Di episode 16 kita pindah dari mencegah ke memperbaiki, dengan judul "Debugging Sistematis Bareng AI". Karena sebaik apa pun review-mu, bug tetap akan muncul, dan cara kamu melaporkannya ke AI menentukan seberapa cepat ia selesai. Sampai jumpa besok jam 21:00. Bakar semangat kodingmu seperti api kompor.