Vibe Coding Security Risks and Pre-Launch Checklist

Apps built by prompting an AI carry the same documented risks as other software, plus a few specific to AI tools: invented package names, secrets in prompts, and agents with too many permissions. OWASP and vendor documentation describe these. This page lists them and gives a checklist. It gives no verdict on any tool.

We read the sources below on 2026-10-03. We tested no app and no tool. We cite no vulnerability-rate statistics, because we have not read a primary study we could vouch for.

What risks do the sources document?

What the sources say: broken access control

The OWASP Top 10:2025 lists "A01:2025 Broken Access Control" first. OWASP defines access control as enforcing policy "such that users cannot act outside of their intended permissions," and says failures typically lead to unauthorized information disclosure, modification or destruction of all data, or performing a business function outside the user's limits. OWASP also states that "100% of the applications tested were found to have some form of broken access control" (OWASP Top 10:2025).

The same list includes security misconfiguration (A02), software supply chain failures (A03), cryptographic failures (A04), injection (A05) and authentication failures (A07) (OWASP Top 10:2025).

What the sources say: risks specific to AI coding tools

OWASP's Secure Coding with AI Cheat Sheet states that agentic coding tools "execute shell commands, install packages, edit files, run tests, access the network, and push branches autonomously," and that many developers run them with auto-accept enabled (OWASP Cheat Sheet Series). It documents these risks:

• Hallucinated dependencies. The cheat sheet says "AI coding assistants frequently suggest package names that do not exist on public registries." Its recommendation: verify that every suggested package exists on the public registry before installing it.
• Outdated dependencies. AI tools "frequently suggest dependency versions that were current during training but now have known vulnerabilities." Its recommendation: run dependency auditing tools on AI-generated dependency lists before merging.
• Prompt injection against agents. "Any content the agent reads can contain hidden instructions that alter its behavior." Its recommendation: treat repository content as untrusted input when an agent processes it.
• No sandbox. "Without sandboxing, a compromised agent context has the same privileges as the developer." Its recommendation: run agents in dev containers, restricted shells or virtual machines.
• Context leakage. The prompt context sent to an AI provider may include credentials, personal data and proprietary logic. Its recommendation: exclude files such as .env and key files from the tool's context, and keep secrets in environment variables or secret stores, not in project files the tool can read.
• Review anchoring. The cheat sheet says reviewers anchored on the requested change miss other modifications. Its recommendation: review every file in an agent-generated pull request, and do not approve based on the description alone.
• Accountability. "AI-generated code must have a human owner." The cheat sheet adds that AI tools do not accept responsibility for the code they generate, and that the developer who accepts and commits it does.

The cheat sheet does not use the phrase "vibe coding". Its guidance applies to AI-generated code in general.

The OWASP Top 10 for LLM Applications 2025 names "LLM06:2025 Excessive Agency." It describes three causes: excessive functionality, excessive permissions and excessive autonomy, meaning a lack of human verification before high-impact operations (OWASP GenAI Security Project). This applies when your app lets an AI call functions or other systems.

What the sources say: vendor documentation for generated apps

• Lovable documents these practices in its security best practices. Secrets stored in frontend code "are visible to users and should be considered compromised." Authentication decisions "must happen server-side, not in the browser." Row-level security (RLS) should be enabled on sensitive tables, and server-side code that uses the service role bypasses RLS, so that code must check permissions itself (Lovable security best practices).
• Lovable's built-in scans. The Quick scan runs every time you publish. It covers database access rules (for example tables without row-level security), a dependency audit, and an MCP server your app exposes without authentication. The Deep scan covers more areas, including access control, injection and leaked secrets. Lovable also says these tools "cannot guarantee complete security" and suggests considering a professional review for apps that handle sensitive data or critical functionality (Lovable security overview).
• Supabase documents that "a table in an exposed schema without RLS is readable and writable by any role with a grant on it," and says to enable RLS on every table in an exposed schema. It also says that once RLS is enabled, no data is accessible through the API with a publishable key until you create policies (Supabase Row Level Security docs). Supabase is a common backend for generated apps, but not the only one. Other backends have their own equivalents.

What to consider

The pattern across these sources is that the generated app and the data behind it need separate checks. The code can look finished while access rules are missing or secrets sit where users can read them. The sources also show that AI tools can add risk to the build process itself, through package names and agent permissions.

What should you check before launch?

This is our own checklist, built from the sources above. It is tool-agnostic and incomplete. It does not show that an app is secure.

Access and accounts

1. Test as a stranger. Open the app in a private window. Can you see or change data without logging in?
2. Test as a second user. Create two accounts. Can account B read or change account A's records? OWASP puts broken access control first.
3. Check where access is enforced. Lovable's docs say authentication decisions must happen server-side. If your only check is a hidden button in the browser, it is not an access control.
4. Check database rules. If your backend has row-level security, confirm it is enabled on every table that the API exposes, and read the policies.

Secrets and keys

5. Search for secrets in the frontend. Per Lovable's docs, secrets in frontend code should be considered compromised. Search the code and the built files for API keys and tokens.
6. Use the platform's secret storage. Keep keys out of prompts and out of project files.
7. Rotate any key that was ever pasted into a prompt or committed to a repository. The OWASP cheat sheet describes prompt context as a leakage path.

Dependencies and build

8. Check every package. Confirm that each dependency exists on the official registry, and that its name is spelled correctly, before you install it.
9. Run a dependency audit. Update packages that have known vulnerabilities.
10. Review the diff. If an agent changed your project, read the changed files, not only the summary.

Agents and integrations

11. Limit what the AI can do. Grant the minimum tools, permissions and data access. Require human approval for high-impact actions, as OWASP's Excessive Agency entry describes.
12. Check any MCP server or tool your app exposes. Lovable's Quick scan flags an MCP server exposed without authentication.
13. Treat content the agent reads as untrusted. Web pages, files and issues can contain hidden instructions.

Before you publish

14. Run the platform's scan, then read the results. Do not treat a clean scan as a security guarantee. Lovable says its scans cannot guarantee complete security.
15. Name an owner. Someone must be accountable for the code, as the OWASP cheat sheet says.
16. Decide what happens if something goes wrong. Know how to take the app offline, revoke keys and notify affected users.
17. Get an independent review if the stakes are high. This applies when the app handles personal, payment or health data.

Limitations of this page

• It draws on OWASP, Lovable and Supabase documentation. It does not cover every builder or backend.
• We tested no generated app. We did not scan any app, and we make no claim about how common these issues are.
• We left out vulnerability-rate figures. Search results showed several, but we did not verify any against its primary study.
• OWASP lists describe categories of risk. They do not say your app has these problems.
• Vendor pages change. The statements above are as read on 2026-10-03.
• This is not a compliance or legal analysis.

When is this checklist not enough?

• You handle regulated data. Payments, health and children's data come with legal duties that this page does not address. Get qualified advice and an independent review.
• You are shipping to many users or to a business customer. They may ask for a security assessment. A checklist from an explainer is not one.
• You want to know whether a particular tool is secure. Read that vendor's security and trust pages. This page makes no judgment of any tool.

For background on the term, see what vibe coding means. To compare tools by the documented features they list, see our coding and app builders category. If you work in an editor with an assistant rather than a builder, see how to choose an AI coding assistant.