Vibe coding security: 5 checks before you launch your app

Your app works. Customers can sign up. They can pay. The AI tool that built it says it’s done. So you’re ready to launch, right?

Here’s a question nobody asked while you were building: can a stranger reset your password? Can one customer see another customer’s orders? That’s what vibe coding security comes down to, and you don’t need to be a developer to check it.

You’re not alone if you’re unsure. When a security firm scanned more than 5,600 live apps made with AI app builders, it found over 2,000 vulnerabilities, more than 400 exposed secrets, and 175 cases of exposed personal data, including medical records and bank details.

Before any of our projects goes live, it passes a launch checklist. Not because the code is bad, but because “it works” and “it’s safe to launch” are two different tests. Below are five checks from that list you can run this week, each with a prompt you can give your AI coding tool.

Why “it works” isn’t the same as safe to launch

Your app passed the test it was given: does it work when everyone behaves? Launch asks a different question: what happens when someone doesn’t?

There are five places where AI-built apps usually leave a side door open. You don’t need to read the code to check them. You need to know what to ask, and what to try yourself.

Check 1: Who can get into an account?

Your login works. You tested it, but you tested it as you. Now try it as a stranger.

Ask for a password reset twice. Does the first link still work? Does it ever expire? Type an email address that isn’t a customer. Does the page say “no account found”? That message tells an attacker exactly which emails are real. And can anyone sign up as ceo@yourcompany.com without ever opening that inbox?

Give your AI tool this prompt:

Review our sign-up, login and password reset against the OWASP Forgot Password Cheat Sheet. Check that reset links are random, single use and expire. Check that the reset page shows the same message whether or not the email exists. Check that new accounts must verify their email. List what fails, fix it, and show me a test for each.

Then test it yourself in two minutes: two reset requests, one fake email, and one sign-up you never verify.

Check 2: Can customer A see customer B’s data?

Log in as a customer and open one of your orders. Look at the address bar: something like orders/1042. Now change it to 1043. If someone else’s order shows up, every customer can read every other customer’s data.

Security people call this broken access control. It’s number one on the OWASP Top 10, the industry’s list of the most common web app risks, and it isn’t theoretical. In 2025, a researcher found more than 170 apps built with one AI app builder where the database rules were missing. Names, emails, phone numbers and payment status were readable by anyone.

Check 3: Are your secret keys out in the open?

Your app talks to other services: payments, email, AI. Each one gives you a secret key. The AI needs those keys to make things work, and sometimes it puts them wherever works fastest. That can be the code that runs in your customer’s browser.

Anyone can open their browser’s developer tools and read that code. The scan mentioned above found more than 400 exposed secrets. Database providers’ own documentation is blunt about this: never put a secret key in the browser.

Give your AI tool this prompt:

Search the whole project, including the Git history, for API keys, secret keys and passwords. Tell me which ones are sent to the browser. Move every secret to server-side environment variables, make sure the .env file is in .gitignore, and list every key I should rotate.

Then rotate any key that was ever exposed. Moving it isn’t enough. Assume someone has already copied it.

Check 4: What happens when payments get messy?

You paid once with a test card and it worked. Real payments are messier.

When a payment goes through, your payment provider sends your app a message, called a webhook, saying “this order is paid.” Stripe’s own documentation warns that the same message can arrive more than once, and that messages don’t always arrive in order. And if your app doesn’t check that the message really came from your payment provider, anyone can send a fake “paid” message and unlock an order for free.

Give your AI tool this prompt:

Check our payment flow against Stripe’s webhook best practices. Verify the Stripe signature on every webhook. Record each event ID so the same event is never processed twice. Don’t rely on events arriving in order. Then test, using Stripe’s test cards: a double-click on Pay, a declined card, and a refund. Show me what happened to the order each time.

Check 5: Do your tests actually test anything?

You ask the AI to fix something and it comes back with “All 24 tests pass.” Sounds great. But the same AI wrote the code and the tests. A test can check that the code does what it does, instead of what it should. A test can even fake the very part it’s supposed to check. Green ticks only mean something if a test can turn red.

Your vibe coding security checklist, and its limits

Five checks: accounts, other people’s data, secrets, payments, and tests that can fail. Most of these are an afternoon’s work with the prompts above. For a lot of apps, that’s all you need.

But be honest about one thing. These prompts help you ask the right questions. They don’t make you able to judge the answers. If the AI says “access control looks good” and you can’t tell whether that’s true, that’s not a failure on your part. That’s the point where an experienced delivery team earns its fee.

If your app is still stuck before it gets anywhere near launch, start with the vibe coding mistakes that leave apps stuck at 80%, then come back to these checks.

What to do next

Run the two-minute self-tests from checks 1 and 2 today. They need no prompts and no technical skill, and they catch the problems that hurt customers most. Then work through the prompts one at a time, and keep the results somewhere you can show someone else.