Senarai Semak Keselamatan untuk Aplikasi Dibina AI: Apa yang Perlu Diperiksa Sebelum Pelancaran

Sebelum orang sebenar menggunakan aplikasi yang anda bina dengan AI, semak tujuh perkara: setiap halaman dan API menyemak siapa pengguna dan apa yang dibenarkan untuknya; kunci rahsia berada di pelayan, tidak sekali-kali dalam pelayar atau sembang; semua input disahkan di pelayan; setiap pengguna hanya boleh mengakses rekodnya sendiri; log masuk dan titik akhir yang berkos dihadkan kadarnya; kebergantungan dikemas kini; dan anda boleh memulihkan data jika berlaku sesuatu yang salah. Senarai semak di bawah menukarkan setiap satu daripada itu kepada ujian khusus yang boleh anda jalankan tanpa membaca kod.

Pembina aplikasi AI pandai menjadikan ciri berfungsi. Mereka tidak secara automatik berhati-hati, kerana “berhati-hati” jarang ada dalam arahan. Kebanyakan masalah di bawah datang daripada perkara yang tiada siapa minta, jadi biasanya penyelesaiannya ialah dengan memintanya.

Cara menggunakan senarai semak ini

Kerjakan mengikut urutan, dan untuk setiap item lakukan dua perkara: minta AI untuk memastikan ia dikendalikan, dan uji sendiri. AI boleh menulis semakan kebenaran; hanya ujian yang memberitahu anda ia berfungsi. Item ditandakan seperti berikut:

• Wajib — lakukan ini sebelum orang lain menggunakan aplikasi.
• Sepatutnya — lakukan ini sebelum anda mempunyai pengguna sebenar atau data sebenar.
• Kemudian — berbaloi dilakukan apabila aplikasi berkembang.

Jika anda hanya ada satu jam, lakukan setiap item Wajib.

1. Pengesahan: siapa ini?

Pengesahan bermaksud mengesahkan siapa seseorang — biasanya log masuk. Lihat apa itu pengesahan untuk asas dan cara menambah log masuk pada aplikasi anda untuk pilihan.

• Wajib: Setiap halaman yang memaparkan data peribadi memerlukan log masuk. Ujian: log keluar, kemudian tampal URL halaman peribadi terus ke dalam pelayar.
• Wajib: Setiap titik akhir API di sebalik halaman tersebut juga memerlukan log masuk — bukan hanya halaman. Ujian: log keluar, buka tab rangkaian pelayar, dan ulang permintaan yang dibuat aplikasi semasa anda log masuk.
• Wajib: Kata laluan disimpan dalam bentuk hash dengan algoritma hashing kata laluan yang perlahan, tidak sekali-kali dalam teks biasa. Panduan penyimpanan kata laluan OWASP mengesyorkan Argon2id dahulu, dengan scrypt, bcrypt atau PBKDF2 sebagai alternatif. Tanya: “Bagaimana kata laluan disimpan?”
• Sepatutnya: Pautan tetapan semula kata laluan tamat tempoh dan hanya berfungsi sekali.
• Sepatutnya: Kuki sesi ditandakan Secure, HttpOnly dan SameSite, dan log keluar menamatkan sesi di pelayan.
• Kemudian: Tawarkan pengesahan dua faktor, atau log masuk melalui pembekal yang menyediakannya.

Semak setiap laluan API dan halaman yang mengembalikan data pengguna. Setiap satunya mesti menolak permintaan daripada pengguna yang tidak log masuk, di pelayan, bukan sekadar dalam kod halaman. Senaraikan laluan yang anda semak.

2. Kebenaran: apa yang mereka dibenarkan lakukan?

Kebenaran ialah langkah selepas log masuk: memutuskan apa yang boleh dilihat dan diubah oleh pengguna tertentu ini. Di sinilah aplikasi dibina AI paling kerap mempunyai lubang yang serius, kerana aplikasi itu kelihatan betul — papan pemuka setiap pengguna hanya menunjukkan data mereka sendiri — sedangkan pelayan akan menyerahkan data sesiapa sahaja jika diminta secara langsung.

• Wajib: Setiap bacaan, kemas kini dan pemadaman menyemak bahawa rekod itu milik pengguna semasa (atau pasukan mereka), di pelayan.
• Wajib: Uji: buat dua akaun, A dan B. Sebagai A, buka salah satu rekod A dan catat ID dalam URL atau permintaan rangkaian. Log masuk sebagai B dan minta ID yang sama. B mesti mendapat ralat, bukan data A.
• Wajib: Halaman pentadbir dan titik akhir API pentadbir menyemak peranan pengguna di pelayan. Menyembunyikan pautan pentadbir bukanlah perlindungan.
• Wajib: Pengguna tidak boleh menukar peranan, harga, baki atau medan pemilik mereka sendiri dengan mengubah permintaan. Uji: dalam tab rangkaian, lihat apa yang dihantar oleh kemas kini profil. Jika ia termasuk medan seperti role atau isAdmin, minta AI mengabaikannya daripada klien.
• Sepatutnya: ID dalam URL sukar diteka (ID rawak dan bukannya 1, 2, 3). Ini bukan pengganti semakan kebenaran, tetapi ia mengehadkan kerosakan apabila satu semakan tiada.

Untuk setiap titik akhir yang membaca atau mengubah rekod, semak di pelayan bahawa pengguna yang log masuk memilikinya atau dibenarkan mengaksesnya. Kembalikan 404 jika tidak. Kemudian tunjukkan kepada saya bagaimana anda akan mengujinya dengan dua akaun.

3. Akses peringkat baris dalam pangkalan data

“Akses peringkat baris” bermaksud setiap baris jadual (satu tempahan, satu invois) hanya kelihatan kepada pengguna yang memilikinya. Ada dua cara biasa untuk menguatkuasakannya:

Kedua-duanya boleh dilakukan dengan baik. Yang penting ialah:

• Wajib: Jika pelayar bercakap terus dengan pangkalan data (sesetengah produk pangkalan data dihoskan membenarkannya), peraturan peringkat baris diaktifkan untuk setiap jadual. Tanpanya, sesiapa sahaja yang mempunyai kunci awam boleh membaca keseluruhan jadual.
• Wajib: Pertanyaan menapis mengikut pengguna atau pasukan semasa, bukan mengikut ID yang dihantar oleh pelayar.
• Sepatutnya: Data kongsi (projek pasukan) mempunyai peraturan yang jelas tentang siapa dalam pasukan, dikuatkuasakan di satu tempat.

4. Rahsia dan kunci API

Kunci API ialah kata laluan untuk satu perkhidmatan. Stripe, e-mel dan pembekal AI semuanya menggunakannya. Untuk latar belakang, lihat apa itu pembolehubah persekitaran dan rahsia.

• Wajib: Kunci disimpan dalam pembolehubah persekitaran atau rahsia projek, tidak sekali-kali ditulis dalam kod.
• Wajib: Kunci yang boleh membelanjakan wang atau membaca data peribadi hanya digunakan di pelayan. Ujian: buka laman langsung anda, lihat sumber halaman dan fail JavaScript dalam devtools, dan cari permulaan kunci anda (contohnya sk_). Ia tidak boleh muncul.
• Wajib: Kunci tidak pernah ditampal ke dalam sembang, repositori awam atau tangkapan skrin. Jika pernah, jana semula (rotate) kunci itu di pembekal (cipta yang baharu, padam yang lama).
• Sepatutnya: Gunakan kunci terhad atau berskop jika pembekal menyediakannya. Stripe, contohnya, mengesyorkan kunci terhad yang hanya mempunyai kebenaran yang diperlukan oleh integrasi anda.
• Sepatutnya: Kunci ujian dan kunci langsung diasingkan, dan aplikasi langsung hanya menggunakan kunci langsung apabila anda sudah bersedia.

Sesetengah kunci memang direka untuk umum — kunci boleh terbit Stripe (pk_…) atau kunci peta yang dihadkan kepada domain anda. Peraturan ini berkaitan dengan kunci yang memberi kuasa, bukan setiap rentetan yang kelihatan seperti kunci.

5. Pengesahan input

Apa sahaja yang dihantar pengguna — medan borang, muat naik fail, parameter URL — boleh jadi apa sahaja, bukan hanya apa yang dibenarkan oleh borang anda.

• Wajib: Pengesahan berlaku di pelayan, bukan hanya dalam pelayar. Semakan pelayar adalah untuk kemudahan; sesiapa sahaja boleh melangkaunya.
• Wajib: Pertanyaan pangkalan data menggunakan parameter, bukan teks yang dicantum daripada input pengguna (ini menghalang suntikan SQL). Minta AI mengesahkannya.
• Wajib: Teks yang dimasukkan pengguna dipaparkan sebagai teks, bukan dijalankan sebagai HTML. Ujian: masukkan <b>hello</b> sebagai nama anda. Anda sepatutnya melihat tag, bukan teks tebal.
• Sepatutnya: Muat naik fail menyemak jenis dan saiz, dan fail yang dimuat naik tidak dihidangkan dari domain utama aplikasi anda sebagai halaman yang boleh dijalankan.
• Sepatutnya: Ralat yang dipaparkan kepada pengguna adalah ringkas (“Ada sesuatu yang tidak kena”); butiran ralat terperinci hanya pergi ke log pelayan.
• Sepatutnya: Webhook daripada perkhidmatan seperti Stripe mengesahkan tandatangan pembekal sebelum bertindak. Lihat apa itu webhook.

Tambahkan pengesahan di pelayan kepada setiap borang dan titik akhir API: medan wajib, panjang, format dan nilai yang dibenarkan. Tolak apa-apa yang lain dengan mesej yang jelas. Jangan tunjukkan butiran ralat dalaman kepada pengguna.

6. Had kadar dan penyalahgunaan

Had kadar menghadkan berapa banyak permintaan yang boleh dibuat seseorang dalam tempoh tertentu. Tanpanya, sesiapa sahaja boleh meneka kata laluan sepanjang hari, membanjiri borang pendaftaran anda, atau menjana bil yang besar pada API berbayar anda.

• Wajib: Log masuk, pendaftaran dan tetapan semula kata laluan dihadkan kadarnya mengikut alamat IP dan mengikut akaun.
• Wajib: Apa sahaja yang menelan kos setiap panggilan — permintaan model AI, SMS, e-mel — mempunyai had setiap pengguna dan memerlukan log masuk.
• Sepatutnya: Borang awam (hubungi, senarai tunggu) mempunyai perlindungan spam: had kadar, medan sembunyi (honeypot), atau CAPTCHA.
• Sepatutnya: Tetapkan had perbelanjaan atau amaran di pembekal berbayar anda, supaya pepijat atau penyerang tidak boleh menghasilkan bil tanpa had.

7. Kebergantungan

Aplikasi dibina daripada pakej sumber terbuka, dan pakej kadang-kadang mempunyai kelemahan yang diketahui.

• Sepatutnya: Minta AI menyemak kelemahan yang diketahui (untuk projek JavaScript, npm audit atau yang setara bagi pengurus pakej anda) dan kemas kini yang terjejas.
• Sepatutnya: Buang pakej yang tidak lagi digunakan oleh aplikasi.
• Sepatutnya: Berhati-hati dengan pakej yang mempunyai pengguna yang sangat sedikit atau nama yang kelihatan seperti salah taip bagi pakej popular.
• Kemudian: Semak semula setiap sebulan atau dua bulan, atau aktifkan amaran automatik jika kod anda berada di GitHub.

8. Sandaran dan pemulihan

Keselamatan termasuk keupayaan untuk pulih daripada kesilapan — kesilapan anda, kesilapan AI, atau kesilapan penyerang.

• Wajib: Ketahui di mana data anda disimpan dan sama ada ia disandarkan. Jangan andaikan; semak dokumentasi hos anda.
• Sepatutnya: Simpan eksport berkala anda sendiri bagi data penting (contohnya ciri eksport CSV atau dump pangkalan data), disimpan di tempat yang berasingan.
• Sepatutnya: Simpan kod anda dalam kawalan versi, supaya mana-mana versi boleh dipulihkan.
• Sepatutnya: Tindakan memusnahkan (padam akaun, padam projek) meminta pengesahan, dan pertimbangkan “pemadaman lembut” yang boleh dibatalkan untuk tempoh tertentu.
• Kemudian: Benar-benar uji pemulihan sekali. Sandaran yang tidak pernah dipulihkan ialah harapan, bukan pelan.

9. Sebelum pelancaran

• Wajib: Laman langsung menggunakan HTTPS di mana-mana.
• Wajib: Data sampel, akaun ujian dan halaman nyahpepijat daripada pembangunan dibuang.
• Sepatutnya: Dasar privasi menyatakan data yang anda kumpulkan dan sebabnya — diperlukan di banyak tempat jika anda mengumpulkan data peribadi. Jangan dakwa pensijilan (SOC 2, HIPAA) yang anda tidak miliki.
• Sepatutnya: Anda mempunyai cara untuk dihubungi tentang isu keselamatan, dan anda tahu cara menjana semula setiap kunci dengan cepat.

Untuk semakan pra-pelancaran yang lebih luas di luar keselamatan, lihat cara membawa prototaip AI ke pengeluaran.

Bila perlu mendapatkan semakan profesional

Senarai semak menangkap kesilapan biasa; ia tidak menggantikan pakar. Pertimbangkan untuk membayar semakan jika anda memproses nombor kad secara sendiri dan bukannya melalui pembayaran dihoskan, menyimpan data kesihatan, kewangan atau kanak-kanak, menjual kepada syarikat yang meminta soal selidik keselamatan, atau akan terjejas teruk jika berlaku kebocoran. Kod yang boleh dieksport memudahkan semakan itu.

Keselamatan semasa membina di Mythex

Mythex tidak mempunyai panel imbasan keselamatan, jadi senarai semak di atas ialah proses yang perlu diikuti. Beberapa perkara yang membantu:

• Rahsia projek. Simpan kunci di bawah tetapan projek → Rahsia, atau melalui kad rahsia yang dipaparkan ejen dalam sembang, supaya ia kekal di luar kod dan mesej anda. Selepas menukar rahsia untuk aplikasi langsung, terbitkan semula.
• Mod Pelan dan Tanya. Minta ejen menyemak kebenaran tanpa menyunting: “Dalam mod Tanya, senaraikan setiap laluan API dan semakan kebenaran yang dibuatnya.”
• /test meminta ejen mengklik melalui pratonton anda sebagai pengguna — berguna untuk ujian dua akaun dalam seksyen 2.
• Pusat semakan membolehkan anda mengundur perubahan yang merosakkan sesuatu.

Lihat Keselamatan untuk aplikasi yang anda bina dan Pembolehubah persekitaran dan rahsia dalam dokumentasi. Jika anda seterusnya menambah akaun pengguna, baca cara menambah log masuk pada aplikasi anda.

Soalan lazim