Skip to content
BuildThenTestedSee packages

Lovable pre-launch checklist

42 checks in the order we run them, most severe first. Each one has a self-check you can do in the Lovable dashboard and your browser, and a fix direction. Free to use; nothing to sign up for.
Download .md

Defaults referenced come from Lovable's documentation, verified 2026-09-21, on the Lovable hub.

  1. Secrets and keys

  2. Data access

    • Inverted policy logic

      In the Supabase dashboard, open Authentication, then Policies, and read every policy on a table that holds customer data.

      Critical
    • Any signed-in user can read every row

      In the Supabase dashboard open Authentication, then Policies. Row Level Security (RLS) is the per-row access rule set Postgres applies to each query, and this page shows each policy's expression.

      Critical
    • Row Level Security disabled on a table

      In the Supabase dashboard open Table Editor. Tables without Row Level Security (RLS, the per-row access rules Postgres applies to each query) show an RLS disabled or Unrestricted label next to the name.

      Critical
    • RLS policy that allows everything with using (true)

      In the Supabase dashboard open Authentication, then Policies. Row Level Security (RLS) is the per-row access rule set Postgres applies to each query, and this page lists every policy per table.

      Critical
    • Uploaded files in a public storage bucket

      In the Supabase dashboard open Storage and look for the Public label on each bucket; in Firebase open Storage, then the Rules tab.

      High

  3. Login and permissions

  4. Payments

    • Stripe webhook accepted without signature verification

      In the Stripe Dashboard, open Developers, then Webhooks, and copy the endpoint URL your app uses. It usually ends in something like /api/stripe/webhook or /functions/v1/stripe-webhook.

      Critical
    • No idempotency on payment handlers

      In the Stripe Dashboard, open Developers, then Webhooks, select your endpoint and open a recent invoice.paid or checkout.session.completed event for a test account.

      High
    • Price or plan taken from the client

      Open your app's pricing page in Chrome, press F12 to open developer tools (the browser's built-in inspector), and select the Network tab.

      High
    • Subscription state trusted from local storage

      Sign in to your app with a free account, press F12 to open developer tools, select the Application tab, then Local Storage on the left.

      High
    • Stripe test keys in production

      Open your live app's checkout, press F12, select the Network tab, and start a checkout. Look for requests to stripe.com or js.stripe.com and read their URLs and payloads for a key beginning pk_test_ or a session ID beginning cs_test_.

      High

  5. AI features

    • LLM API key exposed to the client

      Open your live app, press F12, select the Network tab, and use the AI feature once.

      Critical
    • No output validation before actions

      List the things your AI feature can do beyond replying with text: run queries, call APIs, send messages, change records, fetch URLs, run code.

      Critical
    • No spend cap on model calls

      Sign in to your model provider's console and open the billing or limits page (OpenAI: Limits; Anthropic: Settings, then Billing). Note whether a monthly spend limit and a spend alert are set.

      High
    • Prompt injection through user content

      List every place where text from a user, a webpage, an uploaded file or an email reaches the model: chat boxes, ticket forms, document upload, URL summarisers.

      High
    • Unbounded input length to the model

      Open the AI feature in your app and paste an unusually long text, for example a whole book chapter copied several times, then submit.

      Medium

  6. Reliability

  7. Data integrity

  8. Deploy and config

    • Builder project set to public

      Open the project in your builder and find the settings or share dialog. Look for two separate controls: one for who can open the project in the editor, one for who can visit the published site.

      High
    • Dependencies with known vulnerabilities

      If your builder shows a package.json file or lets you export the code, open a terminal in that folder and run npm audit (or pnpm audit or yarn audit).

      High
    • Missing security headers

      Open your published app in Chrome or Firefox, press F12 and choose the Network tab.

      Medium
    • No automated checks before deploy

      Open the project's GitHub repository; if the builder has a GitHub sync, connect it first so the code is visible there.

      Medium
    • Every change goes straight to production

      Open your hosting dashboard (Vercel: the Deployments tab) or the builder's publish panel and look at the recent deployments.

      Medium

  9. Performance

Questions

lovable security checklist

The list above: 42 checks across 9 categories, most severe first. Each links to a page with what the issue looks like, a self-check and a fix direction. Download the Markdown file to tick items off in your own notes.

can i use this checklist without buying anything

Yes. That is the point of publishing it. If you run every self-check and fix what you find, you have done most of what the security sweep does. What our test adds is a second account, scripts that enumerate everything, and a written report you can show someone.

Prefer someone else to run it: the security sweep covers the critical items in 24 hours; the pre-launch check covers the full list. Or run the self-check tool.