Supabase Row Level Security (RLS) gives your database a strong row-level enforcement layer, but it does not design your authorization model for you. Your team still needs to choose table grants, write policies for each operation and role, protect views and functions, keep privileged credentials server-side, and test both allowed and denied access.
What RLS enforces—and what it does not
PostgreSQL evaluates RLS policies when a role accesses a protected table. A policy can add a row condition to a query—for example, allowing a user to see rows whose user_id matches auth.uid(). Supabase Auth helpers provide request identity to policies. Because enforcement happens in the database, it applies to requests reaching that table through different clients or database tools, subject to grants, bypass privileges, and other database surfaces. Supabase’s RLS documentation explains the policy model.
As an Amazon Associate I earn from qualifying purchases.
Two separate checks matter: grants decide whether a role may attempt an operation on a table; policies decide which rows that operation may affect. Creating a policy does not remove a grant already given. Some existing Supabase projects automatically grant anon and authenticated access to tables in the public schema, so inspect the privileges in your own project rather than assuming RLS alone closed access.
Start with roles, operations, and grants
For each exposed table, list the roles that should reach it and the operations each role needs. Then grant only the necessary table privileges. A policy cannot compensate for an unnecessarily broad grant: it filters rows for a permitted operation, not whether the role should have been permitted to attempt that operation in the first place.
#1 Best Overall
Supabase recommends operation-specific policies for SELECT, INSERT, UPDATE, and DELETE. Name the intended target roles with each policy’s TO clause; do not rely on an unstated assumption about which roles a policy applies to. Supabase’s Postgres roles guide covers roles and privileges.
Write policies around the row before and after a change
Policy expressions differ by operation. USING filters rows an operation may see or target; WITH CHECK validates row values being inserted or produced by an update. For an owner-only table, a common invariant is that the authenticated user’s ID matches the row’s user_id.
| Operation | Policy condition to consider | What it protects |
|---|---|---|
SELECT |
USING |
Which existing rows the role can read. |
INSERT |
WITH CHECK |
Whether the new row has permitted values, such as the caller’s own user_id. |
UPDATE |
USING and WITH CHECK |
Whether the existing row can be targeted and whether the resulting row remains permitted. |
DELETE |
USING |
Which existing rows the role can delete. |
For ownership-based updates, checking only the old row is not enough: a user could otherwise change user_id and transfer the row. Check the existing row with USING and the resulting row with WITH CHECK. Supabase also notes that an UPDATE needs a corresponding SELECT policy to work as expected. Treat the ownership pattern as a starting point to adapt and test, not as a complete policy for every application.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
auth.uid() returns null when there is no authenticated user. An equality check against null does not match, but an explicit authentication check can make the policy’s intent easier to understand. Also consider whether JWT claims are safe and current enough for the particular authorization decision; do not treat every claim as authoritative by default.
Review views, functions, and columns separately
Views
Views commonly bypass underlying RLS in Supabase configurations. On PostgreSQL 15 and later, a view can use security_invoker = true so underlying policies apply to anon and authenticated callers. For older PostgreSQL versions, Supabase advises revoking those roles’ access to the view or placing it in an unexposed schema. Check the project’s actual PostgreSQL version and API exposure configuration before relying on either approach. See Supabase’s RLS guidance.
Functions
RLS does not govern function execution. Grant EXECUTE only to roles that need it, and review SECURITY DEFINER functions especially carefully because they run with their owner’s privileges. Supabase advises setting an empty search_path and schema-qualifying objects inside such a function. Do not place a privileged security-definer function in an exposed schema. See Securing your API and the RLS guide.
Columns
RLS filters rows, not columns. If a role must not receive particular columns, review column privileges or use a separate table or view design. Supabase describes column-level privileges as an advanced control and recommends RLS with a dedicated table for role-specific data in common cases. See Column Level Security.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Clear out junk files and repair common Windows errorsFree Scan →Keep privileged credentials and bypass paths out of clients
Supabase’s service_role bypasses RLS. Secret and service-role keys therefore belong on trusted server-side paths, not in browser or other client code. A table’s ordinary client policies do not make a separate privileged path safe. Review where keys are stored and which server components can use them. See Supabase’s secure-data guidance and its Postgres roles guide.
Prove the rules with tests, then check query cost
SQL that looks restrictive is not proof that access behaves as intended. Supabase recommends a SQL test file for each RLS-protected table, with allowed and denied cases for all four operations and for both anon and authenticated roles. For shared tables, add member and non-member cases. Run the tests with supabase test db and address failures before treating the rules as reliable. The RLS guide describes this testing approach.
Policy filters also affect query work as data grows. Index columns used in policy conditions. Supabase notes that wrapping row-independent helpers such as auth.uid() in a scalar SELECT can let PostgreSQL evaluate or cache the result once per statement rather than for every candidate row. The benefit depends on the query and policy shape, so assess it against your workload and inspect query plans when necessary; it is not a universal performance guarantee.
Quick Recap
A practical review for one exposed table
- Inventory access: list each role that can reach the table and whether it needs
SELECT,INSERT,UPDATE, orDELETE. - Inspect grants: verify the actual privileges for those roles; remove operations they do not need rather than expecting policies to revoke them.
- Define row invariants: describe which rows each role may read, create, change, or delete, including the permitted values after an insert or update.
- Write operation-specific policies: use the appropriate
USINGandWITH CHECKconditions, name target roles, and account for the associatedSELECTpolicy needed for updates. - Audit adjacent surfaces: check views, function execution rights, security-definer functions, column exposure, and any server-side path using privileged keys.
- Test both outcomes: exercise allowed and denied operations for anonymous, authenticated, and relevant member/non-member cases using
supabase test db. - Review performance: index policy-filter columns and use workload evidence or query plans to assess policy cost.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
Recommended Free Tools
