Is Lovable secure? What to check before you put real data in your app

The short answer

Lovable ships good, free security tools. They do not guarantee that your app is secure. Lovable’s own documentation says you are responsible for making sure the app meets the security requirements of your use case, and that the tools do not replace a full review (Lovable, Security).

In practice, the more useful question is “is the app I built on Lovable secure?”. That depends on how the tables, keys and routes were configured. You can check almost all of it yourself in an afternoon.

What Lovable already checks on its own

There are two kinds of scan (Lovable, Security):

• Quick scan: runs automatically when you publish. It looks at the database (tables without RLS, policies that let everyone through, leaked password protection turned off), at dependencies and at MCP servers without authentication.
• Deep scan: reads the whole codebase. It looks for broken access control, routes without login or easy to abuse, injection, leaked secrets, flaws in payment and login flows, and exposed personal data. It does not run on its own. You have to start it from the project’s security view or from the publish dialog.

Findings are labeled Critical, Warning or Info.

Why the app can still leak data

An app built on Lovable runs in the browser and talks directly to the database (Lovable Cloud is built on Supabase). To do that, a public key ships with the site. That is normal and by design: the Supabase publishable key is meant to be exposed (Supabase, API keys).

What protects the data is something else: row-level access rules, or RLS. The Supabase documentation is blunt: an exposed table without RLS can be read and changed by any role that has privileges on it (Supabase, Row Level Security). In other words, anyone who opens the site can take the public key and read the entire table.

The same goes for logic. Hiding a button from non-admins does not stop anyone from calling the function behind that button. Lovable is clear: use the browser’s login state only to control what the screen shows, never to grant access (Lovable, Security best practices). Broken access control is the first item in the 2025 OWASP Top 10 (OWASP, A01:2025).

A 7-step checklist

Go in order. Write down what you find.

1. Run the Deep scan and fix the critical issues

Open the project’s security view and start the Deep scan. Fix everything marked Critical before moving on. Then, in the workspace settings, turn on the option that blocks publishing when there is a critical issue (Block publishing with critical issues), which Lovable recommends (Lovable, Security).

2. Look for secret keys in the published site

Lovable says that any secret stored in front-end code is visible to users and should be considered compromised (Lovable, Security best practices). To check:

1. Open your published site in Chrome.
2. Press F12, go to Sources and search across all files (Ctrl+Shift+F).
3. Search for service_role, sb_secret_, secret, sk_live, sk_test and api_key.
4. Run the same search in the GitHub repository, if one is connected.

The Supabase publishable key (sb_publishable_... or the legacy anon key) may appear. A secret key (sb_secret_... or the legacy service_role) must not. It bypasses every RLS policy (Supabase, API keys). Secret keys for payments, email or AI services must not be there either. They belong in Lovable’s Secrets feature, read only by server code.

3. Check the RLS on every table

In Lovable Cloud, policies live under More → Database → Manage → Policies. That screen is read-only: to change a policy, you ask Lovable in the chat (Lovable, Database access).

If the app uses your own Supabase project, open the Security Advisor in the Supabase dashboard. Three alerts matter here (Supabase, Database Advisors):

• 0013_rls_disabled_in_public: a public table with RLS turned off. Anyone with the project URL can read, edit and delete its rows. This is the most serious one.
• 0007_policy_exists_rls_disabled: the policy exists, but RLS is off, so the policy does nothing.
• 0010_security_definer_view: a view that bypasses RLS.

New tables need policies too. Lovable recommends checking this every time the app gets a new table (Lovable, Security best practices).

4. Test as a stranger and as another customer

Reading the policy is not enough. Test it:

1. Open the app in a private window, without logging in, and try to open internal pages by typing their address directly.
2. Create two test users, A and B. As A, create a record. Log in as B and try to view, edit or delete A’s record, including by changing the ID in the address.
3. If B can see A’s data, the policy is wrong. Stop and fix it before you open the app to customers.

This is exactly the test Lovable asks for: confirm that one user cannot see another user’s private data (Lovable, Security best practices).

5. Check the server functions

Every Edge Function or API route has to verify who is calling and what that person is allowed to do. That also applies when someone calls the function directly, outside the app’s screens (Lovable, Security best practices).

Take extra care with functions that use the secret key. It bypasses RLS, so the function itself has to check permissions. Payments, sign-up and any multi-step flow should run on the server.

6. Check who can see the project and how login works

• Internal app: workspace visibility and mandatory login.
• Confirm that the app is published as public on purpose.
• Turn on leaked password protection for email and password login.
• Review who has access to the workspace.

All of these items are in Lovable’s docs (Security and Security best practices).

7. Check data protection law (LGPD, if you have users in Brazil)

If your app stores the name, email, phone number or CPF (Brazilian tax ID) of people in Brazil, it processes personal data under the LGPD, Brazil’s data protection law. The LGPD requires anyone who processes personal data to adopt security measures against unauthorized access (Lei 13.709/2018, art. 46). In practice, steps 2 to 6 are part of that.

You also need a privacy policy that says what the app collects and why. And know the deadline: if an incident may cause significant risk or harm to the people whose data you hold, the controller must notify the ANPD (Brazil’s data protection authority) and those people within three business days (ANPD, Comunicação de incidente de segurança).

Found a leaked key? Do it in this order

This is the order Supabase gives for secret keys (Supabase, API keys), and the logic applies to any service:

1. Fix the cause: remove the key from the front-end code.
2. Create a new key in the dashboard (in Supabase, under Settings → API Keys).
3. Replace the key everywhere it is used and confirm that everything works.
4. Only then deactivate the old key. Deleting a secret key cannot be undone.

Rotating the key does not undo what was already read with it. If the table was open and held personal data, assess whether there was an incident (step 7).

When it is worth bringing someone in

Lovable itself suggests a professional review for apps with sensitive data or critical functions, and a penetration test before a major launch (Lovable, Security). It is worth considering when:

• the app stores customers’ personal, health or financial data;
• you cannot say who is able to read each table;
• the Deep scan flags something you do not know how to fix;
• you are about to promote the app and the number of users will grow.

No review eliminates the risk. It reduces the risk and shows what is still missing.

Order a Heartscale diagnostic

Heartscale takes care of apps built with AI. In the diagnostic, our team reviews your app’s keys, RLS, routes, server functions, dependencies and data protection compliance. You receive a report with findings ranked by severity and the price of each fix.

The diagnostic costs US$ 79 and is credited toward the fix, the migration or the monthly plan if you go ahead. We only work on apps whose owners can prove they own them.

Order the diagnostic for my app