This guide first appeared on BuiltSafely: https://builtsafely.com/guides/lovable/

Label for every step in this guide: Docs-only. We wrote it from Lovable's public docs (last reviewed October 21, 2026) and did not run these steps end to end. Source overview: Lovable docs: Security overview.

Lovable's own docs say its tools "do not replace a thorough security review" and that you are responsible for your app's security. Here's how to use them well.

Copy this fix

Run both security scans first, then paste this prompt into the project chat. Treat the answer as a to-do list to check, not a guarantee.

Review the authentication flow and every server-side function in my app. For each one,
tell me who can call it, what data it can read or change, and whether it checks the
caller's identity and role.

1. Run both scans

Docs-only

• Quick scan runs automatically when you open the publish dialog. It checks database access rules (for example, tables without row-level security, or rules that let everyone through), dependency vulnerabilities, and MCP servers exposed without authentication.
• Deep scan doesn't run automatically. Run it from the project's Security view before you publish. It reviews your app code for access-control gaps, unauthenticated endpoints, injection, leaked secrets, payment/billing logic and auth weaknesses.
• Fix every Critical finding. Read each Warning and decide on purpose. Don't just ignore it.

A scan is a starting point, not a sign-off.

2. Keep API keys in Secrets, and call APIs from server-side code

Docs-only

Lovable's frontend runs in the browser, so secrets can't be stored safely there. Its docs recommend storing keys in Secrets and making third-party API calls from server-side functions, which your frontend then calls.

• Manage secrets in More → Settings → Secrets (Lovable docs: Secrets).
• Your server-side functions are listed in More → Database → Manage → Edge functions (Lovable docs: Edge functions).
• If you pasted a key into chat, move it to Secrets and rotate it at the provider.

More on this: Check what your build actually ships: secret keys in frontend env vars.

3. Review your RLS policies yourself

Docs-only

Lovable's docs call misconfigured RLS "a common cause of data leaks". To review every policy, go to More → Database, select Manage, then Policies. Each row shows the policy name, the command it covers (SELECT, INSERT, UPDATE or DELETE), who it applies to (such as signed-in authenticated or anon users), and whether it has a condition. Expand a row to read its SQL condition.

The view is read-only, so to change a policy, ask Lovable in the project chat, then check the result in the view (Lovable docs: Control who can access your app's data). Then read our Supabase RLS guide and test with two accounts.

On the built-in backend you can also ask Lovable to rotate the database password, for example:

Rotate my database password.

Lovable asks you to confirm, doesn't show the new password, and your app keeps working. Any BI tool or script that someone connected with the old password stops working until it's updated. This applies only to the built-in backend, not to a connected Supabase project (same Lovable page).

Check: in More → Database → Manage → Policies, each policy's Applies to and condition match who should see or change those rows.

4. Turn on leaked-password protection

Docs-only

If your app uses email and password sign-in, turn on Password HIBP check in More → Users → Settings → Email. It rejects passwords found in the Have I Been Pwned database of leaked passwords (Lovable docs: Email authentication). If you connected Supabase directly, use the Supabase equivalent.

5. Review your sign-in methods

Docs-only

Unless you name the methods you want, Lovable's login pages for apps on the built-in backend (Cloud) include email and password, Google, and Sign in with Lovable (Lovable changelog, Oct 15, 2026). With Sign in with Lovable, "Any Lovable account can sign in," and your app receives the person's name, email address and profile picture (Lovable docs: Sign in with Lovable).

1. Open More → Users → Settings. The Sign in methods list shows each method as Enabled or Disabled.
2. Turn off any method you don't mean to offer.
3. Use Disable sign-up if new people shouldn't be able to join (Lovable docs: Users and authentication).
4. Keep at least one method enabled so existing users can get back in.

OpenID Connect (OIDC) sign-in lets your users sign in with your own identity provider, such as Auth0, Okta, Microsoft Entra ID or Keycloak. Your provider then decides who can sign in and applies its own password and MFA rules (Lovable docs: OIDC sign-in). Steps and limits, all from that page:

• What it needs: a project on the built-in backend (Cloud) with authentication on, edit access, and admin access to your OIDC provider. It's available on all plans. On Business and Enterprise workspaces, SAML SSO must be allowed under App login methods, because that one setting covers OIDC too. It isn't available for self-hosted backends.
• Set it up: go to More → Users → Settings → OIDC, enable OIDC sign-in and copy the Redirect URI. Register a web application with your provider and add that redirect URI. Then enter the Issuer URL (must start with https://), Client ID and Client secret in the form and save. Lovable runs a build that adds the sign-in button, and that build uses credits.
• Keep the client secret out of chat: enter it in the OIDC form, not in the project chat. Lovable keeps it masked. To rotate it, enter the new secret and save.
• Test it: open your sign-in page in a private window, use the new button, and confirm you come back signed in.
• Know the limits: one OIDC provider per project, and the scopes are fixed to openid, profile and email.

If an app or website you didn't build on Lovable signs people in through Lovable, it uses an OAuth client that a workspace admin registers under Workspace settings → API keys & OAuth → OAuth clients. A Web server client's secret is shown only once. Lovable says: "Do not put it in browser code, a public repository, or a prompt." Scopes that read or change projects and workspaces need a Business or Enterprise plan and verification by Lovable (Lovable docs: OAuth clients).

Check: your login page offers only the sign-in methods you chose, and every other method shows Disabled in More → Users → Settings.

6. Ask for a focused review, then verify

Docs-only

Use the prompt from Copy this fix above. Conversational reviews use credits (per Lovable's docs). Treat the answer as a to-do list to check, not a guarantee.

For apps handling sensitive data or payments, Lovable's docs suggest an additional professional security review. We agree.

Related

• Check what your build actually ships: secret keys in frontend env vars
• new row violates row-level security policy (Supabase)
• Supabase row-level security, explained for builders

This guide is educational and based on the vendor's public docs as of the review date. Platforms change: check the linked sources. Not a security audit. Disclaimer.

More fixes like this at https://builtsafely.com/fixes/

This guide first appeared on BuiltSafely: https://builtsafely.com/fixes/infinite-recursion-policy/

Last checked October 19, 2026 · Educational, not an audit.

The fix

Verified: we ran this in a throwaway local Postgres 17 database (not a full Supabase stack). Details under What we tested below.

Stop the policy from querying its own table (or a chain of tables that loops back). Move the lookup into a SECURITY DEFINER function in a private schema, pin search_path, then call that function from the policy. Keep RLS on.

create schema if not exists private;

-- Look up the caller's team ids without re-entering the policy
create or replace function private.my_team_ids()
returns setof uuid
language sql
stable
security definer
set search_path = ''
as $$
  select team_id
  from public.members
  where user_id = (select auth.uid())
$$;

revoke all on function private.my_team_ids() from public;
grant usage on schema private to authenticated;
grant execute on function private.my_team_ids() to authenticated;

drop policy if exists "members read their teams" on public.members;
create policy "members read their teams"
on public.members
for select
to authenticated
using ( team_id in (select private.my_team_ids()) );

Replace members and team_id with your table and columns.

That shape follows Supabase's security-definer guidance: run as the creator (which bypasses RLS on the lookup), pin search_path = '', schema-qualify names, and keep the function out of an exposed schema (Supabase: RLS).

What we tested (October 19, 2026): on a throwaway local Postgres 17, a self-referencing SELECT policy on members raised ERROR: infinite recursion detected in policy for relation "members". After adding the private helper above (with a stand-in JWT claim for auth.uid()), a user saw only their team's rows, and a second user saw both teams they belonged to.

Why it happens

Docs-only

Supabase's troubleshooting page says this error is "infinite recursion in your Row-Level Security (RLS) policies." It happens when a policy queries a table that has RLS, and that table's policies end up triggering the original policy again: either the same table, or another table that loops back (Supabase troubleshooting: RLS policy causes infinite recursion). Postgres raises SQLSTATE 42P17 and aborts the query (PostgreSQL error codes).

A common pattern is "show every member of any team I belong to" written as a subquery on the same members table. Evaluating the policy runs the subquery, which re-enters the policy.

What not to do

Docs-only

• Don't disable RLS to clear the error.
• Don't put a secret or service_role key in the client to "bypass" it (Supabase: API keys).
• Don't leave a SECURITY DEFINER function in an exposed schema, and don't skip set search_path = ''. Supabase warns both are risky (Supabase: RLS).

Copy this fix: AI prompt

Paste this into your AI coding tool:

My app hits: infinite recursion detected in policy for relation (42P17).
Find any RLS policy that queries its own table or forms a policy loop.
Propose a private SECURITY DEFINER helper with set search_path = '', revoke public execute, and a rewritten policy that calls it.
Do not disable RLS. Do not use a secret or service_role key in client code.
Show the SQL first and wait for my OK before applying anything.

How to verify (two accounts)

Verified in our local test with two stand-in users; run it against your own app too.

1. Sign in as user A. Confirm you can read the rows you should (for example your team's members).
2. Sign in as user B on another team. Confirm you see B's teams, not A's private rows.
3. Sign out. Confirm signed-out requests get no private rows.

Related

• Our Supabase RLS guide
• new row violates row-level security policy
• Empty array with RLS on

Educational, not a security audit. Platforms change: check the linked sources. Disclaimer.

More fixes like this at https://builtsafely.com/fixes/

This guide first appeared on BuiltSafely: https://builtsafely.com/fixes/42501-permission-denied/

Last checked October 19, 2026 · Educational, not an audit.

The fix

Verified: we ran this against a throwaway local Supabase Postgres 17 container (no real project). Details under What we tested below.

Grant the role the privilege it's missing, in a migration, and keep RLS on. The error's hint tells you which role and privilege it needs:

-- Signed-in users manage their own notes; signed-out visitors get nothing
grant select, insert, update, delete on table public.notes to authenticated;
alter table public.notes enable row level security;
-- ...plus one policy per operation (see our RLS guide)

Replace notes with your table. Grant only what each role needs. Only grant to anon for data that's meant to be public.

What we tested (October 16, 2026): without a grant, a signed-out read failed with 42501: permission denied for table notes and the hint "Grant the required privileges to the current role with: GRANT SELECT ON public.notes TO anon;". A public table with grant select ... to anon, RLS on and a read-only policy returned its rows to anon.

Why it happens

Docs-only, except where marked

Postgres checks grants before policies. Supabase's RLS guide says a missing grant "raises a 42501 error before any policy runs", so check grants before you change policies (Supabase: RLS).

To see a table's grants (Supabase: 42501 errors):

select grantee, privilege_type
from information_schema.role_table_grants
where table_name = 'notes';

Verified: on the same test container, this listed the roles and privileges for the table.

Why you may see it more on tables created on or after October 30, 2026: Supabase applies a changed default to all existing projects on that date. Existing tables keep their current grants and stay reachable. Only tables created in public after the change need an explicit grant before the Data API can see them. Direct Postgres connections are unaffected (Supabase changelog). Our Oct 30 grants guide covers the migration pattern.

Clients often surface 42501 as a 401 or 403, so read the response body for permission denied for table (Supabase: 42501 errors). Not every 42501 is a missing grant: Supabase also lists restricted schemas, custom schemas without API grants, column-level restrictions, and RLS blocking an insert or update. If the message says "new row violates row-level security policy", see our RLS error fix.

If you limited updates to certain columns on purpose, for example so users can't change their own role, a 42501 on those columns is that protection working. See Never let users edit the field your access rule trusts.

What not to do

Docs-only

• Don't disable RLS.
• Don't grant everything to anon without policies.
• Don't move the secret or service_role key into the frontend (Supabase: API keys).

Treat grant + enable RLS + policies as one unit in the same migration (Supabase changelog).

Copy this fix

-- Replace notes with your table. Signed-out visitors get nothing.
grant select, insert, update, delete on table public.notes to authenticated;
alter table public.notes enable row level security;
-- ...plus one policy per operation (see our RLS guide)

Grant only what each role needs, and keep RLS on. Policy examples: Supabase row-level security, explained for builders.

Related

• new row violates row-level security policy
• Supabase's Oct 30 change: new tables need a GRANT
• infinite recursion detected in policy for relation (42P17)

Educational, not a security audit. Platforms change: check the linked sources. Disclaimer.

More fixes like this at https://builtsafely.com/fixes/