Is your vibe-coded app leaking?

Vibe coding securityis the practice of finding and closing the holes an AI coding assistant leaves behind. When you build fast by prompting a model, the app works before anyone checks what it hands to the public: a secret key in the browser, a database table with no access rule, an API that returns everyone's data. None of it looks broken. All of it is readable from outside.

Common questions

Is my vibe-coded app safe?

Not automatically. In a controlled 2025 study, Veracode found AI introduced a known security flaw in 45% of the code-generation tasks it tested when the model was given no explicit security guidance. That does not mean half of all shipped apps are broken, but it does mean the code an assistant writes is not secure by default. The holes that show up from outside are usually a small set: a key that shipped to the browser, a database table with no access rule, and an API that returns more than it should. Those are the ones worth checking first.

Why is there an API key in my frontend, and is that a problem?

Some keys belong in the browser and some do not. A publishable key, like a Supabase anon key or a Stripe publishable key, is public by design and shipping it is fine. A secret key, like a Supabase service_role key or a Stripe secret key, is a fire: the Supabase service_role key bypasses row-level security entirely and gives whoever holds it full read, write, and delete on every table. The rule is simple: publishable keys can ship, secret keys never can. If you cannot tell which one you have, that uncertainty is the thing to resolve first.

How can my waitlist or user data be visible in the frontend?

Because the browser queries your database directly and the only thing stopping it is a policy you may not have written. With Supabase, the public anon key can read any table that has no row-level security rule. Supabase enables RLS by default on tables made through its dashboard, but tables created in raw SQL or a migration, which is the path an AI assistant takes, do not get it automatically. So the waitlist table ships, the query runs from the browser, and every row comes back to anyone who sends the request. The fix is a policy on the table, not hiding the key.

Does the same thing happen with Firebase?

Yes, through Firebase Security Rules. Firebase lets the client read and write the database directly, and the rules are the only safeguard. When you create a database you choose Locked mode (deny by default) or Test mode (allow anyone). Ship an app that is still in Test mode and, in Firebase's own words, anyone who guesses your project ID can steal, modify, or delete the data. The classic open ruleset, allow read and write if true, carries Firebase's warning to never use it in production.

How do I check what my AI-built app is exposing?

Open your live site in an incognito window with no login, open the browser's network tab, and watch what the page requests. Every call to your backend or database is something a stranger can make too. For each response that carries data, ask whether a logged-out visitor should see it. A passive external scan does the same thing at scale: it reads what your site already serves to the public and grades it, without sending an attack or logging in. That is what SurfaceCheckr does, and it is why the exposures on this page are exactly the ones it looks for.