Is Your Vibe-Coded App Secure?

Not unless someone has checked: AI tools are very good at making apps work, but they do not reliably make them secure, so every vibe-coded app should pass the checklist below before real users and real data arrive.

We work with Replit, Lovable, Bolt, Cursor, v0, Base44 and Claude Code.

Get a free health check See the App Launch Audit

What does the research say?

Escape's research on the state of security in vibe-coded apps reported more than 2,000 highly critical vulnerabilities and more than 400 leaked secrets across about 1,400 vibe-coded applications, along with exposed personal information. Veracode's 2025 GenAI Code Security Report tested more than 100 large language models on 80 coding tasks and found that in 45 per cent of test cases the generated code introduced a vulnerability in the OWASP Top 10. CVE-2025-48757 describes insufficient row level security policies in some Lovable-generated projects using Supabase. The reported issue has been disputed by the supplier and is not evidence that every current Lovable app is vulnerable. None of this means AI tools are bad. It means the security check has to be done deliberately, by someone who knows where to look.

The vibe-coded app security checklist

1. Are any API keys or secrets exposed?

Check: secret keys (payments, AI providers, email, database service keys) must never appear in front-end code, public repositories or git history. Why: anyone who finds a secret key can spend your money or read your data. Quick check: search your code and repository history for key prefixes and anything named secret, token or key. Rotate any key that has ever been public.

2. Is Supabase row level security on and correct?

Check: every table has row level security enabled, with policies that limit each user to their own rows and roles. Why: many AI-built apps query the database from the browser with a public key, so these policies are the main protection. Quick check: review each table's policies and test as a logged-out user and as a second user.

3. Do auth and roles work as intended?

Check: sign-up, login, password reset, email verification, session expiry and role assignment. Why: broken auth lets people into accounts or features they should not reach. Quick check: create users for each role and try every protected action with each one.

4. Are admin routes checked on the server?

Check: admin pages and APIs verify the user's role on the server, not just by hiding buttons. Why: hidden buttons do not stop a direct request. Quick check: as a normal user, try the admin URLs and API calls directly.

5. Are payment webhooks verified?

Check: webhook endpoints verify the provider's signature and handle repeated or out-of-order events. Why: unverified webhooks can be faked to mark orders as paid. Quick check: confirm signature verification is in the code and test with the provider's test tools.

6. Are dependencies up to date and needed?

Check: packages are maintained, free of known vulnerabilities and actually used. Why: AI tools add packages freely, and each one is code you are trusting. Quick check: run your package manager's audit command and remove what you do not use.

7. Is there rate limiting?

Check: login, sign-up, password reset, contact forms and expensive API routes have rate limits. Why: without limits, bots can guess passwords, spam forms or run up your bills. Quick check: confirm limits exist in code or at the hosting layer.

8. Are backups running and tested?

Check: automated database backups exist, are stored separately and have been restored at least once. Why: AI agents and people both make destructive mistakes. Quick check: restore last night's backup to a test environment.

9. Are AI features protected from prompt injection and runaway costs?

Check: user input cannot override your system instructions or pull private data through the model, and token use is capped per user. Why: prompt injection can leak data, and uncapped usage can produce a very large bill. Quick check: review what data the model can reach, and set usage limits and spend alerts with your AI provider.

Which tool did you build with?

We work with Replit, Lovable, Bolt, Cursor, v0, Base44 and Claude Code.

Want a second pair of eyes?

If you ticked fewer than all nine, start with a free health check. For a full review with a launch readiness score and prioritised fixes, book the App Launch Audit from A$2,800 plus GST.

Frequently asked questions

Are vibe-coded apps less secure than traditional apps?

Not by definition, but they are more likely to ship without a security review. AI tools optimise for code that works, and research such as Veracode's 2025 report found security flaws in 45 per cent of AI code test cases. The fix is simple: check the app deliberately against a list like this one before launch.

What is the most common security problem in AI-built apps?

Data access is the one we check first. Many AI-built apps let the browser talk to the database directly, so if row level security or security rules are missing or too loose, other people's data can be read or changed. Exposed secret keys in front-end code are the other issue worth checking straight away.

Can I check my app's security myself?

You can work through this checklist yourself, and it will catch many common gaps. Some checks, such as testing permissions across roles or reviewing webhook handling, are easier with development experience. If you are unsure about any item, the free health check is a no-obligation way to get a quick second opinion first.

How do I fix exposed API keys?

Rotate the key with the provider first, because a key that was ever public should be treated as compromised. Then move the new key into a server-side secret store, make sure only server code uses it, and remove the old key from your code and repository history so it cannot be found again later.