If you've used a tool like Base44, Lovable, Bolt, Replit, or v0 to build a website or web app in the past year, start here: what you did is impressive. A year ago, turning an idea into a working, deployed product without a developer was mostly out of reach. You've done it, and that counts for something.
But there's a gap between working and safe, and almost nobody building with these tools is shown where it sits. The tools are very good at producing something that looks finished. They are bad at telling you what's missing underneath. The result is a common type of project: it runs fine on the surface while sitting on problems the owner can't see.
This isn't rare. In mid-2025 a security researcher found more than 170 live applications built on one popular AI platform with their entire databases wide open. Anyone could read, change, or delete any record, including names, emails, and payment identifiers. A separate study of the same platform found around 70% of apps had their core database protection switched off. One AI-built social network was breached three days after launch, leaking 1.5 million access tokens and 35,000 email addresses. Researchers now call these tools "representatively insecure", meaning the problems are typical of the category rather than the exception.
None of this means you should stop using them. It means the work isn't finished when the tool says it is. Here are the issues I see most often when I look under the hood of an AI-built site or app, and the quick wins you can act on today.
The big one: your database might be an open door
Most AI builders that store data (contact submissions, signups, bookings, user accounts, anything people enter) put that data in a backend like Supabase or Firebase. These services are excellent. But they ship with the protective layer, the rules that decide who can see what, turned off by default. The AI building your app usually doesn't turn it on.
The technical name is Row Level Security. In plain terms: without it, the public key embedded in your app's code (which is meant to be there) works like a master key to every room in the building instead of just the front door. Anyone who opens their browser's developer tools can find it and pull your whole database.
Quick win: if your project uses Supabase, log into your dashboard. If you see a warning banner about RLS being disabled on tables in the "public" schema, that's the problem. Turning it on is close to one line per table. If you're not sure how, this is the kind of thing worth paying someone for an hour to check. It's cheap insurance against a breach that could end your business.
Your secret keys might not be secret
AI builders often hardcode sensitive credentials, things like payment keys, email service keys, and admin tokens, straight into the part of the code that runs in the visitor's browser. Anything in there can be read by anyone. A payment key in your frontend code is like leaving the admin PIN for your EFTPOS terminal taped to the counter.
Quick win: ask whoever built it, or the AI itself, a direct question: "Are any API keys or secrets in the client-side code?" If the answer is yes, or unclear, those need to move to a secure server-side location. Service keys, the powerful kind that bypass every protection, should never be in frontend code under any circumstances.
The edit buttons everyone can see
A common one on AI-built sites and apps: the edit, delete, and admin controls the owner uses are visible to the public, because permissions were never set up. The owner sees them and assumes they're private. They're part of the public page.
Quick win: open your live site in a private or incognito browser window, where you're not logged in as the owner. Click around. If you can see edit controls, draft content, or admin functions, so can your visitors.
Your forms are a magnet for abuse
A contact or signup form with no spam protection will start collecting junk, and sometimes worse, within days of going live. Bots find forms automatically. Beyond the nuisance, unprotected forms can run up costs (if every submission triggers a paid email) or open you to injection attempts.
Quick win: add basic spam protection. Most form tools have a built-in option, a honeypot field or a simple CAPTCHA, that takes minutes to switch on. If yours doesn't, that's a sign the form was wired up too quickly.
You may be collecting personal data with no plan for it
The moment your site or app has a contact form, you're collecting personal information. In New Zealand that brings obligations under the Privacy Act 2020, and the GDPR as well if any of your visitors are in the EU. Most AI-built projects have a form quietly collecting names and emails with no privacy policy, no statement of what happens to the data, and no thought about where it's stored or who can reach it.
Quick win: add a short, honest privacy policy and a one-line note near your form explaining what you'll do with the information. This is less about ticking a compliance box and more about being able to say "we had a process" rather than "we had no idea" if data ever goes missing. The database fixes above are part of the same picture. If you're holding people's data, you're responsible for protecting it.
Not a security flaw, but it will still hurt: no backups
Most AI platforms keep your work, and your data, inside their own walls, with no easy export and no version history you control. If the platform changes, breaks, suspends your account, or just has a bad day, you can lose everything with no way back.
Quick win: find out how to export your data, and do it. If your project's code can be connected to a free GitHub account, connect it. That gives you a copy that lives outside the platform. Even a manual monthly export to a folder you control beats nothing.
The honest bigger picture
Here's what I'd tell anyone who's just shipped something with these tools. They're changing what a small business can build on its own. The sensible response is a short checklist before anything real goes live or starts collecting customer data:
- Database protection (RLS) on every table
- No API keys or secrets in frontend code, and no service keys client-side, ever
- Admin and edit controls hidden from the public
- Spam protection on every form
- A privacy policy, and a clear home for any personal data you collect
- A backup that lives somewhere you control
Most of these are an afternoon's work, not a rebuild. A project with those six handled is in better shape than most AI-built sites and apps currently live.
The pattern I keep seeing is that people treat the AI-built version as finished when it's really a strong first draft. The hard creative work is done. What's left is the unglamorous wiring that keeps it safe, and that wiring is the exact part these tools are worst at and say least about. Knowing it exists puts you ahead of almost everyone else building this way.
If you've built something and want a second pair of eyes before it goes live, that's a reasonable thing to ask for, and a cheap one next to what it protects.
