# Why does an app you build with AI need database access rules?

Date: 2026-10-28 · Author: Robert Scales · https://guidetoartificialintelligence.com/en/learn/ai-built-app-database-access-rules/

**Answer:** Many AI-built apps let the web page talk straight to the database, so the only thing stopping a visitor from reading every row is a set of access rules, such as Row Level Security, stored in the database itself. If those rules are missing or too loose, anyone who looks at the page's traffic can read, and sometimes change, all of your users' data.

A database is where an app keeps its information: user accounts, bookings, messages, orders. In a traditional web app, the browser never touches the database. It asks a server, and the server decides what each person may see. Many AI app builders take a shortcut that makes apps faster to generate: the page in the visitor's browser sends queries directly to a hosted database, using a key that is built into the page and therefore public.

That design is not wrong in itself, but it moves all the protection into the database. The key in the page is meant to be harmless; what keeps one user from reading another user's records is a set of rules attached to each table. If an AI writes the tables but not the rules, or writes rules that say "everyone may read," the app works perfectly in testing and leaks everything in public.

## What Row Level Security does

Supabase, a database service many builders use, relies on a Postgres feature called **Row Level Security (RLS)**. Its [documentation](https://supabase.com/docs/guides/database/postgres/row-level-security) describes a policy as a condition quietly added to every query on a table, much like a filter. Two layers work together: **grants** say whether a kind of visitor may read, add, change or delete in a table at all, and **policies** say which rows those actions apply to.

Supabase names the visitors with roles. `anon` is someone who is not signed in. `authenticated` is a signed-in user. A third, `service_role`, ignores the rules entirely and must only ever be used on a server, never in a web page. The documentation is blunt: a table that is exposed to the web without RLS can be read and written by any role that has been granted access to it.

## A worked example: a bookings table

Imagine your yoga app stores bookings with a name, an email, a class time and the ID of the user who booked. A safe rule says each signed-in user can see only their own bookings:

```sql
alter table bookings enable row level security;

create policy "people see their own bookings"
on bookings for select
to authenticated
using (auth.uid() = user_id);
```

The dangerous version, which an assistant might write to "make the error go away," lets every visitor read every row:

```sql
create policy "anyone can read bookings"
on bookings for select
to anon
using (true);
```

You don't need to write SQL yourself to use this. You need to ask, and then test:

```prompt
For every table in this app, show me whether Row Level Security is enabled
and list each policy in plain English: which role it applies to, which action
(read, add, change, delete) and which rows. Then tell me which tables a
visitor who is not signed in can read or change.
```

Then test it the way an outsider would: open the app in a private browser window without signing in and try to load another person's data, or sign in as a second test user and see whether the first user's bookings appear.

> **Try it:** In a test project with made-up data, create two accounts, add a booking with each, and confirm that neither account can see the other's booking.

## How did apps built with these tools end up leaking their users' data?

**Missing rules at scale.** In May 2025, a vulnerability record, [CVE-2025-48757](https://www.cve.org/CVERecord?id=CVE-2025-48757), was published for apps generated with Lovable up to April 15, 2025. It describes insufficient Row Level Security policies that let attackers who were not signed in read or write arbitrary tables of the generated sites, and rates the problem critical. The record also notes that Lovable disputes it, on the grounds that each customer is responsible for protecting their own app's data. Both points are worth holding at once: the builder made the shortcut easy, and the app's owner is still the one whose users are exposed.

**A public key with nothing behind it.** In February 2026, Wiz researchers looked at Moltbook, a social network for AI agents built, by its founder's account, without writing code by hand. They found the database key in the site's JavaScript, which is normal for this design, but no row-level rules behind it, which is not. Anyone could read and write the production data, including, Wiz reports, about 1.5 million API tokens and about 35,000 email addresses. Moltbook secured it within hours of being told.

**The platform's own permissions.** Not every leak is in your tables. Lovable reported in April 2026 that a regression in its own backend had let any logged-in user with a project link read the code and build conversations of projects marked public from February 3 to April 20, 2026. Chats and code often contain table names, business details and sometimes pasted keys, so a project that is public in the editor can reveal far more than the finished website.

The pattern is the same each time: an app that behaves correctly for the person who built it, and nobody testing what it does for a stranger. Turning RLS on, writing a policy for every table, keeping the service key off the page, keeping projects private, and testing as a signed-out visitor closes most of that gap.

## Sources

- CVE-2025-48757: https://www.cve.org/CVERecord?id=CVE-2025-48757
- Hacking Moltbook: The AI Social Network Any Human Can Control: https://www.wiz.io/blog/exposed-moltbook-database-reveals-millions-of-api-keys
- Our response to the April 2026 incident: https://lovable.dev/blog/our-response-to-the-april-2026-incident