No. The generated stack uses solid infrastructure. What varies is configuration — access rules, key placement and auth gating are decided per app, and a generator optimises for a working feature, not a hostile reviewer.

Does the preview URL matter?

Yes. A preview deployment usually points at the same database as production. If the data is real, the preview is production for security purposes.

What should I check after every AI edit?

Any new table, bucket or endpoint the edit created. New tables arrive without policies unless the migration adds them, so the check that passed last week says nothing about today.

Lovable App Security: What to Check Before You Publish

By SentrailPublished August 13, 2026Updated August 20, 2026 7 min read

lovablesupabasechecklistpre-launch

Lovable gets you from idea to a working, deployed app quickly. What it cannot do is decide how much risk your app should carry. That decision shows up in a handful of configuration choices, and they are all reviewable in an afternoon.

Here is the publish-day list.

Database: access rules first

The generated backend exposes your tables through a public API protected only by row-level security. For every table, verify RLS is on and a policy genuinely scopes rows to auth.uid(). A policy of using (true) looks configured and protects nothing.

Also confirm table privileges exist for the roles your policies mention — RLS without grants gives permission errors, grants without RLS gives everyone everything.

Keys: know which one is public

The publishable key belongs in the browser. The service-role key bypasses every policy and belongs only in server code. Search your built bundle, not just your source, and check git history for committed env files. If an admin key was ever shipped, rotate it before anything else.

Auth: gate on the server

Hiding a nav item is not access control. Confirm that a protected route rejects an unauthenticated request at the server or route-guard level, that email confirmation matches your intent, and that password recovery is discoverable and actually delivers mail. Store roles in a dedicated table — never on a profile row the user can update.

Storage: buckets are public until they are not

Check each bucket's public flag against what it holds. Scope object policies by path so one user cannot list another's folder, and set size and MIME limits on upload inputs.

Edge functions and server routes

Every endpoint reachable without a session is an attack surface. Verify webhook signatures before trusting a payload, validate input with a schema, and never return more of a record than the caller needs. An endpoint that decides admin status from a request body is not an endpoint, it is a door.

Headers and deployment

Add a content security policy, HSTS, X-Content-Type-Options: nosniff, a referrer policy and a frame-ancestors rule. Turn off debug output, keep source maps off public paths, and make sure preview environments do not write to production data.

Dependencies

Resolve the lockfile against advisory data and prioritise what is reachable from your request path over what only runs at build time.

Then decide honestly

When all of the above has fresh evidence, you get a real answer: ready, needs review, blocked, or — the one that matters most — insufficient evidence. If a check never ran, the honest output is not a score.

Independent scanning projects have repeatedly found publicly readable databases in AI-built apps across several platforms, including a Q2 2026 sample of tens of thousands of apps. The pattern is not a platform flaw; it is unreviewed configuration.

Sentrail connects to your GitHub repository, Supabase project and hosting provider, runs these checks against the real resources, and keeps the evidence behind each verdict so you can re-check instead of remember.