# Vibe Coding Security Audit: Find What Your AI-Built App Exposes DreamLabs is an AI-powered app development agency in California — a fractional product team for mobile and web apps, from strategy to launch. Apps built with Lovable, Bolt, Replit, and their peers leak in a short, predictable list of ways. We check yours against it, prove each finding, and close what's open — starting with a test you can run yourself in ten minutes. ## Frequently asked questions ### How do I check my own app right now, before talking to anyone? Do the two-account test. Sign in with a second account and change the ID in a request so it points at the first account's record. If it loads, every user of your app can read every other user's data. Then open your app in a browser, look at the network tab, and search your JavaScript bundle for anything named service, secret, admin, or key — a privileged credential shipped to the browser is readable by anyone. Those two checks take ten minutes and find most of what we find. ### Is my Lovable, Bolt, or Base44 app insecure? Probably in one or two specific ways, and in our experience it is not really about which builder you used — apps from the same tool, built in the same week, vary enormously. What predicts trouble is the stack and the shortcuts taken to make features work, especially any arrangement where users authenticate through one system and the database expects a token from another. That is a fixable configuration problem, not a verdict on your product or your judgment. ### We have no engineers on the team. Can you just fix it? Yes, and that is the common case here. You do not need to understand row-level security to have it done correctly; you need someone to close what is open, rotate what has been exposed, and leave behind tests that keep it that way. We report findings in plain language, tell you what each one would mean if it were exploited, and do the work. ### Will you disclose what you find? No. Findings are yours, we work under an NDA if you want one, and nothing about your app appears in our marketing without your explicit written permission. If we find something that affects other users of a platform rather than just you, we will tell you first and agree on how to handle it with the vendor. ### Do we need a full migration afterwards? Often not, and we will tell you which case you are in. Plenty of AI-built apps have a sound enough foundation that a focused security engagement is all they need, and continuing to build on it is the right call. The migration conversation belongs to teams who are also hitting reliability, velocity, or ownership walls — the audit tells you whether that is you, with evidence rather than a sales pitch. ## AI-built apps leak in the same few ways The failure here is structural, not careless, and understanding why matters more than the individual bugs. A code generator optimizes for one thing: the feature works. A database rule that blocks the feature looks exactly like a bug, so it gets loosened until the screen loads again — and nothing anywhere warns you what just happened. A missing permission rule does not throw an error. The owner signs in, sees their own data, and everything looks correct, because the flaw only exists in the relationship between two different accounts. The findings repeat with remarkable consistency, and the pattern is not the one people expect. It is rarely about which builder you used: two apps from the same tool, built in the same week, land in completely different places. What predicts trouble is the stack, and the shortcut taken to make a feature work. The clearest example is putting a separate authentication library in front of Supabase. Your users now log in through that library instead, so they never receive a database token. Row-level security asks who is making the request, gets nothing back, matches no policy, and returns empty for every query. To whoever is building it the app has simply broken — nothing anywhere says the security rules are rejecting everyone. So the fastest way to get it working again is to switch off row-level security, or use the service key that ignores every rule. Thirty seconds, and the app works. It is also now readable by anyone. None of this makes you careless, and none of it is exotic. It is what happens when nobody with a security lens has read the app — which, for most products built this way, nobody yet has. ## The list your app is probably failing These are the checks, in the order they usually find something. You can run several of them yourself today, and we would rather you did than stayed unsure. - **Can anyone read your tables?** Anonymous access to data, and row-level security policies that are technically present but assert nothing about who is asking. - **Do your policies reference the actual user?** A rule that always evaluates true is the most common finding in this category, and it looks identical to a working rule from inside the app. - **Is schema introspection open?** An exposed table-and-column listing removes the guessing step: one request to see the shape, one to download it. - **Is a privileged key in your browser bundle?** Service-role keys, admin credentials, and third-party API secrets shipped to the client, where anyone can read them from the network tab. - **Do your serverless and edge functions authenticate their callers?** Functions deployed with no auth in front of them are a direct path around every rule you did write. - **Is authorization enforced anywhere but the interface?** A hidden button is not a permission, and a disabled field is not a rule. - **Object-level access.** The ten-minute test: create a second account, sign in as that user, and change the ID in a request to point at the first account's record. If it loads, every user of your app can read every other user's data. - **Payments, uploads, and storage.** Webhooks verified and idempotent, prices set on the server rather than sent from the browser, and storage buckets that are not readable by the public internet. ## Rules enforced where users can't reach them You end up with every rule that protects your data enforced on a server where users cannot reach around it, each one covered by a test that tries to break it. Privileged keys are out of the browser and rotated. Functions authenticate their callers. Your permission model exists as something written down and testable rather than as an assumption distributed across a hundred generated files. You also get an honest verdict, which is the part most people actually want: whether hardening is enough, or whether the app needs the deeper rebuild. For a lot of products the answer is that a week of focused work closes everything that matters, and we would rather tell you that and do the small engagement than sell you a migration you did not need. ## The audit, step by step ### The Free Surface Check We start with what we can see without any access at all: what your published app exposes to an ordinary visitor, what is sitting in your client bundle, and whether the obvious data paths are open. You get those findings whether or not you hire us, because a critical exposure is not something to hold hostage to a proposal, and because it is the fastest way for you to judge whether we know what we are talking about. ### Full Audit With Access With access to the repository and the backend, we go through the whole list: every table and its policies, every function and its authentication, storage rules, key exposure, payment flows, and dependency risk. Every finding comes with a reproduction — the account, the request, the response — so nothing is theoretical and nobody has to take our word for it. ### Close the Criticals Days, not weeks, and sequenced by what is actually reachable. Keys that have been sitting in a browser bundle get rotated, policies get rewritten against an explicit model of who is allowed to see what, authorization moves to the server, and each rule ships with a test whose job is to break it. This phase exists to make the dangerous things stop being dangerous immediately, independent of anything longer-term. ### Keep It Closed Fixes that nothing enforces come undone on the next prompt. So we leave behind tests that fail when a rule regresses, CI checks that run them, and a written permission model your team can extend rather than re-derive. If the audit concludes the foundation cannot be held closed — which happens — we say so plainly and show you what a full migration would take instead. ## Links - Full page: https://www.dreamlabs.pro/services/vibe-coding-security-audit - Offerings & pricing: https://www.dreamlabs.pro/offerings - Contact: https://www.dreamlabs.pro/contact