Vibe-Coded App Security Checklist: What to Fix Before Real Users Arrive

You built an app with Lovable, Bolt, Replit, Cursor or Claude Code. It works, people want it, and someone has now asked whether it is safe to put real customers and real payments on it. These tools are a fast way to prove an idea, and they are much better at making software work than at making it safe. This checklist covers what to fix, in the order we would fix it, and how to decide between hardening the app and rebuilding it.

What the Research Actually Shows

Most numbers on this topic come from security vendors with something to sell, and they measure different things. Read them as direction rather than precision. Even so, the same failures keep appearing.

Audit Your App in Five Minutes

Tick what is true today, and be strict: a ticked box means you tested it. The tool applies three stated rules. If the data model signal is ticked, or any two rebuild signals, the verdict is rebuild the core. If any item marked "must fix" is open, the verdict is fix first. Otherwise, harden. Nothing you tick leaves your browser, and nothing is saved.

Before You Change Anything

Get the code out of the builder and into a Git repository you own, and take a database backup. Every fix below is safer if you can see what changed and undo it. If real users are already on the app, make these changes on a copy first, then move them over.

The Checklist, in Order

1. Find and rotate exposed secrets

Open your deployed site, view the page source and the JavaScript files, and search for sk_, secret, api_key and service_role. Check your Git history too. Wiz lists hardcoded secrets in client-side code as one of the four most common failures in these apps.

Moving a key out of the code is not enough. If it ever reached a browser or a public repository, treat it as stolen: create a new one, delete the old one, and call that service from a server-side function. A Stripe secret key, a model provider key and a Supabase service_role key should never reach the browser. Supabase's docs are direct about the last one: it bypasses Row Level Security and belongs on the server. We follow the same rule in Shelf Inn, our home library app for iOS and Android. It sends photos through a server proxy so that provider keys stay off the device.

2. Lock down the database

If your app uses Supabase, this is the most valuable hour you will spend. The public key is designed to be visible, and it is safe only when Row Level Security is doing its job. You can test your own app in one command:

curl "https://YOUR-PROJECT.supabase.co/rest/v1/orders?select=*&limit=1" \
  -H "apikey: YOUR_PUBLIC_KEY"

Repeat that for every table. If real rows come back with no login, anyone on the internet can read them.

Supabase's guidance is to enable RLS on every table in an exposed schema. Its docs also warn that adding policies does not take back grants already given to the anon role, so revoke those separately:

alter table public.orders enable row level security;
revoke all on public.orders from anon;

create policy "customers read their own orders"
  on public.orders for select
  to authenticated
  using ((select auth.uid()) = customer_id);

Then test with two accounts. Log in as user A and try to fetch user B's record by changing the ID. Policies that look right often are not, and only this kind of test shows it.

3. Move every permission check to the server

Generated apps often hide the admin button in the interface and stop there. Wiz found logins checked in the browser, with session flags in LocalStorage that anyone can set by hand. Tenzai found an ownership check in one generated PHP snippet that ran only for logged-in users, so unauthenticated requests could still delete products. Every request that reads or changes data has to answer two questions on the server: who is this, and may they do this to this record? In BlurbBio, our AI writing platform, every project route runs an ownership check for that reason. Test yours by calling the API route directly, logged out, and then logged in as the wrong user.

4. Validate the numbers that involve money

The negative price in the Tenzai study is the kind of bug that passes every demo. Never trust a price, quantity, discount or plan name sent from the browser. Recalculate it on the server from your own data. For Stripe, confirm paid status from a signature-verified webhook rather than the redirect back to your success page, and make the handler safe to run twice, because webhooks can be delivered more than once. Retries are where charging bugs live. In BlurbBio, each job reserves credits against its own ledger key and commits only on delivery, so a retry cannot charge twice.

5. Check what is public by accident

Open every staging link, admin page and internal tool in a private browser window. Search Google for site:yourapp.lovable.app, or your platform's equivalent. Wiz lists internal apps exposed without login as a common failure, and RedAccess said many exposed apps were indexed by search engines.

6. Put limits on anything that costs you money

If your app calls an AI model or sends email or SMS, one abusive user can run up your bill overnight. Add rate limits per user and per IP on login, signup and AI endpoints, set hard spending caps with each provider, and add alerts well below those caps.

7. Add the safety net

• Backups you have restored once. An untested backup may fail when you need it.
• A separate staging environment with its own database, so an AI edit cannot touch production data.
• Database migrations in Git rather than changes made by hand in a dashboard.
• Error tracking and uptime alerts, so you hear about a failure before your customers tell you.
• Automated tests on login, permissions and payments. You need coverage only on the paths that would cost you money or trust if they broke.
• A kill switch on risky changes. Every risky change in BlurbBio carries one. It is more code to maintain, and we accept that cost.

8. Get a human to read the risky parts

Asking the same AI to review its own code helps, but it is not independent. An experienced engineer can review authentication, permissions, payments and data access quickly, because those are the same problems in every app. Stack Overflow's 2026 survey points the same way: 48% of developers would trust AI output if they could easily check it, and only about 7% would trust it with important decisions.

Harden It or Rebuild It?

Most apps do not need a rewrite. Here is how we would decide.

Either way, the first version was not wasted. You now know that people want the thing, which is what most MVP projects exist to find out. What we would not do is hand the same tool a broken app and ask it to rewrite everything in one prompt. You lose the working parts and keep the same blind spots.

Where This Is Heading

Three shifts are visible now, and each changes what you should expect from these tools.

• Newer models are not closing the gap by themselves. Veracode's July 2026 report shows the average pass rate at 56%, up one point. Its best model scored 68% and cross-site scripting passed only 15% of the time. Plan on checking the output for the life of the app.
• Platform defaults are tightening, for new work only. Supabase made new public tables unreachable through its Data API without an explicit grant, the default for new projects from 30 May 2026 and scheduled for existing projects on 30 October 2026. Its changelog says existing tables keep their grants. If your app was built before that, you still have to do step 2 yourself.
• Verification is becoming the job. Stack Overflow's 2026 trust numbers turn on whether output can be easily checked. Teams that keep test accounts, migration history and tests on the risky paths can use AI faster, because they can tell when it gets something wrong.

If You Want a Second Pair of Eyes

We've shipped production products on this stack. AskOrac, for example, runs on Next.js, Supabase and pgvector. If you have a working app and want it ready for paying customers, send us the link and tell us what worries you. We can harden what you have, or take it forward as a full SaaS build with billing, roles and monitoring. If you are still deciding whether to build at all, start with our guide to custom software vs SaaS. If your app calls a model, read how to prevent prompt injection next.