Is Supabase safe? The pre-launch checklist
Supabase is a secure backend when it's configured, and a wide-open one when it isn't. Your anon key is meant to live in the browser, and that is safe only because Row-Level Security is supposed to stand between it and your data. Leave RLS off on a single table and that table is readable, and often writable, by anyone who opens your app. Two more Supabase-specific traps: the service_role key bypasses RLS entirely and must never reach client code, and Storage buckets have their own access rules that a locked database does not cover.
Where Supabase apps leak most (Supabase (Postgres, Auth, Storage))
- A table with Row-Level Security turned offArgosX auto-checks
The anon key in your page can read, and often write, any table that has RLS off. It has to be on for every table, with a policy that says who sees which rows.
- The service_role key served to the browserArgosX auto-checks
service_role ignores RLS completely. If it appears anywhere in your page source or network calls, your entire database is open regardless of your policies.
- Public Storage buckets, or RPC functions that skip the caller checkManual review
RLS on your tables doesn't cover Storage buckets or SECURITY DEFINER functions. A public bucket or an unguarded RPC can leak files and rows a table policy would have blocked. Manual review item.
Here's the full pre-launch checklist. For Supabase, the database and secret-key sections are the ones to work first: every table needs its own RLS policy and no service_role key can be in the browser. ArgosX verifies both against your live app on a free scan.
Built by ArgosX — independent verification for AI-built apps.
ArgosX auto-checks 38 of these free right now. 5 need a signed-in Pro scan to verify as a real user. The remaining 74 are tagged Human, judgment calls a scanner can't make alone, which is exactly what our $249/scan Human-Verified tier adds on top. Between automated and human review, that's nearly all 117 checks off your plate.
Your database & data
0/13The number-one way AI-built apps leak: the database is wide open to anyone who views the page source. This is where a scan pays for itself.
6 auto-checked · 6 need human review
Secret keys & API tokens
0/10AI tools love to paste real keys straight into the frontend. Anyone can open your JavaScript and read them.
6 auto-checked · 4 need human review
Login & accounts
0/14Getting sign-in right is where AI-generated apps quietly cut corners — no rate limits, no email checks, sessions that never expire.
1 auto-checked · 12 need human review
Who can access what
0/11The hardest thing for AI to get right: making sure a regular user can't reach admin pages or do admin things just by asking.
2 auto-checked · 7 need human review
Forms, inputs & uploads
0/13Anywhere a user can type or upload, someone will try to break it. These checks keep bad input from becoming a bad day.
2 auto-checked · 11 need human review
Payments & billing
0/8If money moves through your app, the price and the entitlement have to be decided by your server — never by the browser.
7 need human review
Going live: headers, HTTPS & CORS
0/13The boring settings that browsers rely on to protect your users. Most of these ArgosX can confirm for you in seconds.
10 auto-checked · 3 need human review
Accessibility, SEO & error states
0/16The trust-and-polish layer. It won't get you hacked, but broken states and inaccessible UI quietly cost you users — and ArgosX checks a lot of it free.
8 auto-checked · 8 need human review
AI features & chatbots
0/7If your app has an AI chat or assistant — and most vibe-coded apps do — it's a brand-new attack surface most builders never test.
1 auto-checked · 6 need human review
Business logic & edge cases
0/6The bugs no scanner alone can find: places where the app does exactly what it was told, but the rules were wrong.
6 need human review
Third-party integrations
0/6The services you wired in — Stripe, OpenAI, SendGrid, Google login — each add a way in if they're set up loosely.
2 auto-checked · 4 need human review
Two ways to verify your Supabase app
The database and exposed-secret items above aren't just advice — ArgosX checks them against your live app and proves what's exposed with a copy-paste reproduction.
One-off
Run a free scan
Paste your live URL and get the automatable checks run in seconds — no signup for the free tier.
Scan my Supabase app free →While you build
Add the ArgosX MCP server
Building with Cursor, Claude Code or another AI agent? Add argosx-mcp so your agent can run these security checks as it writes the code.
npx argosx-mcpOr run a scan without it →Frequently asked
Is it safe to expose the Supabase anon key in my frontend?
Yes, that's what it's for, but only if Row-Level Security is on for every table. The anon key is a publishable key: it identifies your project, it isn't a secret. Its safety depends entirely on your RLS policies, because without them the anon key can read and write tables directly. Turn RLS on everywhere and write policies, then run a free ArgosX scan to confirm what an anonymous visitor can actually reach.
Does turning on Row-Level Security block everything?
Turning RLS on with no policy denies all access to that table, which is the safe default, but it's not the finish line. You then add policies that grant exactly the access you intend, for example 'a user can read and write only their own rows'. The mistake to avoid is a policy so broad (like 'true') that it re-opens the table to everyone. The checklist covers both 'RLS is on' and 'the policy is actually scoped'.
What's the difference between the anon key and the service_role key?
The anon key is public and always subject to your RLS policies, so it's safe in the browser. The service_role key bypasses RLS entirely and can read and write everything, so it belongs only in server-side code and must never be shipped to the client. A leaked service_role key makes every RLS policy you wrote irrelevant. ArgosX flags a real service_role key if it finds one served to the browser.
Is my Lovable / Bolt / v0 app safe to launch?
Often not without a check. AI coding tools generate working UI fast, but they routinely skip the security layer — most commonly leaving the database readable by anyone and pasting real API keys into the frontend. Work through this checklist before you launch, and run a free ArgosX scan to confirm the automatable items against your live app.
What's the most common way AI-built apps get hacked?
An exposed database. Tools like Supabase, Firebase and Base44 need Row-Level Security switched on and configured per table. When it's missing — which is the default in many quickstarts — anyone can download your entire users table using the public key that's already in your page source. It's the first thing this checklist covers.
Did my AI app leak my database or API keys?
You can check in seconds. Open your app, view the page source or network tab, and look for a service-role key or private API key. If your database has no Row-Level Security, the public key alone can dump your data. ArgosX automates both checks and shows you a copy-paste reproduction if it finds a leak.
How many of these 117 checks can ArgosX do for me?
ArgosX automatically verifies 38 of them on a free public scan — the database, secret-key, HTTPS/header and accessibility items that a black-box scan can confirm from the outside. The rest are manual, because they depend on your app's logic or business rules. A paid Pro scan also signs in and tests access-control items like IDOR and privilege escalation.
Do I need to be technical to use this checklist?
No. Every item is written in plain language with a one-line reason it matters, not security jargon. Check off what you've handled, and the page remembers your progress in your browser so you can come back to it.
Is the ArgosX scan really free?
The public-surface scan is free and needs no signup — enter your URL and it runs read-only against the pages anyone can already see. The $99 Pro scan additionally signs in and tests your authenticated app; the $249 tier adds a human reviewer.