Checklist Keamanan untuk Aplikasi Buatan AI: Apa yang Harus Dicek Sebelum Peluncuran

Sebelum orang sungguhan memakai aplikasi yang Anda bangun dengan AI, periksa tujuh hal: setiap halaman dan API memeriksa siapa pengguna dan apa yang boleh mereka lakukan; kunci rahasia tinggal di server, tidak pernah di browser atau chat; semua input divalidasi di server; setiap pengguna hanya bisa mengakses datanya sendiri; login dan endpoint yang mahal dibatasi rate-nya; dependensi selalu terbarui; dan Anda bisa memulihkan data jika terjadi kesalahan. Checklist di bawah menerjemahkan masing-masing menjadi tes spesifik yang bisa Anda jalankan tanpa membaca kode.

Pembuat aplikasi AI bagus dalam membuat fitur berfungsi. Mereka tidak otomatis berhati-hati, karena "berhati-hati" jarang ada di prompt. Sebagian besar masalah di bawah berasal dari hal-hal yang tidak diminta siapa pun, jadi biasanya perbaikannya adalah dengan memintanya.

Cara memakai checklist ini

Kerjakan secara berurutan, dan untuk setiap item lakukan dua hal: minta AI untuk memastikan itu ditangani, dan uji sendiri. AI bisa menulis pemeriksaan izin; hanya pengujian yang memberi tahu Anda bahwa itu berfungsi. Item ditandai sebagai:

• Wajib — lakukan ini sebelum orang lain memakai aplikasi.
• Sebaiknya — lakukan ini sebelum Anda punya pengguna atau data sungguhan.
• Nanti — layak dilakukan seiring aplikasi berkembang.

Jika Anda hanya punya satu jam, kerjakan semua item Wajib.

1. Autentikasi: ini siapa?

Autentikasi berarti memastikan siapa seseorang — biasanya lewat login. Lihat apa itu autentikasi untuk dasarnya dan cara menambahkan login ke aplikasi Anda untuk pilihan-pilihannya.

• Wajib: Setiap halaman yang menampilkan data pribadi membutuhkan login. Tes: keluar, lalu tempel URL halaman pribadi langsung ke browser.
• Wajib: Setiap endpoint API di balik halaman tersebut juga membutuhkan login — bukan hanya halamannya. Tes: keluar, buka tab network di browser, lalu ulangi permintaan yang dibuat aplikasi saat Anda masih login.
• Wajib: Kata sandi disimpan dalam bentuk hash dengan algoritma hashing kata sandi yang lambat, tidak pernah sebagai teks biasa. Panduan penyimpanan kata sandi dari OWASP merekomendasikan Argon2id sebagai pilihan utama, dengan scrypt, bcrypt, atau PBKDF2 sebagai alternatif. Tanyakan: "Bagaimana kata sandi disimpan?"
• Sebaiknya: Tautan reset kata sandi kedaluwarsa dan hanya bisa dipakai sekali.
• Sebaiknya: Cookie sesi diberi tanda Secure, HttpOnly, dan SameSite, dan logout mengakhiri sesi di server.
• Nanti: Tawarkan autentikasi dua faktor, atau login melalui penyedia yang memilikinya.

Periksa setiap rute API dan halaman yang mengembalikan data pengguna. Setiap rute harus menolak permintaan dari pengguna yang belum login, di server, bukan hanya di kode halaman. Daftar rute yang sudah Anda periksa.

2. Otorisasi: apa yang boleh mereka lakukan?

Otorisasi adalah langkah setelah login: memutuskan apa yang boleh dilihat dan diubah oleh pengguna tertentu ini. Di sinilah aplikasi buatan AI paling sering punya lubang serius, karena aplikasinya tampak benar — dashboard setiap pengguna hanya menampilkan datanya sendiri — sementara server akan dengan senang hati menyerahkan data siapa pun jika diminta langsung.

• Wajib: Setiap operasi baca, ubah, dan hapus memeriksa bahwa data tersebut milik pengguna saat ini (atau timnya), di server.
• Wajib: Uji: buat dua akun, A dan B. Sebagai A, buka salah satu data milik A dan catat ID-nya di URL atau permintaan network. Login sebagai B dan minta ID yang sama. B harus mendapat error, bukan data milik A.
• Wajib: Halaman admin dan endpoint API admin memeriksa peran pengguna di server. Menyembunyikan tautan admin bukanlah perlindungan.
• Wajib: Pengguna tidak bisa mengubah peran, harga, saldo, atau field pemilik mereka sendiri dengan mengedit permintaan. Tes: di tab network, lihat apa yang dikirim saat memperbarui profil. Jika ada field seperti role atau isAdmin, minta AI untuk mengabaikannya dari klien.
• Sebaiknya: ID di URL sulit ditebak (ID acak, bukan 1, 2, 3). Ini bukan pengganti pemeriksaan izin, tetapi membatasi kerusakan jika ada yang terlewat.

Untuk setiap endpoint yang membaca atau mengubah data, periksa di server bahwa pengguna yang login memilikinya atau berhak mengaksesnya. Kembalikan 404 jika tidak. Lalu tunjukkan cara Anda menguji ini dengan dua akun.

3. Akses per baris di database

"Akses per baris" berarti setiap baris di tabel (satu booking, satu faktur) hanya terlihat oleh pengguna yang memilikinya. Ada dua cara umum untuk menegakkannya:

Keduanya bisa dilakukan dengan baik. Yang penting:

• Wajib: Jika browser berkomunikasi langsung dengan database (beberapa produk database hosted mengizinkannya), aturan akses per baris diaktifkan untuk setiap tabel. Tanpanya, siapa pun yang memegang kunci publik bisa membaca seluruh tabel.
• Wajib: Query memfilter berdasarkan pengguna atau tim saat ini, bukan berdasarkan ID yang dikirim browser.
• Sebaiknya: Data bersama (proyek tim) punya aturan yang jelas tentang siapa yang ada di tim, yang ditegakkan di satu tempat.

4. Secret dan kunci API

Kunci API adalah kata sandi untuk sebuah layanan. Stripe, email, dan penyedia AI semuanya memakainya. Untuk latar belakangnya, lihat apa itu environment variable dan secret.

• Wajib: Kunci disimpan di environment variable atau secret milik proyek, tidak pernah ditulis di dalam kode.
• Wajib: Kunci yang bisa menghabiskan uang atau membaca data pribadi hanya dipakai di server. Tes: buka situs live Anda, lihat source halaman dan file JavaScript di devtools, lalu cari awal kunci Anda (misalnya sk_). Teks itu tidak boleh muncul.
• Wajib: Kunci tidak pernah ditempel di chat, repositori publik, atau screenshot. Jika pernah, rotasi di penyedia (buat yang baru, hapus yang lama).
• Sebaiknya: Gunakan kunci terbatas atau berlingkup jika penyedia menyediakannya. Stripe, misalnya, merekomendasikan kunci terbatas yang hanya memiliki izin yang dibutuhkan integrasi Anda.
• Sebaiknya: Kunci test dan live dipisahkan, dan aplikasi live hanya memakai kunci live saat Anda siap.

Beberapa kunci memang dirancang untuk publik — kunci yang dapat dipublikasikan dari Stripe (pk_…) atau kunci peta yang dibatasi ke domain Anda. Aturannya berlaku untuk kunci yang memberi kekuatan, bukan untuk setiap string yang kebetulan terlihat seperti kunci.

5. Validasi input

Apa pun yang dikirim pengguna — field formulir, unggahan file, parameter URL — bisa berisi apa saja, tidak hanya yang diizinkan formulir Anda.

• Wajib: Validasi dilakukan di server, tidak hanya di browser. Pemeriksaan di browser hanya untuk kenyamanan; siapa pun bisa melewatinya.
• Wajib: Query database memakai parameter, bukan teks yang disambung dari input pengguna (ini mencegah SQL injection). Minta AI untuk memastikannya.
• Wajib: Teks yang dimasukkan pengguna ditampilkan sebagai teks, bukan dijalankan sebagai HTML. Tes: masukkan <b>halo</b> sebagai nama Anda. Anda seharusnya melihat tag-nya, bukan teks tebal.
• Sebaiknya: Unggahan file memeriksa tipe dan ukuran, dan file yang diunggah tidak disajikan dari domain utama aplikasi Anda sebagai halaman yang bisa dijalankan.
• Sebaiknya: Error yang ditampilkan ke pengguna bersifat sederhana ("Terjadi kesalahan"); detail error hanya masuk ke log server.
• Sebaiknya: Webhook dari layanan seperti Stripe memverifikasi tanda tangan penyedia sebelum bertindak. Lihat apa itu webhook.

Tambahkan validasi sisi server ke setiap formulir dan endpoint API: field wajib, panjang, format, dan nilai yang diizinkan. Tolak yang lain dengan pesan yang jelas. Jangan tampilkan detail error internal kepada pengguna.

6. Rate limit dan penyalahgunaan

Rate limit membatasi berapa banyak permintaan yang bisa dibuat seseorang dalam satu periode. Tanpanya, siapa pun bisa menebak kata sandi sepanjang hari, membanjiri formulir pendaftaran Anda, atau menaikkan tagihan API berbayar Anda.

• Wajib: Login, pendaftaran, dan reset kata sandi dibatasi rate-nya per alamat IP dan per akun.
• Wajib: Apa pun yang menghabiskan uang Anda per panggilan — permintaan model AI, SMS, email — memiliki batas per pengguna dan membutuhkan login.
• Sebaiknya: Formulir publik (kontak, daftar tunggu) memiliki perlindungan spam: rate limit, kolom honeypot yang tersembunyi, atau CAPTCHA.
• Sebaiknya: Atur batas pengeluaran atau peringatan di penyedia berbayar Anda, agar bug atau penyerang tidak bisa menghasilkan tagihan tanpa batas.

7. Dependensi

Aplikasi dibangun dari paket open-source, dan paket kadang punya kerentanan yang diketahui.

• Sebaiknya: Minta AI untuk memeriksa kerentanan yang diketahui (untuk proyek JavaScript, npm audit atau padanannya untuk package manager Anda) dan memperbarui yang terdampak.
• Sebaiknya: Hapus paket yang tidak lagi dipakai aplikasi.
• Sebaiknya: Waspadai paket dengan pengguna yang sangat sedikit atau nama yang terlihat seperti salah ketik dari paket populer.
• Nanti: Periksa ulang setiap satu atau dua bulan, atau aktifkan peringatan otomatis jika kode Anda ada di GitHub.

8. Backup dan pemulihan

Keamanan juga mencakup kemampuan untuk pulih dari kesalahan — milik Anda, milik AI, atau milik penyerang.

• Wajib: Ketahui di mana data Anda disimpan dan apakah sudah dibackup. Jangan berasumsi; cek dokumentasi host Anda.
• Sebaiknya: Simpan ekspor berkala Anda sendiri untuk data penting (misalnya fitur ekspor CSV atau dump database), disimpan di tempat terpisah.
• Sebaiknya: Simpan kode Anda di version control, agar versi mana pun bisa dipulihkan.
• Sebaiknya: Tindakan destruktif (hapus akun, hapus proyek) meminta konfirmasi, dan pertimbangkan "soft delete" yang bisa dibatalkan selama beberapa waktu.
• Nanti: Benar-benar uji pemulihan sekali. Backup yang belum pernah dipulihkan adalah harapan, bukan rencana.

9. Sebelum peluncuran

• Wajib: Situs live memakai HTTPS di semua halaman.
• Wajib: Data contoh, akun uji, dan halaman debug dari pengembangan sudah dihapus.
• Sebaiknya: Kebijakan privasi menjelaskan data apa yang Anda kumpulkan dan untuk apa — di banyak tempat ini wajib jika Anda mengumpulkan data pribadi. Jangan mengklaim sertifikasi (SOC 2, HIPAA) yang belum Anda miliki.
• Sebaiknya: Ada cara bagi orang untuk menghubungi Anda soal masalah keamanan, dan Anda tahu cara merotasi setiap kunci dengan cepat.

Untuk pemeriksaan pra-peluncuran yang lebih luas di luar keamanan, lihat cara membawa prototipe AI ke produksi.

Kapan perlu tinjauan profesional

Checklist menangkap kesalahan umum; ia tidak menggantikan ahli. Pertimbangkan untuk membayar tinjauan jika Anda memproses nomor kartu sendiri alih-alih lewat checkout hosted, menyimpan data kesehatan, keuangan, atau data anak-anak, menjual ke perusahaan yang meminta kuesioner keamanan, atau akan sangat dirugikan jika terjadi kebocoran. Kode yang bisa diekspor membuat tinjauan itu jauh lebih mudah.

Keamanan saat membangun di Mythex

Mythex tidak punya panel pemindaian keamanan, jadi checklist di atas adalah proses yang perlu diikuti. Beberapa hal yang membantu:

• Secret proyek. Simpan kunci di pengaturan proyek → Secrets, atau lewat kartu secret yang ditampilkan agen di chat, agar tidak masuk ke kode atau pesan Anda. Setelah mengubah secret untuk aplikasi live, publikasikan lagi.
• Mode Plan dan Ask. Minta agen meninjau izin tanpa mengedit: "Dalam mode Ask, daftarkan setiap rute API dan pemeriksaan izin yang dilakukannya."
• /test meminta agen mengklik pratinjau Anda sebagai pengguna — berguna untuk tes dua akun di bagian 2.
• Checkpoint memungkinkan Anda membatalkan perubahan yang membuat sesuatu rusak.

Lihat Keamanan untuk aplikasi yang Anda bangun dan Environment variables dan secret di dokumentasi. Jika Anda menambahkan akun pengguna berikutnya, baca cara menambahkan login ke aplikasi Anda.

Pertanyaan