What does Supabase's "Function Search Path Mutable" warning mean, and how do I fix it?

It means a database function doesn't pin which schemas it looks in, so a table or function with the same name in another schema could be used instead of yours. The fix is one line per function: ALTER FUNCTION ... SET search_path = '', then refer to tables with their schema, like public.profiles.

By Rodolfo Egarter, founder of Shippable · Updated

Why

When a Postgres function mentions a table such as profiles, Postgres finds it by walking the search_path, a list of schemas. If the function doesn't set its own search_path, it uses the caller's. Someone who can create objects in a schema earlier in that list can put a lookalike there and change what the function does.

That matters most for SECURITY DEFINER functions, which run with their owner's rights: hijacking one means running code as the owner. On its own it usually needs another weakness to exploit, which is why it's rated medium. But it's the single most common finding in Bolt repos (50% in our scan), because Bolt's migrations create many helper functions, and it costs one line to fix.

Supabase's Security Advisor reports it as "Function Search Path Mutable" (lint 0011).

How to check

  1. In the Supabase dashboard, open Advisors → Security Advisor and look for Function Search Path Mutable warnings.
  2. For each function listed, set an empty search_path and make every table and function reference schema-qualified (public.my_table, not my_table).
  3. Re-run the advisor, or scan your project with Shippable, to confirm the warnings are gone.
Supabase SQL editor
ALTER FUNCTION public.handle_new_user() SET search_path = ''; -- Inside the function body, qualify names: -- INSERT INTO public.profiles (id) VALUES (new.id);

More on this: Endpoints and functions without access checks, from the Vibe-Code Top 10.

Check your app

Your first app is free, and it is read-only. You prove the app is yours with a one-line tag first.

More questions