Vibe Coding Security: A Pre-Launch Checklist for Non-Technical Founders

An AI tool can now build you a working app in a weekend. It will have sign-up, a database, and a polished interface. What it may not have is a lock on the front door. Vibe coding security is the part of building with AI that nobody demos, because a broken permission rule looks exactly like a working app until a stranger finds it.

This is not a theoretical worry. In one widely covered case, security researchers at Wiz found that Moltbook, a social platform built with AI tools, had exposed user data and API keys through a database key left in its public website code, according to Infosecurity Magazine. The problem was not exotic. It was a basic setting that nobody had checked.

The good news is that the most common failures are well known, and you can test for many of them yourself without reading any code. This guide explains what goes wrong, how to check, and when to bring in a professional.

Why AI-built apps have this problem

AI coding tools are good at making features work. If you ask for a page that shows a user's orders, you will get one. But "works" and "safe" are different goals. The page may show the right orders when you click through it normally, while the database behind it would happily hand any order to anyone who asks in a slightly different way.

Three things make vibe coding security harder for non-technical founders:

• You only test the normal path. You log in as yourself and click the buttons. Attackers do neither.
• You do not know what to ask for. If you have never heard of a database access rule, you cannot ask the AI to write one.
• The AI tends to say yes. Ask "is my app secure?" and you may get a confident answer. A confident answer is not a test.

Asking the tool to review its own work is still useful, as you will see below. It just cannot be the only check.

The five failures that show up most

Most vibe coding security problems fall into five groups.

1. Database rules that are missing or too open

This is the big one. Many AI-built apps talk to the database directly from the browser or the phone, using a public key. That design can be perfectly safe, but only if access rules on the database decide who can read and change each record. In Supabase these are called Row Level Security policies. In Firebase they are called Security Rules.

If those rules are missing or too loose, anyone who finds your public key, which is easy to find, can read or edit other people's data. Often all of it.

2. Secret keys in the wrong place

Some keys are meant to be public. Others, like your OpenAI, Anthropic, or Stripe secret keys, must never reach a user's device. Anything sent to the browser or built into a mobile app can be extracted. A stolen AI key can produce a surprise bill in days. A stolen payment key is far worse.

Secret keys belong on a server, in protected settings, with your app calling the server rather than the outside service directly.

3. Checking permissions only on the screen

An AI may hide the "Admin" button from regular users and consider the job done. But hiding a button does not stop someone from sending the request directly. Every permission check must also happen on the server or in the database rules, where users cannot tamper with it. The same applies to paid features and anything else that is restricted.

4. Trusting whatever users send

Forms, file uploads, and URLs can all carry input you did not expect, like an enormous file, a price changed to zero, or text containing code. Good apps check everything on the server before acting on it. AI-generated apps sometimes skip this, especially for features added late in a long conversation.

5. No limits on expensive actions

If anyone can trigger an AI call, send an email, or send a text message as many times as they like, someone eventually will. Rate limits and spending caps turn a potential disaster into a minor annoyance.

How to test your app without reading code

You can run these checks in an afternoon. Do them on a test copy of your app if you have one, and only on apps you own.

The two-account test. Create two accounts, A and B. As A, create something private, then copy the URL of that item. Log in as B and paste the URL. If B can see or edit A's data, you have a serious problem. This single test catches a surprising number of failures.

The logged-out test. Copy the URL of a private page, log out, and open it in a private browser window. You should be sent to a login page, and no private data should appear.

The small-user test. Log in as a regular user and try to open any admin address you know about. Try using a paid feature from a free account.

The key search. Open your site in a desktop browser, open the developer tools, and search the loaded files for text like "sk-", "secret", or "service_role". Anything that looks like a secret key should not be there. If you find one, treat it as stolen: replace it with a new key from the provider, then fix how the app stores it.

The repository check. If your code lives on GitHub, make sure the repository is private unless you meant otherwise, and search it for the same terms. Old commits count too, because a key removed later can remain in the history.

The form test. Try absurd inputs: a very long name, a negative quantity, a huge file, a file with the wrong type. The app should refuse gracefully rather than accepting it or crashing.

Make the AI check its own work, carefully

AI tools are better at finding security problems when you ask specific questions instead of a general one. Try prompts like these, one at a time:

• "List every database table and the exact access rule on each one. Which tables can be read by someone who is not logged in?"
• "List every API key and secret this app uses, and where each one is stored. Which ones reach the browser or the mobile app?"
• "For each paid or admin feature, show me where permission is checked on the server, not in the interface."
• "List every action that costs money or sends a message, and what limits it."

Then verify the answers with the tests above. Also check your platform's own security scanner and database advisor if it has them, since some builders now include one. They do not catch everything, but they are free and quick.

Before you launch: a short checklist

• Access rules are turned on for every database table, and the two-account test passes.
• No secret keys appear in browser files, mobile builds, or your code history.
• Permissions are enforced on the server, not only in the interface.
• Payments are confirmed by the payment provider on the server, not by a message from the app saying "paid."
• Spending caps and alerts are set on every AI, email, and SMS service.
• Backups are on, and you have tried restoring one.
• Your privacy policy matches what you actually collect, and users can delete their accounts.
• You have a way to hear about problems, like a security contact email.

When to pay for a review

Do-it-yourself checks are a sensible floor, not a guarantee. Pay a developer or security specialist for a review before launch if your app does any of the following:

• Handles health, financial, or children's data
• Takes payments in any custom way
• Stores private messages, documents, or photos
• Lets users see or act on each other's data in complex ways
• Is about to get real traffic, for example from a launch or a paid campaign

A focused review of your authentication, database rules, and secret handling is much smaller than a full audit, and it costs far less than a breach, an emergency rebuild, or the loss of your users' trust. Ask for a written list of findings, ranked by severity.

If you find a problem after launch

Do not panic, and do not ignore it. Fix the hole first, and replace any exposed keys. Then check your logs to work out what was accessed. If personal data may have been exposed, you may have legal duties to notify users or regulators, sometimes within tight deadlines, so get proper legal advice quickly.

Vibe coding security comes down to one habit: never treat a working app as proof of a safe one. AI has made building dramatically easier, and the tools are improving, but you are still the one responsible for your users' data. An afternoon of testing before launch is one of the cheapest forms of insurance you will ever buy.