Lovable + Supabase pre-launch security checklist
Lovable scaffolds Supabase projects fast — and that speed is exactly why most Lovable apps ship with disabled RLS, anon keys in places they should not be, and missing security headers from the deploy host. Run through these fifteen checks before you tweet your launch URL.
15 checks
Tick through each one
Click any item to open the detailed fix guide. The detector tag shows which scanner module flips the state pass or fail when you run a SafeToShip scan.
RLS enabled on every public schema table
CriticalPrompt Lovable: "Enable RLS on every public table and add ownership policies."
Detector: supabase
Service role key only used in server functions
CriticalDetector: js-secrets
.env not exposed at /.env on the deployed URL
CriticalDetector: exposed-files
No third-party API keys in client bundles
CriticalDetector: js-secrets
Content-Security-Policy header set
HighDetector: headers
HSTS header set with max-age ≥ 31536000
HighDetector: headers
X-Frame-Options or frame-ancestors directive blocks framing
HighDetector: headers
CORS does not echo arbitrary origins on credentialed endpoints
CriticalDetector: cors
Session cookies have Secure and HttpOnly flags
HighDetector: cookies
Cookies have SameSite attribute set
MediumDetector: cookies
Valid, non-expiring TLS certificate
CriticalDetector: ssl
SPF record published for the sending domain
MediumDetector: email
DMARC policy set to quarantine or reject
MediumDetector: email
Rate limiting on sign-up and login routes
MediumLovable does not auto-add this — wire it via Supabase Edge Functions or Vercel rate-limit.
Detector: rate-limit
Error monitoring configured (Sentry or similar)
LowDetector: tech-detect
Paste this into Lovable
One prompt that runs the entire checklist as a code review pass.
Audit my Lovable + Supabase app for these 15 security checks: enable RLS on every public table with ownership policies, move all third-party API keys to server-only env vars (no NEXT_PUBLIC_), prevent .env files from being exposed via the deployed URL, set CSP, HSTS, X-Frame-Options, and Permissions-Policy headers via Vercel/Netlify config, restrict CORS to specific origins for credentialed endpoints, set Secure + HttpOnly + SameSite on every session cookie, verify the TLS cert, publish SPF and DMARC for the sending domain, add rate limiting on auth routes, and configure error monitoring. Fix each one in the codebase and confirm with the user before deploying.FAQ
Frequently asked questions
- Do I really need to enable RLS on every table?
- Yes — even tables you think nobody can reach from the client. Supabase auto-enables PostgREST so any anon-role JWT can hit any unprotected table. The default is open. RLS plus explicit policies is the only safe baseline.
- Can SafeToShip check the items automatically?
- Most of them, yes. Click "Scan now" and the items light up with pass/fail per scanner. A few items (rate limiting, monitoring) require manual confirmation — they are best-effort detections.
Per-issue depth
Fix guides for this checklist
Supabase RLS disabled
A Supabase table without RLS is readable (and often writable) by anyone with your anon key. Here is exactly how to turn on RLS and write your first policy.
Read moreExposed Supabase service key
The service role key bypasses all security in Supabase. If it is in your client code, an attacker has full database access. Here is how to find and fix it.
Read moreExposed .env file
An exposed .env file is a critical leak — it contains API keys, database URLs, and secrets. Here is why it happens in vibe-coded apps and how to lock it down.
Read moreHardcoded API key in JS
Any secret in your client bundle is public. Here is how to find them, rotate them, and move the calls server-side.
Read moreMissing CSP header
A missing Content-Security-Policy header lets attackers inject scripts into your site. Here is what CSP does, why you need it, and how to add it in Next.js, Vercel, and Supabase apps.
Read moreRun the scan to confirm each check
60 seconds. Free. No account required.