Vibe Coding Security Checklist: 12 Production Readiness Checks Before Real Users Arrive

The app works. You built it with Claude, Cursor, Lovable or Replit, or you paid someone who did, and it does what your business needs. Now customers, an investor or regulated data are about to depend on it. The question changes from “does it work” to “who else does it work for”.

A vibe coding security checklist answers that in three layers. Who can log in and what can they reach. Do secrets and database rules hold when nobody is watching. Can the app be rebuilt, restored and changed once it is live. This is the checklist we run when we audit an AI-built app, in the order the audit runs it, with a ten-minute test for every item. The go-to-market half lives in our product launch checklist.

Key Takeaways

• 45% of AI-generated code contains security vulnerabilities (Veracode, 2025), and the failures cluster. Of the six AI-built apps we have audited or hardened so far, most failed at least two of the first four checks below.
• Order matters more than count. Four checks block a launch, five belong before launch, three before scale or a legal trigger. Run them in that order.
• A clean scan is where the review starts, not where it ends. The two launch blockers in our last audit were found by reading the code and starting the app, after the secret scanner had reported zero.

Why does an AI-built app pass every demo and still fail a security review?

Because the demo and the review ask different questions. The demo asks whether the app works for the person who built it. The review asks who else it works for: a logged-out visitor, a second customer, someone who has read the code. In Veracode’s 2025 tests, 45% of AI-generated code contained security vulnerabilities (Veracode, 2025). In October 2025, security firm Escape analyzed more than 5,600 publicly deployed vibe-coded apps. It found more than 2,000 vulnerabilities, 400+ exposed secrets and 175 instances of exposed personal data, including medical records and bank account numbers (Escape, 29 October 2025).

We have audited or hardened six AI-built apps so far, some of them in finance and healthtech, where compliance requirements are not optional and the rules reach into the architecture. The pattern repeats. The screens are right, because the owner knows the business. Underneath, the model made up the rules wherever it was not given any: who may see which record, what happens when a setting is missing, what a change in one file does to another. None of that shows in a demo, because the demo is run by the one person the app was built for. For the wider picture, read our take on whether vibe coding is bad.

Tier 1: which four checks block a launch?

Fix these before anyone outside your team logs in. Each one alone is a reason not to launch.

1. No secret or default password lives in the code. Test: search the repository for “secret”, “password” and the fallback pattern (a value supplied with || when a setting is missing). Then start the app with its environment variables removed. If it starts and lets you log in, it is running on defaults.

Why it matters: anyone who has read the code is an administrator. In our last audit the secret scanner reported zero findings, yet a fallback signing key and a default admin password were live whenever one setting was missing. We found them by reading the code and booting the app.

2. Every endpoint checks which customer, not only whether someone is logged in. Test: log out and paste a private URL into the address bar. Then log in as a second test customer and change an ID in the URL or the request. If either returns data, the rule is “logged in”, not “allowed”.

Why it matters: this is the flaw behind CVE-2025-48757, a 9.3-severity record from May 2025. It describes Lovable-generated sites whose database tables could be read or written without logging in, because the per-table policies were missing (CVE record, 2025). In a multi-tenant SaaS in a regulated sector, one customer reading another’s records is a reportable breach. Several endpoints in our last audit did exactly this.

3. Secrets stay out of the browser. Test: open the page source, search the loaded JavaScript for key formats (sk_, eyJ, AKIA), then load /.env and add .map to the main script’s URL. Anything that comes back is public. Lovable’s documentation puts it plainly: “API keys and other secrets cannot be stored safely in client-side code” (Lovable docs). The Lovable to production page covers the Supabase specifics.

Why it matters: Escape’s 400+ exposed secrets were found this way, from the outside.

4. Login attempts are limited in a way that survives a restart. Test: enter twenty wrong passwords from one address, then the right one. If the right one goes straight through with no delay or lockout, the limit is not real. Why it matters: in our last audit the limit existed in the code. It was counted separately by each short-lived server instance and reset on restart, so it did almost nothing against password guessing.

Tier 2: what must be true before launch?

These decide whether you can recover, change and trust the app once it is live.

5. The database can be recreated from the repository. Test: clone the code to a fresh machine, point it at an empty database, run the migrations, open every main screen. Our example: the structure was built by start-up code with ten columns missing, and a clean install failed with “no such column”.

Why it matters: recovery after an incident depends on this.

6. Tests run against the real application. Test: open the test folder. Do the tests call the running app, or copies of its functions? Our example: hundreds of passing tests, not one of which called the deployed code.

Why it matters: access control can break and nothing turns red.

7. Dependencies are known and current. Test: run the package audit for your stack and count high and critical advisories in packages used at runtime. Confirm every package in the manifest exists on the registry, because models invent names.

Why it matters: an upload library with a known flaw is reachable from every upload form.

8. Uploads and files fit the platform. Test: upload a file just above your hosting plan’s request limit; then open a private file’s URL while logged out. Our example: the code allowed 30 MB on a platform that caps requests at 3 MB. Private documents were served with headers that let them be cached publicly.

Why it matters: customers cannot receive large documents, and “private” was a label, not a property of the file.

9. Errors are tracked and logs are safe. Test: break something on purpose. What does the user see, where is it recorded, does anyone get an alert? Then search the logs for “reset”. Our example: internal error text shown to users, no error tracking, and reset links written to the server log.

Why it matters: you learn about problems from customers, and the log holds credentials.

Tier 3: what matters before scale or a legal trigger?

10. A backup has been restored once. Test: restore last night’s backup into a fresh environment and log in. Until you have done this, you have a backup job, not a backup.

11. Deleting a user deletes the user. Test: create a test account with a distinctive email, use it, delete it, then search every table and stored file for that email. Our example: deletion left copies in five other tables, in stored files, and in a change history that kept sensitive identifiers in plain text.

Why it matters: once an EU user arrives, erasure is a legal duty. An acquirer’s technical due diligence checklist asks the same question.

12. One backend, one region, one staging environment. Test: compare what runs on your machine with what is deployed, and look up where the server and the database are hosted. Our example: two backends that had drifted apart, with nearly a fifth of the code duplicated between them. The server sat on one coast and its database on the other, so every page took 0.7 to 4 seconds. The first fix was one line of configuration.

Why it matters: what you test is not what customers run.

Harden, restructure or rebuild: which one does your app need?

The checklist tells you what is wrong. The verdict tells you what to do about it, and there are only three. Keep and harden when the features work, the data model is sound, and the failures are local: a missing policy here, a default there. Restructure when the behaviour is worth keeping but the structure fails everywhere: access rules missed on some routes, logic in one oversized file, tests that never touch the deployed code. Rebuild when the data model itself is wrong, or when the app is small enough that a clean base is cheaper than untangling it.

Our September audit ended in restructure. The app did a lot and did it well, it built from a clean clone, and its data model could be carried forward. But checks 1, 2, 6 and 12 failed across the whole backend, so hardening route by route would have left the cause in place. The opposite case was a healthcare company’s Replit prototype. The workflow and the data model had proved themselves, but the back end could not be allowed near patient data, so we kept what the prototype had proved and rebuilt the rest. A vibe code to production audit answers which verdict fits yours, in writing, with the price of each path. Whether to harden it yourself or bring in engineers is covered in vibe coding versus hiring an agency.

Why isn’t the AI’s own review enough?

Run the scans. Lovable’s Quick scan runs when you publish; its Deep scan reads the code for access control and leaked secrets but, in Lovable’s words, “does not run automatically as you work” (Lovable docs). Then understand what a scan cannot do. First, a model that reviews code it wrote misses the same mistakes, because those mistakes belong to the model rather than to the code. The same blind spot sits on both sides of the review. Second, no scanner knows your business. It can tell you a table has no policy. It cannot tell you that your clients table must never be visible across tenants, because it does not know you have tenants. The time saved by having the code written for you comes back at review, and that review belongs to someone who did not write the code and has asked you what the app is for.

What the reviewer checks against matters as much as who reviews. When we build, our AI tools work inside a harness: a set of architecture decision records (ADRs) that say how we handle authentication, permissions, validation, data, errors and deployment, written from thirteen years of shipping products in fintech, healthtech and legaltech. When we audit, the same records are the yardstick. The model that built your app had no such rules unless you gave it some, so every check above is, in effect, a comparison between what the model improvised and what a team has already paid to learn.

Frequently Asked Questions About Vibe Coding Security

Is vibe-coded software safe to ship to production?

Not by default. Veracode found that 45% of AI-generated code contains security vulnerabilities (2025), and the failures cluster in access control, secrets and defaults. It becomes safe to ship when the four Tier 1 checks pass under a test from the outside: logged out, as a second customer, and with the environment variables removed.

How do you vibe code safely in production?

Write the rules before the prompt: who may see what, how login works, what every input must look like. Keep secrets out of client-side code. Put one access policy on every table or endpoint and test it as a second user. Make tests call the running app. Have someone who did not write the code review it before real data arrives.

Are vibe-coded apps production ready out of the box?

Rarely. They are demo-ready: they work for the person who built them. Production-ready means they also behave correctly for a logged-out visitor, a second customer, a lost setting and a restart. Of the six AI-built apps we have audited or hardened, most failed at least two of the four launch-blocking checks.

What is a production readiness review, and do I need one for an AI-built app?

A production readiness review is a structured check of whether a system can be run, recovered and changed safely once live: security, reliability, observability, deployment and ownership. For an AI-built app it is more necessary, not less, because nobody has yet read the code with those questions in mind. This checklist is that review, scaled to one app.

What does production hardening for a vibe-coded app involve?

Fixing the checklist failures in order of risk, against a written standard rather than taste. Launch blockers first: secrets, access control, rate limiting. Then structure: versioned migrations, tests against the real application, input validation, file storage that fits the platform. Then operations: staging, error tracking, backups with a tested restore, one backend in one region. Small apps take one to two weeks; complex ones can take months.

The decision this week

Run the four Tier 1 checks today. They take under an hour and none needs a developer: a repository search, a logged-out URL, a second account, twenty wrong passwords. If all four pass, run the other eight at your own pace. If any one fails, the decision is made for you: nobody outside your team logs in until it passes, whoever does the fixing. That is not a verdict on the tool or on you. It is the normal next step for software that has started to matter.

If you would rather have the twelve checks run for you, book an intro call. The audit is a fixed price, the report is yours whether or not we do the work, and it ends in one of the three verdicts above, in writing.