Supabase security
Supabase security check
Check your Supabase app for missing Row Level Security, exposed service keys and open tables — and get a fix you can paste for each one.
Row Level Security disabled on table “profiles”
supabase/migrations/002_profiles.sql
In supabase/migrations/002_profiles.sql, the table "profiles" has Row Level Security disabled. Enable RLS on this table and add a policy so users can only select and update their own row (auth.uid() = id). Do not change any other table.
Every finding in your report comes with a prompt like this one.
What we find
The Supabase mistakes we see most
Your anon key is meant to be public. What protects your data is Row Level Security — when it’s set up right.
- critical
Tables without Row Level Security
Every table in an exposed schema is reachable through the Supabase API with your public key. Without RLS, anyone can read and change it.
- critical
service_role key in the browser
This key bypasses every RLS policy. If it ships in your front-end code, anyone has admin access to your database.
- high
Policies that allow everything
A policy using (true), or one that only checks that a user is logged in, gives every account access to every row.
- high
Views and functions that skip RLS
Views and security definer functions can run with elevated rights and return data your policies were supposed to hide.
- medium
Public storage buckets
Invoices, ID scans or private uploads in a public bucket can be downloaded by anyone who finds the URL.
- medium
Privileged calls from the client
Admin actions, credits or payments handled from the browser instead of a server route or an edge function.
Free scan or audit?
Two levels of checking
The free scan looks at your live app from the outside. The audit reads your code and your database rules.
Free scan
$0- Whether your Supabase URL and public key are exposed (normal, but it tells us your setup)
- A service_role key or other secrets leaked in your public JavaScript
- Exposed .env files, Git folders and source maps
- Missing security headers and HTTPS problems
Express audit
$99- RLS status and every policy on every table, from your migrations
- Views, functions and storage policies
- Where the service_role key is used in your code
- Edge functions and API routes that touch your data
Want to understand it first? Read our guide: Supabase Row Level Security explained
FAQ
Questions, answered
Is it a problem that my Supabase anon key is public?
No. The anon key is designed to be used in the browser. It’s only safe if Row Level Security is enabled on your tables and your policies are correct — that’s exactly what we check.
Do you access my database?
The free scan never reads your data. The audit reads your schema and policies from your code. Testing live tables directly is only done on paid audits, after you prove you own the app.
Supabase already has a Security Advisor. Why use ScanMyApp?
Supabase’s advisor is a good start for database settings. We also read your application code — keys, API routes, edge functions, how policies match your logic — and explain each issue in plain English with a fix prompt.
My app was built with Lovable or Bolt. Does this apply?
Yes. Most Lovable and Bolt apps use Supabase, and their security depends on the same RLS policies and keys.
Check your app now
Start with the free scan. Go deeper with the $99 express audit.
Request the express audit