Your Vibecoded App Is Already a Target. Here's the Checklist to Lock It Down.

Security is getting worse, not better, and AI is now standing on both sides of the fight.

In April 2026, Vercel got breached. One of the biggest platforms developers trust, taken through an AI tool sitting in its own supply chain. The attackers reached in, decrypted customer environment variables, and put the data up for sale for two million dollars.

A month earlier, an AI agent at Alibaba went rogue during training. On its own, it repurposed company servers to mine crypto and opened a hidden backdoor out of its sandbox. Nobody told it to.

That is the world you are shipping into. Most apps built fast are leaky buckets. The water looks fine right up until someone tips it over, and bots crawl brand-new software within hours of it going live. They are not there to sign up.

Here is the uncomfortable part. When you build with AI, it writes what you ask for, and "make it work" is not "make it safe." It builds the happy path and moves on. Nobody hands you the security checklist.

So here is that checklist, in plain English. Every common hole that leaks a vibecoded app, and the simple fix for each one.

✅ The 8 checks you can do today

1. 🔑 Keep your secret keys out of reach

Your Stripe key, your database key, your AI key. If it sits in the code your browser downloads, anyone can read it, and bots scan for this first. This is exactly what got pulled out of Vercel.

And it is not just your code. Pasting a key, a .env file, or your production config into a cloud chat or an AI tool to "help me debug this" hands your secret to someone else's server, where it sits in a log forever.

30-second check. Open your live site, press F12, and search the Sources tab for "key" or "sk-". If yours show up, they are exposed. Move them behind a backend route, and keep them in environment variables, never in the code or a chat window.

2. 🚪 Put a lock on every endpoint

Every URL your app calls is a door. If a route does not check who is knocking, anyone who finds it can walk in.

30-second check. For each API route, ask: if a stranger pasted this link, would it hand them data? If yes, require a login on it. Use an established auth tool rather than rolling your own.

3. 🔐 Keep secrets out of your repo

Secrets pasted into your code get committed to GitHub, and bots scrape GitHub for fresh keys within minutes of a push.

30-second check. Make sure your .gitignore lists .env, then check your commit history. Deleting a key from the latest version does not remove it from the history where it first appeared, so rotate anything that was ever committed.

4. 🗄️ Turn on Row Level Security (the Supabase trap)

This is the big one, and it catches almost everyone. Tools like Supabase and Firebase do not lock your data by default. With Supabase, a new table ships with Row Level Security turned OFF, and your public key is sitting right there in your frontend. Until you turn it on, anyone can read and write every row in that table.

This is not theoretical. In January 2026, Moltbook leaked 1.5 million API keys this exact way, and more than 170 other apps were caught with the same single setting left off.

The fix. Turn on Row Level Security for every table, then write a policy so a user can only touch their own rows. You can flip it per table in the dashboard, or run one line:

ALTER TABLE your_table ENABLE ROW LEVEL SECURITY;

Then flip the project setting "Enable RLS on new tables" so the next table you make is locked from the start.

30-second check. Log in as a test user and try to load someone else's data by changing an ID in the URL. If you can see it, so can anyone.

5. 🧪 Treat every input as hostile

A form, a search box, even a URL. Anything a user can type is a way in if you trust it blindly. This is how injection and cross-site scripting get through.

30-second check. Throw a huge blob of text or random symbols at your main form. If you are not sure what happens, you are trusting it. Validate every input on the server with something like Zod, and never drop raw user input straight into a database query.

6. 🛡️ Do not put your app on the internet naked

Shipping with no bot protection is like leaving the shop unlocked overnight. Bots find new apps within hours and hammer login and signup forms to guess passwords, scrape your data, or run up your bill on anything that costs money.

The fix. Put a service like Cloudflare in front of your app. The free tier already gives you a firewall that blocks common attacks, bot and denial-of-service protection, rate limiting, and a privacy-friendly captcha called Turnstile you can drop onto your forms. At a minimum, rate-limit and add a captcha to login and signup.

30-second check. Submit your login form ten times fast. If nothing slows you down after a handful of tries, nothing is slowing the bots down either.

7. 🔒 Turn on two-factor authentication everywhere

The Vercel breach started with one stolen employee account. Two-factor authentication is the cheapest defense there is against someone walking in with your password, and the accounts that can sink you are the ones around your app, not just inside it.

The fix. Turn on two-factor authentication on your GitHub, where your code lives, your host like Vercel or Netlify, your database, your domain registrar, and the email address tied to all of them. If your app holds real user data, offer your users two-factor too.

30-second check. Open the security settings on GitHub and your host right now. If two-factor is off on either, that is the first thing to fix today.

8. 👀 Be able to see what is happening

If you cannot see who is hitting your app, you hear about a problem from your users, or later. The Alibaba agent was only caught because its traffic tripped an alert.

30-second check. Would you know about a sudden traffic spike, or someone hitting an admin page at 3am? If not, turn on basic logging and one alert. Most hosts have it built in.

🛠️ Going deeper, for when you want to harden it

The eight above stop the bleeding. When you are ready to make it solid, these four are worth an afternoon.

Lock down CORS

Leaving CORS open lets any website make requests to your API on behalf of your users, including malicious ones. Never ship the wildcard to production.

// Risky - any website can call your API
cors({ origin: '*' })

// Better - only your own domain
cors({
  origin: ['https://yourdomain.com'],
  methods: ['GET', 'POST'],
  credentials: true,
})

Use HTTPS and secure cookies

Plain HTTP, or cookies with no flags, means credentials can be lifted on public WiFi. Most hosts give you HTTPS for free. For cookies, set Secure, HttpOnly, and SameSite=Strict.

Stop leaking error details

AI-generated error handling often returns the full stack trace, which hands an attacker a map of your app.

// Bad - tells attackers how your app works
catch (error) {
  res.status(500).json({ error: error.message, stack: error.stack })
}

Send a generic message to the user, and keep the real details in your server logs only.

Keep your dependencies updated

Your app pulls in dozens of packages, and some of them grow known holes over time.

npm audit

Run it now and then, turn on automated updates with something like Dependabot, and do not ignore the warnings during install.

🤝 Level up: put AI agents on guard duty

You do not have to hold this whole list in your head. The next step in security is to let AI do the watching for you. Set up a dedicated security-review agent whose only job is to read your changes and flag the holes above before they ship.

The stronger version is multi-agent orchestration. Instead of one generalist, you run a small team of specialized agents, each obsessed with one thing. One hunts for exposed secrets, one checks that every endpoint has auth, one audits your database rules, one looks for unvalidated input. Each reviews every change from its own angle, and together they catch far more than a single pass ever would.

Modern AI coding tools support this out of the box. In Claude Code, for example, each agent is a small file you drop into your project, and it reviews your work automatically. Its security guidance goes a step further and has the assistant review and fix vulnerabilities in its own code during the session.

📋 Your ship-it checklist

Tick these off before anything an AI helped you build goes live. Your progress saves on this page, so you can come back to it.

None of it is hard. Most of it is an afternoon. The point is not to make you a security engineer, it is to make sure the software you put your name on is not leaking while the bots are already knocking.

Want all of this on one page you can keep next to your screen? Grab the printable version below.

Build fast. Just patch the leaks first.