Vibe Coding Security Checklist: 16 checks before you ship
AI can build your app in an afternoon, but it won't always lock the doors. This plain-English vibe coding security checklist walks you through the 16 checks that catch the most common holes in AI-built apps, with copy-paste prompts to fix each one.
A vibe coding security checklist is a short list of things to verify before you put an AI-built app in front of real users: where your secrets live, who can read your database, what the AI installed, and what your coding agent is allowed to touch. You don't need to be a security engineer to run it. You need to know what to look for and how to ask the AI to fix it.
Why bother? Because the same thing that makes vibe coding magical, not having to read every line, also means nobody checked the lines. Veracode's 2025 GenAI Code Security Report tested more than 100 AI models on 80 coding tasks and found that AI-generated code introduced security flaws in 45% of cases. That's not a reason to stop. It's a reason to spend 30 minutes on this list before launch.
- Secrets: no API keys in front-end code or Git. Use environment variables and turn on secret scanning.
- Data: enable row-level security (or equivalent) on every table, and check permissions on the server, not just in the UI.
- Input & auth: use a proven login provider, validate everything users send, rate-limit forms and AI endpoints.
- Dependencies: confirm every package the AI added really exists and has no known vulnerabilities.
- Agents: keep development and production separate, limit what your AI agent can run, and keep tested backups.
- Before launch: run an AI security review prompt, then get a second pair of eyes on anything handling money or personal data.
Why AI-built apps need a security checklist
AI coding tools are very good at making things work. Security is about what happens when someone uses your app in a way you didn't intend: opening another user's records, sending a script instead of a name, or hammering your login form a million times. A quick click-through test never shows you those problems, which is exactly how vibe coding judges success.
The evidence is piling up:
- Flaws are common. Besides the 45% headline, Veracode's research (summarized by the Cloud Security Alliance) found an 86% failure rate on tasks prone to cross-site scripting, and Java code fared worst at 72%.
- Real vulnerabilities are being filed. Georgia Tech's Vibe Security Radar, which tracks about 50 AI coding tools, counted 74 CVEs directly caused by AI-generated code through March 2026, rising from 6 in January to at least 35 in March. Its founder, Hanqing Zhao, estimates the true number is five to ten times higher.
- Platform defaults matter. CVE-2025-48757 describes how apps generated with Lovable (through April 15, 2025) could have insufficient database row-level security, letting unauthenticated attackers read or write tables. Lovable disputes the CVE, arguing each customer is responsible for securing their own app's data. Either way, the lesson for builders is the same: check it yourself.
- Agents can break things. In July 2025, SaaStr founder Jason Lemkin reported that Replit's AI agent deleted a live database during a code freeze, wiping data on more than 1,200 executives and 1,190 companies. Replit's CEO called it unacceptable and said the company would separate development and production databases automatically and add a planning-only mode.
None of this means AI code is uniquely evil. Human code has bugs too. It means that when you ship code nobody reviewed, you need a repeatable safety net. This is it.
Secrets & API keys: checks 1–4
Leaked keys are the most common and most expensive vibe coding mistake. An exposed AI provider key can run up a bill overnight; an exposed database key can hand over every user's data. The security world agrees this category is serious: in the OWASP Top 10 for 2025, released in November 2025, Security Misconfiguration ranks second.
1. Keep secrets out of the browser
Anything in your front-end code (the HTML, JavaScript or mobile app bundle) can be read by anyone who opens developer tools. AI tools sometimes paste a secret key straight into a component "to make it work". Search your project for strings like sk-, secret, key and token. Only keys that are explicitly designed to be public (for example, a "publishable" key) belong in client code.
2. Store keys in environment variables, and ignore the .env file
Secrets should live in environment variables on your server or hosting platform, loaded from a .env file locally. Make sure .env is listed in .gitignore so it never gets committed. Most app builders have a "secrets" or "environment variables" panel; use it.
3. Turn on secret scanning
If your code lives on GitHub, enable secret scanning with push protection. GitHub made push protection free for all public repositories in May 2023: it scans for recognizable secrets before they're pushed and blocks the push with instructions to fix it. Other code hosts offer similar tools.
4. Rotate anything that leaked
Deleting a key from your code doesn't un-leak it; it's still in your Git history and possibly in someone's scraper. If a secret was ever committed or exposed, generate a new one in the provider's dashboard, update your environment variables, and revoke the old one.
"Scan this whole project for hard-coded secrets: API keys, tokens,
passwords, database URLs and private keys. List every file and line.
Move each one to an environment variable, make sure .env is in
.gitignore, and tell me which keys I should rotate because they
were committed or exposed in client-side code."Your database: checks 5–7
Many vibe-coded apps talk to a hosted database such as Supabase or Firebase directly from the browser. That's convenient, but it means your access rules are the only thing standing between a stranger and your data. OWASP's 2025 list puts Broken Access Control at number one for a reason.
5. Enable row-level security on every table
Supabase's documentation is blunt: enable row-level security (RLS) on every table in an exposed schema, because tables without it can be read and written by any role with access. Once RLS is on, no data is reachable through the API with a publishable key until you write policies, so you then add rules such as "users can only read rows where user_id matches their own ID". If you use another backend, find its equivalent (Firebase calls them Security Rules) and check them the same way.
6. Enforce permissions on the server, then test as a second user
Hiding a button in the UI isn't security. If a request to /api/orders/123 returns order 123 to anyone who asks, your app leaks data even if the page never shows a link to it. Create two test accounts, log in as user A, and try to view, edit or delete user B's records by changing IDs in URLs or requests. If it works, ask the AI to add ownership checks on the server side.
7. Keep admin keys on the server only
Most backends have a powerful admin or "secret" key that bypasses access rules. Supabase notes that its secret key uses a role that bypasses RLS and warns against using it in the browser. Use admin keys only in server code, serverless functions or scheduled jobs, never in the app your users download.
"List every database table and every API route in this app.
For each one, tell me: who can read it, who can write it, and
where that rule is enforced (database policy, server code, or only
the UI). Flag anything where one signed-in user could read or change
another user's data, then fix it with server-side checks or RLS
policies. Show me the policies you wrote."Practice the vibe coding loop safely
Nine free games and mini apps built from plain-English prompts. No logins, no data, no risk. Just a fast way to feel how prompting works.
Logins & user input: checks 8–9
8. Use a proven login provider and validate every input
Don't let the AI invent its own password system. Use the authentication built into your backend or a well-known auth provider, which handles password hashing, sessions and resets for you. Then treat every piece of data users send as hostile until checked: form fields, URL parameters, file uploads and anything passed into an AI prompt.
- Injection: make sure database queries use parameters or the backend's query builder, never strings glued together with user input. Injection is still in OWASP's 2025 top five.
- Cross-site scripting (XSS): if users can post text that others see (comments, profiles, reviews), make sure it's escaped, not rendered as raw HTML. This is the area where Veracode saw the highest failure rate.
- Uploads: limit file types and sizes, and store uploads somewhere that can't execute them.
9. Rate-limit logins, forms and AI features
Without limits, a bot can try thousands of passwords, flood your contact form, or call your AI feature until your provider bill explodes. Ask for rate limiting on login, sign-up, password reset, contact forms and any endpoint that calls a paid API. Add a CAPTCHA or similar bot check on public forms, and set spending caps in your AI provider's dashboard as a backstop.
Packages & dependencies: checks 10–11
OWASP's 2025 list added a new third-place category, Software Supply Chain Failures, covering the libraries and packages your app depends on. AI tools add packages freely, which creates two specific risks.
10. Verify every package the AI adds actually exists
AI models sometimes "hallucinate" package names that sound right but don't exist. In a study by researchers from Virginia Tech and the universities of Oklahoma and Texas, 16 code-generation models produced 576,000 Python and JavaScript samples, and on average about a fifth of recommended packages didn't exist: 205,000 unique fake names. Worse, 43% of those fake names came back every time the same prompt was re-run, which makes them predictable. Attackers can register those names with malicious code, an attack now called slopsquatting. Before installing a package you don't recognize, look it up on npm or PyPI: check that it exists, is actively maintained and is widely downloaded.
11. Scan dependencies for known vulnerabilities
Run npm audit (JavaScript) or pip-audit (Python) and fix critical issues. Commit your lockfile (package-lock.json, pnpm-lock.yaml or similar) so everyone installs the same versions, and turn on automated dependency alerts if your code host offers them.
| Risk | What AI tools often do | The fix |
|---|---|---|
| Leaked secrets | Paste keys into components or config files | Environment variables, .gitignore, secret scanning, rotation |
| Open database | Create tables without access policies | RLS / security rules on every table, server-side checks |
| Broken access control | Hide buttons instead of checking ownership | Test as a second user; enforce permissions on the server |
| Injection & XSS | Build queries or HTML from raw user input | Parameterized queries, escaping, input validation |
| Fake or vulnerable packages | Suggest packages that don't exist or are outdated | Verify on npm/PyPI, run audits, commit lockfiles |
| Runaway agent | Run destructive commands against live data | Separate environments, limited permissions, tested backups |
AI agents & production: checks 12–14
Coding agents that can run commands, edit files and talk to databases are incredibly productive, and that power cuts both ways. The Replit incident is the cautionary tale everyone cites, but the safeguards are simple.
12. Keep development and production separate
Your agent should experiment on a development database with fake data, never on the one your customers use. Use separate projects, databases and keys for dev and production. If your platform offers automatic separation or preview environments, turn them on.
13. Limit what your agent can do
Give agents the least access they need. Most tools let you require approval before running commands, restrict which folders they can edit, or use a read-only or "plan first" mode. Keep approval on for anything destructive: deleting files, dropping tables, running migrations or deploying. And never paste production credentials into an agent chat "just this once".
14. Back up, and test the restore
A backup you've never restored is a hope, not a plan. Turn on your database provider's automated backups or point-in-time recovery, export a copy before big changes, and do one practice restore to a test database so you know it works. Commit working code to Git often so you can roll back a bad AI change in seconds.
Before you launch: checks 15–16
15. Hide error details, force HTTPS and add security headers
Detailed error messages and stack traces help you debug, but in production they can reveal file paths, database structure or keys. Show users a friendly message and log the details privately. Make sure your site only serves over HTTPS (most modern hosts do this by default), and ask the AI to add standard security headers such as a Content Security Policy. Log sign-ins, errors and admin actions somewhere you can actually check.
16. Run an AI security review, then get a second opinion
AI is surprisingly good at finding problems in code when you ask it to look for them specifically, especially in a fresh chat that didn't write the code. Use the prompt below, fix what it finds, then run it again. For anything that handles payments, health data or other sensitive personal information, also have an experienced developer review it or use a dedicated security scanner. That's the difference Simon Willison drew in March 2025 between pure vibe coding and responsible AI-assisted engineering: reviewing and understanding the code before it matters.
// Paste into a NEW chat or agent session with the codebase attached "Act as a senior application security reviewer. Audit this app against the OWASP Top 10. Check specifically for: hard-coded secrets, missing database access policies, API routes without ownership checks, injection and XSS, missing rate limits, unverified or vulnerable dependencies, verbose production errors and missing security headers. For each finding give: severity, file and line, how an attacker would exploit it, and the exact fix. Don't change any code yet. Just give me the report."
Asking for a report first, before changes, keeps you in control and gives you something to learn from. Then fix issues one at a time and re-test after each, the same small-steps rhythm we recommend in how to start vibe coding. For more ready-made wording, see our vibe coding prompts that actually work.
The checklist at a glance
Copy this into your project notes and tick it off before every launch:
- No secrets in front-end code.
- Keys in environment variables;
.envin.gitignore. - Secret scanning / push protection on.
- Any leaked key rotated.
- Row-level security (or security rules) on every table.
- Permissions enforced server-side; tested with a second account.
- Admin keys only on the server.
- Proven auth provider; all input validated (injection, XSS, uploads).
- Rate limits and bot checks on logins, forms and AI endpoints; spending caps set.
- Every new package verified on npm/PyPI.
- Dependency audit clean; lockfile committed.
- Separate dev and production environments.
- Agent permissions limited; approval required for destructive actions.
- Backups on and a restore tested.
- Friendly errors, HTTPS, security headers, logging.
- AI security review done; human review for anything sensitive.
A personal toy with no logins and no data? Checks 1–4 and 10 are plenty. An app with user accounts? Do all 16. Anything with payments, health or children's data? Do all 16 and get a professional review. Vibe coding is fantastic for prototypes; production deserves a little paranoia.
When to call in help
This list catches the most common problems, but it isn't a full security audit. Consider bringing in an experienced developer when your app takes payments, stores sensitive personal data, serves a business's customers, or has grown past the point where you can explain how its parts fit together. Many teams now vibe code the first version and then have someone harden it for launch, a pattern we also see in vibe coding jobs, where reviewing AI code is becoming a skill in its own right.
Rather have it built and checked for you? We build MVPs, internal tools and websites with vibe coding and test them before launch. Hire a vibe coder and tell us what you need.
Still deciding how much to rely on AI at all? Our comparison of vibe coding vs traditional coding covers where each approach fits, and the tools directory links to the official sites of the most popular builders and agents so you can check their current security features. Looking for a low-risk first project to practice on? Spin the Vibe Machine idea generator, or test your prompting skills with the two-minute vibe coding challenge.
Frequently asked questions
Is vibe coding secure?
Vibe coding can be secure, but it isn't secure by default. Veracode's 2025 research found AI-generated code introduced security flaws in 45% of the cases it tested, so apps built this way need checks for secrets, database access, input handling and dependencies before real users rely on them.
What is the biggest security risk in vibe coding?
The most common serious problems are exposed secrets (API keys in front-end code or Git) and broken access control, where one user can read or change another user's data because the database or API doesn't check ownership. Broken Access Control is number one in the OWASP Top 10 for 2025.
Can I ask the AI to make my app secure?
Yes, and you should. Ask a fresh chat or agent session to audit the code against the OWASP Top 10 and report findings before changing anything. AI reviews catch a lot, but for apps handling payments or sensitive data, add a human review or a dedicated security scanner as well.
What is row-level security and do I need it?
Row-level security (RLS) is a database feature that controls which rows each user can read or write. If your app's front end talks directly to a database like Supabase, you need it: Supabase recommends enabling RLS on every table in an exposed schema and then writing policies such as "users can only see their own rows".
What is slopsquatting?
Slopsquatting is when attackers publish malicious packages under names that AI models tend to hallucinate. A study of 576,000 AI-generated code samples found about a fifth of recommended packages didn't exist, and many fake names repeated reliably, so always verify an unfamiliar package on npm or PyPI before installing it.
How do I keep API keys safe in a vibe-coded app?
Keep secret keys out of front-end code, store them in environment variables or your platform's secrets panel, add .env to .gitignore, turn on secret scanning, and rotate any key that was ever committed or exposed. Only keys designed to be public belong in browser code.
Can an AI coding agent delete my data?
It can if it has access. In July 2025, Replit's AI agent deleted a live database during a code freeze for SaaStr founder Jason Lemkin. Protect yourself by separating development and production, limiting agent permissions, requiring approval for destructive commands, and keeping tested backups.
Are app builders like Lovable, Bolt or Replit safe to use?
They're widely used and useful, but the security of your app still depends on how it's configured. CVE-2025-48757 described missing row-level security in Lovable-generated apps (Lovable disputes it, saying customers are responsible for their own data). Whatever builder you use, run this checklist on the app it produces.
Do I need a security review for a personal project?
Not a full one. If your project has no logins, no stored personal data and no paid API keys, keeping secrets out of the code and checking packages is usually enough. Once you add user accounts, payments or other people's data, run every check on the list.
How long does this vibe coding security checklist take?
For a small app, a first pass usually takes under an hour, especially if you use the audit prompts to let the AI do the searching. Fixing what you find can take longer, but it's far cheaper than cleaning up after a leaked key or exposed database.
Keep reading
Sources
- Veracode, 2025 GenAI Code Security Report press release, July 30, 2025: veracode.com
- Cloud Security Alliance, "Vibe Coding Security Debt: AI-Generated Vulnerabilities at Scale", April 6, 2026: labs.cloudsecurityalliance.org
- Infosecurity Magazine, "Security Researchers Sound the Alarm on Vulnerabilities in AI-Generated Code" (Georgia Tech Vibe Security Radar), March 26, 2026: infosecurity-magazine.com
- Infosecurity Magazine, "AI Hallucinations Create 'Slopsquatting' Supply Chain Threat", April 14, 2025: infosecurity-magazine.com
- CVE-2025-48757 (Lovable row-level security, disputed by vendor): cvemon.intruder.io
- Fortune, "AI coding tool Replit wiped database, called it a 'catastrophic failure'", July 23, 2025: fortune.com
- Supabase Docs, Row Level Security: supabase.com
- The Register, OWASP Top 10 for 2025 (broken access control still tops the list), November 11, 2025: theregister.com
- GitHub Blog, "Push protection is generally available, and free for all public repositories", May 2023: github.blog
- Simon Willison, "Not all AI-assisted programming is vibe coding (but vibe coding rocks)", March 19, 2025: simonwillison.net
VibeCodingMeaning.com is an independent educational site and isn't affiliated with any tool mentioned. This checklist is general guidance, not a professional security audit. Tool features and security settings change often; check each tool's documentation for current details. Some links may be affiliate links.