Menambahkan Database dan Login Tanpa Panik

Aplikasi pencatat pengeluaran kita menyimpan data di browser. Itu cukup untuk aplikasi pribadi, tapi ada batasnya: data di laptop tidak muncul di HP, data hilang kalau data browser dihapus, dan aplikasi tidak bisa dipakai bersama orang lain.

Untuk mengatasinya, kamu butuh database online dan login. Bagian ini sering membuat panik, dan memang di sinilah aplikasi buatan AI paling sering bocor. Tutorial ini membahas kapan kamu benar-benar membutuhkannya, pilihan yang tersedia, satu konsep yang paling menentukan keamanannya, dan cara mengujinya sendiri.

Apakah kamu benar-benar butuh database dan login?

Database dan login menambah biaya, kerumitan, dan tanggung jawab: begitu kamu menyimpan data orang lain, kamu wajib menjaganya. Jadi pastikan dulu kamu memang butuh.

Gambaran cara kerjanya

Ada dua pola yang umum:

Pola 1: lewat server milikmu. Browser mengirim permintaan ke server (API) milikmu. Server memeriksa siapa penggunanya dan apa haknya, lalu baru membaca atau menulis ke database. Database tidak pernah diakses langsung dari browser.

Pola 2: browser langsung ke database, dijaga aturan akses. Layanan backend-as-a-service seperti Supabase dan Firebase memungkinkan aplikasi di browser membaca dan menulis database secara langsung. Karena tidak ada server milikmu yang memeriksa, aturan akses di database adalah satu-satunya penjaga. Di Supabase, aturan ini disebut Row Level Security (RLS). Di Firebase, namanya Security Rules.

Banyak app builder dan tool vibe coding memakai pola 2 karena paling cepat. Pola ini aman, asalkan aturan aksesnya benar. Di sinilah kebocoran sering terjadi. Pada 2025, tercatat sekitar 10% dari 1.645 aplikasi yang dipindai seorang peneliti punya tabel yang bisa dibaca atau diubah tanpa login, karena aturan aksesnya tidak diatur dengan benar (CVE-2025-48757, dibahas di checklist keamanan aplikasi buatan AI).

Langkah 1: Rancang data dengan kolom pemilik

Setiap baris data milik pengguna harus menyimpan siapa pemiliknya. Untuk pencatat pengeluaran, tabelnya kira-kira seperti ini:

Kolom user_id adalah kuncinya. Tanpa kolom ini, database tidak bisa membedakan catatan Budi dan catatan Sari.

Langkah 2: Pakai sistem login yang sudah ada, jangan bikin sendiri

Login terlihat sederhana: form email dan password. Di baliknya ada hashing password, session, reset password lewat email, batas percobaan login, dan banyak detail lain yang mudah salah. Untuk aplikasi pertamamu, pakai sistem login dari layanan yang kamu gunakan (Supabase Auth, Firebase Authentication, atau fitur login bawaan app builder-mu). Pilihan yang umum: login dengan email dan password, magic link lewat email, atau login dengan akun Google.

Minta AI memakai fitur bawaan itu, bukan menulis sistem login sendiri.

Langkah 3: Aktifkan aturan akses di setiap tabel

Ini langkah paling penting. Aturannya sederhana untuk diucapkan: pengguna hanya boleh membaca dan mengubah baris yang user_id-nya sama dengan ID dia sendiri.

Di Supabase, aturan itu ditulis dalam SQL. Contoh berikut mengikuti pola di dokumentasi resmi Supabase:

-- 1. Nyalakan Row Level Security. Setelah ini, tanpa aturan, tidak ada data yang bisa diakses lewat API.
alter table pengeluaran enable row level security;

-- 2. Pengguna yang login hanya bisa membaca catatan miliknya
create policy "baca catatan sendiri"
on pengeluaran for select
to authenticated
using ( (select auth.uid()) = user_id );

-- 3. Pengguna hanya bisa menambah catatan atas namanya sendiri
create policy "tambah catatan sendiri"
on pengeluaran for insert
to authenticated
with check ( (select auth.uid()) = user_id );

-- 4. Pengguna hanya bisa menghapus catatan miliknya
create policy "hapus catatan sendiri"
on pengeluaran for delete
to authenticated
using ( (select auth.uid()) = user_id );

Kamu tidak harus menulisnya sendiri. Yang penting, kamu tahu bahwa aturan ini harus ada, dan bisa memeriksa bahwa AI membuatnya. Minta dengan jelas:

Aktifkan Row Level Security di SEMUA tabel. Buat aturan agar pengguna hanya bisa
membaca, menambah, mengubah, dan menghapus baris yang user_id-nya sama dengan ID
pengguna yang sedang login. Tampilkan SQL aturannya dan jelaskan setiap aturan.

Di Firebase, prinsipnya sama, hanya ditulis sebagai Security Rules. Apa pun layanannya, pastikan aturan akses tidak dalam mode terbuka untuk semua orang. Mode itu kadang dipakai saat percobaan, lalu lupa dimatikan.

Langkah 4: Bedakan dua jenis kunci

Layanan seperti Supabase memberimu dua jenis kunci API:

Kunci rahasia hanya boleh dipakai di server, disimpan sebagai environment variable. Kalau kunci rahasia sampai ke kode yang berjalan di browser, seluruh database terbuka untuk siapa saja yang membuka DevTools. Saat meninjau kode buatan AI, cari kata secret dan service_role, dan pastikan keduanya tidak ada di kode frontend.

Langkah 5: Uji sendiri bahwa data tidak bocor

Jangan percaya begitu saja bahwa aturannya sudah benar, walaupun AI bilang begitu. Buktikan:

1. Buat dua akun, misalnya Budi dan Sari.
2. Login sebagai Budi, lalu tambahkan beberapa catatan.
3. Logout, login sebagai Sari. Catatan Budi tidak boleh muncul.
4. Masih sebagai Sari, coba buka atau hapus catatan Budi lewat alamat atau ID-nya (kalau aplikasimu punya halaman detail). Harus ditolak.
5. Logout. Halaman yang berisi data harus mengarahkan ke login, atau tampil kosong.

Kalau satu saja uji gagal, jangan lanjut ke fitur lain. Perbaiki aturan aksesnya dulu. Masukkan kelima uji ini ke daftar regresimu (lihat satu fitur sekali jalan), dan ulangi setiap kali ada perubahan pada tabel atau aturan.

Langkah 6: Pecah pekerjaannya menjadi fitur kecil

Menambahkan database dan login sekaligus adalah permintaan besar. Pecah seperti ini, dan uji serta commit setiap langkah:

1. Buat tabel dengan kolom user_id, lalu aktifkan aturan akses.
2. Tambahkan halaman daftar dan masuk.
3. Simpan catatan baru ke database, lengkap dengan user_id.
4. Tampilkan catatan dari database, bukan dari browser.
5. Hapus catatan dari database.
6. Jalankan kelima uji dua akun di atas.

Jangan lupa: data orang lain adalah tanggung jawabmu

• Cadangkan data. Cek fitur backup di layanan yang kamu pakai, dan pahami cara memulihkannya.
• Simpan seperlunya. Jangan meminta atau menyimpan data pribadi yang tidak benar-benar dibutuhkan.
• Jelaskan ke pengguna data apa yang disimpan dan untuk apa, misalnya lewat halaman kebijakan privasi.
• Pantau biaya. Hampir semua layanan punya paket gratis dengan batas pemakaian. Pasang peringatan sebelum batasnya terlampaui.

Pertanyaan yang sering diajukan

Supabase atau Firebase?

Keduanya matang dan punya paket gratis. Supabase memakai PostgreSQL (database SQL), sehingga pengetahuannya bisa dipakai di banyak tempat lain. Firebase memakai database dokumen dan sangat menyatu dengan ekosistem Google. Pilih yang didukung tool-mu. Yang jauh lebih penting dari pilihannya adalah aturan aksesnya benar.

Apakah aplikasi dengan login otomatis aman?

Tidak. Login hanya memberi tahu siapa penggunanya. Aturan akseslah yang menentukan apa yang boleh ia lakukan. Aplikasi dengan login tapi tanpa aturan akses tetap membiarkan pengguna yang sudah login membaca data semua orang.

Bagaimana kalau aplikasiku butuh peran, misalnya admin?

Tambahkan informasi peran untuk setiap pengguna, lalu buat aturan akses yang membedakan perannya. Ini lebih rumit, jadi kerjakan sebagai fitur terpisah setelah aturan dasar “hanya data sendiri” sudah teruji. Untuk aplikasi yang menyimpan data penting, sebaiknya minta developer meninjaunya.

Kesimpulan

Database dan login dibutuhkan saat data harus berpindah perangkat atau dipakai banyak orang. Pakai sistem login yang sudah ada, simpan pemilik di setiap baris data, nyalakan aturan akses di setiap tabel, jangan pernah menaruh kunci rahasia di browser, dan buktikan dengan uji dua akun bahwa data tidak bocor.

Langkah berikutnya di jalur Vibe Coding: saat aplikasi makin besar, kemajuan sering melambat drastis. Kenali tandanya dan cara melewatinya di masalah 70% di proyek AI.