DEV Community: Pon

My public view leaked every user's email. The AI called it "partial user data."

Pon — Mon, 06 Jul 2026 15:53:36 +0000

Every email address in my users table was readable with just the anon key. The app worked fine, tests were green, and it sat like that for about three weeks.

I was building a side project with Claude earlier this year. At some point I asked for a public profiles page, the kind where visitors can see usernames and avatars without logging in. It did what I asked and created a view:

create view public_profiles as
select id, username, avatar_url, email
from users;

I remember skimming this and thinking it looked reasonable. I had RLS enabled on users, policies tested, the whole thing. When I later asked the AI what the view returned, it described it as "partial user data." Which is technically true. It just didn't mention that the partial data included the one column I'd never want public.

Why RLS didn't save me

Two Postgres behaviors stack up here, and neither one is obvious if you came in through Supabase:

Views run with the owner's permissions by default. My RLS policies on users were fine. But a view created by postgres reads the table as postgres, and the owner isn't subject to my policies. Reading users through the view skips RLS entirely, with no warning anywhere.
Supabase exposes the whole public schema through its API. Anything I create in public gets an endpoint. So the view wasn't sitting unused in the database, it was one HTTP request away for anyone holding the anon key. And the anon key ships in the frontend bundle by design.

So: RLS on, policies correct, and every email still public. Each piece works exactly as documented; together they published a column I never meant to share.

Why the AI didn't warn me

I don't think the AI did anything wrong by its own lights. I asked for a public profiles page and got a working one. The code ran, the page rendered, my tests (which check what the app shows) all passed. There was no test for "what else can be read that I never render." That question only comes up when someone is thinking like an attacker, and code generation doesn't.

Most of the security issues I've found in my own AI-built projects follow this shape. Working code that does slightly more than I intended.

Check your own project in two minutes

List the views in your public schema:

select viewname from pg_views where schemaname = 'public';

For each one, look at which columns it exposes:

select column_name from information_schema.columns
where table_schema = 'public' and table_name = 'public_profiles';

And the honest test — ask your API the way a stranger would, with only the anon key:

curl "https://YOURPROJECT.supabase.co/rest/v1/public_profiles?select=*" \
  -H "apikey: YOUR_ANON_KEY"

If emails, phone numbers, or anything else private comes back, you have my three-week problem.

The fix

Pick whichever fits your case:

Drop the sensitive columns from the view. A public profile needs a username and an avatar. It doesn't need an email.

On Postgres 15+, make the view respect the caller's RLS:

alter view public_profiles set (security_invoker = true);

Now reads through the view run as the person asking, and your policies apply again.

If the view was never meant to be public, revoke API access:

revoke select on public_profiles from anon;

I did the first two. Belt and suspenders felt right after three weeks of not noticing.

I build with AI every day and that's not changing. But I've stopped treating "it works" as the end of the review, because working code can expose more than it renders. I ended up building a small tool that scans for this pattern and a few related ones automatically. If you're on Supabase and want me to take a look at your repo for free, leave a comment and I'll run it.

I shipped a Supabase app last month and left the front door open for weeks

Pon — Mon, 29 Jun 2026 13:57:52 +0000

I build with AI like everyone else right now. Claude writes most of my backend, I review it, it works, I ship. For a side project I was working on, that loop felt great until I finally sat down and read one of my own RLS policies.

Here is what I found sitting in my migration:

create policy "Users can view their data"
on profiles for select
using (true);

Read that policy name again, then read the using (true) under it. The name says "users can view their data." The code says "anyone can view everyone's data." Those are not the same thing, and I had shipped the second one.

If you have ever turned on Row Level Security in Supabase and felt safe, this is the part nobody warns you about. RLS being "enabled" does not mean RLS is doing anything. A policy with using (true) is a policy that always passes. The lock is on the door, but the rule is "let everybody in."

I want to be honest about how this happened, because I do not think I am special here. I asked the AI for a policy so users could read their own profiles. It gave me something that ran, the app worked in testing, every row came back fine because I was logged in as myself. Nothing failed. Tests passed. The bug only exists when a different user shows up and reads rows that were never theirs, and that is exactly the case you never test by hand.

The AI was not wrong in a way I could see. It wrote code that worked. It just did not write code that was safe, because "safe" means thinking about the attacker, and the AI was thinking about the happy path I asked for. That is the gap. It is fast and it is genuinely good, but it does not sit there imagining the user who changes an id in the URL to see if your server stops them.

So here is how I check now. It takes about two minutes.

Open the Supabase dashboard, go to the SQL editor, and run this:

select schemaname, tablename, policyname, qual
from pg_policies
where schemaname = 'public';

The qual column is the actual USING expression for each policy. Read it. If you see true sitting in there on a SELECT policy for a table that holds user data, that row is readable by anyone who can hit your API. Same story for with check on insert and update policies.

What you usually want instead is the policy tied to the logged-in user, something like:

create policy "Users can view their own profile"
on profiles for select
using (auth.uid() = user_id);

Now the rule says what the name always claimed: a user only sees rows where the user id matches theirs. Swap user_id for whatever your column is.

A few things I do every time now, none of them clever:

Read the qual, not the policy name. The name is a comment. It can say anything. The qual is the law.

Check every table that holds something personal. Not the obvious one alone — all of them. I had three tables and only thought about one.

Log in as a second test user and try to read the first user's rows. If you get data back, you found it before someone else did.

I am not writing this to scare anyone off AI. I use it every day and I am not going back. I just had to learn that the speed it gives me on building is speed I have to spend back on checking, because it will hand me something that runs and let me believe it is finished.

I kept finding this same using (true) pattern in my own projects often enough that I started writing a small thing to scan for it automatically, along with a couple of other Supabase footguns like public views that leak email and policies granted to the anon role. If you have an AI-built Supabase app and want me to run it over your schema for free, drop a comment. I am still testing it and I would rather find these on a friendly repo than have you find them the hard way.