Vibe Coding Security: What to Check Before Your AI-Built Site Goes Live

Why everyone is vibe coding now

Vibe coding means describing what you want in plain language and letting an AI tool write the code. Founders build MVPs this way, designers ship their own landing pages, and marketing teams create internal tools without waiting for developers.

Developers use AI just as heavily. In the Stack Overflow 2025 Developer Survey (opens in a new tab), 84% of respondents said they use or plan to use AI tools, up from 76% a year earlier. The same survey shows the catch: 46% of developers distrust the accuracy of AI output, and only 3% highly trust it.

That gap is the whole story. People who write code for a living use AI every day and still check what it produces. Many people building with AI for the first time don't know what to check.

Why AI-generated code is often insecure

AI tools are trained to produce code that works, not code that is safe. In Veracode's 2025 GenAI Code Security Report (opens in a new tab), code from more than 100 language models introduced vulnerabilities from the OWASP Top 10 in 45% of test tasks. Newer models wrote better-working code, but not more secure code.

There are three reasons for this.

• The prompt rarely mentions security. "Build a booking form" gets you a booking form. Nobody asked who may read the bookings.
• The model doesn't see the whole system. It writes one piece at a time and doesn't know where your data lives, who your users are or what an attacker would want.
• It learned from public code. Public code is full of shortcuts and tutorials that were never meant for production, and the model repeats them confidently.

The result looks finished. The interface is polished, the demo works, and the problems are invisible until someone goes looking for them.

The 7 most common security gaps in vibe-coded sites and apps

These are the issues I see most often when reviewing AI-built projects. None of them requires a sophisticated attacker. Most can be found by anyone who opens the browser's developer tools.

1. Secret keys shipped to the browser

AI tools often put API keys for OpenAI, Stripe or email services straight into front-end code to make a feature work. Anything in the browser is public. A leaked key means someone else spends your money or sends email in your name.

What to check: secret keys live only on the server, are stored as environment variables, and never appear in the code users download.

2. A database anyone can read

Many AI builders connect the app directly to a hosted database. That is fine only if the database has rules saying who may read and change each record. In 2025, researcher Matt Palmer scanned 1,645 public apps built with Lovable and found 170 of them (opens in a new tab) with tables open to anyone, exposing names, emails, addresses and API keys. The issue was registered as CVE-2025-48757.

What to check: every table has access rules switched on, and a logged-out visitor can't read anyone's data.

3. Security that exists only in the interface

A common pattern: the "Delete" button is hidden for regular users, so the app looks protected. But the server still accepts the delete request from anyone who sends it. Hiding a button is design, not security.

What to check: every action that changes or reveals data is checked on the server, for every request.

4. Trusting whatever users send

Forms, file uploads and URL parameters are input from strangers. AI-generated code often accepts them as they are, which opens the door to spam, broken data and injection attacks.

What to check: input is validated on the server, uploads are limited by type and size, and forms are protected from bots.

5. Packages that don't exist

AI tools sometimes recommend software libraries that were never published. A USENIX Security 2025 study (opens in a new tab) of 16 models found that 19.7% of suggested packages didn't exist. Attackers register those invented names with malicious code inside, a technique now called slopsquatting.

What to check: every dependency is real, maintained and actually needed. Fewer packages means fewer doors.

6. AI agents with too much access

Agents that can run commands are powerful, and they make mistakes with confidence. In July 2025, a Replit agent deleted a live production database (opens in a new tab) during a code freeze in SaaStr founder Jason Lemkin's public experiment. At the time, the same database was used for development and production.

What to check: development, testing and production are separate, and no AI tool has write access to live data.

7. No safety net

Vibe-coded projects often launch without backups, error monitoring, rate limits or a plan for updates. Nothing goes wrong until something does, and then there is no way back.

What to check: automatic backups you have restored at least once, monitoring that alerts a person, and dependencies kept up to date.

Is vibe coding safe for a business website?

It depends on what the site does, not on how it was built. A static landing page with no forms carries little risk. An app with logins, payments or personal data needs the same engineering care whether a person or an AI wrote the first draft.

The rule of thumb: once real people trust your app with their data or money, "it works" is no longer enough.

A 10-point pre-launch checklist

Use this as a first pass before an AI-built site or app goes public. If you can't answer "yes" to a point with confidence, that's where a second pair of eyes helps most.

1. No secret keys appear in the code that runs in the browser.
2. Every database table has access rules, and a logged-out visitor can't read private data.
3. Every action that changes data is checked on the server, not only hidden in the interface.
4. Forms and uploads are validated on the server and protected from bots.
5. Every package in the project exists, is maintained and is actually used.
6. Development, testing and production use separate databases and keys.
7. No AI agent or tool has write access to production.
8. Passwords and logins use a proven service or library, not custom code.
9. Backups run automatically, and you have tested restoring one.
10. Someone gets an alert when the site breaks or behaves unusually.

This list catches the most common problems. It is not a full security audit, and an app that handles payments or sensitive data needs one.

How we use AI at ROOKS

We use AI every day, and we're not going to pretend otherwise. It speeds up routine work: boilerplate, first drafts of components, test cases, documentation. That time goes back into the parts that decide whether a project is safe and holds up.

What AI doesn't do at ROOKS:

• Make architecture decisions. Where data lives, who can access it and how the parts connect is decided by an engineer.
• Ship code nobody has read. Every line that reaches production is reviewed by a person who understands it.
• Touch live systems. AI tools work in development. Production access stays with the team.
• Replace testing. We check layouts, interactions and content on real devices and browsers before handover.

The result is the speed of AI with the responsibility of a team of four engineers, where the people you talk to are the people who write and check the code.