AI AutomationWeb Design

Lovable, Bolt and v0 for Your NZ Business Website: What the Security Research Found

Kage Works20 August 20268 min read

Type a sentence into Lovable, Bolt.new or v0 and you get a working website back in under a minute, with a signup form, a database and a dashboard if you asked for them. Andrej Karpathy named this "vibe coding" in February 2025; Collins Dictionary made it their word of the year eight months later. The obvious question a business owner asks is whether it's good enough to skip a developer. For a lot of sites, it is. A more useful question comes before that one.

The question that matters more is what happens to the data your customers hand over through the form the AI built you. In October 2025, a security firm scanned 5,600 publicly deployed apps built on these platforms and found 175 of them leaking personal information in plain view, no login required. That number is worth sitting with before you connect a signup form, a booking system, or a payment flow to anything an AI generated for you this week.

A security firm's scan of 5,600 apps

Escape, an application security company, scanned 5,600 publicly deployed vibe-coded apps and 14,600 associated assets (hosts, APIs, database schemas) in October 2025. The dataset skewed heavily toward Lovable, at roughly 4,000 of the apps, with smaller numbers on Base44, Create.xyz, Vibe Studio and Bolt.new. They found more than 2,000 high-impact vulnerabilities, over 400 exposed secrets (API keys, access tokens), and 175 instances of exposed personal data, including medical records, IBANs, phone numbers and email addresses, all live in production (Escape). The researchers ran passive scans only, deliberately avoiding anything destructive, and said as much: their own numbers understate the real total.

Other research lands on the same pattern. Veracode tested more than 100 large language models on security-sensitive coding tasks and found 45% of the AI-generated code samples introduced an OWASP Top 10 vulnerability. CodeRabbit's December 2025 analysis of 470 open-source pull requests found AI-authored code carried roughly 1.7 times more issues than human-written code overall, with security vulnerabilities up to 2.74 times more common and logic errors 75% more frequent. GitGuardian's State of Secrets Sprawl 2026 report tracked Claude Code-assisted commits leaking secrets at 3.2%, against a 1.5% baseline across all public GitHub commits, peaking at 31 leaked secrets per 1,000 commits in August 2025 (GitGuardian). Different tools and different methodologies point the same way: a platform can generate code that runs correctly without generating code that's safe to expose to the internet, and these tools are optimised to produce a working demo, which is a different bar than a safe one.

The missing setting nobody demos

Most of these builders, Lovable included, run on Supabase for the database layer. Supabase's design makes every table in your public schema reachable through an auto-generated API, using an "anon key" that ships inside your site's own browser code by design, visible to anyone who opens developer tools. The only thing stopping a stranger from reading every row in that table is Row Level Security (RLS), a Postgres feature that has to be switched on and configured per table. It is off by default. An AI assistant generating a database schema is focused on making your feature work, and a working demo doesn't require RLS to be correct, so the step gets skipped unless something forces it.

This already happened. Security researcher Matt Palmer disclosed CVE-2025-48757 on 29 May 2025: Lovable-generated projects deployed with insufficient RLS policies, exposing user names, email addresses, third-party API keys and access tokens, and financial and subscription data to anyone who knew where to look, no authentication required (Matt Palmer). The CVSS base score was 8.26, "high." Lovable had been notified in March that year.

To its credit, Lovable has since built scanning into the product. A Basic scan, included on every plan, checks RLS policy configuration, reviews the database schema and audits dependencies, and runs automatically each time you publish. A Deep scan goes further, reviewing access control and backend endpoints and looking for exposed secrets and injection flaws, but it does not run automatically. You have to trigger it yourself from the project's security view, and Lovable's own documentation is direct about the limit: "you are responsible for ensuring that your app meets the security requirements appropriate for its use case," and the scans "do not replace a thorough security review" (Lovable Documentation). Bolt.new and v0 don't currently ship an equivalent built-in scanner at all, which means the checking is entirely on you if you build there.

The line that matters for your business

Not every AI-built site carries this risk, and treating a five-page marketing site the same as a customer database wastes your own caution. The line is whether the site collects, stores or displays any personal information at all. A brochure site with a phone number and an embedded map has nothing for RLS to protect and nothing for the Escape researchers' findings to apply to. Add a contact form that saves submissions to a database, a login, a booking calendar, or anything resembling e-commerce, and you've crossed into exactly the territory that produced 175 exposed records in a single scan.

New Zealand's Privacy Act 2020 applies the same way regardless of how the database got built. It covers every business holding personal information about an identifiable person, with no size threshold: a sole trader's customer list carries the same baseline obligation as a large company, though what counts as "reasonable" security does scale with the size of the business. A serious privacy breach has to be reported to the Privacy Commissioner within 72 hours, and to the people affected if they're at risk of harm. Failing to report a notifiable breach is itself an offence, with fines up to $10,000 (Office of the Privacy Commissioner).

Sending data offshore, which is what you're doing by default with these tools, brings a second obligation. Information Privacy Principle 12 requires you to have reasonable grounds to believe personal information sent overseas will be protected to a standard comparable with the Act. The onus sits with you, as the business disclosing the data, not with the platform. The Commissioner can prohibit an overseas transfer outright if not satisfied it's adequately protected. The guidance doesn't say a US-hosted Supabase project automatically fails that test, and it doesn't say it automatically passes either. You're the one who has to make that call before you hit publish.

Ownership looks different on each platform

Ownership varies by platform and is worth checking before you're forty pages into a build, not after. Lovable states plainly that you own the apps and code you build, and GitHub sync lets the repository live outside their platform as well as inside it. Pricing runs on a credit system: the free tier gives five build credits a day up to 30 a month plus 20 monthly cloud credits, and paid plans start around $25 USD a month for Pro. Bolt.new's free tier caps you at 300K tokens a day and puts Bolt's own branding on your site; the $25 USD a month Pro plan removes the branding, lifts the cap to 10 million tokens a month and adds custom domain support. Bolt lets you download a ZIP or push to GitHub, though a storage format change in April 2026 removed the option to reopen older migrated projects in StackBlitz, a reminder that being able to export and being able to export cleanly on any plan, indefinitely, are different promises. v0 hands you React components to copy into your own project rather than a hosted app, the least lock-in of the three, though it also means you're assembling the rest of the stack yourself.

Read the export and ownership terms with the same attention you'd give a monthly web design contract, covered in more detail in the real cost of a cheap website.

Before you publish anything that collects data

Decide up front whether the site touches personal information at all. If it's a pure marketing site, most of this doesn't apply to you and you can ship with normal caution.
If it does collect data, run the platform's deepest available security scan before launch, not after, and don't take a clean basic scan as sufficient. On Lovable, that means triggering Deep scan manually.
Test it yourself: open the site in an incognito window, sign up as a second "customer," and try changing an ID in a URL or request to see someone else's record. This is the exact check that would have caught CVE-2025-48757.
Get someone who isn't the AI to look at the database rules before real customer data goes anywhere near it. Veracode and CodeRabbit's findings both point the same way: AI-generated code doesn't reliably catch its own security mistakes.
Write down which region hosts your database and keep a one-paragraph note on why you believe it meets IPP 12's "comparable protection" test. If you can't answer that in a sentence, you haven't done the assessment yet.
Know who in your business makes the 72-hour call if something leaks, because none of these platforms will tell you on their own.
Confirm you can export the code and the data before you're reliant on the platform for either.

A vibe-coded marketing site is a reasonable way to get online fast, and plenty of small NZ businesses have nothing on their site worth stealing. The moment your site starts asking for a name, an email or a card number, the question worth asking is who checked the one setting that decides whether that data is public. At Kage Works we get asked increasingly often to review a build someone's already prompted their way to, rather than start from scratch; if that's where you are, our questions to ask before hiring an agency covers what a proper security review should include either way.