You built an app with AI this weekend. Here are the security holes it probably has.

You had an idea on Friday. By Sunday you had a working app. The AI wrote most of the code, you wired it together, and it just worked.

Here is the part nobody says out loud: you did not read every line the AI wrote. Almost nobody does. That is fine, it is how building works now. But it means there are probably a few security holes sitting in your app that you cannot see, because you never looked at the code that made them.

The good news: the most common holes in AI-built apps are a short, predictable list. You can check for them in about 15 minutes. Here are the three that cause the most real trouble, in plain terms.

1. A secret written straight into the code

AI assistants love to put your API key or database password right in the code to make things work. It runs great. The problem shows up later: that secret ends up in your git history, and public repos get scanned by bots within minutes of going up.

Deleting the line does not fix it. The secret still lives in your past commits. Anyone who clones the repo can read it.

How to check: search your code for anything that looks like a key or password. If you find one, or if one was ever committed, rotate it now (create a new one, revoke the old), then move secrets into environment variables instead of the code.

2. An API route with no lock on the door

When the AI builds a route that returns data, it often does not add a check for who is asking. It works in testing because you are the only user. Then it ships, and anyone who finds the URL can pull the data.

How to check: for every route that returns user or account data, confirm there is a login or permission check in front of it. If a route hands back private data to anyone who asks, that is the first thing to fix.

3. A public default that should be private

Storage buckets, databases, and file uploads often start with a default that is more open than you meant. The AI picks a setting that works, not the one that is safe. So your uploads or your database might be readable by the whole internet without you knowing.

How to check: look at your storage and database settings. Anything holding real user data should be private by default, with access granted on purpose, not by accident.

The 15-minute pre-launch checklist

Before you put your app in front of real people, run this list:

1. No API keys, passwords, or tokens in the code. Rotate anything that was ever committed.


2. Every route that returns user data has a login and permission check.


3. Storage, databases, and buckets are private by default.


4. Dependencies are up to date, with no known-vulnerable versions.


5. Error messages do not leak stack traces, config, or secrets.

That covers the large majority of real incidents in fast-built apps.

If you want it done for you

You do not have to eyeball all of this. An independent scan can run the whole checklist and hand you the exact fixes, so you can ship with confidence instead of a nagging worry. That is the problem we built RepoFortify to solve, and it plugs into Claude Code, Cursor, and Windsurf so the fixes show up right where you are already working. But even if you never use a tool, the checklist above will catch most of what matters.

Ship fast. Just do the 15-minute check first.

https://repofortify.com/mcp?utm_source=devto&utm_medium=content&utm_campaign=vibe-security