Last updated: 19 June 2026 · By the Think Big Digital team · 9-minute read
Quick answer: If you built your website or app with an AI tool like Lovable, Bolt, v0, or Replit and never set up something called row-level security, there's a real chance strangers can read your customers' emails, addresses, and payment details straight from your database. You don't need to code to check. This guide walks you through a 10-minute safety check, in clear terms with no tech-speak, so you can find out today whether your site is exposed.
Key takeaways
AI website builders often store data in a cloud database, where the main security rule isn't enabled by default. The pretty front end works; the lock on the back door was never fitted.
In 2025, security researchers found 303 exposed data endpoints across 170 websites built with one popular AI tool, leaking emails, payment status, API keys, and home addresses.
One AI-built app, Moltbook, was breached within about three days of launch, spilling roughly 1.5 million API keys and 35,000 email addresses.
You can check your own site in about 10 minutes without writing a single line of code. The steps are below.
If something looks wrong, fixing it is usually fast and cheap, far cheaper than a breach.
Who this article is for
This is for you if you run a small business or startup, you built your website or web app using an AI tool (or paid a freelancer who did), and nobody has ever explained to you whether it's actually safe. You're not a developer. You shouldn't have to be one to know your customers' data isn't sitting in the open.
If that's you, keep reading. By the end, you'll know exactly what to look for and what to do about it.
Why AI-built websites leak data in the first place
Here's the thing nobody tells you when the demo looks like magic.
AI builders are brilliant at the part you can see. You type "build me a booking site for my salon," and 60 seconds later there's a working page with a calendar, a sign-up form, the lot. It feels like you skipped six weeks and a developer's invoice. Genuinely impressive.
The problem is the part you can't see. Most of these tools store data in a cloud database, and Supabase is the most common one. That database has a setting called row-level security, or RLS. Think of RLS as the rule that says "customer A can only see customer A's data, and a random stranger on the internet can see none of it."
Here's the catch. Supabase automatically enables RLS only when you create a table by clicking through its dashboard. When a table is created the way AI builders create them, through code and migrations behind the scenes, that protection is not turned on for you. So a lot of AI-built projects go live with the rule switched off and nobody the wiser.
The result: the front of your site looks locked. The form asks for a password. But the database behind it can hand over every record to anyone who knows how to ask, and asking is not hard. The login screen is a saloon door, not a vault.
This isn't a rare edge case. A 2025 Veracode report found that roughly 45% of the AI-generated code samples it tested introduced a known security flaw from the industry-standard OWASP Top 10 list of common web application security risks. Nearly half. That's the foundation a lot of these sites are built on.
What "row-level security" actually means (no jargon)
Picture a filing cabinet in a shared office. RLS on means every drawer is locked and each customer holds a key to only their own drawer. RLS off means the cabinet is unlocked and pushed into the hallway. Everything still files neatly. Anyone walking past can open it.
That's the whole concept. You don't need to understand the code. You just need to know whether your cabinet is locked.
The real-world damage: two stories worth knowing
Let's be specific here, because "your site might be insecure" is easy to wave away. Hard numbers are harder to ignore.
In 2025, security researcher Matt Palmer, working with Kody Low, ran a scan of 1,645 apps made with the AI tool Lovable. They found 303 leaking endpoints across 170 of them, about 1 in 10. What was exposed? Real things: email addresses, phone numbers, payment and subscription status, API keys, and in some cases home addresses. Not hypothetical. Sitting there, readable.
Then there's Moltbook, an AI-agent social app built almost entirely by "vibe coding." According to Wiz Research (the misconfiguration was also spotted independently and first reported by 404 Media), it was breached within roughly three days of going live. The cause was the exact problem in this article: a database left without row-level security, with the access key sitting in the site's own code. The result was about 1.5 million API keys and 35,000 email addresses exposed, along with private messages.
Three days. That's the gap between "we launched!" and "we have a problem."
Now, most small business sites won't make headlines. But the mechanism is identical whether you have 30 customers or 30,000. If the cabinet's unlocked, it's unlocked.
How to check your AI-built website in 10 minutes
You can run this yourself. No terminal, no code. Here's the safety check.
Step 1: Find out what's running behind your site (2 minutes)
Open the tool you built with and look for the word Supabase, Firebase, or database in your project settings or integrations. If you paid someone to build it, send them one message: "What database does my site use, and is row-level security enabled on it?" Their answer (or their silence) tells you a lot.
Step 2: Look for the security warning you probably ignored (2 minutes)
Log into your database provider (most likely Supabase). In the Table Editor, any table without row-level security is flagged with a red "Unrestricted" label. That word is the tell: it means the table can be read through the public API. Even better, open Supabase's built-in Security Advisor (under Advisors in the dashboard). It runs an automatic check and lists every table flagged as "RLS disabled in public." If that list isn't empty, those tables are open.
Step 3: Try to reach your data the way a stranger would (3 minutes)
This one's a bit more hands-on, so it's fine to hand it to someone technical. The idea: your project has a public key (Supabase now calls it a "publishable" key; older projects call it the "anon" key) that's meant to be visible. The problem is that when row-level security is off, that public key is enough to read your tables straight from Supabase's automatic data API, no login needed. A developer can confirm this in under a minute by requesting one of your tables with only that public key. If real customer rows come back, anyone could pull them the same way.
If you're not comfortable doing this, that's completely fine. The Step 2 check already tells you most of what you need. Skip to Step 5 and have someone confirm.
Step 4: Check who your forms trust (2 minutes)
Submit a test entry through your own contact or sign-up form using a fake name. Then check whether that entry, and everyone else's, is visible from the front end without logging in. If your "admin only" data shows up for a logged-out visitor, the trust rules aren't set.
Step 5: If anything looked off, stop and get a second opinion (1 minute)
If any step raised a flag, don't panic and don't start deleting things. Write down what you saw, take screenshots, and have a developer (or us) confirm it. Most of these issues are a quick fix once someone knows what to switch on.
What to do if your site is exposed
First: breathe. An open database is common and usually fast to fix. Here's the order I'd go in.
Turn on row-level security for every table that holds personal data. This is the single biggest fix. In Supabase it's often a toggle plus a short access rule.
Rotate any keys or passwords that may have been visible. Treat them as compromised.
Check whether data was actually accessed. Your provider's logs can show this. If real customer data was exposed, you may have legal duties to notify people (more on that below).
Get a proper review before you relaunch. Fixing one table while three others stay open isn't a fix.
If that list makes your eyes glaze over, that's a reasonable signal to bring in help rather than learn database security on the fly while customer data sits exposed.
Do you have to tell your customers? (The legal bit)
Short version: maybe, and it depends where your customers live.
Under the UK GDPR and EU GDPR, if a personal-data breach is likely to risk people's rights, you generally must report it to your regulator within 72 hours of becoming aware of it. Telling the affected individuals is a separate duty: you must do that "without undue delay" when the risk to them is high, though there's no fixed 72-hour clock on that part. In Australia, the Notifiable Data Breaches scheme requires notifying both the regulator and affected people when a breach is likely to cause serious harm. Several US states have their own breach-notification laws with their own timelines.
I'm describing the general shape of the rules, not giving legal advice. If you find a real exposure, talk to someone qualified in your jurisdiction. The point is simply this: an open database isn't only a technical issue. It can become a reporting obligation.
Frequently asked questions
Are AI website builders unsafe to use?
No. The tools aren't the villain here. They're fast and genuinely useful. The risk comes from launching without checking the database security, which often isn't enabled automatically on the tables these tools generate. Used carefully, with row-level security switched on and a quick review before launch, an AI-built site can be perfectly safe.
How do I know if my website uses a database at all?
If your site stores anything, sign-ups, bookings, contact-form entries, user accounts, orders, it uses a database. A plain brochure site with no forms and no logins usually doesn't hold personal data, so this risk is much lower. The moment you collect customer information, a database is involved.
Can I check my site myself without a developer?
Yes, for the basics. The five steps above are designed for non-technical owners and take about 10 minutes. They'll tell you whether you likely have a problem. Confirming and fixing a real exposure is where a developer earns their fee, but you can do the detection yourself first.
What is row-level security in simple terms?
Row-level security is a database rule that limits who can see which records. With it on, each customer sees only their own data and outsiders see none. With it off, anyone who reaches the database can read everything. It's the lock on the filing cabinet.
My freelancer built it. Isn't security their job?
It should be, but "should" doesn't lock the cabinet. Many freelancers using AI tools ship the visible product and miss the database settings, sometimes without realising. Ask them directly whether RLS is enabled on every table with personal data. A good developer will answer clearly. A vague answer is its own red flag.
How much does it cost to fix an exposed database?
Usually far less than people expect, and far less than a breach. Enabling row-level security and writing sensible access rules is often a few hours of work, not a rebuild. The expensive version is the one where you skip the check, get breached, and pay in lost trust and regulatory fines instead.
The bottom line
AI builders gave non-technical founders something real: the ability to ship a working website without waiting on anyone. That's worth keeping. But the same speed that skips the developer also skips the safety check, and the database protection often isn't on unless someone turns it on.
You've now got the check. Ten minutes, no code, five steps. Run it this week. If everything's locked, you've lost ten minutes and gained peace of mind. If it isn't, you found out before a stranger did, which is the whole game.