Supabase Security Definer Functions Bypass RLS: The Fix (2026)

Our own Supabase tutorials had this bug. Three of them create SECURITY DEFINER functions in the public schema with no search_path and no REVOKE, which is exactly what Supabase's linter flags as 0028_anon_security_definer_function_executable. We'd copied the pattern from the same places your AI coding tool did.

The ones in our tutorials turned out to be harmless, for a reason worth understanding. The same pattern with one parameter changed is not.

What we tested

We rebuilt the relevant parts of a Supabase project on stock PostgreSQL 16.15: anon and authenticated roles, an auth.uid() that reads the JWT subject, and Supabase-style default privileges that grant new functions in public to both roles. Then one profiles table with RLS on and a policy that lets a user see only their own row.

This is a reproduction, not a live Supabase project, so treat the exact error text as Postgres's. The privilege behaviour is plain Postgres, which is what Supabase runs.

Five things fall out of that table. RLS was on the whole time. The invoker version of the same function behaved correctly. A definer function that writes is worse than one that reads. Revoking from anon alone is a no-op, because anon inherits EXECUTE from PUBLIC. And a fix for lint 0028 still leaves every signed-up user able to call it, which is lint 0029.

Why this happens

Supabase's database functions guide says it in three sentences, and they're worth reading together:

"A security definer function can return rows the caller isn't allowed to read."

"A function created in the Dashboard or by a migration is owned by postgres, which bypasses Row Level Security."

"Any role can call it by default, including anon."

Add the fact that functions in an exposed schema are callable through the REST API and you get the full chain: a POST to /rest/v1/rpc/get_email_definer with the anon key in the header runs your SQL as the database owner.

curl -X POST "https://YOUR_PROJECT.supabase.co/rest/v1/rpc/get_email_definer" \
  -H "apikey: YOUR_ANON_KEY" \
  -H "Content-Type: application/json" \
  -d '{"uid": "any-user-id"}'

AI tools reach for SECURITY DEFINER for a legitimate reason: it's the standard fix for infinite recursion when a policy on team_members needs to query team_members. The keyword makes the error go away, and nothing else changes visibly, so nobody looks again.

The safe kind and the dangerous kind

Not every definer function is a hole. The test is simple: does the function decide whose data to touch, or does the caller?

Here's the shape from our own RLS tutorial. It's fine:

create function is_team_member(team_id uuid) returns boolean as $$
  select exists (
    select 1 from team_members
    where team_members.team_id = $1
      and team_members.user_id = auth.uid()
  );
$$ language sql security definer;

An anonymous caller has no auth.uid(), so it gets false for every team. A signed-in caller can only ask about themselves. The function bypasses RLS internally, but its answer is pinned to the caller's identity, so it leaks nothing they couldn't already know.

Now the dangerous shape, which is what you get when you ask an AI to "write a function that gets a user's email" or "add credits after payment":

create function get_user_email(uid uuid) returns text as $$
  select email from profiles where id = uid;
$$ language sql security definer;

The caller chooses uid. Nothing checks it against auth.uid(). That's an IDOR with the database owner's privileges, reachable from a browser. Anything that writes (credits, roles, subscription status) on a caller-supplied id is the same bug, and it's the worse version.

Step 1: Find every definer function anon can call

Run this in the Supabase SQL Editor. It lists every SECURITY DEFINER function in public, who can execute it, and whether its search_path is pinned:

select
  p.proname as function,
  pg_get_function_identity_arguments(p.oid) as args,
  has_function_privilege('anon', p.oid, 'EXECUTE') as anon_can_call,
  has_function_privilege('authenticated', p.oid, 'EXECUTE') as signed_in_can_call,
  p.proconfig as settings
from pg_proc p
join pg_namespace n on n.oid = p.pronamespace
where n.nspname = 'public'
  and p.prosecdef
order by 1;

Anything with anon_can_call = true is reachable with your public key. A null settings column means no search_path pin. The Security Advisor in the dashboard reports the same thing as lints 0028 and 0029, but this query also shows you the arguments, which is what you need for the safe-or-dangerous test above.

Trigger functions (the returns trigger kind, like the usual handle_new_user()) will show up too. Postgres refuses to call those directly, so they're not an RPC risk, but pin their search_path anyway.

Step 2: Pick the right fix for each one

alter function public.get_user_email(uuid) security invoker;

revoke execute on function public.add_credits(uuid, int)
  from public, anon, authenticated;
grant execute on function public.add_credits(uuid, int) to service_role;

create schema if not exists private;
grant usage on schema private to authenticated;

create function private.is_team_member(team_id uuid)
returns boolean
language sql
security definer
set search_path = ''
as $$
  select exists (
    select 1 from public.team_members
    where team_members.team_id = $1
      and team_members.user_id = auth.uid()
  );
$$;

alter function public.handle_new_user() set search_path = '';

Step 3: Stop new ones from shipping open

Postgres grants EXECUTE to PUBLIC on every function it creates, so fixing today's list doesn't help next week's migration. Change the default, and note that it takes two statements:

-- the PUBLIC grant is global, so it has to be revoked globally
alter default privileges for role postgres
  revoke execute on functions from public;

-- the anon/authenticated grants are per-schema
alter default privileges for role postgres in schema public
  revoke execute on functions from anon, authenticated;

We first wrote this as a single in schema public statement covering all three roles. It ran without error and changed nothing: new functions were still callable by both roles. Postgres documents why: per-schema default privileges are added to the global ones, so you can't take away per-schema what was granted globally. Run both, then create a test function and check it with the audit query.

After that, any function you want callable from the browser needs an explicit grant execute ... to authenticated, which is the point. You decide per function instead of inheriting "everyone."

What we changed in our own posts

The is_team_member, is_team_admin and is_admin examples in our RLS policies tutorial and Supabase security guide now live in a private schema with set search_path = ''. They were never exploitable, because each one keys off auth.uid(), but they tripped the same lints yours will, and a tutorial shouldn't teach the pattern that becomes dangerous the moment someone adds a parameter.