Do Supabase views bypass RLS? How to check

By default, yes, when the view's owner bypasses row level security. Postgres's CREATE VIEW page says that by default "access to the underlying base relations referenced in the view is determined by the permissions of the view owner", and that when a table under the view has row level security enabled, "the row-level security policies of the view owner are applied". Postgres's Row Security Policies page says superusers and roles with BYPASSRLS always bypass row security. Table owners normally bypass it too, unless FORCE ROW LEVEL SECURITY is enabled; FORCE does not override superuser or BYPASSRLS bypass. GRANT says the owner of an object is usually the user that created it. So if one role, such as postgres, created both your tables and the view, the view reads those tables as their owner, and their policies normally do not filter the rows.

Supabase's Views guide puts it this way: "If a privileged role creates a view, everyone reading it does so through that role's permissions." Lint 0010, level ERROR, "View bypasses row-level security", says a view in public is accessible over your project's APIs, and that a view created through Supabase Studio or the Supabase CLI in this default mode will bypass row level security rules and could expose more data over the APIs than the developer intended.

The fix for a view that should respect row level security:

alter view public.your_view set (security_invoker = true);

After that, the caller needs its own grant on each table the view reads, and those tables' row level security policies apply to the caller. security_invoker needs Postgres 15 or later.

This does not mean every view leaks. It depends on who owns the view and who can select from it. The query further down shows both.

The Views guide calls a view "a convenient shortcut to a query". Creating one adds no tables or data. When you read it, Postgres runs the underlying query and returns the results. The question is whose permissions that query runs with.

By default it is the view owner's. CREATE VIEW says this "can be used to provide secure but restricted access to the underlying tables". Lint 0010 calls it "an unintuitive default, chosen for backwards compatibility with older Postgres versions, which makes it easy to accidentally expose more data in views than was intended." Supabase's lints call this default mode SECURITY DEFINER.

With security_invoker set to true, CREATE VIEW says "access to the underlying base relations is determined by the permissions of the user executing the query, rather than the view owner", and the invoking user's row level security policies are used instead of the owner's. The Views guide says the same: the setting checks the querying role's permissions, "which is also what makes the underlying tables' row level security policies apply."

security_invoker arrived in Postgres 15. Lint 0002 says the setting was "introduced in Postgres 15", and the lint 0010 query only reports views on Postgres 15 or later. If you are not sure which version your project runs, select version(); in the SQL editor returns it (version information functions).

Supabase's Views guide example creates a plain transcripts view over three tables and then runs grant all on table transcripts to authenticated;. Its View security section, right below, explains the owner default and how to switch to security_invoker. If you copied the first part, read the second part too.

Keep views and functions apart. CREATE VIEW says functions called inside a view run with the privileges of the caller or of the function's owner, depending on whether each function is SECURITY INVOKER or SECURITY DEFINER, and the view's security_invoker setting does not change that. It also says a view with security_invoker set to false "is not equivalent to a SECURITY DEFINER function and those concepts should not be confused." For functions on the Data API, see Can anyone call your Supabase functions?

The October 30 changelog is about tables. On October 30, 2026 Supabase applies the new behavior to existing projects, and new tables in public need an explicit grant before the Data API can see them. The changelog does not say what this means for views. The points below are how Postgres privileges work, applied to that change.

• New views follow the table defaults. Postgres's ALTER DEFAULT PRIVILEGES page says default privileges cover "tables (including views and foreign tables)". Securing your API lists the default privileges that new tables in public get on existing projects, including select, insert, update, and delete for anon, authenticated, and service_role. Put together: while your project still has those table defaults, a new view in public, created by the role whose default privileges grant that access, gets the same grants as a new table. Once the table defaults are revoked, by the changelog's opt-in SQL or on October 30, a new view needs an explicit grant, the same as a new table.
• The rollback grants every view. The changelog's rollback runs grant select, insert, update, delete on all tables in schema public to anon, authenticated, service_role;. Postgres's GRANT page says "ALL TABLES also affects views and foreign tables". So that statement also grants every view in public to anon and authenticated. If you run it, check your views afterwards with the query below.
• Existing views keep their grants. ALTER DEFAULT PRIVILEGES "does not affect privileges assigned to already-existing objects", and the changelog says existing objects keep their current grants. The changelog says the change touches default privileges in the public schema. Nothing in it sets security_invoker on a view.
• Check the mode before you grant. In the default mode, Postgres's Rules and Privileges page says that, except for security invoker views, users only need privileges on the tables and views named in their own queries. A grant on a default-mode view is enough to read what the view's owner can read through it. If the rows should depend on who is asking, switch the view to security_invoker first.
• An invoker view needs table grants. CREATE VIEW says "the user of a security invoker view must have the relevant permissions on the view and its underlying base relations." Once the October 30 behavior is on, a new table has no grant for anon or authenticated until you add one, so reading an invoker view over it fails for those roles until you grant select on the table. Supabase's 42501 guide says Postgres 42501 errors "imply the request lacked adequate privileges", and that an error like permission denied for table your_table means the querying role may not have the privilege it needs. The grant SQL is in Supabase's Oct 30 change: new tables aren't exposed automatically.

This read-only query lists every view (v) and materialized view (m) in public, skipping ones an extension owns. It is adapted from the queries behind lints 0010 and 0016 in Supabase's open source linter, splinter, and uses the same security_invoker test.

select
    n.nspname as schema_name,
    c.relname as view_name,
    case c.relkind when 'v' then 'view' else 'materialized view' end as kind,
    pg_catalog.pg_get_userbyid(c.relowner) as owner,
    lower(coalesce(c.reloptions::text, '{}'))::text[]
        && array[
            'security_invoker=1',
            'security_invoker=true',
            'security_invoker=yes',
            'security_invoker=on'
        ] as security_invoker,
    pg_catalog.has_table_privilege('anon', c.oid, 'SELECT') as anon_select,
    pg_catalog.has_table_privilege('authenticated', c.oid, 'SELECT') as authenticated_select
from pg_catalog.pg_class c
join pg_catalog.pg_namespace n
    on n.oid = c.relnamespace
left join pg_catalog.pg_depend dep
    on c.oid = dep.objid
    and dep.deptype = 'e'
    and dep.classid = 'pg_catalog.pg_class'::regclass
where c.relkind in ('v', 'm')
  and n.nspname = 'public'
  and dep.objid is null
order by c.relkind, c.relname;

has_table_privilege reports whether a role holds a privilege on a table, and pg_get_userbyid returns a role's name from its id, so owner is the role whose permissions a default-mode view uses.

This query inventories public only. When public is an exposed Data API schema, a regular view with security_invoker false and either SELECT flag true meets lint 0010's conditions on Postgres 15 or later; a materialized view with either flag true meets lint 0016's conditions. The lints also inspect other configured exposed schemas. These flags check table-level SELECT privileges, so false does not rule out access through column-level grants.

If your project uses pg_graphql, yes, for any view anon or authenticated can select. Lint 0026 says any table, view, materialized view, or foreign table that anon can SELECT is visible in pg_graphql introspection at /graphql/v1, regardless of row level security, and that this visibility is governed entirely by GRANT and REVOKE. Lint 0027 says the same for authenticated. To hide a view from a role's GraphQL introspection, remove every effective SELECT privilege on its columns, including access through PUBLIC or inherited roles, then repeat the introspection check as that role.