TL;DR
These prompts help you add Row Level Security (RLS) to your Supabase tables. RLS ensures users can only access their own data, even if someone bypasses your application code and queries the database directly. Without RLS, your data is exposed.
Enable RLS and Create Basic Policies
Use this prompt to enable RLS on all tables and create basic policies:
Enable Row Level Security (RLS) on all tables in my Supabase database.
My schema includes these tables: List your tables, e.g., users, posts, comments, likes
For each table:
- Enable RLS with: ALTER TABLE tablename ENABLE ROW LEVEL SECURITY
- Create a policy for SELECT (read your own data)
- Create a policy for INSERT (create your own data)
- Create a policy for UPDATE (update your own data)
- Create a policy for DELETE (delete your own data)
Assume each table has a user_id column that references auth.uid().
Also:
- Explain what each policy does
- Handle tables without user_id differently
- Consider public vs private data
Common RLS Patterns
User Owns Data
Create RLS policies for a table where users can only access their own data.
Table: your table name User ID column: user_id
Policies needed:
- Users can SELECT only their own rows
- Users can INSERT only with their own user_id
- Users can UPDATE only their own rows
- Users can DELETE only their own rows
The INSERT policy should also prevent users from setting a different user_id.
Generate the complete SQL for these policies.
Team/Organization Access
Create RLS policies for team/organization-based access.
Tables:
- organizations (id, name)
- org_members (org_id, user_id, role)
- projects (id, org_id, name)
Policies needed:
- Users can access organizations they belong to
- Users can access projects in their organizations
- Only admins can create/delete projects
- Members can read but not modify
Generate policies that check membership through org_members table. Include helper functions if needed for checking roles.
Public and Private Data
Create RLS policies for a table with both public and private data.
Table: posts Columns: id, user_id, content, is_public (boolean)
Policies:
- Anyone can SELECT rows where is_public = true
- Authenticated users can SELECT their own rows (public or private)
- Only the owner can UPDATE their posts
- Only the owner can DELETE their posts
- Authenticated users can INSERT posts (as themselves)
Handle both anonymous (not logged in) and authenticated users.
Critical: Without RLS enabled, anyone with your Supabase anon key can query ALL data in your tables. The anon key is meant to be public, RLS is what protects your data. Enable RLS on EVERY table.
Audit Existing Policies
Audit my Supabase RLS policies for security issues.
Check for:
- Tables without RLS enabled
- Tables with RLS but no policies (blocks all access)
- Overly permissive policies (using TRUE)
- Missing policies for certain operations
- Policies that don't properly check auth.uid()
- Bypass opportunities
For each issue found:
- Explain the risk
- Provide the fix
Also check if service_role key is used anywhere in client code (it bypasses RLS).
Pro tip: Use Supabase's Policy Editor in the dashboard to visualize your policies. You can also test policies by switching between different user contexts in the SQL editor.
What happens if I enable RLS but don't add policies?
All access is blocked by default. You need at least one policy per operation (SELECT, INSERT, etc.) to allow any access. This is secure by default but can cause confusion if you forget to add policies.
Can RLS be bypassed?
RLS can only be bypassed using the service_role key, which should never be exposed to clients. If you use the anon key or user JWTs, RLS is always enforced.
Does RLS affect performance?
There's minimal overhead for well-written policies. Supabase adds the policy conditions to queries automatically. Complex policies with many joins may have more impact, but it's usually negligible.
Check Your Supabase Security
Scan your application to find tables without proper RLS policies.
Start Free Scan