Is my Supabase database public?
Your Supabase anon key is public by design, so any table without Row Level Security is one fetch away from the open internet. Paste your app’s URL and CheckVibe probes your tables with that public key to show exactly what is readable without RLS, in about 30 seconds.
No repo, no database password, no service-role key required. CheckVibe tests your live URL the way an attacker would.
The Supabase mistakes that expose user data
Live anon-key reads against discoverable tables
Service-role keys leaked into the client bundle
Public buckets exposing user uploads
Leaked-password protection, weak settings
Missing CSP/HSTS, permissive origins
Whether Google and AI engines can read your app
Three steps. One pasted URL.
- 01
Paste your app URL
CheckVibe finds your Supabase project URL and public anon key in the served bundle, the same thing any browser gets.
- 02
Tables probed live
It issues read-only requests with the anon key and flags every table that returns rows without a logged-in session.
- 03
Fix with one prompt
Each exposed table ships as a copy-paste RLS policy and an AI fix prompt for Claude, Cursor, or the Supabase SQL editor.
Frequently asked questions
- How do I know if my Supabase database is public?
- Your Supabase anon key ships in your app’s JavaScript bundle by design: it is public. If a table has no Row Level Security (RLS) policy, anyone who reads that key from your bundle can query the table directly. CheckVibe checks this for you: paste your live URL and it uses the public anon key to attempt reads against your tables, then reports which ones respond without authentication.
- What is Supabase Row Level Security (RLS)?
- RLS is Postgres’ per-row access control. In Supabase it is the line between "only the right user sees their data" and "the whole table is world-readable with the public key." RLS is off by default on new tables, so a table you forgot to lock down is readable by anyone, the single most common Supabase security mistake.
- How does the RLS checker work?
- CheckVibe loads your deployed site, extracts the Supabase project URL and public anon key from the bundle (the same thing any visitor’s browser has), and issues read requests against discoverable tables. Tables that return rows without a session are flagged as readable without RLS. It also checks storage bucket policies and whether your service-role key has leaked. Nothing destructive is written.
- Is it free? Do I need to sign up?
- Scanning is free and runs with no signup: you see your issue count and a sample finding immediately. A free account unlocks the full table-by-table breakdown; paid plans add copy-paste fix prompts (the exact RLS policy to apply), continuous monitoring, and the SEO + AEO scans in the same pass.
- Does CheckVibe see my source code or service-role key?
- No. CheckVibe only reads what your deployed site already serves to the public: it never needs your repo, your database password, or your service-role key. It scans your URL the way an attacker would, which is exactly why it catches what a code review misses.
- How is this different from Supabase’s advisor or other scanners?
- Supabase’s own Security Advisor is excellent and you should use it: it inspects your project from the inside. CheckVibe is the outside view: it tests what is actually reachable from your live URL with the public key, with no project access. Other tools (including Aikido) also run live checks; CheckVibe’s wedge is that it is free, instant, needs no setup or repo, and runs RLS, exposed-key, SEO and AEO checks together in one scan.