From prototype to production: a go-live security check for AI-built apps

From prototype to production: a go-live security check for AI-built apps

An app built with Lovable, Bolt, Cursor or Replit can work perfectly in a demo and still let any logged-in user read everyone else's data. Before real users and real data arrive, run the seven checks below. You can do some of them yourself. Others need a web application pentest by someone who tries to break the app on purpose.

TL;DR

• AI coding tools build features fast, but they rarely decide who may see which data.
• Seven checks cover most launch risks: database rules, secrets, authorisation between users, login and sessions, payments, browser protections, and storage and hosting.
• You can review the configuration checks yourself in an afternoon.
• Authorisation flaws and chained attacks need a human tester.
• A go-live pentest gives you a go or no-go before launch, with the retest included.

Why AI-built apps reach production with gaps

AI coding tools aim for a feature that works. Security is rarely part of the prompt, so it is rarely part of the result. When Escape scanned more than 5,600 publicly deployed apps built on platforms such as Lovable, Bolt.new and Base44 in late 2025, it found over 2,000 vulnerabilities, more than 400 exposed secrets and 175 cases of exposed personal data (Escape research). Georgia Tech's Vibe Security Radar counted 6 published vulnerabilities traced to AI-generated code in January 2026, 15 in February and 35 in March (Infosecurity Magazine).

We explained earlier what typically goes wrong in a vibe-coded app. This post is the practical follow-up: what to check before you press the launch button.

The seven checks before you go live

1. Database rules and row-level security

Apps on Supabase or Firebase talk to the database straight from the browser. That is only safe when the database itself decides who can read and change each row. Check that row-level security is switched on for every table and that each rule limits access to the user's own records. A table without it, or with a rule that allows every logged-in user, is open to anyone with an account.

2. Secrets in the frontend and the repository

Open your app in the browser, view the source and search the JavaScript files for words like key, secret and token. A public key meant for the browser is fine. A service key, a payment secret or an API key for an AI provider is not. Check the repository history too, because a key you removed later still sits in old commits. Rotate every key you find.

3. Authorisation between users

Log in as two test users. Copy a link or an ID from user A and open it as user B. If B sees A's invoice, profile or file, the app checks that someone is logged in but not whether the data belongs to them. Automated scanners struggle to find this flaw, often called IDOR. In Tenzai's test of five AI coding agents that each built the same three apps, improper API authorisation was among the most common of 69 findings (SecurityWeek).

4. Login, password reset and sessions

Test the flows around the login, not only the login form. Can a reset link be used twice? Does a session end when someone logs out? Can a normal user reach an admin page by typing its address? Generated code often hides a button in the interface but leaves the function behind it open.

5. Payments and webhooks

If your app takes payments, check that the price and the paid status come from the payment provider, not from the browser. A webhook that confirms a payment must verify the provider's signature. Otherwise anyone can send your app a fake paid message.

6. Browser protections and server requests

Check that the app sets basic security headers and protects its forms against requests from other sites. If the app fetches a URL on the user's behalf, for an image preview or an import, test whether you can point it at internal addresses. That flaw, server-side request forgery, appeared in the output of all five agents in the Tenzai test.

7. Storage buckets, dependencies and hosting

Uploaded files often land in a storage bucket that is public by default. Check who can list and download them. Run a dependency check on the packages the AI added and remove what you do not use. Then review the hosting settings: debug mode off, test accounts removed and environment variables only where they belong.

What you can check yourself, and what needs a pentest

Checks 1, 2 and 7 are mostly configuration. A developer or a technical founder can review them in an afternoon with the platform's own security tools. Checks 3, 4, 5 and 6 depend on how the app behaves under misuse. That is where a human tester adds the most: someone who logs in as several users, changes requests on purpose and chains small weaknesses into one real attack path.

Sectricity offers this as the Go-Live Pentest, a web application pentest for apps built with AI, done before launch. You get a clear go or no-go, findings in plain language, a fix instruction per finding that you can paste into your AI coding tool, and a retest once you have fixed the findings.

After launch: test every release that changes data access

An AI-built app rarely stands still. Every new feature can change who sees which data. With RedSOC you request a pentest when you ship something new, so the next release gets the same check as the first.

Frequently Asked Questions

Is an app built with Lovable or Bolt safe to launch?

It can be, but the platform does not decide that for you. It generates the code and the hosting. Database rules, access between users and the handling of secrets stay your responsibility. Run the seven checks in this post before launch, and have the app tested if it handles personal data or payments.

Can I use the platform's built-in security scan instead of a pentest?

Use it, because it catches configuration mistakes quickly. It does not log in as two users and try to read each other's data, and it does not chain small flaws into an attack path. A scan and a pentest answer different questions.

What is a Go-Live Pentest?

It is Sectricity's web application pentest for apps built with AI coding tools, done before launch. It focuses on data access, secrets, login and payment flows, and ends with a go or no-go, a fix instruction per finding and an included retest.

Do you need access to my code?

No, we can test the running app on its own. Access to the repository and the database settings makes the test faster and more complete, because we see the rules behind what the app does.

What should I do after launch?

Test again when a release changes who sees which data, for example new roles, sharing features or integrations. RedSOC lets you request that pentest when you need it.

Related services and resources

Sectricity tests applications whether they were built with AI or not. Start with our web application pentest, which includes the Go-Live Pentest for AI-built apps. If your app contains an AI assistant or agent, our AI and agent security test covers prompt injection and agent permissions. Teams that release often use RedSOC for pentesting on demand, and every pentest includes a retest of your fixes. For background, read what typically goes wrong in a vibe-coded app and what your AI agent can reach in production.