DEV Community: Pon

Your Supabase notifications table has RLS on. Anyone signed in can still write into someone else's inbox.

Pon — Tue, 04 Aug 2026 14:34:38 +0000

Here's a pattern I keep running into when I look at Supabase apps that shipped a notifications feature: RLS is on, the SELECT policy is correct, everyone tests it, everyone sees only their own notifications, and the feature gets marked done. Nobody checks the other three commands.

A typical setup looks like this:

create policy "read own notifications"
on notifications
for select
to authenticated
using (recipient_id = auth.uid());

That policy is fine. It's also usually the only one anyone thinks about, because reading your own notifications is the only thing you personally test.

Where this breaks

Somewhere in the build, a feature needs the client to create a notification directly, someone likes a post, follows a user, whatever. The fastest way to make that work from the frontend is an INSERT policy that just lets it through:

create policy "authenticated can insert notifications"
on notifications
for insert
to authenticated
with check (true);

with check (true) means any signed-in user can set any recipient_id, with any title and body they want. The SELECT policy still only shows you your own notifications, so you never notice you can also write everyone else's. You're not scanning your own inbox for messages you didn't send, why would you.

But anyone holding a valid session token can do exactly that:

curl -X POST "https://YOURPROJECT.supabase.co/rest/v1/notifications" \
  -H "apikey: YOUR_ANON_KEY" \
  -H "Authorization: Bearer YOUR_USER_JWT" \
  -H "Content-Type: application/json" \
  -d '{"recipient_id":"<someone-elses-uuid>","title":"Your payment failed","body":"Update your card: evil.example.com"}'

If that succeeds, you've just put a message of your choosing into a stranger's notification feed, from inside your own app's UI, using a phishing hook the recipient has every reason to trust.

Why this slips past both AI and manual review

The AI wired up exactly what was asked: a client-side path that lets a user action produce a notification. Verifying who the real sender is was never part of the request. Manual testing has the same blind spot. You only ever test your own account, which happens to be the one case this bug doesn't affect.

Check your own project in two minutes

List the policies on your notifications table and look at the INSERT row specifically:

select policyname, cmd, qual, with_check
from pg_policies
where tablename = 'notifications';

If the insert policy's with_check is true, blank, or has no link back to an actor/sender column you control server-side, that's the bug sitting right there.

The fix

Two ways to close it, in order of how much I'd trust each:

Constrain the insert to match the actor:

create policy "insert notifications you really triggered"
on notifications
for insert
to authenticated
with check (actor_id = auth.uid());

This at least ties the row to who really did it, so it's traceable and the client can't spoof actor_id. It still trusts the client to pick the right recipient_id, which is weaker than it sounds if any other column drives real behavior later.

Better: don't let the client write notifications at all. Derive them server-side from the event that should trigger them, with a trigger the client can't touch:

create or replace function notify_on_like()
returns trigger as $$
begin
  insert into notifications (recipient_id, actor_id, type, post_id)
  values (
    (select user_id from posts where id = new.post_id),
    auth.uid(),
    'like',
    new.post_id
  );
  return new;
end;
$$ language plpgsql security definer;

create trigger on_like_notify
after insert on likes
for each row execute function notify_on_like();

With this, the client's insert policy on notifications can just be false, or not exist at all. The only thing that ever writes there is the trigger, and recipient_id comes from the real post owner, never from client input.

I build with AI constantly and this isn't a reason to stop. It's a reason to stop treating "the notifications I see look right" as proof the table is safe, since that test only ever checks the one direction that was never broken. I put together a small tool that checks for this pattern and a few related ones across a repo automatically. If you want me to run it against yours for free, drop a comment.

Update, 13 Aug 2026. Mads Hansen pointed out in the comments that the fix above moves the authority into the trigger function and then leaves it unguarded, and he's right. Two things were missing.

security definer runs the body as the function's owner, and on Supabase that owner usually owns the table too. The RLS bypass comes from that ownership, not from the keyword. With no set search_path, the caller's path is still in force inside the body, so an unqualified notifications or posts resolves to whatever a schema earlier on that path happens to hold. Pin it to empty and qualify every name.

Mads named the second one too, in his line about deriving actor and recipient from the trusted source row. What it costs to skip: auth.uid() reads the request JWT, so the moment a like gets inserted from the server with the service role, or straight from SQL, there is no JWT and actor_id lands as NULL.

create or replace function public.notify_on_like()
returns trigger
language plpgsql
security definer
set search_path = ''
as $$
begin
  insert into public.notifications (recipient_id, actor_id, type, post_id)
  values (
    (select p.user_id from public.posts p where p.id = new.post_id),
    new.user_id,
    'like',
    new.post_id
  );
  return new;
end;
$$;

That version only holds if likes itself constrains who the liker is, so its insert policy is now load-bearing:

create policy "like as yourself"
on public.likes
for insert
to authenticated
with check (user_id = auth.uid());

Mads also suggested a unique key on the event identity so a retry cannot double-post the same notification. Worth having, with the caveat that if you allow unlike and re-like you need the old row gone first, or the second like goes quiet.

create unique index notifications_event_once
on public.notifications (type, actor_id, recipient_id, post_id);

This endpoint has auth. The tests are green. It still lets a user hand themselves admin.

Pon — Thu, 23 Jul 2026 14:14:41 +0000

Here's a pattern I keep running into in AI-scaffolded update endpoints: the code looks completely ordinary. Nothing about it reads as risky.

The whole endpoint is one line most people never look twice at:

app.patch('/api/users/:id', requireAuth, async (req, res) => {
  const user = await User.findByIdAndUpdate(req.params.id, req.body, { new: true });
  res.json(user);
});

requireAuth checks that someone is logged in. It never checks what they're allowed to send. req.body goes straight into the update, whatever shape it happens to be.

Where this breaks

The intended use is updating your own name, bio, or avatar URL. Normal, boring, exactly what AI writes for you in a second when you ask for "let users edit their profile."

Nothing stops the client from sending fields nobody meant to expose:

curl -X PATCH https://yourapp.com/api/users/YOUR_OWN_ID \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"name":"Same As Before","role":"admin"}'

If role is a column on that user row, that request just promoted the caller to admin. Nothing crashed. The response looks exactly like a normal profile update, because as far as the database is concerned, it was one.

I shipped a version of this myself, and I didn't catch it right away. Every tool I ran on it was happy — linter clean, tests green, and an AI reviewer signed off. None of them asked what the client was allowed to put in that body.

Why this slips past both AI and manual review

The AI wired up exactly what was asked: read the request body and write it straight into the record. Nobody told it that role, is_admin, credits, or plan_id are different in kind from name and bio. It has no way to know a column is privileged unless something tells it so.

Manual testing has the same blind spot, because you're the one writing every request by hand. You check that your own update works, and you have no reason to try sending a field you were never supposed to touch.

Check your own project in two minutes

Search your codebase for anywhere a request body gets passed into a write call without being filtered first:

grep -rn "findByIdAndUpdate(req\|\.update(req\.body\|\.create(req\.body" .

For every hit, ask: does the model behind this call have any column a normal user shouldn't be able to set themselves? Role, admin flags, credit balances, subscription tier, ownership fields — anything like that sitting in the same table as the profile fields users are supposed to edit is a mass assignment waiting to happen.

The fix

Never pass req.body into a write call directly. Pick only the fields you meant to allow:

app.patch('/api/users/:id', requireAuth, async (req, res) => {
  const { name, bio, avatarUrl } = req.body;
  const user = await User.findByIdAndUpdate(
    req.params.id,
    { name, bio, avatarUrl },
    { new: true }
  );
  res.json(user);
});

Now role in the request body just gets ignored, no matter who sends it. If you're using a schema validator like Zod, .pick() or .strict() on the update shape does the same thing with less to maintain by hand — and it fails loudly on an unexpected field instead of silently dropping it.

If a privileged field genuinely needs to change through an API, give it its own endpoint with its own authorization check, separate from the one a regular user hits to edit their bio.

The habit that catches this

Every time a request body flows into a write, it's worth asking one question before shipping: what's allowed in here, and did I decide that on purpose, or did the tool decide it for me? Most of the checks I run don't ask that at all. It's the one I've started asking by hand.

I put together a small tool that checks a repo for this pattern and a few related ones automatically. If you want me to run it against yours for free, drop a comment.

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.