How to Audit Vibe-Coded Apps Before Launch: A Founder's Checklist

If you want to know how to audit vibe-coded apps before launch, start with one fact: the app working on your screen says almost nothing about whether it is safe for strangers. An AI tool will happily generate a login page, a database and a payment flow that all demo well. Whether the database refuses a request from someone who is not you is a different question, and it is the one that decides if your users' data stays private.

This article is a practical pre-launch audit for founders who built a prototype with an AI coding tool such as Lovable, Cursor or similar. It is built on primary sources: the OWASP Top 10, Veracode's 2025 GenAI Code Security Report, the public write-up of CVE-2025-48757, and the security documentation from Supabase and Lovable. We have not audited any specific app named here. Where a point is our own judgment, we say so.

Why a working demo proves so little

Veracode tested more than 100 large language models on coding tasks in Java, JavaScript, Python and C#. In 45% of the samples, the generated code failed security tests and introduced a vulnerability from the OWASP Top 10. Source

The same report found that newer and larger models were better at writing code that runs, but not better at writing code that is secure. Security results stayed flat across model size and release date. For JavaScript, 43% of tasks failed. Cross-site scripting was the most common single failure, with the models failing to defend against it in 86% of the relevant samples. Source

So do not assume a newer model fixed this. The tool produces features. It does not ask what happens when someone sends a request your interface would never send. The nine checks below ask that for you.

A real example: what missing database rules look like

In March 2025, a researcher found that a site built with Lovable let anyone change a query and read the whole users table. The cause was not a leaked key. Supabase's public anon key is public by design. The cause was missing Row Level Security, so the database answered requests it should have refused. Source

He then scanned the homepages of 1,645 projects from Lovable's showcase list. The scan flagged 303 endpoints across 170 projects, about 10.3%, with inadequate access rules. The exposed endpoints included tables named users, transactions and subscriptions, and functions that returned API tokens. Source

In a follow-up check, he reports that a table showed RLS working for signed-in requests, but removing the authorization header turned the request into an anonymous one that could read and write. He wrote a record with payment_status set to paid, which skipped the payment step. Source

The vulnerability was assigned CVE-2025-48757. The public record notes that the vendor disputes it, because each customer of the platform accepts responsibility for protecting their own application's data. Source

You do not have to decide who is right to take the practical point. It is your users' data, and you are the one who answers for it. Lovable's own documentation says it sets up basic RLS policies automatically, but you should review and adjust them early. Source

The nine checks

1. Turn on RLS for every table, then test it

Supabase's documentation is blunt: a table in an exposed schema without RLS is readable and writable by any role with a grant on it, so you should enable RLS on every table in an exposed schema. Source

Open your database dashboard and list every table. Confirm RLS is on for each, and that a policy exists and says what you mean. Lovable's checklist asks you to verify that users cannot access other users' private data and that new tables are not missing policies. Source

Existence is not enough. The researcher in the CVE write-up points out that Lovable's scanner checked only whether an RLS policy existed, not whether it was correct. Matt Palmer A policy that says "allow everything" passes that kind of check.

2. Test as a stranger, not as yourself

Open a private browser window, or use a command line tool, and call your data endpoints with no login and then with a second test account. Try to read the first account's rows. Try to write a row you should not be allowed to write. If you can, so can anyone else.

This would have caught the unauthenticated read and write described above. For a small app it should take well under a day, and it is the most valuable check here. This is our recommendation, not a quote from a source.

3. Check grants, not only policies

Supabase explains that two layers work together. Grants decide which database roles can reach a table at all, and RLS policies decide which rows those roles can read or change. Its guide says to use both for every exposed object. Source

It also notes that on existing projects, tables created in the public schema get read, insert, update and delete privileges for the anon, authenticated and service_role roles by default, and that Supabase is changing that default so exposure becomes opt-in. Check which behavior your project has. Source

4. Search the front end for secrets

Anything that ships to the browser can be read by the user. Lovable's documentation says secrets stored in frontend code are visible to users and should be considered compromised. It says to keep them in a secrets store and read them only in server-side code. Source

Search your repository and your built bundle for strings like sk_live, secret, api_key and token. The CVE write-up listed functions that returned API keys to anyone who called them, so also check that no endpoint hands out a credential to an anonymous caller. Source

If you find a live key in the front end, rotate it. Deleting it from the code is not enough, because the old value may already be in your git history.

5. Move every real decision to the server

Lovable's guidance says frontend code runs in the user's browser, where it can be inspected or changed, so it should never make security decisions. Validation in the interface is for user experience only. Validation that matters has to run again on the server. Source

The payment_status example shows why. If an open endpoint can mark an order as paid, the payment flow is decoration. Anything involving money, roles, plans or permissions should be set by server-side code you control.

6. Enforce authentication on the server

The same Lovable page lists a client-side check as the wrong pattern, such as testing for a token in local storage before showing an admin panel. It says to validate sessions and tokens in server-side code and to use frontend auth state only to control the interface. Source

OWASP says the same thing in more general terms: access control is only effective in trusted server-side code, where the attacker cannot modify the check. It also recommends denying by default, except for public resources. Source

A quick test: hide the admin button, then call the admin endpoint directly from a normal account. If it works, the button was the only protection.

7. Check ownership on every record

OWASP's list of common access control failures includes viewing or editing someone else's account by changing an identifier, and APIs with missing controls on POST, PUT and DELETE requests. It recommends that access models enforce record ownership instead of assuming a user may create, read, update or delete any record. Source

In practice, log in as user A, copy the ID of one of A's records, then try to open, edit and delete it as user B. Do this for every kind of record: profiles, orders, files, messages and settings.

In the 2021 data OWASP collected, this category had over 318,000 occurrences, the most of any. OWASP A demo never exercises it, which is why we would expect vibe-coded apps to miss it. That expectation is ours.

8. Handle user input as hostile

The Veracode figure for cross-site scripting is a reminder that generated code often passes user text straight into a page. Veracode Paste a script tag into every text field and see whether it runs when the page reloads. Check file upload limits and types, and that search boxes do not build database queries from raw text.

Lovable's guidance asks for the same habit: treat client input as untrusted, validate formats and business rules on the server, and handle inputs safely before storing them. Source

9. Add logging, limits and a way to find out when something breaks

OWASP recommends logging access control failures, alerting admins when appropriate, and rate limiting API access to reduce harm from automated tools. OWASP Supabase also notes that RLS does not cover every API requirement and points to pre-request checks for needs such as per-user rate limits. Source

For a first launch, our minimum is that you can see failed requests, get an alert, and turn off a key or feature quickly.

What an audit will not tell you

This checklist covers common ways a small app leaks data. It does not replace a proper review for apps that handle health, financial or children's data, or that must meet a compliance standard. Treat the checks as a floor and run them again whenever you add a table, a role, an integration or a payment step. Lovable says the same about its own checklist: review it whenever you change authentication or data access. Source

Where a short review helps

If you have a prototype that works and want a second pair of eyes, our vibe coding for founders service takes a prototype to a version you can put real users on. If your app uses AI agents, our post on agent permissions in AWS AgentCore shows how the same access control problems appear on that side.