AI tool · Lovable

From a Lovable app to production

Lovable generates the front end and connects it to a Supabase project you own. Its publish scan lints row-level security policies. What it does not do is run the two-user test, check payments, or watch the release after the first one.

Termsrow-level security (database rules that decide which rows each signed-in user may read or write) · two-user test (sign in as one user, create a row, then try to read or change it as another user; pass is nothing comes back) · Edge Functions (small server-side functions hosted by Supabase, where secret keys and payment calls belong) · client bundle (the JavaScript your app sends to the browser or ships inside the mobile app; anyone can read it) · webhook (a message a provider such as Stripe sends to your server when something happens, like a payment) · critical flow (a path a user takes that costs money or trust if it breaks: sign-up, checkout, invite, export) · verdict (a one-word release result (pass, pass with findings, fail) with the findings and the checklist version behind it)

What Lovable changes in a codebase

A prompt-to-app platform that generates a front end and connects it to a Supabase project you own; server logic goes in Supabase Edge Functions. It runs a security scan on publish.

A founder graduating from Lovable usually has paying users before a test suite. The first step is the coverage audit: a flow map, the catalogue patterns that apply, and a 30-day plan. The second is Starter, which runs the checklist on every release from then on.

Defaults, from the docs verified 2026-09-21

Verified defaults for Lovable
Default, from the docs	Why it matters for release testing	Source
"When you open the publish dialog, Lovable automatically runs the basic security scan in the background, including RLS policy linting and database schema review."	The scan lints policies; it does not run the two-user test. AC-02 is the test that proves isolation on the deployed data.	docs verified 2026-09-21
The Basic scan covers "RLS policy linting, Database schema review, and Dependency audit"; the Deep scan adds "Access control review, Backend endpoint protection, Code-level vulnerabilities, and Project-specific issues."	Payments, LLM spend, error handling, performance and rollback are outside both scans and stay on the checklist.	docs verified 2026-09-21
"Before going live, make sure every table has Row Level Security policies that restrict who can read and write each row"; the docs call missing policies "the most common way app data gets exposed."	The vendor's own going-live note matches CVE-2025-48757; AC-01 and AC-02 run it on every release, not once.	docs verified 2026-09-21
Recommended secrets pattern: "Store your API key securely in Secrets, Create an Edge Function to make the API call server-side, Call that Edge Function from your frontend code."	Any key that did not follow this route is in the bundle; SC-01 finds it.	docs verified 2026-09-21
Testing tip: "turn off email confirmation in your Supabase dashboard's Authentication settings so test accounts can sign in immediately. Re-enable it before launching to real users."	A development switch that has to be flipped back before launch; SC-04 checks production configuration for exactly this class of setting.	docs verified 2026-09-21

Each row was read on the linked page on the date shown. Docs change; the date tells you how current the row is. Lovable documentation.

Failure patterns most associated

critical
API key shipped in the client bundle
A key meant for the server ends up in JavaScript the browser downloads, so anyone can read it and call the service as the app.
critical
Service-role key used from the front end
The database's bypass-everything key is used in client code, so row-level rules no longer protect anything.
critical
Secret committed to the repository
A key or token is in git history, where it stays readable to anyone with repository access even after the file changes.
critical
Row-level security off on a new table
A table created by a migration or SQL has no row-level security, so the anonymous key can read and write every row through the public API.
critical
Policy that allows everything
Row-level security is enabled but the policy condition is true for everyone, so isolation exists in name only.
critical
List endpoint returns other tenants' rows
A list or search endpoint filters by the wrong column or none, so a user sees records belonging to other accounts.
critical
Object fetched by id without an ownership check
An endpoint checks that the caller is logged in, then returns whatever id was requested.
critical
Admin gate enforced only in the UI
The admin page hides its buttons from ordinary users, but the underlying route or action accepts calls from anyone logged in.

All 55 patterns tagged Lovable in the catalogue

How the checklist adapts

AC-01 and AC-02 run on every table, every release: the vendor's own docs call missing policies the most common way app data gets exposed, and CVE-2025-48757 was filed for it.
SC-01 scans the bundle for keys that did not follow the Edge Function route the docs recommend.
SC-04 checks development switches (email confirmation off, test-mode keys) are back to production settings.
Payments, error handling and rollback items apply in full; the publish scan does not cover them.

Release checklist, five of the published items

v1.0 · verified on 2026-09-21

IdCheck and howPass criterionSeverity if failedStarter · Growth · Scale

AC-01

Every table exposed to the client has row-level security enabled

automated Query the database catalog for tables in exposed schemas and their RLS flag (Supabase, Postgres) or list collections against rules (Firebase).

Pass when

Every exposed table reports RLS enabled; the list of exemptions is empty or each exemption is a public read-only table named in the release notes.

critical

AC-02

Policies deny cross-tenant reads and writes when tested as another user

automated For every table or collection, sign in as user A, create a row, then as user B attempt select, update and delete on it through the client API.

Pass when

User B receives zero rows on select and a permission error on update and delete, for every table.

critical

PY-01

Webhook signatures are verified against the raw body

automated Send an unsigned event, an event with an altered body, and an event signed with the wrong secret to the webhook endpoint.

Pass when

All three are rejected with a 4xx status and no state change.

critical

LM-01

Spend cap enforced per user and globally

automated In a test account, make model calls past the per-user cap and, in staging, past the global daily cap.

Pass when

Calls beyond either cap are refused with a user-visible message and a log entry; no further provider spend is recorded.

critical

EH-01

Failures surface to the user and to logs

automated Force a failure in each critical flow's backing call (database, payment, email, model).

Pass when

The user sees a specific message and a log entry with a request id exists for every forced failure.

high

Read the full checklist

Which plan fits

Starter $2,900/mo

Starter after the audit: weekly releases, one web surface, 30 flows by month 2. Growth when an API or a mobile app is added.

For 3-8 engineers, weekly releases, web. Limits, cadence and what is not included.

Email about Starter Start with the audit

Questions

Lovable app to production checklist

Before the first real users: every table has a tested RLS policy (AC-01, AC-02), no secret in the bundle (SC-01), email confirmation and other test switches back on (SC-04), webhook signatures verified if you take payments (PY-01), and a rollback rehearsed (DR-02). The full list is the checklist page; the audit tells you which items fail today.

Is my Lovable app secure?

The publish scan tells you whether policies exist and lints them. Whether they hold is proved by signing in as a second user and trying to read the first user's rows, on every table. That test, plus the secrets scan and the auth items, is the minimum before real users.

Lovable security checklist

Use the access control, secrets and auth categories of the release checklist; they cover what the documented incidents on prompt-to-app platforms had in common. Each item has a pass criterion you can verify yourself.

Testing vibe coded apps

Start with the audit: a flow map, the patterns that apply to your code, and a 30-day plan. Then run the checklist on every release. The catalogue lists what published scans of prompt-built apps found most often, with the sources.

Get a risk list for your codebase

5 business days, $1,200, credited to the first month.

Get a risk list for your codebase See plans