You don’t need to be a security expert to understand the mistakes that show up most often in code an AI generates without anyone reviewing it afterward. These are basic errors, not sophisticated attacks, and that’s exactly why they’re so easy to avoid —if someone knows to look for them.
Keys and passwords sitting in plain sight
The most common flaw by far: leaving the database connection key, a payment service key, or an email service key directly in the code loaded by any visitor’s browser. The AI needs that key for the site to work, and if nobody explicitly tells it where it should and shouldn’t be visible, it puts it wherever is simplest to get working, not wherever is safest to leave. That’s exactly what happened in the Moltbook case we covered a few weeks ago: the database key was sitting in plain sight in the page’s JavaScript.
Forms that accept anything
A contact form, a signup form or a search box needs to validate what it receives: that an email looks like an email, that a number is a number, that a text field doesn’t contain executable code. Without that validation, someone can send malicious code through an ordinary text field —known as injection— and get that code to run on your site or in another visitor’s browser. Recent university research testing several AI coding models found this exact flaw in the vast majority of code samples generated, precisely because thoroughly validating every field isn’t the first thing on an AI’s mind when it’s focused on making the form “look right and send the email.”
Panels and pages nobody protected
An admin panel, an order management page, or a private user area needs to check, on every visit, that whoever’s entering is actually allowed to be there. It’s common for AI-generated code to build that page perfectly functional —it looks right, it works, it does what it should— but with no permission check behind it. Anyone who guesses or finds the URL walks straight in, no username or password needed, because nobody explicitly asked the AI to protect it and it didn’t assume it should.
Dependencies nobody looks at again
Almost no project is built entirely from scratch: the AI pulls in existing libraries and packages to handle common pieces —login, payments, sending emails. Those pieces get security updates constantly, because flaws keep getting found in them, like in any software. The problem isn’t using them, it’s that once the project is live and “working,” nobody checks again whether those pieces have fallen out of date and are carrying known, publicly documented vulnerabilities —which makes them the easiest target for anyone looking for one.
None of these four flaws needs a complex attack to exploit, and none of them shows up while using the site normally. What it does take is someone actively looking for them, through a proper maintenance and security review before someone else finds them first. If you’d like us to take a look at your case: tell us how your site is set up.
Frequently asked questions
Do these flaws only affect sites built 100% with AI?
No, they can show up in any project where security wasn’t thoroughly reviewed, AI or not. What changes with vibe coding is the odds: by definition skipping the human review, these flaws show up far more often than in a traditionally reviewed development.
How is an exposed key actually detected?
Through a technical review of the source code the site loads, along with the server and database configuration. It’s not something you’d notice browsing the site normally, and it’s not something a non-technical user would catch, which is exactly why it needs someone to actively check for it.
Is it enough to just change the key once it’s found exposed?
It’s the first step, but not the only one: you also need to check whether that key was already used to access something without permission, and fix the cause —why it was exposed— not just the symptom. Changing the key without fixing the cause usually means the same problem shows up again on the next change or update.