Is it safe to have the Supabase anon key in my frontend code?

Yes, as long as row-level security is on. Supabase designs the publishable (anon) key to be public and says it is safe in web pages and source code, because row-level security decides what that key can reach. Enable RLS on every table before you deploy. The secret or service_role key is different: it bypasses every RLS policy and must never reach a browser, not even on localhost.

Does Lovable's security scan make my app secure?

It helps, and it has limits. Lovable says every project gets a free pre-publish security scan with recommendations, and applying them is up to you. Scanners are good at configuration problems such as tables without row-level security. They cannot tell whether user A should see user B's records, or whether an auth function has its logic upside down. Test those yourself with two accounts, or get someone to review the code.

How do I check if my Supabase database is exposed?

Open the Security Advisor in your Supabase dashboard. An error titled "Table publicly accessible" means row-level security is off on a table in the public schema, and Supabase warns that anyone with your project URL can then read, edit and delete its data. Fix those first. Then read each policy, because a policy that allows every row still counts as RLS enabled and still exposes everything.

Do I need a penetration test before launching a vibe-coded app?

Not always. For a small beta with no sensitive data, working through this checklist and fixing the failures is a reasonable start. Get an independent review before launch if you take payments, store health, financial or children's data, sell to companies that will send you a security questionnaire, or have an AI feature that reads documents or calls tools. In those cases one missed check can become a reportable breach.

What should I do if a check shows my data was already exposed?

Close the hole first: enable row-level security, make buckets private and rotate any leaked keys. Then look through your database and hosting logs for access you do not recognise. If personal data was exposed and that is likely to put people at risk, UK GDPR requires you to tell the ICO without undue delay and within 72 hours of becoming aware. Keep a record of the breach either way.

Vibe-Coded App Security Checklist: 15 Checks

Before a vibe-coded app takes real users, payments or personal data, run fifteen checks covering database access rules, leaked keys, authentication, file storage, AI cost limits, dependencies, logging, payments and backups. Most of them need only a browser and your Supabase or Firebase dashboard. If you only have an hour, start with row-level security, secret keys in the browser and auth checks on API routes, because each of those can expose the whole database.

This list is for founders who built with Lovable, Bolt, Cursor, v0 or Replit on top of Supabase or Firebase. The tools produce working features quickly. What they rarely do unprompted is decide who is allowed to use each feature, and that gap never shows when you click through the app logged in as yourself.

How insecure are vibe-coded apps?

The research is consistent. Veracode tested more than 100 large language models in 2025 and found that 45% of the code samples failed security tests and introduced OWASP Top 10 vulnerabilities. Cross-site scripting was the worst category: the models failed to defend against it in 86% of relevant samples. Veracode’s 2026 update, reported by SD Times in July, found an average security pass rate of 56%. In other words, models still fail nearly 44% of security tasks when nobody asks for security, barely changed from the year before.

Symbiotic Security scanned 1,072 Supabase-backed apps built with tools such as Lovable, v0, Bolt.new, Replit and Windsurf. 98% had at least one finding and 16% had a critical one. 172 sites allowed data to be deleted without logging in. To be fair to the tools, the sample came from search and discovery pipelines rather than a random draw, and many findings were low severity, such as missing headers.

The Register reported in February 2026 on one Lovable-hosted app, showcased on Lovable’s Discover page, that exposed 18,697 user records. The researcher found 16 vulnerabilities, six of them critical. In one auth function the logic was inverted, so it blocked signed-in users and let anonymous visitors through. Lovable said the project included code it had not generated and that the database was not hosted by Lovable. Either way, the app looked finished, had more than 100,000 views and still let anonymous visitors in.

The 15-point security checklist

Only test apps you own. Where a check says “ask your assistant”, Cursor, Lovable or Bolt can run the command or write the small script for you.

#	Check	How to check it yourself	If this fails
1	Row-level security on every table	Open the Security Advisor in Supabase. A “Table publicly accessible” error means anyone with your project URL can read, edit and delete that table. On Firebase, look for `allow read, write: if true` in your rules.	Enable RLS and write a policy per table, usually tying rows to `auth.uid()`. A policy of `using (true)` lets everyone in.
2	No secret keys in the browser	On your live site press F12, then Ctrl+Shift+F (Cmd+Option+F on a Mac) to search all loaded files for `service_role`, `sb_secret_` and `sk_live_`. Any variable starting `VITE_` or `NEXT_PUBLIC_` ships to the browser.	Rotate the key today. Deleting it from the code does not un-leak it. Move the call into a server route or edge function.
3	Auth check on every API route and server action	Log out, copy a request from the Network tab as cURL, strip the cookie or Authorization header and replay it. You should get a 401 or 403, never data.	Add the check inside each handler. A login redirect on the page only hides the button. Next.js server actions are reachable by direct POST.
4	Changing an ID in the URL (IDOR)	Create two test accounts. As user A, open one of your records and swap its ID in the URL for one of user B’s.	If you can see B’s data, check ownership on every object, in the RLS policy or the handler. Random IDs make guessing harder but fix nothing.
5	Storage bucket permissions	List which Supabase Storage buckets are public. Open the URL of a private document in a logged-out private window.	Move IDs, invoices and contracts to a private bucket, serve them with short-lived signed URLs and scope upload policies to the user’s own folder.
6	Rate limits and AI cost abuse	Check whether the endpoint that calls your AI model works without logging in. Ask your assistant for a script that calls it 50 times in a minute, and check your provider account for a spending limit.	Require login, add per-user quotas and set a hard budget with the model provider. An open AI endpoint is a bill someone else runs up.
7	Input validation and injection	Type `' OR '1'='1` and `<script>alert(1)</script>` into forms and search boxes. Ask your assistant to list every query built by joining strings.	Use parameterised queries or the Supabase query builder, validate input with a schema library such as Zod and never render user text as raw HTML.
8	CORS	Ask your assistant to call your API with a fake `Origin` header. If the response echoes that origin and allows credentials, other websites may be able to read your API’s answers using a visitor’s session.	Allow only your own domains. A wildcard is acceptable for genuinely public data only.
9	Secrets committed to git	Turn on GitHub secret scanning (free on public repositories) or run the open-source gitleaks tool. A key deleted in a later commit is still in the history.	Rotate the credential first, as GitHub advises. Rewriting history is optional once the key is dead.
10	Vulnerable dependencies	Run `npm audit` and read the high and critical items. Check every package the AI added really exists and is the one you meant.	Update and retest. Be wary of `npm audit fix --force`, which can install breaking major versions.
11	Security headers and CSP	Scan your domain with Mozilla’s HTTP Observatory, which grades your security headers. Symbiotic found no Content-Security-Policy on 97% of the apps it scanned.	Add headers in your hosting config. Start the CSP in report-only mode, because a strict policy can break scripts.
12	Personal data in logs (UK GDPR)	Search your hosting, database, error-tracking and AI provider logs for a test user’s email address and a full prompt. Prompts contain whatever users type.	Redact or drop those fields and shorten retention. UK GDPR requires personal data to be limited to what is necessary, and logs count.
13	Payment webhook signatures	Confirm the Stripe handler verifies the `Stripe-Signature` header with your `whsec_` secret on the raw request body. Then send it a fake event: it must be rejected.	Use Stripe’s library. Stripe warns that without verification an attacker can send fake events that fulfil orders or grant access.
14	Admin routes and test accounts	Visit `/admin` and `/api/admin` logged out and as a normal user. Look through your user list for test and demo accounts. Check a user cannot change their own role by editing a profile request.	Delete test accounts, put admin routes behind a server-side role check and make the role column writable only by the server.
15	Backups and a restore test	Supabase takes daily backups only on Pro, Team and Enterprise plans. Free projects should export with `supabase db dump`. Storage files are not in database backups.	Restore last night’s backup into a separate project and log in. A backup you have never restored is a guess.

Which checks can I do myself, and when do I need help?

More of them than you might expect. Checks 1, 2, 5, 9, 11, 14 and 15 need nothing beyond a browser, your dashboards and some patience. Checks 3, 4, 6 and 10 need a test account or a command your coding assistant can run for you. Finding a problem is the easy half. Fixing it properly is where founders get stuck, especially RLS policies, injection, CORS and webhook handling, which all depend on reading code you did not write.

Get help from someone who reads code when:

a check fails and you cannot explain why the fix works;
you take payments, or store health, financial or children’s data;
a customer has sent you a security questionnaire;
your app has an AI feature that reads documents, emails or web pages, or calls tools. That brings a separate set of risks, covered in my practical guide to the OWASP Top 10 for LLM applications;
a check shows data has already been exposed.

What should I fix first if several checks fail?

Work in order of what an attacker could do today:

Live data exposure: tables without RLS, public buckets holding private files and leaked secret keys. Fix these the same day and rotate every key you found.
Money: unsigned payment webhooks and open AI endpoints. Both cost you directly.
Access control: missing auth checks, IDOR and leftover admin routes.
Hygiene: dependencies, headers, logging and backups. They matter, and a week’s delay rarely hurts.

If personal data was exposed and that is likely to put people at risk, the ICO expects a report within 72 hours of you becoming aware, and you must record the breach even when you decide not to report it.

Is Lovable’s or Supabase’s built-in scanner enough?

Use both. Lovable says every project includes a free pre-publish security scan, and the Supabase Security Advisor flags tables with RLS switched off. Those tools are good at configuration. They cannot know that a customer should never see another customer’s invoice, or that an auth function has its condition the wrong way round. Those are business rules, and checks 3, 4 and 14 exist because only a person with two test accounts, or a reviewer reading the code, will catch them.

Security is one part of getting a prototype ready for real users. Scaling, monitoring and maintainability are covered in why vibe-coded apps fail in production. If you would rather hand the whole list to someone else, the AI App Security Review runs these checks plus the OWASP Top 10 and OWASP LLM Top 10, including prompt-injection tests, as a fixed-price package.

Vibe-Coded App Security Checklist: 15 Checks Before You Launch

How insecure are vibe-coded apps?

The 15-point security checklist

Which checks can I do myself, and when do I need help?

What should I fix first if several checks fail?

Is Lovable’s or Supabase’s built-in scanner enough?

Sources

Frequently asked questions

Want a second pair of eyes before launch?