Your app works. You described what you wanted in plain English, the AI wrote the code, and the button does what it's supposed to do. The thing is, an app that works and an app that's safe are two different things. Vibe coding (writing software by talking with an AI instead of typing every line yourself) produces code that passes the eye test but often leaves doors wide open: an API key readable straight from the browser, a database anyone can reach without a password, a form that accepts absolutely anything.
The good news is that these flaws are almost always the same ones. You can close them with a few simple habits, no security engineering degree required. In this article you'll see the six most common holes in an AI-generated app, how to spot them in a couple of minutes, exactly what to ask your assistant so it fixes them, and the checklist to run through before you put anything online.
Why AI-generated code contains security flaws
An AI writes the code you asked for, not the code you forgot to ask for. When you type “build me a page that records sign-ups,” the model takes you literally: it makes a page, and the page records. Nobody mentioned limiting the number of attempts, checking the email format, or deciding who's allowed to read the list of sign-ups.
Three things explain this behavior.
First, models learned from public code, tutorials included. A lot of those tutorials simplify on purpose: they write the API key in plain sight so the example fits in ten lines. The AI reproduces that style, because it's the one it has seen most.
Second, the AI has no idea where your code is going to run. A prototype on your laptop and a public app with 500 users don't have the same requirements. Without guidance from you, the assistant aims for the prototype, because that's the shortest path to something that works.
Third, working code hides leaking code. A vulnerability doesn't crash your app and doesn't show up anywhere. Everything looks normal until the day somebody actually takes a look.
In 2025, the security vendor Veracode published an analysis of more than a hundred language models on development tasks: roughly 45% of the snippets they produced contained at least one weakness listed in the OWASP Top 10, the global reference for application security risks. That's not a reason to stop vibe coding, it's a reason to review. These problems also overlap a lot with the classic mistakes beginners make when vibe coding.
The six flaws AI lets through most often
Six problems show up in nearly every AI-generated app, and most of them can be spotted without reading a single line of code.
| Flaw | What it allows | Quick test |
|---|---|---|
| Hardcoded API key | Someone uses your paid account | Search for “sk-” or “key” in the code sent to the browser |
| Open database | Read or wipe all your data | Open the database URL without being logged in |
| No access control | See other users' data | Change a number in the URL (/invoice/12 to /invoice/13) |
| Unvalidated inputs | Inject code into your database or page | Send <script>alert(1)</script> into a field |
| Badly stored passwords | Grab every account at once | Ask the AI which algorithm it used |
| Unchecked dependencies | Install malicious code | Run npm audit |
1. The hardcoded API key
This is flaw number one. The AI drops your OpenAI, Stripe, or Supabase key directly into a file that gets shipped to your visitors' browsers. Anyone can read it in three clicks, then burn through your quota. Bots constantly scan public repositories looking for exactly these keys.
The fix: keys live in a .env file, never sent to the browser and never published on GitHub, and paid API calls go through a small server-side program. Ask explicitly: “move all keys into environment variables and add .env to .gitignore.”
2. The database that's open for reading and writing
Modern tools like Supabase or Firebase create, by default, a database your app queries directly. If the access rules aren't configured, your database address becomes a public front door. Thousands of side-project databases are readable this way without any password.
The fix: turn on row level security and write one rule per table, along the lines of “a user can only read the rows they own.”
3. No access control between users
Your app checks that the user is logged in, but not that they're allowed to see this particular page. The result: by changing a number in the URL, one customer lands on someone else's invoice. This is category A01 of the OWASP Top 10, the most widespread one in the real world.
The fix: every request has to verify who's asking, on the server, never in the browser. A check hidden in the interface protects nothing, it just hides a button.
4. User input taken at face value
A form field is an entry point into your system. If the text someone types gets pasted straight into a database query, a visitor can make it run their own commands (SQL injection). If it gets displayed back as-is on a page, they can slip in code that runs on your other visitors' machines (XSS).
The fix: parameterized queries on the database side, systematic escaping on display, and validation of the expected format (length, type, allowed characters) before anything else happens.
5. Passwords stored any old way
It still happens that an AI suggests storing passwords in plain text, or hashing them with MD5, which has been obsolete for twenty years. If your database leaks, every account falls, including those of people who reuse that password elsewhere.
The fix: bcrypt, argon2, or scrypt, never MD5 or SHA1. The simplest option is still to hand authentication over to an existing service rather than writing it yourself.
6. Dependencies installed without a second look
When the AI adds a library, it also adds everything that library depends on, sometimes hundreds of packages. Some are abandoned, some contain known vulnerabilities, and a few carry a name deliberately close to a legitimate package.
The fix: run npm audit (or your language's equivalent) after every install, and turn on Dependabot if your code lives on GitHub.
Three ways to audit your app before publishing it
The most reliable method is to have your code reviewed by an AI you've given a specific role, then confirm the results with free automated tools.
Method 1: learn auditing in a guided setting
The real obstacle when you're starting out isn't running an audit, it's understanding the answer. A report announcing “client-side secret exposure” doesn't help you if nobody has explained what a secret is and why the client (the browser) isn't a safe place. That's exactly what the Skilzy program on building and securing an app with Claude Code covers: you build a real project, run the audit on it, and every alert gets explained and then fixed step by step.
The hands-on part happens in the built-in AI Lab, with credits included, so you don't have to stack up three tool subscriptions just to practice. Access starts at €29.90 per month with no commitment, and a free trial lets you test it without a credit card for 7 days (1 image, 1 video, 1 music track, and 10 messages). You do need to create an account, but no payment details are asked for.
Method 2: ask your assistant for the audit directly
Free if you already have access to Claude, ChatGPT, or another assistant. The result depends entirely on how you phrase it. A vague request (“is this secure?”) gets you a reassuring, useless answer. Give it a role, a framework, and an output format:
You are an application security auditor. Analyze this project using the OWASP Top 10 as your reference. For each problem you find, give me: the file and line, the concrete risk to a user, the severity level, and the exact fix. Don't fix anything yet, just list. Be exhaustive, including secrets management, access control, and input validation.
Then ask for the fixes one at a time, starting with the most severe. Fixing eight problems in one go produces code you can no longer review.
Method 3: free automated tools
They don't replace a review, but they catch what an AI forgets. npm audit lists vulnerable dependencies. Dependabot, included with GitHub, automatically opens update requests. Gitleaks detects API keys left behind in your repository's history. Mozilla Observatory grades your live site's configuration (HTTPS, security headers) in about a minute, from nothing more than the URL.
What the law requires the moment you collect an email address
As soon as you store a single piece of personal data, privacy law applies to you, even for a free project you launched solo from your living room. A name, an email, an IP address: those are all personal data.
Four concrete obligations your AI assistant will never set up on its own:
- Collect the minimum. If your service works with an email address, don't ask for a date of birth or a phone number.
- Set a retention period. Data doesn't stick around forever. Decide how long you keep it and how you delete it.
- Allow deletion. A user who asks for their account to be deleted has to get it, which means you need a button or a contact address.
- Encrypt traffic. HTTPS everywhere, with automatic redirection from HTTP. It's free and automatic with most hosts.
The CNIL's personal data security guide walks through these points one sheet at a time, in plain language. It's the reference to keep open if your app is going to welcome real users. And if you're starting from zero on the technical side, our guide to building an app with AI without knowing how to code lays the groundwork before you tackle any of this.
The rules you write once that protect every project
Instead of repeating your security requirements in every conversation, write them into an instructions file your assistant re-reads at the start of each session. Claude Code uses a CLAUDE.md file placed at the root of your project for this, and other tools have their own equivalent.
Seven rules are enough to eliminate most of the flaws above:
- Never write a key, password, or token in the code, always use environment variables.
- Always use parameterized queries, never paste user text into a query.
- Hash passwords with bcrypt or argon2.
- Validate all inputs at the system boundaries.
- Check permissions server-side for every sensitive action.
- No detailed error messages in production.
.env, private keys, and logs always in.gitignore.
Paste this list once and it applies to everything the assistant writes afterward. To go further on writing these instructions, our article on the CLAUDE.md file and the instructions that actually make Claude Code listen gives you the full structure.
One last habit, the highest-payoff one: before every deploy, read what changed. Not all the code, just the changes. If you don't understand what a line does, ask. An experienced developer never signs off on code they couldn't explain, and that standard holds just as much when an AI wrote it.
Key takeaways
Vibe coding doesn't make your app vulnerable by itself. What makes it vulnerable is shipping without reviewing. The six flaws listed here cover most of the real risk for a beginner project, and each one takes a handful of minutes to fix once you've spotted it. Start by getting your keys out of the code, lock down your database, check your access controls, then run the checklist before every release. You'll already be more secure than plenty of apps online today.
