Is your AI-built app's database public? Supabase Row Level Security explained

If your app was built with Lovable, Bolt.new or another AI builder that uses Supabase, your app's browser code talks straight to your database. That's by design, and it's safe, but only if one setting is right on every table: Row Level Security. When it's off or too loose, anyone who visits your app can read, and sometimes change, your data.

This guide explains how Supabase keeps a public app's data private, how AI-built apps get it wrong, and how to check yours in a few minutes.

Why your database key is public

A Supabase app ships a publishable key (the older name is the anon key) to the browser. Supabase says this key is safe to expose online. It identifies your project, but it doesn't grant access by itself. What a visitor can do with it is decided entirely by your Row Level Security policies: the rules for which rows each kind of user can read and write.

There's also a secret key (the older name is service_role). It bypasses Row Level Security completely, so Supabase says it must never go in a browser, a shipped app or source control.

How AI-built apps get it wrong

• Tables created without Row Level Security. An assistant adds a table to make a feature work and never turns the rules on.
• Policies that allow everyone. A rule like "anyone can read" makes an error go away, so it gets written, and it stays.
• Rules that check the wrong thing. A policy that lets any signed-in user read every row, instead of only their own.
• The secret key in the front end. When a policy blocks something, swapping in the secret key "fixes" it by switching off every rule at once.

This has happened at scale. In 2025 a security researcher reported Lovable-built apps whose database rules let unauthenticated visitors read or write their tables, recorded as CVE-2025-48757. Lovable disputes the record, saying each customer is responsible for protecting their app's data. Either way, the fix is in your project's policies.

How to check your app

1. Look at every table. In the Supabase dashboard, confirm Row Level Security is enabled on each table in your public schema. Supabase's Security Advisor also flags tables without it.
2. Read each policy. For every table, ask who can select, insert, update and delete, and whether that matches what the app should allow.
3. Test signed out. Using only your publishable key, try to read each table. Anything sensitive that comes back is exposed.
4. Test as the wrong user. Sign in as one user and try to read or change another user's records.
5. Search for the secret key. Make sure the service_role or secret key appears only in server code and environment settings, never in front-end code or the repository.

What a good policy looks like

A typical rule lets signed-in users read only their own rows. With Row Level Security on, anything you don't explicitly allow is denied:

alter table orders enable row level security;

create policy "Customers read their own orders"
  on orders for select
  to authenticated
  using ((select auth.uid()) = customer_id);

Write separate policies for inserting, updating and deleting, and give the anon role only what visitors who aren't signed in genuinely need, if anything.

Moving makes this your job

When you move off a builder, Lovable points out that security, along with availability, backups and monitoring, becomes your responsibility. Database policies are one of the pieces that need moving and checking at the destination.

On every migration, AppExit checks for data that anyone can read, along with exposed keys, sign-in and access rules, and outdated packages, before and after the move, and tells you what we find. See the five security problems we check for, or start your order.

Sources

Sources checked November 2026. AppExit is not affiliated with Supabase, Lovable or Bolt.new. Brand names belong to their owners.