Before a Lovable or Replit app holds real customer or staff data, check four things the platform leaves to you: the database access rules (on Supabase, row level security and grants on every table), where keys and passwords are kept, whether test and live data are separate with backups that work, and whether the business owns every account. Most of this is configuration, and much of it can be fixed without rebuilding the app.
This guide is for the business owner or operations lead whose colleague built something on Lovable or Replit that now holds customer, staff or financial data. It sets out what to check, in order, and how to decide whether to keep the app where it is. If you would rather an engineer did the checking, that is what our vibe code audit is for.
What Lovable and Replit do well, and what they leave to you
Both platforms are very good at turning a description into working software. Replit gives each app separate development and production databases, and Lovable lets you keep the code in your own Git repository and says plainly that the apps and code you create with it are yours.
What neither platform can do is decide who should see which data in your business. Lovable's security documentation puts it directly: "You are responsible for ensuring that your app meets the security requirements appropriate for its use case." The access rules, the keys and the decisions about data belong to whoever runs the app, which is now your business.
Is Lovable secure?
There are two questions here. The first is about the platform. In April 2026 Lovable published its own account of an incident: between 3 Feb and 20 Apr 2026, the chat history and source code of public projects could potentially be accessed by any Lovable user who had the project link. Lovable said private projects and Lovable Cloud were never affected, and that it was making all current public projects private. If your colleague's project was ever public, assume its code and the conversation that built it have been readable, and rotate any key that appeared in either.
The second question, which usually matters more, is whether your colleague's app is secure, and that depends mostly on how its database is configured. A CVE, CVE-2025-48757, is listed on the US National Vulnerability Database describing insufficient row level security in Lovable-generated sites up to 15 Apr 2025. Lovable disputes it, on the basis that each customer is responsible for protecting its own application data. Either way, the access rules on your database are yours to get right.
Database access rules: the first thing to check
Many apps built on Lovable and elsewhere store their data in Supabase. Lovable's own Supabase guide says "Missing RLS policies are the most common way app data gets exposed", and tells builders to make sure every table has row level security policies before going live.
Row level security (RLS) is a set of rules inside the database that decides which rows each user can read or change. It matters because the browser talks to the database directly using a publishable key, and that key is designed to be visible. Supabase says it is safe to expose because "it only reaches what Row Level Security allows". A visible key is normal. A table without RLS behind it is the problem.
| Supabase key | Where it can go | What it can reach |
|---|---|---|
| Publishable key (starts sb_publishable_) | Web pages, mobile apps, source code | Only what row level security allows |
| Secret key (starts sb_secret_) | Server-side code only. Never a browser, a shipped app or source control | Everything. It bypasses every RLS policy |
Supabase is deprecating the older anon and service_role keys by the end of 2026, so an app still using them needs to switch.
Three details catch AI-built apps in particular:
- RLS is not always switched on for you. Supabase enables it by default on tables created through its dashboard. Tables created in the SQL Editor or "through another tool" need it enabled explicitly. An AI tool that creates tables by running SQL falls into that second group.
- Grants and policies are separate layers. Grants decide whether a role can reach a table at all. RLS policies decide which rows it can see. On existing projects a new table in the public schema starts with every privilege granted to the anonymous, authenticated and service roles, and Supabase notes that adding policies does not take those grants back. Its documentation advises revoking them on projects that still grant by default.
- Checking that someone is logged in is not enough. A policy that only checks for a login lets every user read every other user's records. Test it with two ordinary accounts: sign in as one and try to reach the other's data.
What changes on Supabase on 30 Oct 2026
On 28 Apr 2026 Supabase announced that new tables in the public schema would stop being exposed to its Data API automatically. The change became the default for new projects from 30 May 2026, and Supabase will apply it to all existing projects on 30 Oct 2026. After that date, a new table needs an explicit grant before the app can reach it through the API.
Supabase is clear that existing tables keep their current grants and stay reachable, and that RLS behaviour is unchanged. The change does nothing for a table your app already exposes. It makes the next table less likely to be exposed by accident.
Two side effects matter for an AI-built app. First, a new feature that needs a new table may fail until a grant is added, and the quick fix an AI tool suggests may grant more than the app needs. Supabase's advice is to grant the minimum each role needs and to bundle grants with the RLS setup in the same migration. Second, Supabase emails the notices (the final one is due on 23 Oct 2026) to the owners and admins of each project. If the Supabase project sits in a colleague's personal account, they are the only person who will see the warning.
What the built-in scanners check, and what the vendors say about them
Each platform now ships its own security checks, and each is candid about their limits.
| Platform | Checks | What the vendor says about them |
|---|---|---|
| Lovable | A Quick scan runs automatically when you publish and checks database access rules, known vulnerabilities in npm dependencies and whether an MCP server is exposed without sign-in. A Deep scan, usually started manually, reviews all the application code for problems with logic, permissions and data. | "These tools help identify common security issues, but they cannot guarantee complete security." For apps handling sensitive data, Lovable suggests an additional professional security review. |
| Replit | A build-time check, an Agent security scan for paid builders, Auto-Protect for dependencies, and a Level 3 scan that adds a black-box penetration test of the running app. A setting can block publishing on critical findings. | The build-time check is "an early, lightweight check". Auto-Protect "covers dependency CVEs only". Publish-time checks complement a full scan and do not replace it. |
| Supabase | The Security Advisor runs fixed checks on the database, such as 0013_rls_disabled_in_public ("Table publicly accessible"), rated as an error. | "Some findings may be intentional, so check them against your intended schema and access model before you change anything." |
Run all of them, because they catch real problems. But Lovable lets the builder ignore a finding with a recorded reason, and Replit unblocks publishing once a finding is resolved or dismissed. A finding dismissed by the person who built the app has had no second opinion, and no scanner can know whether your sales team should see the finance table.
Keys, passwords and other secrets
AI tools will paste an API key straight into the code if that is the fastest way to make something work. Look for keys in the code, in the browser's developer tools and in the chat history with the AI tool. Supabase is explicit that a secret key must never go in a browser, a shipped application or source control.
Platform secret stores help, but read their access rules. Replit encrypts secrets with AES-256 at rest, and its documentation notes that organisation members without the Owner role cannot view secret values directly, "but can access their values by printing the environment variables". Lovable's documentation adds a quieter trap: Lovable projects that share one Supabase project overwrite each other's secrets.
Replace any key that has ever sat in code, a chat, a screenshot or a public project, and keep the new one in a secrets store.
Test and live environments, and backups
When the builder tries out a change, which data does it run against? If the answer is live customer data, every experiment puts that data at risk.
Every Replit app has a development and a production database, and the Agent cannot change production. Publishing does apply structural changes from development to production, so a column deleted in development goes from production at the next publish. A deleted Replit database can be restored through Replit support for seven days and is then gone for good.
On Supabase, daily backups come with the Pro, Team and Enterprise plans, kept for 7, 14 and 30 days respectively, with point-in-time recovery available as an add-on. For free-tier projects Supabase recommends exporting data regularly and keeping off-site backups. Check what your plan provides, and test a restore before you need one.
Who owns the accounts and the code
Lovable states that the code is yours, and its Supabase integration connects "a Supabase project you own". In practice, whoever controls the accounts controls the app. List every account the app depends on: the Lovable or Replit workspace, the Supabase project, the code repository, the domain name, the card that pays for them, and any services the app connects to, such as payments or email. Then check whose name and email address each one is in.
If the answer is a colleague's personal account, the business depends on that person's access and goodwill. Move them into company accounts while everyone is on good terms. Our guide to what to do when a colleague has built a tool with AI covers that move. If there may be other tools like this around the business, auditing the shadow AI already in use is a sensible next step, and your AI policy is the place to set the rule for future ones.
Harden it in place, or move it off the platform?
Staying on the platform is often the right answer, because moving costs time and money.
| Usually fine to harden in place | Usually worth moving |
|---|---|
| Used by your own team, with a small number of users | Customers or other businesses log in to it |
| The builder will keep making changes in the platform editor | Several people need to change the code, with changes reviewed before release |
| The platform's hosting, backups and checks meet your needs once configured | You need control over hosting, release process or backups that the platform does not give you |
There is a middle route. Lovable says its apps "can be hosted anywhere", and that with the repository still connected it can keep editing the app while another host serves the live version. The backend is harder: Lovable says there is no automatic migration between its built-in backend and your own Supabase project, and moving only the PostgreSQL database leaves authentication, storage, realtime and Edge Functions behind.
The risk guide for apps your team built with AI sets out how much checking each kind of app needs. A review of an AI-built app by an engineer should end with a clear recommendation to keep, fix or rebuild.
How this differs from taking a ChatGPT prototype to production
We have written separately about taking a ChatGPT prototype to production. That post is about software that uses a model as a feature, where the hard problems are making the model's answers reliable and affordable every day. This post is about software that an AI tool wrote. The finished app may not call a model at all, and its risks sit in the database, the keys and the accounts.
How SpotDev can help
Our Safe to Ship vibe code audit reviews one AI-built app, including Lovable and Replit apps on Supabase, fixes what needs fixing at a fixed price, and ends with our CTO signing off the reviewed version. The sign-off covers that version on the review date and is not a guarantee against every attack. Audits start from £1,500 depending on what the app holds, and 20% of the fee is credited against fixes committed within 30 days. Prices exclude VAT. If your staff will carry on building with Claude Code, Codex or Cursor, Ready to Build sets up a safe way for them to work, from £4,000.
Frequently asked questions
Is Lovable secure enough for business data?
The platform provides hosting, scanning and private projects, but the security of your app depends mainly on how its database is configured. Lovable says it is the customer's responsibility to meet the security requirements of the app's use case, and suggests a professional review for apps handling sensitive data. Check row level security on every table, keep keys out of the code and make sure the project is private.
Is it a problem that my Supabase key is visible in the browser?
Not if it is the publishable key. Supabase designs that key to be visible and says it only reaches what row level security allows. The real risks are a table with no row level security policies behind it, or a secret key appearing in the browser or the code. A secret key bypasses every policy, so if one has been exposed, replace it straight away.
Does the Supabase change on 30 Oct 2026 make my app safe?
No. From 30 Oct 2026 new tables in the public schema on existing projects need an explicit grant before the API can reach them, which reduces accidental exposure in future. Supabase says existing tables keep their current grants and that row level security behaviour is unchanged, so any table your app already exposes stays exposed until its grants and policies are fixed.
Can I rely on Lovable's or Replit's security scan?
Run them, because they catch common problems, but do not treat a clean result as a sign-off. Lovable says its tools cannot guarantee complete security, and Replit describes its build-time check as lightweight and its publish-time checks as complementing a full scan. Both let the builder dismiss findings, and no scanner can judge who in your business should see which data.
Sources
- Supabase, Breaking Change: Tables not exposed to Data and GraphQL API automatically, 28 Apr 2026
- Supabase, Securing your API (documentation), accessed 8 Oct 2026
- Supabase, Row Level Security (documentation), accessed 8 Oct 2026
- Supabase, Understanding API keys (documentation), accessed 8 Oct 2026
- Supabase, Database Advisors (documentation), accessed 8 Oct 2026
- Supabase, Database Backups (documentation), accessed 8 Oct 2026
- Lovable, Security (documentation), accessed 8 Oct 2026
- Lovable, Supabase integration (documentation), accessed 8 Oct 2026
- Lovable, Deployment, hosting and ownership (documentation), accessed 8 Oct 2026
- Lovable, Our response to the April 2026 incident, 22 Apr 2026
- NIST National Vulnerability Database, CVE-2025-48757, published 30 May 2025
- Replit, Security scanner (documentation), accessed 8 Oct 2026
- Replit, Secrets (documentation), accessed 8 Oct 2026
- Replit, Production databases (documentation), accessed 8 Oct 2026
Get new articles by email
Practical guides from the SpotDev team, when we publish them.
By submitting this form, you consent to us sending you emails with our latest content. Privacy Policy
