Security and visibility for your Lovable app

"Lovable security" is two things worth keeping apart. The first is the Lovable project itself: what you paste into the chat, where it stores secrets, who can see your project and where the app ends up deployed. The second is the code Lovable generates, which is a React SPA on Supabase and always ships with the same five or six flaws. This guide covers both, with a block of instructions for your project's Knowledge section, a review prompt to run before publishing and the way to check the result from outside.

Part 1: securing your Lovable project

What you paste into the chat stays there

The project chat is your app's history: every prompt, every key you pasted "to make it work" and every answer. If a secret key enters through the chat, the model tends to write it straight into the frontend code, and from there it travels in the bundle to every visitor. The rule is simple: keys never enter through the chat. When Lovable asks you for a secret to connect a service, use the secrets box it offers; that stores it as a Supabase Edge Function variable, server side, and the generated code reads it with Deno.env.get.

Secrets: server yes, browser no

Lovable can do two things with an integration: call it from the browser or from an Edge Function. The first is right for public keys (Supabase's anon, Stripe's publishable, a project ID). The second is the only option for secret keys (OpenAI, Resend, Stripe's secret, the service_role). If you ask for a feature and the result calls the service from a React component with the key inside, explicitly ask it to move it to an Edge Function. More in secrets your app leaks in the browser.

Project and code visibility

A public project on Lovable exposes the code and the prompt history to anyone with the link, including any key you ever pasted. Check the visibility in the project settings and, if you enabled GitHub sync, make sure the repository is private. If a key was ever in a public project or repository, treat it as compromised and rotate it.

Where the published app lives

Lovable publishes on a .lovable.app subdomain or on your own domain. That hosting does not let you configure security headers or custom redirects. For many apps that is enough; if you need Content-Security-Policy, HSTS or cache rules, export to GitHub and deploy on Vercel or Netlify with their config file. Keep in mind too that each version's preview URL is reachable by anyone who has it.

Supabase is yours, not Lovable's

When you connect Supabase (or use Lovable's managed backend, which is Supabase underneath), Lovable creates tables, policies and functions for you. But RLS, buckets and Auth settings remain your responsibility. Lovable added a security review before publishing after CVE-2025-48757; take it as a first filter, not a guarantee, and go through the Supabase security guide, which has three SQL queries to audit the project in a minute.

Part 2: the flaws Lovable puts into your code

Tables without RLS or with using (true) policies. The origin of the CVE and the most serious flaw. Anyone with the anon key reads and writes your data.
Permission checks only in the frontend. An /admin route that merely hides the button if the user is not an admin. The server (RLS or the Edge Function) has to check it too, because the API can be called without going through the UI.
Edge Functions without authentication or limits. The template answers anyone, with Access-Control-Allow-Origin: *, and if it calls OpenAI or sends emails, anyone can spend your quota. Require the user's JWT, restrict the origin and cap requests per user.
Public buckets for user files. Lovable creates the bucket as public so that images "show up". For private documents, private bucket and signed URLs.
Invisible to AI and search engines. The app is a Vite SPA: the HTML arrives empty and ChatGPT's or Perplexity's bots see nothing. If the landing page and blog matter, separate them from the app. Detail in why AI-built apps are invisible to AI.
No security headers or metadata. No CSP, no HSTS, no X-Frame-Options, and the title is the template's. The first requires deploying outside lovable.app; the second is fixed with one prompt.
Validation only in the form. The field has maxLength but the Edge Function or the table accept whatever arrives. Validate on the server and in database constraints too.

A block for your project's Knowledge section

In the project settings, Lovable has a knowledge section the model reads on every request. Paste this so the rules apply from the first prompt:

Security rules for this project:
- Every new table has RLS enabled and one explicit policy per operation. Never use using (true) or with check (true) except on public read-only content tables, and tell me when you do.
- Never put secret keys in frontend code. Integrations with secret keys go in an Edge Function that reads the secret with Deno.env.get.
- Every Edge Function verifies the user's JWT unless I say otherwise, restricts Access-Control-Allow-Origin to our domain and validates its input.
- Admin permissions are checked in RLS or on the server, never only in the frontend.
- Files uploaded by users go to private buckets with policies and signed URLs.
- The columns role, is_admin, plan and credits are not editable by the user.
- Put a real title, meta description and Open Graph tags in index.html.

A review prompt before publishing

Review the security of this project and do not change anything yet. Answer with a list:
1. Tables without RLS and policies with using (true) or with check (true).
2. Keys or tokens present in the frontend code, with file and line.
3. Edge Functions that do not verify the JWT, answer with Access-Control-Allow-Origin: * or do not validate input.
4. Admin routes or actions protected only in the frontend.
5. Public buckets containing user files.
6. Privilege columns a user can modify.
7. index.html metadata still left from the template.
For each point, propose the exact change and wait for my confirmation.

Check the result from the outside

Open your published app in an incognito window, right-click, "View page source", and search for service_role, sk_live, sk- and Bearer in the JavaScript files it loads. Then probe the Supabase API without a session:

curl -s "https://YOUR_PROJECT.supabase.co/rest/v1/profiles?select=*" -H "apikey: YOUR_ANON_KEY" -H "Authorization: Bearer YOUR_ANON_KEY"

If it returns rows, that table is open. Scanaris does this and about forty more checks in 30 seconds: it detects that the app is built with Lovable, probes the Supabase tables without a session, looks for secrets in the bundle, reviews headers, cookies, CORS and exposed files, and checks whether your content is readable without JavaScript. For every failure it gives you a fix prompt to paste into the Lovable chat with the exact change, and it can rescan every day because a code regeneration can bring back a flaw you had already fixed.

Frequently asked questions

Has Lovable already fixed the RLS problem?

Lovable added a security review before publishing and improved the templates, but the model still generates open policies when a query fails. RLS remains your responsibility: use the queries in the Supabase guide.

Can I set security headers on an app hosted on lovable.app?

Not from Lovable. If you need them, sync with GitHub and deploy on Vercel or Netlify, where they are configured with a file. The app keeps being edited in Lovable.

What do I do if I pasted a secret key into the chat?

Rotate it at the source service even if it is no longer in the code: the chat history and earlier bundles keep it. Then add it through the secrets box and ask the model to move the integration to an Edge Function.