Kunci API rahsia dalam aplikasi Expo: apa perlu dilindungi

Pemboleh ubah persekitaran tidak semestinya rahsia

Dalam aplikasi Expo, pemboleh ubah yang berawalan EXPO_PUBLIC_ ditujukan untuk kod aplikasi. Ia tidak boleh mengandungi rahsia pelayan. Expo menjelaskan bahawa nilai ini dimasukkan ke dalam JavaScript yang telah dikompil dan boleh dibaca oleh pengguna aplikasi. Jadi, memindahkan kunci ke dalam fail .env tidak cukup untuk melindunginya. Sumber: pemboleh ubah persekitaran Expo.

Sebelum meminta AI untuk "menyambungkan API", kelaskan dahulu apa yang anda serahkan kepadanya: alamat perkhidmatan, kunci yang memang direka untuk awam, atau kunci yang membenarkan tindakan berkeistimewaan. Pengelasan ini menentukan di mana kod perlu dijalankan.

Jadual berikut ialah grid reka bentuk, bukan audit aplikasi anda.

Elemen	Di mana diletakkan	Semakan yang perlu dibuat
Alamat awam backend	Konfigurasi aplikasi	Ia menghala ke persekitaran yang betul.
Kunci Supabase publishable, atau kunci anon lama	Aplikasi, jika kebenaran dikonfigurasi dengan betul	Peraturan data benar-benar menyekat akses ke akaun pengguna lain.
Kunci Supabase secret atau service_role	Pelayan sahaja	Ia tidak muncul dalam bundle mudah alih, mahupun dalam log yang boleh diakses oleh klien.
Kunci rahsia penyedia AI	Pelayan sahaja	Aplikasi memanggil pelayan anda, yang menyemak pengguna dan had sebelum memanggil penyedia.

Supabase membezakan kunci yang direka untuk klien daripada kunci rahsia untuk persekitaran yang dipercayai. Kunci awam mengenal pasti projek; ia tidak menggantikan kebenaran ke atas data. Sumber: kunci API Supabase.

Contoh: aplikasi rekaan untuk catatan bacaan

Bayangkan sebuah aplikasi di mana Lea dan Sami merekodkan buku dan nota peribadi mereka. Contoh ini untuk menyediakan ujian; ia tidak menggambarkan keputusan yang diperoleh pada aplikasi Devoria.

Aliran biasa nampak betul: Lea log masuk dan melihat notanya. Tetapi itu belum menjawab soalan penting: adakah pelayan menolak permintaan Lea yang menyasarkan nota Sami?

Penapis dalam antara muka, seperti "paparkan nota pengguna yang log masuk", menambah baik paparan. Kebenaran juga perlu dikuatkuasakan di bahagian data. Dalam Supabase, peraturan Row Level Security membolehkan anda mengehadkan baris yang boleh diakses mengikut sesi. Supabase mengesyorkan pengaktifannya untuk jadual yang didedahkan oleh API dan menerangkan polisi baca dan tulis. Sumber: Row Level Security.

Untuk projek ujian anda sendiri, kaitkan setiap nota dengan pemiliknya dan tentukan secara berasingan siapa boleh membaca, mencipta, mengubah dan memadamnya. Semak juga fail: melindungi satu baris pangkalan data tidak membuktikan bahawa sesuatu imej itu peribadi.

Senarai ujian untuk dijalankan dengan dua akaun ujian

Sediakan dua akaun yang anda kawal, satu buku berbeza dalam setiap akaun dan satu nota kecil yang mudah dikenali. Gunakan data rekaan dalam persekitaran ujian yang dibenarkan.

1. Baca nota sendiri. Akaun A menemui nota A.
2. Baca nota B dari A. Permintaan tidak mendedahkan kandungan peribadinya.
3. Ubah nota B dari A. Pelayan menolak; nota B kekal tidak berubah.
4. Cipta atas nama B dari A. Pelayan menolak atribusi ini.
5. Baca tanpa sesi. Tiada kandungan peribadi dikembalikan.
6. Buka fail peribadi B dari A. Fail tidak boleh diakses.

Catat keputusan sebenar, versi yang diuji dan ralat jika ada. "Peraturan sudah diaktifkan" bukan keputusan ujian. Grid ujian yang tersedia dalam sumber boleh dijadikan asas untuk menyimpan bukti ini.

Hantar panggilan berbayar melalui pelayan anda

Untuk fungsi yang meringkaskan buku dengan API AI, alirannya boleh jadi: aplikasi → pelayan anda → penyedia → pelayan anda → aplikasi. Kunci rahsia kekal di pelayan. Seni bina ini sahaja tidak mencukupi: akses ke pelayan juga perlu dikawal.

Dalam contoh rekaan ini, pelayan antara lain perlu menyemak sesi, memastikan buku itu milik orang tersebut, mengehadkan permintaan berulang dan memulangkan ralat yang mudah difahami jika penyedia tidak bertindak balas. Klien tidak boleh memutuskan sendiri bahawa seseorang pengguna mendapat akses berbayar.

Sediakan empat ujian: pengguna tidak log masuk, buku milik akaun lain, had dicapai dan penyedia tidak tersedia. Ujian terakhir membolehkan anda menyemak bahawa aplikasi keluar daripada keadaan memuatkan tanpa kehilangan input pengguna.

Apa yang boleh anda minta daripada pembantu kod anda

Berikut arahan semakan untuk disesuaikan dengan repositori anda, tanpa menampal nilai rahsia anda:

Senaraikan pemboleh ubah yang digunakan oleh kod mudah alih dan oleh pelayan, dengan memaparkan namanya sahaja. Kenal pasti panggilan berkeistimewaan yang ada di bahagian klien. Untuk data peribadi, terangkan kawalan baca dan tulis, kemudian cadangkan senarai ujian dengan dua akaun ujian. Jangan lakukan sebarang putaran kunci atau perubahan production tanpa pengesahan.

Baca jawapannya bersama kod yang berkaitan. Pembantu boleh mengesan ketidakselarasan; jawapannya tidak menggantikan pelaksanaan ujian. Panduan membina aplikasi dengan Claude Code menerangkan cara memecahkan kerja ini.

Sebelum meneruskan aplikasi anda

Anda perlu boleh menerangkan tiga perkara dengan mudah: nilai mana yang awam, operasi mana yang melalui pelayan dan ujian mana yang menunjukkan satu akaun tidak dapat melihat data akaun lain. Jika salah satu perkara ini masih kabur, jelaskan dahulu sebelum menambah fungsi.

Halaman membina aplikasi iPhone meletakkan langkah ini dalam keseluruhan projek. Untuk maju mengikut urutan, iOS Kit menawarkan laluan empat langkah dan kod permulaan yang sudah merangkumi akaun dan AI. Jika anda tidak pasti dari langkah mana untuk bermula semula, diagnostik percuma menyusun semula projek anda dan menghantar senarai semak anti-penolakan Apple saya kepada anda.

Soalan lazim

Di mana hendak meletakkan kunci API rahsia dalam aplikasi Expo?

Di pelayan anda, jangan sekali-kali dalam aplikasi. Kunci Supabase secret atau service_role, sama seperti kunci rahsia penyedia AI, mesti kekal di bahagian pelayan sahaja. Aplikasi memanggil pelayan anda, yang menyemak pengguna dan had sebelum memanggil penyedia. Pastikan tiada kunci ini muncul dalam bundle mudah alih atau dalam log yang boleh diakses oleh klien.

Adakah fail .env melindungi kunci API saya dalam Expo?

Tidak dengan sendirinya. Pemboleh ubah yang berawalan EXPO_PUBLIC_ ditujukan untuk kod aplikasi dan tidak boleh mengandungi rahsia pelayan. Expo menjelaskan bahawa nilai ini dimasukkan ke dalam JavaScript yang telah dikompil dan boleh dibaca oleh pengguna aplikasi. Jadi, memindahkan kunci ke dalam fail .env tidak cukup untuk melindunginya.

Apakah perbezaan antara kunci API awam dan kunci rahsia?

Kunci awam memang direka untuk dimuatkan dalam aplikasi: ia mengenal pasti projek, tetapi tidak menggantikan kebenaran ke atas data. Kunci rahsia membenarkan tindakan berkeistimewaan dan dikhaskan untuk persekitaran yang dipercayai. Di Supabase, kunci publishable, atau kunci anon lama, boleh kekal dalam aplikasi jika kebenaran dikonfigurasi dengan betul. Kunci secret dan service_role kekal di pelayan.

Bagaimana memanggil API AI dari aplikasi Expo tanpa mendedahkan kunci?

Hantar panggilan melalui pelayan anda: aplikasi memanggil pelayan, yang memanggil penyedia lalu memulangkan jawapan kepada aplikasi. Kunci rahsia kekal di pelayan. Pelayan juga perlu menyemak sesi, mengehadkan permintaan berulang dan memulangkan ralat yang mudah difahami jika penyedia tidak bertindak balas. Klien tidak boleh memutuskan sendiri bahawa seseorang pengguna mendapat akses berbayar.

Bagaimana menyemak bahawa setiap pengguna hanya melihat data mereka sendiri?

Sediakan dua akaun ujian yang anda kawal, dengan satu nota yang mudah dikenali dalam setiap akaun. Dari akaun A, cuba baca, ubah dan cipta atas nama akaun B, kemudian buka fail peribadi B. Buat juga ujian tanpa sesi: setiap permintaan mesti ditolak atau tidak mendedahkan apa-apa. Catat keputusan sebenar, kerana "peraturan sudah diaktifkan" bukan keputusan ujian.

Bagaimana meminta AI menyemak kunci aplikasi saya?

Minta ia menyenaraikan pemboleh ubah kod mudah alih dan pelayan, dengan memaparkan namanya sahaja, tanpa menampal nilai rahsia anda. Minta juga ia mengenal pasti panggilan berkeistimewaan yang ada di bahagian klien dan mencadangkan senarai ujian dengan dua akaun ujian. Larang sebarang putaran kunci atau perubahan production tanpa pengesahan. Jawapannya tidak menggantikan pelaksanaan ujian.