The security checklist for vibe-coded apps

If you built your app mostly by prompting an AI tool, you shipped something that works. That is the whole appeal. You described what you wanted, the code appeared, you deployed it, and people are using it.

The problem is the stuff you did not ask for. When you prompt "build me a dashboard where users can save their notes," the AI builds the dashboard. It does not, by default, add rate limiting, lock down the API routes, set secure cookie flags, or keep your API keys out of the browser bundle. Those are the things a security-minded engineer would add without being told. The AI waits to be told, and you did not know to tell it.

None of this is your fault. You are not a security person, and you should not have to be one to ship a side project. But attackers do not care whose fault it is. So here is a plain-English checklist of the things vibe-coded apps get wrong most often, why each one happens, and how to actually check it.

You can work through this by hand. Or you can run a scan of your live app and have it check all of this for you in about ten minutes. Either way, the goal is the same: find the holes before someone else does.

1. Secrets sitting in your JavaScript bundle

This is the most common one, and the most expensive when it goes wrong.

When you wire up a third-party service, the AI often drops the key straight into your frontend code. If that key is not prefixed correctly (or the service does not distinguish public from secret keys), it gets bundled into the JavaScript that ships to every visitor's browser. Anyone can open dev tools, look at your bundle, and read it.

A leaked Stripe secret key, OpenAI key, or Supabase service-role key is a direct line to your money or your database.

How to check: open your deployed site, open browser dev tools, go to the Sources or Network tab, and search your JS files for strings like sk_, key, secret, or your provider's prefix. If you find a real secret key, rotate it immediately. You can also run the free Exposed API Key Checker, which scans your bundles and common config paths for leaked secrets and shows them masked.

2. API routes that do not check who is calling them

AI builds the endpoint. It does not always add the auth check.

The classic version: you have /api/notes that returns the logged-in user's notes. It works perfectly when you test it logged in. But the AI never added a check that the caller is actually authenticated, or that the note belongs to them. So anyone can hit that endpoint directly, with no session, and get data back. Or they change an ID in the URL from 42 to 43 and read someone else's records.

This is called broken access control, and it is the single most common serious vulnerability on the web.

How to check: open your app's network tab, find an API request that returns your data, copy it as a curl command, then run it with the auth cookie or header removed. If you still get real data back, the route is open. Checking every route by hand is tedious, which is exactly what an automated scan is for.

3. AI endpoints with no rate limiting

This one is specific to apps that call an AI model, which is most vibe-coded apps now.

If you have an endpoint that takes a prompt and calls OpenAI or Anthropic, and there is nothing stopping someone from calling it a thousand times a minute, you have a cost bomb. An attacker (or a bored person, or a bad bot) can run your bill into the thousands of dollars overnight. People post about this constantly: "I woke up to a $4,000 OpenAI bill."

AI coding tools almost never add rate limiting unless you ask. They also rarely cap the size of the input or the number of tokens, so a single request can be made deliberately expensive.

How to check: find your AI endpoint and send it the same request twenty times in quick succession. If all twenty succeed with no slowdown, no 429 response, and no auth required, you have no rate limiting. Add a per-user and per-IP limit, require auth, and cap max_tokens.

4. Cookies without secure flags

When your app sets a session cookie, it should carry three flags: HttpOnly (so JavaScript cannot read it), Secure (so it only travels over HTTPS), and SameSite (so other sites cannot ride along with it). These flags are the difference between a session cookie that resists theft and one that does not.

AI-generated auth code frequently sets the cookie and forgets the flags.

How to check: open dev tools, go to Application, then Cookies, and look at your session cookie. If HttpOnly, Secure, and SameSite are not all set, fix your cookie configuration.

5. Missing security headers

Security headers are small instructions your server sends that tell the browser how to protect your users. The important ones are Content-Security-Policy (limits what can run on your page, a real defense against cross-site scripting), Strict-Transport-Security (forces HTTPS), X-Frame-Options (stops your site being embedded in a malicious frame), and X-Content-Type-Options.

Most frameworks ship with none of these set by default, and AI tools do not add them.

How to check: run the free Security Headers Checker, which fetches your site and grades the headers A to F with the exact fix for each missing one.

6. Exposed .env and .git files

Sometimes a misconfigured deploy leaves your .env file or your .git directory reachable on the public internet. Your .env is every secret you have. Your .git directory can let someone reconstruct your entire source code, including secrets you committed and later removed.

How to check: in your browser, try visiting yoursite.com/.env and yoursite.com/.git/config. If either returns anything other than a 404, you have a serious leak. Fix your hosting config to block dotfiles. The API key checker also probes these paths.

7. CORS set to allow everyone

CORS controls which other websites are allowed to read responses from your API. The dangerous misconfiguration is setting it to a wildcard (Access-Control-Allow-Origin: *) on endpoints that return private data, or reflecting any origin back. That means a malicious site your user visits can quietly read their data from your API.

AI sometimes sets a wide-open CORS policy to "just make it work" during development, and it ships that way.

How to check: send a request to your API with an Origin header set to something like https://evil.example and see if the response allows it. If your private endpoints accept any origin, tighten the policy to your own domains.

8. Vulnerable dependency versions

Your app pulls in dozens of packages. Some of them have known security holes that were fixed in later versions. If you are pinned to an old version, you inherit the hole. AI tools generate package.json with whatever versions they were trained on, which can be months or years out of date.

How to check: run npm audit (or your package manager's equivalent) locally. For the deployed app, an automated scan fingerprints the library versions in your shipped bundle and flags known-vulnerable ones.

9. Open redirects

An open redirect is a URL on your site that sends the visitor wherever a query parameter says, with no validation. Like yoursite.com/go?url=.... Attackers use these in phishing, because the link genuinely starts with your trusted domain before bouncing the victim to a fake login page.

How to check: look for any redirect endpoints that take a destination from the URL. Make sure they only redirect to paths on your own domain, not to arbitrary external URLs.

10. No CSRF protection on state-changing actions

If your app changes data based on a logged-in session (deleting an account, changing an email, making a purchase) and does not verify the request actually came from your own site, an attacker can trick a logged-in user into performing that action by visiting a malicious page. That is cross-site request forgery.

How to check: for your important state-changing endpoints (especially anything with DELETE or POST), confirm they require a CSRF token or rely on SameSite cookies. If a forged cross-site request succeeds, you are exposed.

The honest summary

Most of these are not exotic. They are the boring defaults that experienced engineers add reflexively and AI tools leave out. Working through this list by hand is completely doable, and if you only do the manual checks above you will already be ahead of most apps.

If you would rather not check ten things by hand, that is exactly why I built DeploySafe. You paste your live URL, it probes your running app for everything on this list (and more), and every finding comes with a fix you can paste straight into Cursor or Claude. The first scan is free.

Either way: check before someone else does. The people who find these issues by accident are the lucky ones.