Database rules left wide open
Row-level security never enabled, or a policy that reads "true" so every row is readable by anyone with the public key. The app looks correct because your own account can see its own data. So can everybody else’s.
Vibe coding security · independent 48-hour audit
Your app works. That is not the same as safe.
Lovable, Base44, Bolt, Replit and Cursor write real, working code. What they do not do is push back when the working version is also the exposed one. The app launches, the demo lands, and the database sits open to anyone who opens the network tab.
Is vibe coding secure?
Not by default. Veracode tested 100+ models across 80 coding tasks and found they chose the insecure implementation 45% of the time, with no improvement as models got newer or larger. Worse, prompting the AI to fix problems compounds them: peer-reviewed work measured a 37.6% rise in critical vulnerabilities after five rounds of AI refinement. AI-built apps need a human security review before real users and real payments touch them.
Businesses we’ve worked with
45% of AI code picks the insecure path
Veracode’s 2025 GenAI Code Security Report ran 80 curated tasks across more than 100 large language models. Given a secure and an insecure way to do the same thing, the models took the insecure one 45% of the time — and failed to defend against cross-site scripting in 86% of the samples where it mattered.
Asking it to fix things makes it worse
This is the counter-intuitive one. Research on iterative AI code generation (arXiv:2506.11022) measured a 37.6% increase in critical vulnerabilities after just five rounds of prompting the model to improve its own code. The instinct to keep prompting until the error disappears is the mechanism, not the cure.
We read the code, not the vibes
We are the engineers who take these apps to production, not a scanner reselling a report. You get a human reading your actual repository, your actual database rules, and your actual deploy configuration, and telling you in plain language what a stranger could do with them today.
What we actually find
The six holes that show up again and again.
Across the AI-built apps we have audited, the same handful of failures account for most of the serious risk. None of them are exotic. All of them are invisible from inside the builder’s preview window.
Secrets shipped to the browser
Stripe, OpenAI, Supabase or Resend keys bundled into client-side JavaScript, where anyone can read them from the network tab and spend your money. Prefixing a variable so the build stops complaining is the usual cause.
Authentication that only exists in the UI
The admin button is hidden unless you are an admin — but the endpoint behind it never checks. Hiding a control is not access control, and the API does not know what the interface decided to render.
No rate limiting anywhere
Login, password reset, and any endpoint that calls a paid model, all unmetered. That is a credential-stuffing target and an unbounded bill, and it is the failure most likely to arrive as a surprise invoice.
Sessions and tokens that never end
Tokens issued without expiry, password-reset links that stay valid after use, sessions that survive logout. Each is a small thing on its own and a full account takeover in combination.
Nothing watching
No error tracking, no logs worth reading, no alerts, and often no backups. Not a vulnerability by itself — but it means you find out about all of the above from a customer, or from an extortion email.
How the audit runs.
Forty-eight hours from the moment we have read access. No hourly meter, and no obligation to have us do the fixing.
Read access
You add us to the repository and, if you want the deeper pass, read-only access to the database and hosting dashboard. Nothing is changed and nothing is deployed.
Manual review
An engineer reads the authentication path, database policies, secrets handling, payment flow and deploy configuration by hand, with automated scanning underneath rather than instead.
Plain-language report
Every finding rated by what someone could actually do with it, written so a non-technical founder can act on it, with the exact file and line for whoever does the fixing.
One fixed price to close it
If you want us to fix it, you get a single number and a timeline before you commit. If you would rather hand the report to your own developer, that is a perfectly good outcome and the report is yours.
What ships
What you get.
The report is yours to keep and to share, whoever ends up doing the work.
A written findings report, each item rated by real-world impact rather than scanner severityProof of exploitability for anything critical — what an attacker could actually reach, demonstrated safelyExposed-secret inventory across the repository, the client bundle and the deploy environmentDatabase access-rule review: every table, every policy, and what an anonymous visitor can read or writeAuthentication and session review: token lifetime, reset flows, privilege checks on the serverA prioritised remediation plan with file-level detail, usable by us or by your own developerOne fixed price and timeline to close everything, valid whether or not you take it
What this is not.
This is not a compliance certification, a penetration test against your live production users, or an EU AI Act / ISO 42001 governance audit — if that is what you need, a Big Four firm is genuinely the right call and we will say so. This is an engineering review of an AI-built codebase by the people who fix them, aimed at founders who need to know whether it is safe to launch, take payments, or raise on.
Questions people ask.
Is vibe coding secure?
Not on its own. Veracode’s 2025 GenAI Code Security Report tested more than 100 models across 80 coding tasks and found they selected the insecure implementation 45% of the time, with cross-site scripting undefended in 86% of the relevant samples — and, critically, no improvement from newer or larger models. The code usually works; the failure mode is that "works" and "safe" are different properties, and the tool only optimises for the first.
If I ask the AI to fix the security issues, is that enough?
It is often worse than doing nothing. A study of iterative AI code generation (arXiv:2506.11022) measured a 37.6% increase in critical vulnerabilities after five rounds of asking the model to improve its own code. The model has no memory of the threat model you never gave it, so each pass optimises for the error in front of it and quietly trades away a protection somewhere else.
How much does a vibe coding security audit cost?
It is a fixed price quoted before we start, based on the size of the codebase and whether you want the deeper database and infrastructure pass. You get the number before committing, and there is no hourly meter. Email [email protected] with your tool and roughly how big the app is and you will get a figure back, not a discovery call.
How long does it take?
Forty-eight hours from the moment we have read access, for the audit itself. If real users are already on the app and you think something is actively exposed, say so — we triage the dangerous parts first rather than waiting to deliver the full report.
Do you need to change my code to audit it?
No. The audit is read-only: we take read access to the repository and, optionally, read-only access to the database and hosting dashboard. Nothing is modified and nothing is deployed. Fixing is a separate decision you make after you have seen the report.
Which tools do you audit?
All of the common ones — Lovable, Base44, Bolt, Replit, Cursor, v0, Windsurf and Claude Code — plus anything they generated underneath, which is usually React with Supabase or Firebase. The tool matters less than the stack it produced; the failure patterns are remarkably consistent across all of them.
Do I keep the code and the accounts?
Always. Your repository, your hosting, your database, your keys, your customers. We work inside your accounts rather than moving anything into ours, and the report is yours to hand to any developer you like.
What if you find nothing serious?
Then you get a short report saying so, and you can launch knowing an engineer looked. That is a genuinely good outcome and it happens — most often with apps whose builders already had some engineering background. We would rather tell you it is fine than manufacture a problem to sell a fix.
Find out before someone else does.
Send us the repository and you will know within 48 hours what is exposed, how bad it is, and exactly what it costs to close. If it is clean, we will tell you that instead.
Prefer email? WhatsApp us or email [email protected] — we reply within one business day.
