Error 42501: permission denied for table
This error occurs when Row Level Security (RLS) policies block access to a table. Learn how to fix it by creating proper RLS policies or using the service role key.
The 42501: permission denied error is one of the most common Supabase errors. It means your query was blocked by Row Level Security (RLS) policies.
Understanding the Error
When you see an error like:
permission denied for table users
Supabase is telling you that:
- The table has Row Level Security enabled
- No RLS policy allows your current operation
- The query was rejected to protect your data
This is actually a good thing - RLS is protecting your data from unauthorized access.
Why This Happens
RLS is Enabled but No Policies Exist
When you enable RLS on a table without creating any policies, all access is denied by default. This is secure by design.
Policies Don't Match Your Use Case
You might have policies, but they don't cover your specific operation (SELECT, INSERT, UPDATE, DELETE) or your user's role.
Using the Wrong API Key
Supabase has two keys:
- anon key - Subject to RLS policies (for client-side use)
- service_role key - Bypasses RLS entirely (for server-side use only)
Using the anon key when you need elevated access causes this error.
How to Fix It
Solution 1: Create an RLS Policy
The proper fix is to create policies that define who can access what:
Solution 2: Allow Public Read Access
For public data like blog posts or products:
Solution 3: Use Service Role Key (Server-Side Only)
For admin operations or server-side code, use the service role key which bypasses RLS:
Warning: Never use the service role key in client-side code. It bypasses all security.
Solution 4: Temporarily Disable RLS (Development Only)
For quick testing during development:
Warning: Never disable RLS in production.
Common RLS Policy Patterns
Authenticated Users Only
Owner-Based Access
Role-Based Access
Debugging Tips
-
Check if RLS is enabled:
SQL -
List existing policies:
SQL -
Test as a specific user:
SQL
Best Practices
- Always create policies when enabling RLS - Don't leave tables with RLS but no policies
- Use the principle of least privilege - Only grant the minimum access needed
- Test policies thoroughly - Check all CRUD operations for each user role
- Keep service role key secure - Only use server-side, never expose to clients
Related Errors
- 42501 on functions - The function's
SECURITY DEFINERsetting may need adjustment - 42501 on sequences - Grant usage on sequences when allowing inserts