Supabase RLS Explained in Plain English

What Supabase is in plain English

Supabase is a set of hosted services that can give an app a database, user accounts, file storage, and APIs. It is where important app data may live after a user clicks a button in the interface.

That convenience does not make the access rules automatic. Your app still needs clear answers to: who can read this data, who can add it, who can change it, and who must never see it?

RLS explained with a building analogy

Row Level Security, usually called RLS, is a set of database rules that can decide which individual records a request may read or change.

Supabase = the building that hosts your app data
Tables = rooms that hold different kinds of information
Rows = individual records inside those rooms
RLS = the door rules for who can see or change each record
A frontend button = a sign on the wall; RLS = the actual lock on the door

Why “the app works” proves very little

A successful test with one account usually proves only that one allowed path worked. It does not show what an anonymous visitor, a different user, or a guessed record ID can access.

The UI can hide a button while the database still accepts the request
A logged-in user may still be able to read another user’s rows
A passing build does not inspect Supabase dashboard policies
A test account may have more access than a normal user
Storage files can have separate rules from database rows

Think in four access levels

Public data: information anyone may read, such as a public article or catalog item
Logged-in user data: records a signed-in user may access under an ownership rule
Admin-only data: records or actions reserved for a trusted administrative role
Service-role/server-only access: privileged operations that must stay on a trusted server path
For every table, write the intended level in plain English before asking AI to create or change policies

Common beginner mistakes

RLS is disabled because enabling it initially caused an error
A policy is so broad that every logged-in user can read every row
A user ID comes from the browser and is trusted without server or database checks
The service-role key is placed in client code, a public variable, or a committed file
The frontend hides admin controls but the backend does not enforce the same boundary
Storage buckets are forgotten even though they contain private uploads
Only SELECT is reviewed while INSERT, UPDATE, and DELETE remain open or incorrect

Plain-English RLS checklist

Use this as a conversation starter and test plan. It is not a security certification.

List each table and state who may read, create, edit, and delete its rows
Confirm RLS is enabled for tables that need user or role isolation
Review policies for anonymous, owner, different-user, and admin-like cases
Test a user trying to read and change another user’s record
Check that ownership comes from a trusted identity, not only a submitted ID
Keep service-role operations on the server and out of browser bundles
Review private storage buckets, upload rules, download paths, and deletion
Record what the repository proves and what requires a Supabase dashboard check

Copy-paste Codex RLS audit prompt

Prompt 61

Audit RLS without changing it

Copy-paste prompt

Audit this app’s Supabase Row Level Security without changing files, creating policies, disabling security, or printing secret values. For every relevant table, report the intended owner/access rule in plain English, whether RLS and policies are visible in this repository, which operations are covered (SELECT, INSERT, UPDATE, DELETE), and which tests are missing. Check for client-trusted user IDs, service-role exposure, admin-only paths, storage buckets, and data returned to the browser. Separate verified repository evidence from assumptions and Supabase dashboard checks I must perform manually. Do not claim the app is secure or that RLS is correct without evidence and tests.

Run the prompt in audit-only mode first. A code assistant cannot see dashboard settings unless you deliberately provide safe, non-secret evidence.

What this guide cannot prove

This guide explains how to think about RLS; it does not prove that any particular app is protected.

The actual Supabase dashboard configuration and enabled policies
Whether production uses the same schema and variables as local development
Whether policies behave correctly under real anonymous, owner, non-owner, and admin tests
Whether storage, auth, edge functions, payment access, and logs have matching controls
Whether a secret has already been exposed in history, logs, screenshots, or prompts
Manual verification by someone with the right project access is still required before launch