How to Protect My App Database
Protect your database by enabling Row Level Security (RLS) on every table, using auth.uid() in all policies, keeping your service role key server-side only, setting up regular backups, and monitoring for unusual access patterns. These five steps prevent the vast majority of database attacks on builder-made apps.
Why this matters
Your database is the most valuable target in your application. Attackers do not need to hack your entire system — they just need one misconfigured table to access all your user data.
What's at stake
An unprotected database can be silently read, modified, or deleted. You may not know about the breach until users report missing data or you receive a ransom demand.
Step by step.
Enable Row Level Security on every table
For each table in your Supabase project, run: ALTER TABLE your_table ENABLE ROW LEVEL SECURITY; This is the single most important step. Without RLS, your tables are accessible to anyone with your project URL.
Write proper RLS policies
Add policies that use auth.uid() to restrict access. Example: CREATE POLICY "Users can read own data" ON profiles FOR SELECT USING (auth.uid() = user_id); Add separate policies for SELECT, INSERT, UPDATE, and DELETE.
Keep the service role key server-side
The service role key bypasses all RLS policies. It must only be used in Edge Functions or server-side API routes. Never import it in client-side code or components.
Set up automated backups
Enable automatic daily backups in your Supabase project settings (available on Pro plan). For free tier, manually export your data regularly. Consider syncing critical data to an external backup service.
Monitor database access
Check your Supabase dashboard regularly for unusual patterns — unexpected spikes in API requests, queries from unknown sources, or large data exports. Set up alerts if your plan supports it.
Verify your database protection is actually working
- Automated verification that RLS is enabled and policies are correct
- Continuous monitoring for database security regressions
- Instant alerts if a table is detected without proper protection
Frequently asked questions.
Enable Row Level Security (RLS) on every table that contains user data. This single step prevents the most common and most damaging database vulnerability in builder-made apps.
If a table contains only public, non-sensitive data (like a list of categories), you can use a permissive SELECT policy. But it is safer to enable RLS on every table and explicitly define what is public, rather than leaving tables unprotected.
Without backups, lost data is gone permanently. Supabase provides Point-in-Time Recovery on Pro plans, which lets you restore to any point in the last 7 days. On free plans, you need manual backups.
Yes. The principles are the same for any database: require authentication, restrict access by user, keep admin credentials server-side, back up regularly, and monitor access. The specific tools differ, but the approach is universal.
In the Supabase SQL Editor, switch to the anon role and try querying a protected table. If you can read data that should be restricted, your policies need fixing. Also test as an authenticated user to verify they can only see their own rows.