Views in exposed schemas run with the caller permissions (security_invoker)

A Postgres view runs with the privileges of the role that owns it, which on Supabase is postgres, a role that bypasses row-level security. So a view over an RLS-protected table, readable through the API, returns every row of the underlying table to anyone who can query the view: the table's policies are never consulted. The view looks like a harmless convenience ('a leaderboard', 'a dashboard summary'), and the RLS on the base table gives a false sense of safety. PostgreSQL 15 added security_invoker, which makes the view evaluate with the caller's privileges and therefore enforce the underlying RLS. Supabase's advisor flags the unsafe default as lint 0010, security definer view. AI tools generate CREATE VIEW freely and almost never add the option, so this is a common quiet bypass of an otherwise correct RLS setup.

Create (or alter) every API-exposed view with security_invoker = true so the caller's RLS applies:

create or replace view public.my_open_tasks
  with (security_invoker = true) as
  select id, title, user_id from public.tasks where done = false;

-- or fix an existing view
alter view public.my_open_tasks set (security_invoker = true);

If a view must read data the caller cannot, put it in a non-exposed schema instead and expose a narrow, security_invoker view or a checked function. For a view over deliberately public data, add the -- INTENTIONALLY_PUBLIC: waiver line directly above CREATE VIEW with the reason.