Can anyone call your Supabase functions?

Yes, unless you revoked it. Supabase's Database functions guide says that by default any role can run a database function, and that you call one from your app with rpc(). Lint 0028 says that if anon has EXECUTE on a security definer function, anyone with the public anon key can call it through POST /rest/v1/rpc/<name>.

Two defaults stack. PostgreSQL grants EXECUTE on a new function to PUBLIC, and a grant to PUBLIC goes to every role on the system. Securing your API says that on existing projects, new functions in public also get execute for anon, authenticated, and service_role through default privileges.

The function's security mode decides whose privileges the body runs with. CREATE FUNCTION says SECURITY INVOKER, the default, runs as the caller, and SECURITY DEFINER runs as the owner. The Database functions guide's warning is direct: 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, and any role can call it by default, including anon.

If a function should not be on the API for everyone, revoke EXECUTE from PUBLIC and from the client roles, then grant it back only where it belongs:

-- Use the name and argument types from the owner query further down
revoke execute on function public.your_function(uuid) from public, anon, authenticated;

-- Grant it back only to the roles that should call it, for example signed-in users
grant execute on function public.your_function(uuid) to authenticated;

Leave out the grant when no browser role should call the function. Revoking from anon alone is not enough. The lint docs say to revoke from PUBLIC as well, because the Postgres default grant lives there, and that revoking from anon alone usually leaves the function callable by every signed-up user.

As of October 21, 2026 (Pacific time), two snippets in lint 0028's Quick Reference table leave PUBLIC's execute in place, so anon can still call the functions they target. revoke execute on all functions in schema public from anon; removes only the grant to anon, so a function that still has the default grant to PUBLIC stays callable. alter default privileges in schema public revoke execute on functions from anon, public; is limited to one schema. The Database functions guide says a revoke limited to one schema has no effect on a global default, and Securing your API says Postgres grants execute to PUBLIC on new functions through a global default. Use the revoke block above for existing functions, and the statements in the next section for new ones.

The October 30 changelog is about tables. It names October 30, 2026 as the day the new behavior is enforced on existing projects, and its opt-in SQL revokes default privileges on tables and sequences. It has no statement for functions. Grants for new tables are in Supabase's Oct 30 change: new tables aren't exposed automatically.

Securing your API lists what stays in place when you disable Automatically expose new tables in the Data API settings. For functions it says: "New functions are callable by every role. Postgres grants execute to PUBLIC through a global default, and a revoke limited to one schema can't remove it." The same page's default privileges query leaves out that PUBLIC grant, so an empty result there does not mean new functions are locked.

To make new tables, sequences, and functions in public wait for an explicit grant, that guide runs these statements in the SQL editor:

alter default privileges for role postgres in schema public
  revoke all on tables from anon, authenticated, service_role;

alter default privileges for role postgres in schema public
  revoke all on sequences from anon, authenticated, service_role;

alter default privileges for role postgres in schema public
  revoke all on functions from anon, authenticated, service_role;

alter default privileges for role postgres
  revoke execute on functions from public;

The last statement has no in schema, on purpose. The Database functions guide says a revoke limited to one schema has no effect on the global default. Securing your API warns that the last statement also restricts functions postgres creates in other schemas, including helper functions your row level security policies call. Grant execute on each of those to the roles that call them, or the policies that use them fail.

Default privileges only change functions created later. The Database functions guide restricts the functions you already have with a separate revoke on every function in the schema, from both public and the roles you want to restrict:

revoke execute on all functions in schema public from public;
revoke execute on all functions in schema public from anon, authenticated;

That revokes every function in public, including ones your app or a policy calls on purpose. Grant those back one by one before you deploy.

Lint 0028 and lint 0029 give this read-only query to see who each security definer function in public runs as:

select
    p.proname,
    pg_get_function_identity_arguments(p.oid) as args,
    pg_catalog.pg_get_userbyid(p.proowner) as owner,
    p.prosecdef as security_definer
from pg_catalog.pg_proc p
join pg_catalog.pg_namespace n on n.oid = p.pronamespace
where n.nspname = 'public'
  and p.prosecdef
order by p.proname;

The lint docs say that when the owner is a high-privilege role, the function can read and write everything that role can. args is the argument list to paste into revoke execute on function public.name(args).

This read-only query adds who can call each function in public. It uses has_function_privilege, which reports whether a role holds EXECUTE. A grant to PUBLIC counts, because that grant goes to every role.

select
    p.proname,
    pg_get_function_identity_arguments(p.oid) as args,
    pg_catalog.pg_get_userbyid(p.proowner) as owner,
    p.prosecdef as security_definer,
    has_function_privilege('anon', p.oid, 'EXECUTE') as anon_execute,
    has_function_privilege('authenticated', p.oid, 'EXECUTE') as authenticated_execute
from pg_catalog.pg_proc p
join pg_catalog.pg_namespace n on n.oid = p.pronamespace
where n.nspname = 'public'
order by p.prosecdef desc, p.proname;

A row with security_definer true and anon_execute true is what lint 0028 reports. With authenticated_execute true it is lint 0029. A security invoker row with anon_execute true is still callable, but it runs as the caller, so row level security applies to the tables it touches. The lint docs leave those to the table lints, 0008_rls_enabled_no_policy and 0013_rls_disabled_in_public.

No. The lint docs say disabling pg_graphql closes the /graphql/v1 query and mutation surface, which is one of two ways the function is reachable. The function is still callable through PostgREST at /rest/v1/rpc/<name>, the lint keeps firing, and the remediation above is still required. Disable pg_graphql only when the app does not use GraphQL, and do not count it as the fix.

Views are a separate lint. Lint 0010, "View bypasses row-level security", says Postgres views default to security definer and use the permissions of the view's creator. Lint 0002 says a public security definer view over auth.users exposes all user records to all API users. Lint 0010's fix for a view that should respect row level security is with (security_invoker=on). To check your views, see Do Supabase views bypass RLS?.