Review Supabase RLS in your source code.

For this fictional example, a signed-in person may read only their own draft records. They must not read another person’s draft, and an anonymous caller must not read any draft. If your records are deliberately public or use organization membership, the intended policy will be different.

-- Illustration only: authenticated is a role, not an owner check.
CREATE POLICY "drafts_read" ON public.drafts
  FOR SELECT TO authenticated
  USING (true);

This expression permits every authenticated caller through this policy’s row filter. Exposure still depends on table grants, RLS state, other policies and how requests reach the database. Do not infer deployed access from this snippet alone.

-- Review a migration for the actual schema and existing policies first.
-- This example assumes owner_id is an immutable UUID owner reference.
CREATE POLICY "drafts_owner_read" ON public.drafts
  FOR SELECT TO authenticated
  USING ((select auth.uid()) = owner_id);

Adding a restrictive-looking policy does not remove the broad policy above. PostgreSQL combines permissive policies with OR. A reviewed migration must replace or remove the unwanted broad policy, preserve intended access and check existing grants. This snippet is not a complete migration to paste into production.

For INSERT and UPDATE, review WITH CHECK as well as the rows visible through USING. Verify that a caller cannot create or reassign a row to another owner. Check how the application sets owner IDs instead of trusting a value submitted by the client.

• Find the table definition, every applicable policy and later migrations. A file that enables RLS is not proof that the current database uses it.
• Review grants to public, anon and authenticated roles. An RLS policy does not independently grant table access.
• Trace privileged server clients back to a verified caller and the requested resource. A secret or legacy service-role key can bypass RLS, so a route that accepts an arbitrary record ID needs its own permission checks.
• Inspect SECURITY DEFINER functions, execution grants and caller checks. Table policies do not automatically constrain every privileged function.
• Keep private credentials out of browser-reachable code. A public client key and a privileged secret should not be classified the same way.

1. Create two test users and one private draft for each in an authorized test environment.
2. Confirm each user can read their own record and receives no other user’s private data when requesting the other record’s ID.
3. Confirm anonymous requests receive no private records. Inspect returned data, not just the status code.
4. For writes, test changing the owner and modifying another user’s record. Confirm legitimate writes still work.
5. Test relevant server endpoints and privileged functions separately, then verify the reviewed migration and source version are actually deployed.

A code scan can help locate supported patterns in committed SQL and handlers. Pair it with the Supabase live-app review and authorized permission tests. Incomplete coverage or a disappearing finding is not proof that access is correct.

Can a repository scan verify my deployed RLS?

No. Committed SQL can differ from the deployed schema, grants and policies. A source report is evidence to investigate; use authorized database inspection and runtime permission tests to verify effective access.

Is a Supabase publishable or legacy anon key a secret?

Not by itself. Publishable keys and legacy anon keys are intended for client use, with access constrained by grants, RLS and user authentication. Secret keys and legacy service-role keys can bypass RLS and must not be exposed to a browser.

Does adding auth.uid() make every policy safe?

No. Review the operation, role, ownership relationship, USING and WITH CHECK expressions, grants and any privileged bypass. Other policies or server paths may still widen access.

Product descriptions were checked against the linked vendor guidance on October 27, 2026. Features and plan availability can change. Examples on these pages are authored illustrations, not customer findings or a comparative accuracy benchmark.

• Supabase: row-level security, policy expressions and service keys
• Supabase: API keys and their privileges
• PostgreSQL: row-security policies