Supabase RPC and SECURITY DEFINER review: stop function-level bypasses
Review Supabase RPC exposure, EXECUTE grants, SECURITY DEFINER functions, search_path safety, parameter authorization, and backend-only wrappers.
Inside this guide
- Public EXECUTE grants can expose privileged logic outside your UI.
- SECURITY DEFINER functions need search_path, input validation, and explicit authorization review.
- Sensitive RPC calls are often better behind server routes.
RPC is part of your public API
If a function is executable by anon or authenticated, an attacker can call it directly. They can change parameters, replay calls, and test boundary cases your UI never exposes.
That does not mean RPC is bad. It means function grants and function internals deserve the same review as tables and policies.
Inventory executable functions
List every function callable by PUBLIC, anon, or authenticated. Flag functions that read sensitive tables, write data, send webhooks, change roles, or run as SECURITY DEFINER.
select
n.nspname as schema_name,
p.proname as function_name,
p.prosecdef as security_definer,
array_to_string(p.proacl, ',') as acl
from pg_proc p
join pg_namespace n on n.oid = p.pronamespace
where n.nspname not in ('pg_catalog', 'information_schema')
order by 1, 2;Review SECURITY DEFINER with extra suspicion
SECURITY DEFINER functions execute with the function owner's privileges. That can be valid for controlled server workflows, but dangerous for browser-callable endpoints.
Set a fixed search_path, validate all inputs, and check authorization inside the function or before calling it. Avoid dynamic SQL unless it is heavily constrained.
Prefer server wrappers for privileged actions
When a function performs privileged work, hide it from browser roles and expose a server route instead. The server can authenticate, authorize, rate limit, log, and call the function with trusted credentials.
revoke execute on function public.recalculate_billing(uuid) from public, anon, authenticated;FAQ
Is SECURITY DEFINER always unsafe?
No. It is a powerful tool. Risk comes from public execute grants, unsafe search_path, weak parameter checks, and missing authorization.
Can RLS apply inside functions?
It depends on role and function design. SECURITY DEFINER can bypass normal caller behavior, so test the function directly.