// docs / security guides / pre-launch SaaS

Checklist keamanan pra-peluncuran SaaS: 35+ item

Tinggal beberapa hari lagi peluncuran produk SaaS yang dibuat dengan Cursor, Claude Code, Lovable, atau Bolt. Daftar periksa ini adalah audit go/no-go yang mencakup permukaan keamanan yang sering diabaikan oleh alat AI dan yang perlu ditangani oleh para pendiri pengiriman cepat sebelum mengambil uang pelanggan. Delapan bagian, 35+ item, masing-masing dapat diselesaikan dalam 30-90 menit. Cetak, coret, terapkan dengan percaya diri.

Setiap item di bawah ini penting. Hijau berarti dikirim dan diverifikasi; merah berarti peluncuran yang belum terselesaikan dan memblokir. Untuk penjelasan lebih panjang mengenai setiap kategori dengan cuplikan kode dan pola kegagalan nyata, lihat How to secure an app built with AI coding tools dan The vibe coding security checklist.

Isolasi data pelanggan

Dalam SaaS multi-penyewa, batasan keamanan pertama Anda adalah isolasi data. Setiap data pelanggan harus tidak dapat dijangkau oleh setiap pelanggan lainnya, diterapkan pada lapisan database, bukan pada lapisan aplikasi.

Aktifkan Keamanan Tingkat Baris (RLS) di setiap tabel Supabase dengan ALTER TABLE public.table_name ENABLE ROW LEVEL SECURITY; ALTER TABLE public.table_name FORCE ROW LEVEL SECURITY;. FORCE mencegah pemilik tabel melewatinya.
Untuk setiap kebijakan RLS, verifikasi cakupan predikat ke pengguna atau organisasi yang diautentikasi. Contoh: CREATE POLICY "users_see_own" ON public.items FOR SELECT USING (auth.uid() = user_id);. Uji dengan akun pengguna kedua untuk memastikan data tetap terisolasi.
Jika menggunakan Firebase / Firestore, aturan harus sesuai dengan model penyewa Anda. Jangan gunakan allow read, write: if true; atau aturan pengujian berbatas waktu. Gunakan allow read, write: if request.auth.uid == resource.data.owner_uid; atau pencocokan cakupan organisasi yang setara.
Gunakan URL bertanda tangan atau token berumur pendek untuk akses file, jangan pernah menggunakan keranjang publik. Supabase Penyimpanan: setel ENABLE ROW LEVEL SECURITY pada tabel objects dan kebijakan penulis yang mencakup akses file ke pengguna yang diautentikasi. Uji unduhan sebagai pengguna yang berbeda.
Pada lapisan API Anda, setiap permintaan harus menyertakan auth.uid() atau konteks org-id. Setiap kueri database harus difilter berdasarkan konteks tersebut. Contoh: tidak SELECT * FROM items WHERE id = $1; selalu SELECT * FROM items WHERE id = $1 AND user_id = auth.uid().

Penagihan dan pembayaran

Integrasi Stripe adalah tempat kepercayaan pelanggan bertemu dengan keamanan finansial. Kesalahan konfigurasi di sini berarti pembayaran dicuri, putaran pengembalian dana, atau pendapatan hilang.

Gunakan live Stripe keys dalam produksi. Uji dengan kunci mode pengujian terpisah pada pementasan. Jangan pernah beralih dari pengujian ke siaran langsung tanpa pemindaian mode langsung terakhir.
Verifikasi tanda tangan webhook pada setiap peristiwa masuk: const event = stripe.webhooks.constructEvent(req.body, sig, webhookSecret);. Lempar jika tanda tangan gagal. Simpan rahasia webhook hanya dalam variabel lingkungan, jangan dalam kode.
Menerapkan idempotensi pada penangan webhook menggunakan tabel database yang dikunci oleh event.id. Jika webhook yang sama datang dua kali (akan datang), proses kedua tidak boleh dilakukan. Tulis baris idempotensi dalam transaksi yang sama dengan perubahan keadaan.
Pada customer.subscription.updated dan customer.subscription.deleted, segera cabut akses. Jangan menunggu cron. Uji dengan membatalkan langganan di Dasbor Stripe dan memverifikasi bahwa pengguna terkunci dalam waktu 5 detik.
Simpan hanya pelanggan Stripe ID dan langganan ID di database Anda, jangan pernah menyimpan seluruh kartu atau kunci API. Ambil status langganan langsung dari Stripe pada setiap batas autentikasi (pemuatan halaman, panggilan API, pemeriksaan cron). Jangan menyimpan status langganan dalam cache selama >1 menit.

Otentikasi dan sesi

Auth adalah target penyerang tingkat kedua di SaaS. Akun pengguna adalah vektor data dan metode pembayaran.

Gunakan supabase.auth.getUser() pada setiap rute yang dilindungi, jangan pernah getSession(). getSession() membaca cookie yang belum diverifikasi; getUser() memvalidasi sisi server JWT. Di Next.js: const { data: { user } } = await supabase.auth.getUser(); sebelum menayangkan konten yang dilindungi.
Setel SameSite=Lax pada cookie autentikasi (Supabase Auth melakukan ini secara default). Verifikasi di DevTools → Aplikasi → Cookie. Jika Anda melihat SameSite=None, tambahkan sameSite: 'Lax' ke konfigurasi sesi Anda.
Aktifkan MFA pada akun admin Anda sendiri. Untuk pengguna MFA, ujilah secara menyeluruh sebelum peluncuran: daftar, daftarkan perangkat TOTP, keluar, masuk kembali dengan token TOTP, verifikasi berfungsi.
Token tautan ajaib harus kedaluwarsa dalam waktu 15 menit. Token setel ulang kata sandi harus kedaluwarsa dalam waktu 1 jam. Token sesi (JWTs) dapat bertahan lebih lama (24 jam-7 hari) tetapi harus divalidasi pada setiap penggunaan. Periksa default penyedia autentikasi Anda.
Uji kelengkapan keluar: setelah pengguna mengklik keluar, browser menghapus sesi autentikasi, server mencabut token apa pun, dan pengguna tidak dapat mengakses halaman yang dilindungi. Di Supabase: hubungi await supabase.auth.signOut() dan verifikasi JWT tidak lagi valid pada permintaan berikutnya.

PII dan kepatuhan

Jika Anda mengumpulkan email, nama, info pembayaran, atau PII apa pun, Anda memiliki kewajiban hukum: minimalisasi data, penyimpanan aman, penghapusan sesuai permintaan, dan kesiapan DPA.

Tulis dan publikasikan kebijakan privasi (bukan opsional, bahkan untuk SaaS indie). Nyatakan data apa yang Anda kumpulkan, alasannya, berapa lama Anda menyimpannya, dan hak pengguna (akses, koreksi, penghapusan). Gunakan templat dari Termly atau serupa tetapi sesuaikan.
Terapkan titik akhir penghapusan akun API yang menghapus PII dari database. Uji: buat akun, tambahkan data, hapus akun, verifikasi data hilang (gunakan inspeksi database langsung).
Untuk kepatuhan GDPR / CCPA, tanggapi permintaan subjek data (akses / koreksi / penghapusan) dalam waktu 30 hari. Dokumentasikan proses Anda. Jika aplikasi Anda berbasis EU- atau melayani pengguna EU, diperlukan Adendum Pengaksesan Data Pro (DPA) dengan Stripe, Supabase, dan pemroses apa pun.
Enkripsi bidang sensitif saat tidak digunakan (kata sandi di-hash oleh penyedia autentikasi Anda; tetapi tokenisasi kartu kredit, kunci API, rahasia harus menggunakan pgcrypto atau brankas eksternal). Jangan pernah menyimpan nomor kartu kredit dalam bentuk teks biasa (gunakan tokenisasi Stripe sebagai gantinya).

Kesiapan operasional

Keamanan berkelanjutan. Respons insiden, pemantauan, dan runbook dimulai sebelum hari pertama.

Siapkan halaman status (Statuspage.io, Robot Uptime, atau index.html sederhana). Pelanggan perlu tahu jika Anda mengalami pemadaman listrik. Perbarui pada setiap kejadian.
Dokumentasikan dan uji rotasi panggilan. Siapa yang bangun pada jam 2 pagi? Siapa yang telah menerapkan kunci? Siapa yang dapat mencabut token yang disusupi? Dokumentasikan dan jalankan latihan kebakaran sebelum peluncuran.
Tulis runbook respons insiden keamanan: apa yang harus dilakukan jika pelanggan melaporkan pelanggaran, jika Anda kehilangan kunci, jika layanan tidak berfungsi. Bagikan ke tim Anda. Uji satu skenario (e.g., simulasikan kebocoran kunci) untuk memverifikasi bahwa rencana berhasil.
Prosedur pencadangan dan pemulihan harus diuji, bukan teoretis. Bisakah Anda memulihkan dari cadangan? Atur waktu. Supabase: aktifkan pencadangan otomatis (retensi 7 hari gratis, 30 hari berbayar). Uji pemulihan ke proyek terpisah setiap tiga bulan.
Aktifkan pencatatan audit untuk operasi istimewa: login dasbor Stripe, panggilan Supabase admin API, perubahan skema basis data, rekonsiliasi pembayaran. Alat: CloudTrail (AWS), log audit Supabase, ekstensi PostgreSQL pgaudit.

Permukaan serangan eksternal

Batas API Anda terus-menerus dipindai oleh penyerang. Kunci sebelum lalu lintas berbahaya menyerang.

Batasi tarif setiap titik akhir publik. Contoh: 100 permintaan per menit per IP saat mendaftar, 10 per menit saat menyetel ulang kata sandi. Gunakan Vercel KV, Redis, atau sejenisnya. Gagal dengan 429 (Terlalu Banyak Permintaan).
Tambahkan CAPTCHA (hCaptcha atau reCAPTCHA) ke titik akhir pendaftaran dan setel ulang kata sandi untuk mengalahkan bot. Verifikasi sisi server token sebelum menerima permintaan.
Gunakan WAF (Firewall Aplikasi Web) jika tersedia: Cloudflare, Vercel Firewall Aplikasi Web, atau AWS WAF. Blokir IP dan pola yang diketahui berbahaya secara otomatis.
Pindai titik akhir API yang terbuka. Jalankan pemindaian pasif FixVibe terhadap domain produksi Anda setiap bulan. Tinjau temuan untuk rute debug yang terekspos, introspeksi GraphQL, kebocoran kunci API, atau paparan konfigurasi.
Putar kredensial (API kunci, OAuth token, kata sandi basis data) setiap tiga bulan. Dokumentasikan prosedur rotasi dan otomatiskan jika memungkinkan.

Observabilitas dan pencatatan

Ketika terjadi kesalahan, log adalah catatan forensik Anda. Atur mereka sejak hari pertama.

Sentralisasi log: Supabase Log, Vercel Log, log aplikasi, dan log autentikasi ke satu dasbor (Datadog, LogRocket, atau ELK yang dihosting sendiri). Dapat dicari, disimpan setidaknya selama 90 hari.
Peringatan tentang peristiwa keamanan: kegagalan login berulang kali (kemungkinan pengambilalihan akun), penggunaan API yang tidak biasa (kemungkinan tergores), lonjakan kesalahan (kemungkinan serangan atau insiden yang sah). Tetapkan ambang batas dan integrasi Slack.
Keluarkan log audit untuk setiap operasi istimewa: perubahan peran pengguna, pembuatan akun admin baru, penambahan metode pembayaran, perubahan cakupan pada kunci API. Simpan ini secara terpisah dari log aplikasi dengan retensi yang tidak dapat diubah.

Verifikasi akhir

Sebelum Anda mengumumkannya, jalankan pemindaian penuh FixVibe dan tinjau temuannya dengan hati-hati.

Jalankan pemindaian aktif FixVibe Pro terhadap domain produksi Anda. Konfigurasikan domain Anda untuk pengujian aktif (DNS TXT atau HTTP verifikasi file). Otorisasi pemindaian dan tinjau setiap temuan — terutama temuan kritis dan tingkat keparahan tinggi. Perbaiki atau terima masing-masing secara eksplisit.
Aktifkan pemindaian ulang terjadwal: paket Pro → 3 jam, 6 jam, 12 jam, atau setiap hari. Unlimited paket → 6 jam, 12 jam, setiap hari, setiap 2 hari, atau setiap minggu. Sandingkan dengan active IDOR walking, SQL injection, dan reflected XSS cek pada domain terverifikasi Anda.
Konfigurasikan webhook: sambungkan FixVibe ke Slack atau kirim email sehingga temuan penting memicu peringatan secara real-time. Lihat /docs/webhooks untuk pengaturan.
Lakukan tinjauan kode manual akhir yang berfokus pada gotcha di /docs/security-guides/ai-generated-code-security-scanner: rahasia dalam bundel, RLS/rules, batas autentikasi, CSP, penempatan middleware. Gunakan vibe coding security checklist sebagai templat ulasan.

Hari peluncuran

Anda telah menghapus daftar periksa. Terapkan dengan percaya diri. Setelah peluncuran, pantau secara aktif: periksa temuan FixVibe setiap hari selama minggu pertama, tanggapi peringatan dalam waktu 1 jam, dan terus jalankan jadwal pemindaian. Untuk panduan pengerasan langkah demi langkah dengan cuplikan kode, lihat How to secure an app built with AI coding tools.