Lovable app security: what to fix first before real users arrive

In a Lovable app, the code running in your users' browsers talks to your database directly, so the first thing to fix is the database's access rules: prove, as a signed-out stranger and as a second ordinary user, that nobody can read or change records that are not theirs. Next, move every secret to the server and replace any that ever sat in chat or code, make each backend function check who is calling, tighten sign-in, and make sure paying is the only way to become a paying user. After that come the production issues that can hurt you without any attacker: building against your live data, backups you may not have, and credits that can pause your backend.

This page is the Lovable-specific order, built from Lovable's and Supabase's own documentation and the public disclosures about Lovable apps. For the full list of checks that applies to any AI-built app, see the vibe-coded app security checklist.

Why the database comes first

Lovable's security best practices describe three layers: a frontend that runs in the user's browser, where users can inspect or change it; backend functions; and a PostgreSQL database where row level security (RLS) decides who can access which rows. The browser carries a publishable key. Supabase says that key is safe to expose because anyone holding it "only reaches what Row Level Security allows" (Supabase API keys). So the key in your code is not the leak. The policies are the whole boundary.

Lovable is also clear about whose job those policies are. When researchers reported that Lovable-built apps exposed their databases, the US National Vulnerability Database entry for CVE-2025-48757 noted that Lovable disputed it "because each individual customer of the Lovable platform accepts a responsibility over protecting the data of their application." Lovable secures the platform. Your app's rules are yours. Broken access control also sits first in the OWASP Top 10:2025, OWASP's standard awareness document on the most critical web application security risks, so this order is not peculiar to Lovable; Lovable's architecture just makes it the first thing a stranger can reach.

The fix-first order

1. Prove who can read and change each table

Lovable adds basic policies when it builds a feature that stores user data. A policy existing is not the same as a policy being right. The researchers behind CVE-2025-48757 criticised Lovable's first scanner because it "merely checks for the existence of any RLS policy, not its correctness or alignment with application logic" (Matt Palmer's statement). Lovable's deep scan now reviews access control as well, but only you know the ownership rule: whose record is this, and who else may see it.

Test these before real data arrives; Lovable notes that RLS "is much easier to change before real data exists":

• Signed out. Can a visitor read anything other than content you meant to be public?
• As a second ordinary user. Can one account read or edit another account's records, for example by changing an ID in a request?
• Columns that grant power. Can users update their own role, plan, credit balance or payment status? In a follow-up test in May 2025, the researchers inserted a record marked "paid" into a paid Lovable-built site, bypassing its Stripe integration.
• Files. In Lovable's database documentation, RLS also governs storage and realtime. Any bucket holding user uploads should be private.

You can read the policies under More → Cloud → Database → RLS policies. That view is read-only; you change a policy by asking Lovable in the project chat, then run the two tests again.

2. Move secrets to the server, and replace any that were ever exposed

Lovable keeps two kinds of value apart. Anything named `VITE_` is a "build-time, browser-exposed" value that lives in a committed `.env` file; Secrets are encrypted, write-only and reach only your backend functions (Lovable Secrets). A payment, AI or email key in the first kind is public, whatever the variable is called.

The Lovable-specific risk is history. Project access includes your source code and project chat history, and workspace owners can open every project in the workspace (project visibility). Between 3 February and 20 April 2026, Lovable says a regression meant "public project chat history and source code could potentially be accessed by any Lovable user provided they had a project link" (Lovable's incident post). Lovable says private projects and Lovable Cloud were never affected, and since 22 April 2026 public project visibility has been removed (project visibility).

If a key was ever pasted into the chat, or written into the code of a project that was public at any point, treat it as leaked. Supabase's order for a leaked secret key is a good general rule: fix how it leaked, create a new key, replace it everywhere, then retire the old one. For Stripe, Lovable's own instruction is to "never paste your Stripe key into the project chat as a message" and to prefer a restricted key with only the permissions the app needs (Lovable's Stripe connection).

3. Make every backend function check who is calling

Lovable's best practices say every server function must verify who is calling and whether they may act, including when it is called directly rather than through your screens. A function runs on the server, but anyone can still call it. Server code that uses the service role bypasses RLS completely, so it has to do the checking itself.

A February 2026 case shows what this looks like when it goes wrong. A researcher reported 16 vulnerabilities, six of them critical by his assessment, in one Lovable-hosted app, with 18,697 user records exposed; its access guard was inverted, letting signed-out visitors in while blocking signed-in users (The Register, 27 February 2026). Lovable's chief information security officer said every project gets a security scan before publishing, that acting on it is at the user's discretion, and that "in this case, that implementation did not happen."

Call each function signed out, as an ordinary user and as an admin. Start with the ones that send email, delete accounts, change records other people rely on, or call a paid AI model.

4. Tighten sign-in before you open sign-up

On Lovable Cloud, the settings sit under More → Cloud → Users → Auth settings (email authentication):

• Turn Auto-confirm email off, so people prove they own the address before they can sign in.
• Turn on the Password HIBP check, which rejects passwords known from breaches.
• Raise the minimum password length; the floor is 6 characters, and Lovable recommends 8 or more.
• Set the rate limit for sending emails, and send from your own verified domain.

If you connected your own Supabase project, these settings live in the Supabase dashboard, and Lovable's Supabase guide suggests switching email confirmation off while testing. Switch it back on before launch. Check email delivery too: Supabase's built-in sender is limited to 2 emails an hour across sign-up and password recovery, and only your own SMTP provider raises it (Supabase production checklist). With real users arriving, that limit stops sign-ups before any attacker does.

Then protect the accounts that control the app: turn on multi-factor authentication for Lovable, Supabase, Stripe and your code host. In Lovable, editors can publish by default (publishing), and anyone with edit access can restore a database backup or disconnect a Stripe account you connected yourself. Give edit access only to people who need it.

5. Make paying the only route to paid access

The table that records a user's plan or payment status must not be writable by that user; that is test 1 again, applied to the place where money turns into access.

If you connected your own Stripe account, Lovable matches subscriptions to users by email address: a subscription counts when the sign-in email matches the email on the Stripe customer record. Lovable's sign-in documentation warns that without email confirmation, "anyone can sign up with an address they don't own." Our inference: the subscription match is only as trustworthy as that confirmation, so the setting in step 4 is a payments control as well. Lovable also warns that with a live key in your own Stripe connection, "payments made from the preview are real". Start with a test key, confirm the live prices exist (price IDs differ between test and live), then make one real purchase on the published app.

Lovable's built-in payments keep separate test and live environments and give you a go-live checklist. With built-in payments, Lovable registers and manages the webhook endpoints itself, so do not create or delete them by hand (Lovable payments). With your own Stripe account, webhooks are off by default; if you asked for one, the endpoint and its signing secret are yours to manage in the Stripe dashboard.

The production issues that are not attacks

The path from prototype to production covers the general route. Four issues are particular to how Lovable runs your app today.

6. Building now happens on your live data

Since 5 October 2026, every Lovable Cloud project runs on a single database, so "the data you work with while building is the data your published app runs on" (Lovable's environments guide). The earlier Test and Live split has been retired; Lovable can restore a detached Test database on request until 4 November 2026, when Test databases are deleted for good. Drafts keep code changes apart, but a draft "uses your project's real data", and deleting the draft does not undo what you changed (Lovable drafts).

Some changes reach the published app immediately, before you publish anything: sign-in methods, secrets, whether a storage bucket is public, payments and email settings. New tables, columns and access rules prepared in a draft are added to the shared database when you accept the draft.

What follows from that:

• Test with records you created, never with a customer's.
• Export the data before a change to the database's structure.
• Make sign-in, secret, storage and payment changes deliberately, at a quiet time, and check the live app straight after.
• Drafts do not provide a separate test database. Our inference: if you need one, it has to be a backend you set up and manage yourself outside Lovable Cloud.

7. Find out which backups you actually have

The answer depends on which backend the app uses.

The decision rule: if losing up to a day of records would hurt your customers, a daily snapshot is not enough on its own. Export before every risky change, back up uploaded files separately on either backend, and on your own Supabase consider point-in-time recovery.

8. Decide what happens when credits run out

Lovable's credits documentation is specific. At a zero balance, "your published site stays live", but features that call AI at runtime fail, and backend services pause "shortly after you run out of credits". Adding credits may not restart them; you may need to select Wake up under More → Cloud → Overview. For an app with a login, an empty balance is an outage.

The opposite risk is spending without a ceiling. On Pro and Business plans, auto top-up buys credits at a threshold, with a monthly spend limit that defaults to 400 credits or can be set to none. Our inference: an AI feature or backend function that anyone can call turns your balance into someone else's budget.

So set both edges. Under Workspace settings → Usage limits & alerts, add an alert well before any block. Give auto top-up a monthly limit you can afford. Put AI features behind sign-in, with a per-user limit, and watch More → Cloud → Usage in the first weeks. On your own Supabase, the Spend Cap exists only on the Pro plan and, when on, blocks usage once a quota is exceeded until the next billing cycle (Supabase cost control): the same trade between a bill and an outage.

9. Keep errors where you can find them later

Lovable Cloud's logs cover functions, database, sign-ins and storage, and the relative time ranges go back 5 days; for longer retention, Lovable suggests building logging or analytics into the app itself. Before launch, decide where errors are recorded, who is told, and what a user sees instead of a raw error message.

What Lovable's scans check, and what stays your decision

Lovable's security overview says its tools "help identify common security issues, but they cannot guarantee complete security", and suggests considering an additional professional security review for apps that handle sensitive data or critical functions. It also lists optional third-party scanning and AI penetration-testing connectors, at separate cost.

Run the deep scan before each release, turn on the publishing block if your plan allows it, and read the findings you chose to ignore again before launch.

Is Lovable itself secure? Three public disclosures

Two different questions hide inside "is Lovable secure". One is about the platform: can someone reach your project, its code or its chat through Lovable itself? The other is about your app: can someone reach your users' data through the app you published? The public record has examples of both.

Read together, two of the three were failures inside apps, which the app owner had to find and fix; one was a failure of the platform, where the owner's part was to check visibility and replace secrets. Third-party reports of the April incident differ on its scope; the table follows Lovable's own account, and Lovable says it is contacting the owners of affected projects.

What to hand an engineer

If you are hiring a Lovable developer, or any engineer, to take the app further, these items save the first week:

• The code. Git sync keeps the code in a repository you control, but it does not include database contents or uploaded files (deployment and ownership). Export those separately.
• The backend. Say whether the app runs on Lovable Cloud or your own Supabase. There is no one-click move from Cloud to your own Supabase project, which matters if the engineer wants one.
• A data map. Each table, who should see each row, and which columns grant power or money.
• Secrets by name, never by value. Where each is issued, and which ones were ever pasted into chat.
• The latest deep scan, including findings you ignored and why.
• Payments. Built-in or your own Stripe account, test or live, and whether a webhook exists.
• Backups and limits. When you last exported, and what credit limits and alerts are set.
• The first workflows real users will run, so the engineer tests what matters first.

Then ask to see three things done, not described: the signed-out test, the second-user test, and a restore from an export into a copy that is not your live app.

If you are deciding what kind of help to hire, what a vibe code cleanup specialist does separates the jobs and the questions to ask. Tcules's Prototype Hardening Review separates what a prototype has demonstrated from its shortcuts in data, identity, security, state, accessibility, performance and operations. Tcules can inspect generated code, dependency choices, state handling and tests, with review depth depending on access, and names any security work outside its normal scope explicitly rather than implying it is covered.