Is my Lovable app secure? A practical checklist
Short answer: not automatically. Lovable runs built-in security scans (a Quick scan on every publish and an on-demand Deep scan), and its own docs say those scans help but do not replace a security review. Treat "published" as the start of checking, not the end.
1. Run Lovable's own scans first
Open your project's Security view, run the Quick and Deep scans and fix every Critical finding. They see your code and database config, which an outside scanner cannot.
2. Check Row Level Security on every table
Lovable apps talk to Supabase from the browser with a public anon (or sb_publishable_) key. That's normal, but it means every table in an exposed schema needs RLS turned on and policies scoped to the owner (for example auth.uid() = user_id), not using (true).
How to check: in the Supabase dashboard, open Table Editor or Authentication → Policies and look for tables marked as having RLS disabled, then read every policy that applies to the anon or public role. Supabase's Security Advisor also flags tables without RLS. Then test with two real accounts: user A should never see or edit user B's rows.
3. Make sure no secret key ships to the browser
Anything in your frontend bundle can be downloaded by every visitor. The anon/publishable key is designed to be public; a service_role or sb_secret_ key is not. It bypasses RLS entirely. The same goes for OpenAI, Stripe secret and other third-party keys. Keep secrets in Lovable Secrets and use them only from server-side code such as Edge Functions.
How to check: open your published site, open browser DevTools → Sources (or Network → JS files) and search the bundles for service_role, sb_secret_, sk_live_ and sk-. If a secret key was ever exposed, rotate it; removing it from the code is not enough. Also check your GitHub repo (if you connected one) for a committed .env file.
4. Lock down Edge Functions and storage
An Edge Function that uses a secret key on the server is only safe if it checks who is calling it. If a function sends email, calls a paid API or writes data, it should verify the user's JWT and confirm they're allowed to do that action.
Storage buckets marked Public serve every file to anyone with the URL. That's fine for logos, not for invoices or user uploads. How to check: in Supabase → Storage, look at each bucket's public flag and at the policies on storage.objects.
5. Check what your published site exposes
- Public
/.envfiles or/.git/config - Public JavaScript source maps
- Missing security headers (CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy)
- Cookies without Secure/HttpOnly/SameSite flags, and HTTP that doesn't redirect to HTTPS
How to check: request https://your-site/.env and /.git/config in a browser (you should get a 404), and look at response headers in DevTools → Network.
6. Re-check after every big change
The risky change is usually a new table, a new integration or a pasted key. Re-run your checks whenever you change auth or data access.
Where SniffPup fits
SniffPup scans your published URL the way a stranger would: secrets in your HTML and JS bundles (masked in the report), sensitive files, source maps, headers, cookies and HTTPS, plus whether AI crawlers can read your pages. Every finding comes with a copy-paste fix prompt. On Pro, after you verify you own the domain, a read-only Supabase check uses your site's public anon key to count which tables an anonymous visitor can read (row counts only, never row data) and lists which storage buckets are public. It's passive (about 40 requests or fewer, no logins, no exploit payloads) and the first scan is free. See exactly what the scanner does.
FAQ
Is my Lovable app secure by default?
Not automatically. Lovable runs a Quick scan on every publish and offers a Deep scan, and its docs say these scans do not replace a security review. Check RLS policies, secrets in your frontend and what your published site exposes.
Can SniffPup check my Supabase RLS policies?
Not from the outside. The free scan checks what your published site exposes. Pro users who verify domain ownership get a read-only Supabase check that counts which tables an anonymous visitor can read, using the site's public anon key. It never downloads row data.
A clean report is not a guarantee of security.