Checklist Keamanan Aplikasi Buatan AI

Aplikasi buatan AI biasanya terlihat meyakinkan: tampilannya rapi, tombolnya berfungsi, datanya tersimpan. Tapi keamanan tidak terlihat dari tampilan. Aplikasi yang tampak sempurna bisa saja membiarkan siapa pun membaca data semua pengguna.

Ini bukan sekadar teori. Pada 2025, seorang peneliti keamanan memindai lebih dari 1.600 aplikasi yang dipamerkan di sebuah platform app builder populer. Sekitar 10% di antaranya punya tabel database yang bisa dibaca atau diubah tanpa login, karena aturan akses databasenya tidak diatur dengan benar. Celah ini tercatat sebagai CVE-2025-48757. Akar masalahnya bukan server platform yang dibobol, tapi konfigurasi aplikasi yang dihasilkan tanpa diperiksa.

Checklist ini dibuat untuk mencegah hal semacam itu. Pakai sebelum aplikasimu menyimpan data orang lain, menerima pembayaran, atau dibagikan secara luas. Setiap bagian berisi apa yang diperiksa, cara mengujinya sendiri, dan prompt yang bisa kamu berikan ke AI. Penjelasan lengkap tiap topik ada di artikel yang ditautkan.

Cara memakai checklist ini

• Untuk aplikasi pribadi yang datanya hanya di perangkatmu sendiri (seperti aplikasi pertama kita), bagian 1, 4, dan 6 sudah cukup.
• Untuk aplikasi dengan login, database, atau pengguna lain, periksa semuanya.
• Uji sendiri, jangan hanya bertanya ke AI. AI bisa membantu meninjau kode, tapi ia juga bisa melewatkan celah atau terlalu yakin kodenya sudah aman. Uji di aplikasimu sendiri adalah buktinya.
• Uji hanya aplikasi milikmu sendiri.

1. Secret dan kunci API

• Tidak ada API key, password, atau token yang tertulis di kode.
• Secret disimpan di environment variable, dan .env ada di .gitignore.
• Tidak ada secret di kode yang berjalan di browser, termasuk variabel berawalan PUBLIC_, VITE_, atau NEXT_PUBLIC_.
• Kunci “admin” atau “service role” database hanya dipakai di server, tidak pernah di aplikasi frontend.

Uji sendiri: buka aplikasimu di browser, tekan F12, lalu cari (Ctrl + F) di tab Sources atau Network kata seperti key, secret, token, dan awalan kunci layananmu. Apa pun yang ketemu di sana bisa dilihat semua pengunjung.

Prompt untuk AI: “Periksa seluruh proyek ini. Tunjukkan setiap API key, password, atau token yang tertulis langsung di kode atau terkirim ke browser. Pindahkan ke environment variable dan jelaskan mana yang harus tetap di server.”

Selengkapnya: Environment variable dan secrets.

2. Login dan hak akses

Ini bagian yang paling sering bocor di aplikasi buatan AI. Lihat lagi A01 di OWASP Top 10.

• Halaman dan API admin menolak permintaan dari pengguna yang belum login, dan dari pengguna yang bukan admin.
• Setiap data diperiksa kepemilikannya di server, bukan hanya disembunyikan di tampilan.
• Kalau memakai database seperti Supabase, aturan akses tingkat baris (Row Level Security) aktif di setiap tabel, dengan aturan yang membatasi data hanya untuk pemiliknya.
• Password di-hash dengan algoritma khusus password, bukan disimpan apa adanya.
• Percobaan login dibatasi.

Uji sendiri:

1. Buat dua akun, A dan B. Login sebagai A, buka data milik A, lalu salin alamat atau ID-nya.
2. Login sebagai B, lalu coba buka alamat yang sama, atau ganti ID di URL. Kalau data A muncul, ada celah.
3. Logout, lalu buka langsung alamat halaman admin. Halaman itu harus menolakmu.

Prompt untuk AI: “Untuk setiap endpoint dan query di proyek ini, jelaskan bagaimana sistem memastikan pengguna hanya bisa membaca dan mengubah datanya sendiri. Tunjukkan endpoint yang tidak memeriksa kepemilikan data.”

Selengkapnya: Menyimpan password dengan benar.

3. Database dan query

• Semua query memakai placeholder atau prepared statement. Tidak ada input pengguna yang digabung ke string SQL.
• Akun database aplikasi hanya punya hak yang dibutuhkan.
• Data penting punya cadangan (backup), dan kamu tahu cara memulihkannya.

Uji sendiri: isi kolom pencarian, login, dan filter dengan ' dan ' OR '1'='1. Hasilnya harus kosong atau ditolak, bukan semua data atau pesan error database.

Prompt untuk AI: “Cari semua query database yang menggabungkan input pengguna ke dalam string. Ubah semuanya agar memakai placeholder.”

Selengkapnya: SQL injection.

4. Input dan tampilan

• Teks dari pengguna ditampilkan sebagai teks: textContent, atau fitur escape bawaan framework. Tidak ada innerHTML, dangerouslySetInnerHTML, atau v-html untuk data pengguna.
• Input divalidasi di server: tipe, panjang maksimum, dan format.
• Unggahan file dibatasi jenis dan ukurannya, dan file tidak bisa dijalankan sebagai kode di server.

Uji sendiri: isi setiap kolom teks dengan <b>tebal</b>. Yang tampil harus persis teks itu, bukan huruf tebal. Coba juga teks yang sangat panjang, angka negatif, dan kolom kosong.

Prompt untuk AI: “Tunjukkan setiap tempat data dari pengguna ditampilkan sebagai HTML. Ubah agar ditampilkan sebagai teks, dan tambahkan validasi input di sisi server.”

Selengkapnya: XSS dan CSRF.

5. Form dan session

• Cookie session memakai HttpOnly, Secure, dan SameSite=Lax (atau Strict).
• Tidak ada perubahan data lewat permintaan GET.
• Perlindungan CSRF bawaan framework aktif, tidak dimatikan.
• Logout benar-benar mengakhiri session.

Uji sendiri: buka F12, lalu tab Application → Cookies, dan periksa kolom HttpOnly, Secure, dan SameSite pada cookie login.

Selengkapnya: XSS dan CSRF.

6. Dependensi

• Setiap library yang dipasang benar-benar ada, populer, dan masih dirawat. AI kadang menyarankan nama paket yang keliru atau tidak ada, dan penyerang bisa saja mendaftarkan nama-nama seperti itu.
• Tidak ada celah tingkat tinggi yang sudah diketahui. Cek dengan npm audit, pip-audit, atau tool sejenis.
• Lock file ikut di-commit, supaya versi yang terpasang di server sama dengan yang kamu uji.

Uji sendiri: untuk setiap paket yang ditambahkan AI, buka halaman paketnya (npmjs.com atau pypi.org). Periksa nama, jumlah unduhan, dan tanggal rilis terakhir.

7. Deploy dan konfigurasi

• Aplikasi online hanya bisa diakses lewat HTTPS.
• Mode debug mati di production, dan pesan error ke pengguna tidak menampilkan detail kode atau database.
• File yang tidak perlu (.env, .git, cadangan database, catatan) tidak ikut ter-deploy.
• Repository publik tidak berisi riwayat commit dengan secret.

Uji sendiri: buka https://situsmu.com/.env dan https://situsmu.com/.git/config. Keduanya harus menghasilkan halaman 404.

Selengkapnya: Deploy pertama dan Domain, DNS, dan HTTPS.

8. Biaya dan penyalahgunaan

Aplikasi yang memanggil API berbayar (misalnya API AI) bisa disalahgunakan untuk menghabiskan kuotamu.

• Panggilan ke API berbayar lewat server, bukan langsung dari browser dengan kunci yang terlihat.
• Ada batas pemakaian per pengguna atau per alamat IP (rate limiting).
• Ada batas pengeluaran dan peringatan tagihan di dashboard layanan tersebut.

Prompt peninjauan keamanan menyeluruh

Setelah memperbaiki poin-poin di atas, minta AI meninjau sekali lagi, lalu uji ulang sendiri temuan-temuannya:

Bertindaklah sebagai peninjau keamanan. Periksa proyek ini terhadap OWASP Top 10,
terutama: kontrol akses (apakah pengguna bisa melihat data orang lain), secret di kode,
SQL injection, XSS, CSRF, dan konfigurasi production.

Untuk setiap temuan, sebutkan: file dan baris, kenapa berbahaya, cara saya mengujinya
sendiri, dan perbaikannya. Jangan ubah kode dulu. Berikan daftar temuan, urut dari
yang paling berbahaya.

Kalimat “jangan ubah kode dulu” penting. Kamu ingin melihat daftar masalahnya terlebih dahulu, lalu memperbaikinya satu per satu dengan prinsip yang sama seperti biasa: satu perbaikan sekali jalan, diuji, lalu di-commit.

Kapan perlu bantuan orang

Checklist ini menutup celah yang paling sering terjadi, tapi bukan pengganti pemeriksaan oleh orang yang paham keamanan. Minta bantuan developer atau auditor keamanan sebelum aplikasimu:

• menyimpan data pribadi yang sensitif (KTP, kesehatan, keuangan),
• menerima pembayaran secara langsung,
• dipakai oleh banyak orang atau oleh sebuah organisasi.

Kesimpulan

Aplikasi buatan AI bisa tampak sempurna dan tetap membiarkan siapa pun membaca data semua penggunanya. Sebelum aplikasimu dipakai orang lain, periksa delapan area ini: secret, hak akses, database, input, session, dependensi, konfigurasi deploy, dan penyalahgunaan biaya. Uji sendiri, jangan hanya percaya pada jawaban AI.

Ini bagian dari Level 3 jalur Vibe Coding. Untuk memahami setiap celah lebih dalam, ikuti jalur Security, dimulai dari OWASP Top 10 untuk pemula.