Lovable security scan found issues: what to do next

Open the Security view in your Lovable project, fix the Critical findings first, test each fix from outside the app, and ignore a finding only with a written reason. A finding is not a proof of a breach. It is a report that a check found a risk. Treat each Critical finding as real until you show that it is not.

This guide explains what the scan reports, how to put the findings in order, and how to confirm that a fix works.

What does the Lovable security scan report?

The Lovable docs describe two scan types in the Lovable security documentation.

The Deep scan checks access control, unauthenticated endpoints, unsafe input, leaked secrets, payments, authentication, and exposed sensitive data. According to the docs, the Deep scan does not run while you work. You must start it.

Each finding has a label: Critical, Warning, or Info. The Security view shows the evidence, what the finding means, and how to fix it. Dependency findings name the package, the version, and the advisory. The docs say that only critical vulnerabilities in dependencies become findings.

Read the evidence text of each finding before you do anything. The evidence shows where the tool found the problem. It tells you if the problem is in the database, in a function, or in the browser code.

Which findings do I fix first?

Fix in this order. The order follows the damage that a visitor can cause.

1. Critical findings about data access. These findings mean that a visitor can read or change data without permission. Examples are a table with no access rules and an endpoint with no login check.
2. Critical findings about secrets. A secret in the browser code is public. Delete the secret at its source and create a new one.
3. Other Critical findings. This group includes unsafe input and payment problems.
4. Warning findings. Read each one. Fix the ones that touch user data or money.
5. Info findings. Read them and fix them when you have time.

The Lovable docs say that you should resolve critical issues before you make the app public. A workspace admin can also turn on “Block publishing with critical issues” in the workspace settings under “Privacy & security”. Turn this on if more than one person publishes the app.

Warning: If your app is already public, do not wait for a release cycle. Fix Critical data findings now.

What do the common finding types mean?

The names of findings can change, so read the evidence text. These groups follow the areas that the Lovable docs list for the Deep scan.

Supabase has its own database checks. The Supabase database linter names the common ones. The lint 0013_rls_disabled_in_public reports a table that is publicly accessible. The lint 0010_security_definer_view reports a view that bypasses row-level security. The lint 0002_auth_users_exposed reports user data that a view exposes.

If a finding names one of these, the fix is in the database and not in the page code. Change the table or the view and test with the curl command below.

How do I fix a finding?

Lovable gives you two ways. You can fix a finding yourself, or you can ask Lovable to fix it.

Use Try to fix all, then check the result

The docs describe a “Try to fix all” action. It fixes one finding, a group of findings, or all findings. Your account has 10 free fixes, shared across all workspaces and projects. Each free fix becomes available again 24 hours after use. More fixes use credits.

Do these steps after each automatic fix:

1. Read the change that Lovable made. Look at the code diff or the database change.
2. Run the scan again.
3. Test from outside the app. See the next section.

Caution: An automatic fix can change database rules. A rule that is too strict breaks your app for real users. A rule that is too open leaves the hole. Test both cases: a signed-in user who owns the data, and a visitor who does not.

Fix it yourself

You can do manual changes at any time. The most common manual fix is a Row Level Security (RLS) policy. This is the short version for a table that holds data of one user per row.

alter table public.notes enable row level security;

create policy "owner can read" on public.notes
  for select to authenticated
  using ((select auth.uid()) = user_id);

create policy "owner can insert" on public.notes
  for insert to authenticated
  with check ((select auth.uid()) = user_id);

create policy "owner can update" on public.notes
  for update to authenticated
  using ((select auth.uid()) = user_id)
  with check ((select auth.uid()) = user_id);

create policy "owner can delete" on public.notes
  for delete to authenticated
  using ((select auth.uid()) = user_id);

Replace notes and user_id with your table and column. The Supabase RLS documentation says that after you enable RLS, the API returns no data for a publishable key until you create policies. The same page shows the auth.uid() pattern that this example uses.

For a longer explanation, read the Supabase RLS guide. Stay with the short version if your finding is only about one table.

How do I test that the fix works?

Do not trust the green status alone. Test from outside the app, as a visitor with no account. A scan can miss a problem, and a fix can fail without an error.

The public key of your project is in the browser code, so a visitor can read it. Use that key in this test. Find the project URL and the public key in your Supabase project settings or in the network tab of your app.

curl -s "https://YOUR-PROJECT.supabase.co/rest/v1/notes?select=*&limit=5" \
  -H "apikey: YOUR_PUBLIC_KEY" \
  -H "Authorization: Bearer YOUR_PUBLIC_KEY"

Read the result:

• An empty list [] means that the visitor sees no rows. This is the correct result for a private table.
• A list of rows means that the table is still open.
• An error about permissions also means that the visitor has no access.

Then test as a signed-in user. Sign in to your app with a test account, and check that you see your own rows and not the rows of another account. Use two test accounts for this check.

Run the scan again. The finding should go away. If it stays, read its evidence again. The evidence can point to a second table or a second endpoint.

If you need a deeper explanation of the public key, read the Supabase anon key guide.

What if the finding is wrong?

A finding can be a false alarm. For example, a table can be public on purpose, such as a list of blog posts.

The docs describe an “Ignore” action. It dismisses a finding that does not apply. Lovable asks you to record a reason.

Follow these rules for each ignored finding:

1. Confirm the finding with the curl test above. Do not ignore a finding because you believe that it is false.
2. Write a reason that names the table or the endpoint and says why the public access is intended.
3. Check that the data in the table is safe for every visitor. A public table must not hold emails, tokens, or private notes.
4. Write the date, so that you can review the decision later.
5. Run the scan again after each large change. A new column can change the risk of an ignored finding.

Never ignore a finding to pass the publish check. A real hole stays open after you dismiss it.

How do I check if someone already used the problem?

A scan finds a risk. It does not tell you if anyone used it. Check the logs for the time in which the app was public.

1. Check the database logs. Open the log pages of your Supabase project. Look for requests from unknown sources that read many rows. Look for delete and update requests that you did not expect.
2. Check the auth logs. Look for sign-ups that you did not cause and for failed sign-in bursts.
3. Check your data. Look for rows that you did not create, rows that are missing, and fields that changed.
4. Check the secrets. If a finding reported a leaked secret, open the dashboard of that service. Read its usage and its logs, then delete the secret and create a new one.
5. Check the deploy history. Find when the problem began. A finding often links to a change that Lovable made in a past edit.

If you find signs of use, read what to do about a leaked service_role key when a key is involved. For a project-level overview, read is my Lovable app secure.

How do I stop new findings from appearing?

New edits can add new problems. Use these habits to keep the Security view clean.

1. Run a Deep scan before each important release. The Quick scan runs when you publish, but the Deep scan does not run on its own. Open the Security view and click “Run deep scan”.
2. Use the publish dialog. The Quick scan starts when the dialog opens. Click the summary line to open the Security view.
3. Refresh the dependency audit. The audit runs when dependency files change. You can click “Scan dependencies” to run it by hand.
4. Turn on auto-fix with care. The docs say that Lovable can fix eligible Quick scan findings during builds. It does not apply to Deep scan findings. Review each change that it makes.
5. Add access rules when you add a table. Enable RLS in the same step that creates the table. Then the table is never public, even for a short time.
6. Keep secrets out of the browser. Variable names that start with VITE_ go into the browser bundle. Read environment variables security before you add a key.
7. Test the live app from outside. Use the curl test after each change to the database.

When should I get help?

Get help in these cases:

• You do not understand the evidence of a Critical finding, and the app holds personal data or payments.
• You find signs that someone read or changed data that they should not reach.
• The same Critical finding returns after you fix it three times.
• Your app takes payments, and a finding mentions payments or authentication.
• The app has users in a regulated sector, such as health or finance.

The Lovable docs say that scans are not a guarantee of security and that apps with sensitive data should also get a professional review. Plan one before you launch. A second tool that tests the deployed app from outside helps to find what the built-in scan does not report.

After you fix all Critical findings, run the Deep scan again, run the curl test as a visitor, and make a note of the date.