Lovable app hacked: what to do, in order

If your Lovable app was hacked, close the database with RLS, replace every key the attacker could read, and then read the logs. Unpublish the app first only if the data is being copied right now. Unpublishing stops the website. It does not close the database.

This guide covers the first hours of an incident in a Lovable app. It shows how to find the entry point, how to stop the attack, and how to check the damage. For the full list of Lovable security checks, read Is my Lovable app secure?.

What does “my Lovable app was hacked” mean?

A Lovable app has two parts. The frontend is the website that visitors open. The backend holds the database, the users, the files, and the secrets. The Lovable docs say that you use either the built-in backend or your own Supabase project. In both cases, the backend has its own address, and the browser calls it directly.

For this reason, most attacks on Lovable apps do not touch the website. They go to the backend. These are the usual entry points.

The public key of the database is made to be in browser code. RLS decides what that key can do. The Lovable docs advise that every table has RLS policies that restrict who can read and write each row. If you want to know why the public key is safe only with RLS, read the Supabase anon key guide.

How can I confirm that someone hacked my app?

Look for the signs below. One sign is a reason to check. Two signs are a reason to start the fix.

• Rows exist that you did not create, or rows are missing.
• Unknown users appear in the user list. Some have an admin role.
• Users report spam emails, changed accounts, or messages from strangers.
• The usage numbers or the bill for an API rise with no change in real traffic.
• The code in your repository changed, and you did not make the change.
• A person contacts you and says that they have your data.

Then find out where your backend lives. In the editor, open the More menu. If you see Supabase, the app uses your own Supabase project, and the menu shows its name and status. If you see Database, Users, Storage, and Logs, the app uses the built-in backend. The Lovable docs describe both views.

Then test the public API from outside.

1. Open your published app in a private browser window.
2. Open DevTools and select the Network tab.
3. Use the app. Find a request to the backend. Copy the project URL and the public key from it.
4. Send a read request to a table that holds user data.

curl "https://YOUR_PROJECT_REF.supabase.co/rest/v1/profiles?select=*&limit=5" \
  -H "apikey: YOUR_PUBLIC_KEY"

If the response shows rows of other users, the table is open. Test each table that holds private data. Replace profiles with the table name.

Next, run the scans that Lovable provides. The Lovable security docs say that the Quick scan runs on every publish and checks database access rules. The Deep scan reviews all application code for problems in logic, permissions, and data. You start it from the Security view, the Security center, or the publish dialog.

Warning: Do not delete data or reset the project to “clean up” before you read the logs. Deleted and changed rows are evidence. You need them to learn what the attacker did.

What do I do first? Fix it now, in order of urgency

Do these steps in order. Steps 1 to 3 stop the loss. The rest remove the attacker’s access.

Caution: Some steps break your app for a short time. This is the correct trade. A short outage costs less than an attacker who stays inside.

1. Decide about the website. If the attacker is copying data now, take the site offline. Click Publish, open the menu in the top-right corner of the dialog, and select Unpublish. You can also use Project settings. The Lovable hosting docs say that you can publish again later. This step does not close the database. Continue with step 2 at once.
2. Secure your accounts. Change the password of your Lovable account, your GitHub account, and your Supabase account. Turn on multi-factor authentication where it exists. Remove workspace members and collaborators that you do not know.
3. Turn on RLS for every table. Use the SQL editor if your app uses your own Supabase project.

alter table public.profiles enable row level security;

After RLS is on, the public API returns no rows until a policy allows them. Add a policy so that real users can work again. This policy lets a user read only their own row:

create policy "own rows select" on public.profiles
  for select to authenticated
  using ((select auth.uid()) = user_id);

If your app uses the built-in backend, ask Lovable in the chat to enable RLS on all tables and to explain each policy. The Lovable docs advise that you then check the result yourself. Open the Database view and read each table. For more policy patterns, read the Supabase RLS guide.

4. Find the key leak. Search the published JavaScript for strings that look like keys. Search your repository for sk-, service_role, Bearer, and secret. The Lovable docs state that browser-side code cannot store API keys safely. Values with a VITE_ prefix are build-time values that go into the browser bundle.
5. Replace each leaked key. Create a new key at the service that issued it. Then open More > Secrets, and replace the value. The Secrets view never shows a saved value again, so you cannot read the old one. The Lovable secrets docs say that removing a secret is permanent, and that any feature that needs it breaks until you add it again. Only the built-in AI key has a Rotate action. Delete the old key at the issuing service.
6. Rotate the database keys if the leaked key was a service_role or secret key. The Supabase key documentation says to fix the root cause first, create a new secret key under Settings > API Keys, replace the old key everywhere, and then retire the old key. Read the service_role key guide for the places where this key leaks.
7. Fix the GitHub repository. Open the repository settings on GitHub. Make the repository private. The Lovable docs state that repositories which Lovable creates are private by default. Someone may have changed this. Remove collaborators that you do not know. Treat any secret that was ever in the code as leaked, because the commit history keeps it.
8. Add an auth check to each edge function. Open the code of each function. Make sure it reads the user token and rejects calls without a valid user. A function with no check is a public endpoint.
9. Sign out users and remove unknown accounts. Open the user list in Users or in the Supabase Dashboard. Delete accounts that you did not expect. Remove admin roles that you did not grant.
10. Publish again and test from outside. Run the curl test again. Check that a signed-in user cannot read the rows of another user.

If a step takes too long, do steps 2, 3, and 5 first. They close the most likely entry points.

How do I check what the attacker did?

Read the logs for the period before you noticed the attack. Attacks often start days before the first sign.

1. Open the logs of your backend. For the built-in backend, open More > Logs. For your own Supabase project, open https://supabase.com/dashboard/project/_/logs and replace _ with the project reference. The log retention depends on your plan, so read the logs first.
2. Look at the API requests. Look for requests to tables from unknown IP addresses. Look for a high number of GET requests to one table. This pattern shows a bulk copy of data. Look for POST, PATCH, and DELETE requests to tables that your app does not change.
3. Look at the sign-in events. Look for new sign-ups, many failed sign-ins, and reset requests that you did not start.
4. Look at the edge function logs. Look for calls to functions from unknown sources.
5. Check the usage page. Open More > Usage. A sharp rise in usage can show that someone used your API keys.
6. Check the GitHub history. The Lovable docs state that Lovable commits come from the lovable-dev[bot] identity, with the workspace member as co-author. Look for commits from other authors, and for commits at times when you did not work.
7. Compare the data. Sort each important table by created_at and updated_at. Look for rows from the time of the attack. Check payments, orders, and roles for changes that you cannot explain.

Check your backups before you restore anything. The Lovable docs state that managed backups need the built-in backend. For your own Supabase project, open Database > Backups in the Supabase Dashboard. Do not restore over the live data before the investigation ends. A restore can remove evidence.

Note: Logs show requests. They do not prove which data left the system. If a table was open, assume that the attacker copied all its rows.

Write a short timeline: the first sign, the entry point, the time of each fix, and the tables that the attacker could read. You need it for any user notice.

How do I stop it from happening again?

Use these controls. Each one closes one of the entry points from the start of this guide.

1. Enable RLS when you create a table. Ask Lovable for the policies in the same request. Then read each policy yourself. A policy with using (true) is the same as no policy.
2. Run the scans before each major release. The Quick scan runs on each publish. Start the Deep scan after you change data access, auth, or edge functions. Fix critical findings before the next publish.
3. Ask for a security review in the chat. The Lovable docs describe a prompt such as “Review my app’s security”. It counts as standard build usage and uses credits. It does not replace a test from outside.
4. Keep secrets in the Secrets view. Do not paste keys into the chat or into code. Do not use VITE_ for anything private. The environment variables guide explains the rule.
5. Keep the repository private. Check the setting after each change to the Git connection. To stop the sync, use Project settings > Git > GitHub and select Disconnect. The repository stays on GitHub.
6. Use a separate key for each service and each app. A leak then costs one key, not all of them.
7. Protect the accounts. Use multi-factor authentication for Lovable, GitHub, and Supabase. Give each collaborator the lowest role that they need.
8. Scan the published app from outside. A scan tests what an attacker can reach, not what the code looks like. It finds open tables and keys in the bundle that a code review can miss.

For more about the usual weak points in Lovable projects, read the Lovable guide.

When should I get help?

Get help in these cases:

• The attacker still has access after you finish the steps. Signs are new rows, new users, or new requests after the key change.
• The attacker could read personal data, payment data, or health data. You may have legal duties to report the breach. Ask a lawyer or a privacy officer.
• You cannot find the entry point. A security engineer can review the policies, the functions, and the logs.
• The logs expired, and you cannot say what the attacker took.
• You find a function, a database trigger, or a scheduled job that you did not create. These can give the attacker a way to return.

After you finish, wait one day and read the logs again. Look for new requests from the same IP addresses. Run the outside test from the confirm section once more.