Guide Supabase

Supabase "Function Search Path Mutable" warning: what it means and the safe fix

By the PatchAndShip team Last verified:

Short answer

It's a warning, not proof that anything leaked. Supabase's Security Advisor shows it when a database function (for example, a function that runs at sign up) doesn't lock in which parts of the database (schemas) it looks in. That list is called its search path. The fix is to set an empty search path on the function and write every table name with its schema, both in the same change. Then test the part of your app that uses the function.

Why it matters

When a function doesn't set its own search path, it uses the search path of whoever calls it. Supabase says that can make the function behave differently for different users, and could let someone point it at objects they control.

It matters more for functions marked security definer (they run with their creator's rights instead of the caller's). Supabase says that when you use security definer, you must set the search path.

The safe fix, in plain steps

  1. Open the function from the warning in the Security Advisor.
  2. Recreate it with an empty search path (search_path set to empty).
  3. Inside the function, write every table and function with its schema, for example public.profiles instead of profiles.
  4. Keep the function's other settings exactly as they are, such as security definer, its return type and its inputs. Recreating a function sets any setting you leave out back to its default.

Short example, in the form Supabase's lint doc uses:

create or replace function public.example() returns void language sql set search_path = '' as $$ ... $$;

What it does and doesn't change

  • It fixes where the function looks for tables.
  • It doesn't change who can call the function. Supabase notes that any role can call a function by default, including signed out visitors (anon). If that matters for yours, Supabase's guide to securing a database function covers who can call it.

What can break, and how to check

The function behind this warning is often the one that creates a profile row when someone signs up. Supabase's own guide uses a trigger for that and warns: "If the trigger fails, it could block signups, so test your code thoroughly." Its example already has the fix in place, with an empty search path and the table written as public.profiles:

create function public.handle_new_user()
returns trigger
language plpgsql
security definer set search_path = ''
as $$
begin
  insert into public.profiles (id, first_name, last_name)
  values (new.id, new.raw_user_meta_data ->> 'first_name', new.raw_user_meta_data ->> 'last_name');
  return new;
end;
$$;

So test sign up, or whatever uses the function, straight after the change. Then rerun the Security Advisor to see if the warning is gone.

Want a second pair of eyes?

AI agents run the checks and a human engineer reviews and approves every report and change. It is not a penetration test, a security guarantee or a compliance certification.

See plans and prices

Sources