How to prevent missing RLS in AI-generated apps
A concrete method for turning tenant and ownership requirements into database-enforced row-level policies, tests and service-role boundaries.
Model ownership explicitly, enable RLS before exposing tables, write policies for each operation and role, keep privileged keys server-side, then test every policy with multiple identities and negative cases.
Define the boundary before writing a policy
RLS cannot repair an ambiguous ownership model. Every protected row needs a reliable path to the user, organization or tenant that owns it. Shared records and administrative access must also be explicit.
Ask who may select, insert, update and delete each row. Those are separate decisions; one broad “authenticated users” rule is rarely enough.
- Add stable owner or tenant identifiers with foreign keys.
- Define membership and administrator relationships explicitly.
- Document which tables are public, user-owned, tenant-owned or server-only.
Treat browser and server access differently
The browser should operate under the end user’s identity and be constrained by RLS. Privileged service credentials bypass those protections and therefore belong only in trusted server-side code with its own authorization checks.
A common failure is to solve a blocked browser request by moving a service key into client code. That removes the protection instead of fixing the policy.
- Expose only publishable or anonymous client credentials in the browser.
- Keep service-role keys in server environment variables.
- Authorize the user before every privileged server operation.
Test denial, not only success
Policy testing must prove that the wrong identity is denied. Create two users in different tenants, seed records for both and test every operation from both perspectives. Also test unauthenticated access and users whose membership has been removed.
Run these checks whenever the schema, claims or membership model changes.
- User A cannot read or change User B’s rows.
- A removed member immediately loses tenant access.
- An administrator receives only the explicitly intended elevated access.
Keep schema and policy changes together
A migration that adds a table without its policies creates a temporary security gap. Create the table, enable RLS, add policies and include tests in the same reviewed change.
Do not depend on the interface to hide data while policies are unfinished.
Common questions
Is authentication the same as RLS?
No. Authentication identifies the user. RLS constrains which database rows that identity may access.
Does enabling RLS automatically secure a table?
Enabling RLS establishes the enforcement boundary, but the application still needs correct policies for the operations and roles it intends to allow.
Can the service role be used in the browser?
No. A privileged service key can bypass row-level policies and must remain in trusted server-side code.
Primary references
Platform behavior changes. These primary sources define the external capabilities referenced in this guide.
Supabase: Row Level Security