Is my AI-built app secure?

Also searched as: Vibe coded app security checklist · Vibe coding security risks · Vibe coding security vulnerabilities · Vibe coding security issues · Vibe coded app security

Updated 3 October 2026

Short answer

Don't assume it is. In a peer-reviewed study published at ACM CCS 2023, people using an AI coding assistant wrote significantly less secure code than people without one, and were more likely to believe their code was secure. AI tools build what you ask for. If you didn't ask who's allowed to see what, the app probably doesn't check. Start with three things: whether one user can reach another user's data, whether any secret keys are in the browser, and whether the database is open.

What's the problem

You built an app with Lovable, Bolt, Replit, Cursor, Base44 or a chat assistant, and it works. Now real people are about to sign up, maybe pay, and you can't read the code well enough to know what it's doing with their data.

Why it happens

  • The AI optimises for "it works". It writes code until your request is satisfied. Whether a signed-in user can reach someone else's records is a question it often isn't asked.
  • Security settings get switched off to fix errors. When a database policy blocks a query, a common "fix" is to remove the policy. On Supabase, a table without Row Level Security in an exposed schema can be read and written by anyone with the app's public key.
  • Keys end up in the browser. Secret keys for AI models, payments or the database get placed where the frontend can read them, so every visitor can.
  • Your key pays for everyone. Some builders deploy apps that call a paid AI model with your own key on every user's behalf, so heavy or abusive use lands on your bill.
  • Confidence is high. The study above found that people using AI assistants were more likely to believe their insecure code was secure.

How to fix it

  1. Test access as an attacker. Sign up as two users. As user B, try to open user A's records by changing an ID in the address bar or in a request. It must fail.
  2. Check the database rules. Supabase: Row Level Security on for every table in an exposed schema, with policies. Firebase: no test-mode rules. See Supabase RLS and Firebase rules.
  3. Find every secret in the frontend. Open your live site, view the loaded JavaScript, and search for keys. Anything secret moves to a server-side function and gets rotated.
  4. Put limits on paid calls. Rate limits per user, and spending caps with the AI and payment providers.
  5. Check payments are verified on the server, never trusted from the browser.
  6. Ask the AI to review its own work for these issues, then verify the answers yourself. Its review is a starting point, not a guarantee.
  7. Work through a full pre-launch security checklist.

When to call Preventionlabs

If you can test each item and it holds, you're in a good position. Call us when you can't tell, or when fixing one thing breaks the app. Preventionlabs comes from security research, finding flaws in production systems that their own teams missed, and MVP-level protection is one of the three things every resurrection delivers: authentication, access control, data exposure, injection, existing payment flows, rate limiting, HTTPS and dependency vulnerabilities, tested the way an attacker would test them, then fixed.

Submit your project for a free assessment

Free assessment. $10,000 AUD flat to get it live, only if we take it on and you go ahead.

Sources

  1. Perry, Srivastava, Kumar and Boneh (ACM CCS 2023): Do Users Write More Insecure Code with AI Assistants?peer-reviewed researchOverall, we find that participants who had access to an AI assistant based on OpenAI's codex-davinci-002 model wrote significantly less secure code than those without access.
  2. Perry, Srivastava, Kumar and Boneh (ACM CCS 2023): Do Users Write More Insecure Code with AI Assistants?peer-reviewed researchAdditionally, participants with access to an AI assistant were more likely to believe they wrote secure code than those without access to the AI assistant.
  3. Supabase: Row Level Securityplatform docsA table in an exposed schema without RLS is readable and writable by any role with a grant on it.
  4. Google AI for Developers: Build apps in Google AI Studioplatform docsThe deployed app will use your API key for all users' Gemini API calls.
  5. OWASP: OWASP Top 10:2025security standards bodyA01:2025 - Broken Access Control

Related

How do I check my app is secure before launch? Check what attackers try first: who can see whose data, logins, open keys and databases, injection, payments, rate limits, HTTPS and old dependencies. Supabase RLS is disabled. Is my data public? A table in an exposed schema without Row Level Security is readable and writable through your public key, which is in your app. Turn RLS on for every table. Is my Firebase database open to anyone? If it was set up in test mode and never locked down, possibly. The API key being public is normal: the security rules are what protect the data. How to check. Are my environment variables public? Anything your frontend can read, every visitor can read. Settings prefixed VITE_ or NEXT_PUBLIC_ end up in the browser. Secrets belong on the server.
← All of Built with AI