Database Settings Every Vibe Coder Forgets Before Going Live

You built it with Lovable, Bolt, or Cursor. It works. You are about to ship. If you skip your database settings, here is what happens: the app keeps running, looks fine, and quietly lets strangers read your users' data.

This is not a rare edge case. It is the most common way AI-built apps leak. The good news is that the fix takes minutes, not a computer science degree.

Why AI Builds It This Way

AI tools are trained to make your app run. Security is something they leave for "later" — and later never comes, because nobody told you it was missing.

When you create a table by hand, by migration, or through one of these tools, that rule starts off. Only tables you make inside the Supabase dashboard turn it on for you. Most AI tools build with migrations, so the protection is silently skipped.

It gets worse. To make sign-in "work" in testing, AI often writes a rule that means allow everyone who is logged in. That passes the demo. In production, it hands every customer a key to every other customer's data.

The Cost of Skipping It

This is not theory. In 2025, a flaw tracked as CVE-2025-48757 exposed more than 170 apps built with Lovable, all sharing the same missing-protection mistake. One AI-built app leaked roughly 18,000 user records. A security roundup of 20 AI-app breaches between January 2025 and February 2026 found the same handful of root causes again and again — and missing row-level security was one of them.

The pattern is always the same: ship fast, look fine, leak quietly, find out from an angry customer or a researcher.

The Setting Everyone Misdiagnoses

Here is the part most blog posts get wrong. They tell you to panic because your "public key" is visible in the browser. That key — the anon or publishable key — is meant to be public. It is not the leak.

The real lock is row-level security. The public key only opens the doors that your rules allow. If your rules say "allow everyone," the key becomes a master key. If your rules are scoped per user, the same visible key is harmless.

There is a second key you must never expose: the secret, or service-role, key. It ignores all your rules and grants full admin access. AI tools sometimes reach for it to "make something work." It belongs on your server only — never in your app, your code, or the browser.

The Pre-Launch Database Checklist

Run through these eight checks before you go live. Each one is a yes-or-no you can confirm inside Supabase, no code required.

1. Turn on row-level security for every table — not just the ones the dashboard made for you.
2. Replace "allow everyone" rules so each user can only see their own rows.
3. Keep your secret key on the server only — never in the app, the code, or the browser.
4. Lock down public sign-ups and any table that should be read-only.
5. Turn off the auto-generated public API for tables that don't need to be exposed.
6. Set up a real backup. The free plan has no automatic backups — you export your data yourself. Paid plans let you turn on point-in-time recovery, which rewinds your database to any moment.
7. Restore a backup once. A backup you have never restored is a hope, not a backup.
8. Re-run Supabase's built-in Security Advisor and clear every red flag before launch.

The catch with a checklist is that you still have to check each item correctly — and knowing whether a rule really scopes to one user is exactly the part that trips up non-coders. That is the gap we close for you.

Let the Audit Run Itself

Instead of clicking through eight settings and hoping you read them right, you can drop a small skill into Claude Code and let it inspect your setup for you. It reports, in plain English, which of these eight items are unsafe and which button fixes each one — sorted by what is exposed right now versus what is merely nice to have.

You do not write any code. You read a short report and click the fixes.

Read Next

• The 10-Step Security Check Before Your AI App Goes Live
• €2.1 Billion in GDPR Fines Last Year — These AI Tools Keep You Safe
• The Best AI Coding Tool for People Who Can't Code
• How I Run a 10-Person Business With Zero Employees
• 5 AI Agents That Actually Run Your Business (Not Just Chat)

Frequently Asked Questions

Is it safe that my Supabase public key is visible in my app?

Yes — the public key (also called the anon or publishable key) is designed to be visible in your app's front end. It is not a secret. Your safety does not depend on hiding it. What matters is row-level security: the public key can only do what your rules allow. If your rules limit each user to their own rows, the visible key is harmless. If row-level security is off or set to "allow everyone," that same key becomes a master key to all your data. The official guidance from Supabase is to keep only the public key in the browser and rely on row-level security for access control. The key you must never expose is the secret, or service-role, key.

What is row-level security and do I really need it?

Row-level security is the rule that decides who can read or change which rows in your database. Each row is usually one person's record — one user's profile, one customer's order. With the rule on and scoped per user, a logged-in person sees only their own rows. Without it, anyone with your public key can read, change, or delete everything. You need it on every table you expose through Supabase's automatic API. It is not optional for a live app with real users. Missing row-level security is the single most common cause of AI-built app data leaks, including the 2025 flaw (CVE-2025-48757) that exposed more than 170 apps built with Lovable.

Does Supabase back up my database automatically?

Not on the free plan. The free Supabase tier has no automatic backups, so the responsibility is entirely yours — you export your data yourself and store a copy somewhere safe. Paid plans add automatic daily backups (the Pro plan keeps the last 7 days) and let you turn on point-in-time recovery, which can rewind your database to almost any moment within the retention window. Whichever plan you are on, do one thing before launch that almost nobody does: actually restore a backup once. If you have never restored it, you do not really know you have one.

Why does my AI tool keep skipping these settings?

AI coding tools are optimized to produce code that runs on the first try, not code that is secure for production. To make features like sign-in "work" during testing, they often generate the most permissive rule possible — effectively "allow everyone who is logged in." That passes the demo and ships fast, but it leaves the door open in production. The tools also tend not to distinguish between your public key and your secret key, sometimes reaching for the powerful secret key to bypass a rule instead of writing a correct one. None of this is malice; it is the tool doing what it was trained to do. Closing the gap is your job, and it is a short one.

How long does it take to fix all of this before launch?

For a small app, the core fixes take well under an hour once you know what to look for: turning on row-level security per table, scoping each rule to the logged-in user, moving the secret key to the server, and setting up one backup. The hard part for non-coders is not the clicking — it is knowing whether a rule truly scopes to one user, which is easy to get subtly wrong. That is why an automated audit helps: it inspects your live setup, flags exactly which of the eight checklist items are unsafe, and tells you the one button that fixes each. You read a short report instead of guessing.