cd /news/ai-safety/vibe-coding-security-a-pre-launch-ch… · home › topics › ai-safety › article
[ARTICLE · art-162639] src=dev.to ↗ pub= topic=ai-safety verified=true sentiment=· neutral

Vibe Coding Security: A Pre-Launch Checklist for Non-Technical Founders

A pre-launch security guide for non-technical founders outlines five common failure modes in AI-generated "vibe coded" apps, including missing database access rules, exposed secret keys, client-side-only permission checks, unvalidated input, and absent rate limits. It cites Wiz researchers' finding that Moltbook, a social platform built with AI tools, exposed user data and API keys through a database key left in its public website code. The guide offers hands-on tests, such as the two-account and logged-out checks, that founders can run without reading code.

by read6 min views1 publishedNov 2, 2026

An AI tool can now build you a working app in a weekend. It will have sign-up, a database, and a polished interface. What it may not have is a lock on the front door. Vibe coding security is the part of building with AI that nobody demos, because a broken permission rule looks exactly like a working app until a stranger finds it.

This is not a theoretical worry. In one widely covered case, security researchers at Wiz found that Moltbook, a social platform built with AI tools, had exposed user data and API keys through a database key left in its public website code, according to Infosecurity Magazine. The problem was not exotic. It was a basic setting that nobody had checked.

The good news is that the most common failures are well known, and you can test for many of them yourself without reading any code. This guide explains what goes wrong, how to check, and when to bring in a professional.

AI coding tools are good at making features work. If you ask for a page that shows a user's orders, you will get one. But "works" and "safe" are different goals. The page may show the right orders when you click through it normally, while the database behind it would happily hand any order to anyone who asks in a slightly different way.

Three things make vibe coding security harder for non-technical founders:

Asking the tool to review its own work is still useful, as you will see below. It just cannot be the only check.

Most vibe coding security problems fall into five groups.

This is the big one. Many AI-built apps talk to the database directly from the browser or the phone, using a public key. That design can be perfectly safe, but only if access rules on the database decide who can read and change each record. In Supabase these are called Row Level Security policies. In Firebase they are called Security Rules.

If those rules are missing or too loose, anyone who finds your public key, which is easy to find, can read or edit other people's data. Often all of it. Some keys are meant to be public. Others, like your OpenAI, Anthropic, or Stripe secret keys, must never reach a user's device. Anything sent to the browser or built into a mobile app can be extracted. A stolen AI key can produce a surprise bill in days. A stolen payment key is far worse.

Secret keys belong on a server, in protected settings, with your app calling the server rather than the outside service directly.

An AI may hide the "Admin" button from regular users and consider the job done. But hiding a button does not stop someone from sending the request directly. Every permission check must also happen on the server or in the database rules, where users cannot tamper with it. The same applies to paid features and anything else that is restricted.

Forms, file uploads, and URLs can all carry input you did not expect, like an enormous file, a price changed to zero, or text containing code. Good apps check everything on the server before acting on it. AI-generated apps sometimes skip this, especially for features added late in a long conversation.

If anyone can trigger an AI call, send an email, or send a text message as many times as they like, someone eventually will. Rate limits and spending caps turn a potential disaster into a minor annoyance. You can run these checks in an afternoon. Do them on a test copy of your app if you have one, and only on apps you own.

The two-account test. Create two accounts, A and B. As A, create something private, then copy the URL of that item. Log in as B and paste the URL. If B can see or edit A's data, you have a serious problem. This single test catches a surprising number of failures.

The logged-out test. Copy the URL of a private page, log out, and open it in a private browser window. You should be sent to a login page, and no private data should appear.

The small-user test. Log in as a regular user and try to open any admin address you know about. Try using a paid feature from a free account.

The key search. Open your site in a desktop browser, open the developer tools, and search the loaded files for text like sk-, secret, or service_role. Anything that looks like a secret key should not be there. If you find one, treat it as stolen: replace it with a new key from the provider, then fix how the app stores it.

The repository check. If your code lives on GitHub, make sure the repository is private unless you meant otherwise, and search it for the same terms. Old commits count too, because a key removed later can remain in the history.

The form test. Try absurd inputs: a very long name, a negative quantity, a huge file, a file with the wrong type. The app should refuse gracefully rather than accepting it or crashing.

AI tools are better at finding security problems when you ask specific questions instead of a general one. Try prompts like these, one at a time:

Then verify the answers with the tests above. Also check your platform's own security scanner and database advisor if it has them, since some builders now include one. They do not catch everything, but they are free and quick.

Do-it-yourself checks are a sensible floor, not a guarantee. Pay a developer or security specialist for a review before launch if your app does any of the following:

A focused review of your authentication, database rules, and secret handling is much smaller than a full audit, and it costs far less than a breach, an emergency rebuild, or the loss of your users' trust. Ask for a written list of findings, ranked by severity.

Do not panic, and do not ignore it. Fix the hole first, and replace any exposed keys. Then check your logs to work out what was accessed. If personal data may have been exposed, you may have legal duties to notify users or regulators, sometimes within tight deadlines, so get proper legal advice quickly.

Vibe coding security comes down to one habit: never treat a working app as proof of a safe one. AI has made building dramatically easier, and the tools are improving, but you are still the one responsible for your users' data. An afternoon of testing before launch is one of the cheapest forms of insurance you will ever buy.

Originally published at https://foundyra.com/news/vibe-coding-security

── more in #ai-safety 4 stories · sorted by recency
── more on @wiz 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
→ Live at https://your-agent.zahid.host ✓
Get free account → Pricing
from €0/mo · no card required
LIVE [news/vibe-coding-security…] indexed:0 read:6min 2026-11-02 · —