Anyone can make themselves admin: Supabase user_metadata

Updated Oct 22, 20264 min read

Supabase stores two kinds of metadata on every user. Your users can rewrite Supabase user_metadata themselves, straight from the browser. If your app reads a role, an admin flag or a paid plan from there, any user can give themselves admin rights or Pro for free.

What the bug looks like

An admin route that checks the role like this looks reasonable:

const { data: { user } } = await supabase.auth.getUser()
if (user?.user_metadata?.role !== "admin") {
  return new Response("Forbidden", { status: 403 })
}

Any signed-in user can change that field. With the Supabase client (or a direct call to the Auth API with their own token), it takes one line:

await supabase.auth.updateUser({ data: { role: "admin" } })

The same trick works at signup, because supabase.auth.signUp accepts any options.data the caller sends. In SQL the pattern looks like using ((auth.jwt() -> 'user_metadata' ->> 'role') = 'admin'), and then the database itself hands out the access.

Supabase user_metadata vs app_metadata

How it ends up in AI-built apps

The same goes for RLS policies in general: anything they read from the token must be something the user can't edit. Supabase's own guide on user data shows a signup trigger that copies first_name and last_name from raw_user_meta_data into a profiles table. That's fine for names. AI tools extend the same trigger with role or plan, or read the role from user.user_metadata because it's already in the session object and needs no extra query. Team apps do the same with org_id or tenant_id, so changing one value shows you another company's data.

What we found in public repos

We searched public GitHub code for roles and org ids read from user_metadata and ran our check on 8 files. It flagged all 8. Seven were real or likely holes: an admin check on user_metadata.role in an audit API route, RLS policies that took both the admin flag and the org_id from user metadata, and an invite flow where the invited user's role came from a field they could set themselves before accepting. One we couldn't judge from the code. That's a small sample, picked because it matched the pattern.

How to store Supabase roles safely

1. Move roles to app_metadata

   Only the service role can write it, so set it from server code, for example supabase.auth.admin.updateUserById(id, { app_metadata: { role: "admin" } }). Set paid plans only from a verified payment webhook.

2. Read it from app_metadata in SQL

   Use auth.jwt() -> 'app_metadata' ->> 'role'. For more than a couple of roles, use a roles table with RLS that stops users from changing their own row, and a custom access token hook (Supabase has a guide for role-based access).

3. Fix signup triggers

   Never copy role, plan or admin flags from raw_user_meta_data. Insert a fixed default such as 'user'.

4. Keep user_metadata for display

   Name, avatar and preferences are fine there.

create policy "admins read audit"
on public.audit_log for select
to authenticated
using ((auth.jwt() -> 'user_metadata'
        ->> 'role') = 'admin');

create policy "admins read audit"
on public.audit_log for select
to authenticated
using ((auth.jwt() -> 'app_metadata'
        ->> 'role') = 'admin');

Fix prompt you can paste

Find every place this repo reads role, is_admin, plan, tier, permissions,
org_id or tenant_id from Supabase user_metadata or raw_user_meta_data:
RLS policies, SQL functions, signup triggers, API routes, middleware and
client code. Move those fields to app_metadata (set only from server code
with the service role) or to a roles table whose RLS stops users from
updating their own role. Change signup triggers to insert a fixed default
role. Keep user_metadata for display fields only. Show me each change and
write a test where a normal user calls updateUser({ data: { role: "admin" } })
and still can't reach the admin route.

How Leakcade checks this

Our user_metadata check reads your repo as text. A role, admin flag, plan or org id taken from user_metadata in SQL (policies, functions, signup triggers) is critical. The same read in server code is high, and in client code only it's medium, because it may just change what the UI shows. Display fields and app_metadata are left alone.

Further reading

1. Supabase docs: Row Level Security (auth.jwt and metadata)
2. Supabase Security Advisor: RLS references user_metadata
3. Supabase docs: Custom claims and role-based access control
4. Supabase docs: User management and user data
5. Supabase JS reference: updateUser

FAQ