Why AI Built Apps Work in the Demo and Leak in Production
Vibe coding security problems rarely come from a single dramatic bug. They come from the way AI coding tools are prompted. You ask for a dashboard that shows a customer's invoices, and the tool builds exactly that: a screen, a query and a database table that light up correctly when you click through it yourself. Nobody asked who should not be able to see those invoices, so the code often never checks.
That gap between "it works" and "it is safe" is the whole story. A prototype is tested by one friendly person with full access. A production app is used by strangers, some curious and a few hostile, who will open the browser's developer tools, change an ID in a request or paste strange text into a form. Tools like Lovable, Cursor, Bolt, Replit and v0 are excellent at producing the first version, and they will often fix a security issue when you point at it. They are much less reliable at noticing the issue nobody mentioned.
The good news is that the holes are predictable. The same handful of mistakes show up again and again, and most of them line up with categories in the OWASP Top 10:2025, the industry's reference list of web application risks. If you know where to look, you can find most of them in an afternoon.
Exposed Secrets in the Browser Bundle
The most common hole is also the easiest to check. Anything shipped to the browser is public, including the JavaScript bundle your build tool produces. When an AI tool wires up Stripe, an email service, an AI model provider or a database, it sometimes places the secret key directly in front end code or in an environment variable that the framework exposes to the client. Anyone can open the page source, search for words like key, secret or token, and copy what they find.
A second version of the same problem lives in your repository. Files such as `.env` get committed to git, and a public or shared repo then carries live credentials in its history even after you delete the file. Deleting the line does not remove the secret from earlier commits.
The fix has three parts. Move every secret to server side code or a serverless function so the browser only ever talks to your own endpoint. Rotate any key that has ever appeared in a bundle or a commit, because you have to assume it was copied. Then turn on secret scanning in your git host so the next accidental commit is caught before it ships. Most payment and backend providers separate publishable keys, which are safe in the browser, from secret keys, which never are. Learning which is which removes most of the risk.
Missing Authorization Checks on Every Request
Broken access control sits at the top of the OWASP list, and vibe coded apps are a big reason why. The pattern looks like this: the app checks that you are logged in, then serves whatever record you ask for. If your invoice lives at `/api/invoices/1043`, changing the number to 1044 shows you somebody else's invoice. Being logged in answers who you are. It does not answer what you are allowed to see, and that second question is the one AI generated code tends to skip.
The same gap shows up in admin features. A tool hides the admin menu from regular users in the interface, but the admin API endpoints behind it accept requests from anyone with a valid session. Hiding a button is a design choice, not a security control.
The fix is to enforce ownership and roles on the server for every request that reads or changes data. Deny by default, then allow only the specific user or role that owns the record. Write a few automated tests that log in as one user and try to read another user's data, and keep them in your test suite so a future prompt cannot quietly undo the check. When we review an app, this is usually where the most serious findings live, because the app looks perfectly fine until someone tries a second account.
Open Database Rules and Disabled Row Level Security
Many AI builders pair with hosted backends that let the browser talk to the database directly. That design is fine, but only because the database enforces rules about which rows each user may read and write. In Supabase that means row level security policies. In Firebase it means security rules. When those rules are missing, or set to allow everything, the public key that ships with the app becomes a key to the whole table.
This often happens for an understandable reason. A query fails during development with a permissions error, the builder asks the AI to fix it, and the quickest fix is to turn the protection off or write a rule that allows all reads. The app starts working, the error disappears, and nobody remembers that the door was propped open. OWASP files this kind of problem under security misconfiguration, which climbed to second place in the 2025 list.
Closing it means enabling row level security on every table that holds user data, writing a policy for each role and action, and then testing those policies with a second, unprivileged account. Check storage buckets too, since uploaded files such as IDs, contracts and photos often sit in buckets set to public. Review the rules again every time the schema changes, because a new table starts life unprotected unless someone remembers to add its policy.
Injection, Including the New Prompt Kind
Injection has been on the OWASP list for as long as there has been a list, and it is still there in the 2025 edition. The classic case is SQL built by gluing user input into a query string. AI tools usually reach for an ORM or a query builder, which helps, but generated code still drops into raw queries for search filters, reports and sorting options, and those are exactly the places where input gets concatenated. Cross site scripting is the browser side cousin: user content rendered as HTML without escaping, often through a component that was told to "render rich text".
Apps with AI features add a newer problem. If your app sends user text or uploaded documents to a language model and then lets the model's answer trigger actions, such as sending email, updating records or calling an API, a crafted input can steer the model into doing something you never intended. Treat model output as untrusted input, just like a form field.
The fixes are well established. Use parameterized queries everywhere, with no exceptions for admin screens. Validate input on the server, not only in the form. Escape output by default and sanitize any HTML you must render. For AI features, limit which tools the model may call, require confirmation for anything destructive and log every action it takes so you can audit it later.
Dependencies and Software Supply Chain Risk
A vibe coded app can pull in dozens of packages in a single session, and each one is code you are now trusting with your users' data. OWASP's 2025 list folds the old "vulnerable and outdated components" category into a broader one called software supply chain failures, which reflects how much risk now arrives through packages, build tools and the services around them.
AI tools add two twists. They sometimes suggest packages that are abandoned, duplicated or far heavier than the job needs, because those packages were common in training data. Less often, they suggest a package name that does not exist at all, and attackers have learned to register plausible names in the hope that someone installs them. Either way, the person accepting the suggestion rarely checks who maintains the package or when it was last updated.
A sensible routine closes most of this. Commit your lockfile so builds are repeatable. Run your package manager's audit command and review what it reports instead of ignoring it. Remove packages the app no longer uses, and before adding a new one, confirm it exists on the official registry, has an active maintainer and does what its name suggests. Then schedule regular updates rather than letting versions drift for a year and facing a painful upgrade all at once.
Login, Error Handling and the Logs Nobody Set Up
Three quieter problems round out the usual findings. The first is authentication that works but has no defenses: no rate limit on the login form, no lockout after repeated failures, password reset links that never expire and sessions that live forever. Using a reputable auth provider solves much of this, but only if its protections are actually switched on.
The second is error handling. Generated code often returns full error messages and stack traces to the browser, which can reveal table names, file paths and library versions to anyone who triggers a failure. Worse, some code fails open, so when a permission check throws an error the request proceeds anyway. OWASP added mishandling of exceptional conditions to the 2025 list for exactly this reason. Errors should be logged in detail on the server and shown to users as a plain, generic message, and any failed check should deny the request.
The third is logging and alerting. Many prototypes record nothing about who did what, so when something goes wrong there is no trail to follow. At minimum, log sign ins, permission failures, payment events and admin actions, and send alerts for unusual spikes. You cannot fix what you cannot see, and you certainly cannot explain it to a customer.
Vibe Coding Security Fixes in a Practical Order
If you have a live app and a list of worries, order matters. Start with anything that exposes data right now: secrets in the bundle or repository, tables without row level security and endpoints without ownership checks. Rotate keys first, because a leaked key keeps working until you replace it. Then add the tests that prove each fix, so the next round of AI assisted changes cannot reopen the hole.
Next, deal with injection points and file storage, then the login protections and error handling, and finally the dependency cleanup and logging. That sequence puts the problems that harm users today ahead of the ones that are merely untidy. It also keeps you shipping, since most of these fixes can land one at a time without a rewrite.
Some apps are better rebuilt than patched, usually when business logic lives in the browser or every screen talks to the database in its own way. An honest review tells you which situation you are in. Neon Manatee is a Florida-based team that does this work for apps built on any of the popular AI tools, and rescues are priced in our online estimator with the rescue option checked. Floors start at $1,200 per platform for simple apps, $15,000 for logic heavy apps and $25,000 for complex and secure apps, with 30 percent down.
Frequently asked questions
Is vibe coding secure?
Vibe coding can produce secure software, but it does not do so by default. AI tools build what you ask for, and most prompts describe features, not threats. The result is often an app with exposed keys, missing authorization checks or open database rules. A security review by someone who reads the code the way an attacker would closes those gaps before real users and real data arrive.
What is the most common security hole in AI built apps?
Two problems show up most often. Secret keys end up in the browser bundle or the git history, where anyone can copy them, and the server returns records without checking that the logged in user owns them. Both are quick to find and fix, but both can expose customer data or run up bills on your accounts until they are closed.
How do I check my app for exposed API keys?
Open the live app, view the page source and the loaded JavaScript files, and search for words like key, secret, token and sk_. Then search your repository history, not just the current files, for the same terms. Turn on secret scanning in your git host. Any secret key you find should be moved to server side code and rotated immediately, because you have to assume it was copied.
Does the OWASP Top 10 apply to small apps?
Yes. The OWASP Top 10 describes categories of risk, not company sizes, and small apps are frequent targets because they are less likely to be monitored. Broken access control, security misconfiguration, supply chain failures and injection all apply to a two screen prototype just as much as a large platform. The list is a practical checklist for any app that stores user data.
Should I rebuild or fix a vibe coded app?
Most apps can be fixed in place: secrets moved, rules written, checks added and tests put around each fix. A rebuild makes more sense when core business logic runs in the browser, when every screen accesses data differently or when the data model no longer fits the product. A code review answers the question honestly before you spend money either way.
