Lovable Security Guide: RLS, secrets, scans and publishing controls that prevent leaks

Apps built with Lovable talk to their database straight from the browser, so the only thing standing between a visitor and every row is the row-level security policy the AI wrote. Under shared responsibility, the customer owns the data protection rules of each app, so reviewing those policies is the core task. This guide covers workspace identity and roles, secrets and keys, RLS on Lovable Cloud and connected Supabase projects, the built-in scans, publishing policies, audit logs and a hardening baseline. It goes deeper on Lovable than our cross-product AI App Builder Security Guide. Facts come from Lovable's own documentation, checked on 8 November 2026; several controls are Business or Enterprise only, so re-check your plan.

This is an independent guide from NHI Mgmt Group, based on Lovable's public documentation as of November 2026. It is not sponsored or reviewed by Lovable. Product features change, so confirm settings against Lovable's current documentation.

Key takeaways

• RLS is the perimeter. The publishable key is meant to be visible in the app and requests using it arrive as anon or authenticated, so policies alone decide what each visitor can read or change.
• "Signed in" is not "owner". Lovable's docs flag the common pitfall: a policy that only checks authenticated gives every signed-in user the same rows. Compare the requester with an owner column.
• Secrets belong in Edge Functions. Project secrets are write-only and injected server side; anything prefixed VITE_ is embedded in the client bundle and must be safe to publish.
• Scans help but do not gate by default. The Quick scan runs on publish, but "Block publishing with critical issues" is off by default except on new Enterprise workspaces, and the Deep scan only runs when someone starts it.
• Default audience is Anyone. First-time publishes default to public; change the workspace default and use publishing policies before people start shipping.

How identity and access work in Lovable

Two identity layers matter: who can build in the Lovable workspace, and who can sign in to the apps it produces. For the workspace, SSO is available on Business and Enterprise plans with OIDC (recommended) or SAML 2.0, configured under Workspace settings, Access, Identity, after you verify a domain with a DNS TXT record.

• Enforce SSO: members must sign in through your provider, with session length from 8 hours to 7 days. The toggle stays locked for six hours after you add a provider so you can test. The docs state Enforce SSO and Lovable two-factor authentication cannot be enabled together, so MFA must be enforced at the identity provider.
• Group mapping: IdP groups map to Viewer, Editor, Admin or Owner, optionally restricting login to mapped groups. The IdP must send group names, not IDs, and claims must match exactly.
• Provisioning: just-in-time provisioning creates accounts on first SSO login (on by default on Business, toggleable on Enterprise); SCIM is Enterprise only. Only one SSO provider can be active per workspace.
• App sign-in: "App login methods" (Business and Enterprise) allows or blocks sign-in methods for apps built in the workspace, which lets you standardise end-user authentication.

See the SCIM Provisioning Guide for leaver handling.

Admin roles and privileged access

The key point is that Editors publish by default. On Enterprise, publishing policies let admins require approval or block publishing; any admin or owner approves in the Action center, nobody can approve their own request, and requests expire after 30 days. Limit "External project collaborators" (allow all, editors and viewers, viewers only, or none) so outside contractors cannot become editors who publish. See the Privileged Access Management Guide.

Integrations, API tokens and service accounts

Secrets and keys

Each project secret is encrypted and injected into Edge Functions at runtime and never reaches the browser. Values are write-only: after saving you can replace or delete a secret but not read it back. Manage them under More, Settings, Secrets. The LOVABLE_API_KEY secret has a Rotate action for suspected exposure. Names starting SUPABASE_ or LOVABLE_ are reserved for the platform. Lovable detects API keys pasted into chat and directs you to store them in Secrets instead.

With your own Supabase project, secrets are stored and managed in the Supabase dashboard, and the docs warn that several Lovable projects sharing one Supabase project overwrite each other's secrets. See the Supabase Keys Security Guide and the Secrets Management Guide.

Supabase connection

Lovable Cloud, the built-in backend, is on by default. To use your own Supabase project, a workspace owner or admin authorises Lovable for a Supabase organisation through a Supabase sign-in, after which anyone with edit access can connect projects. Lovable writes SQL migrations to supabase/migrations/ and runs them only after approval in chat; data inserts and storage bucket changes also need approval, but Edge Functions are written and deployed without a separate approval step described. That organisation-level authorisation is a standing non-human credential: review which Supabase organisation is linked and remove it when no longer needed.

Connectors and MCP

"Remote MCP connectors" (on by default on all plans) lets members connect MCP servers; "Local desktop MCP servers" is on by default except on Enterprise; "Third-party MCP clients" controls whether external tools can drive Lovable through the Lovable MCP server, off by default only on Enterprise. The Quick scan also checks for an MCP server exposed without authentication. The Enterprise policy "Require approval to publish apps that use connectors" adds a human check. See the MCP Security Guide.

Row-level security in practice

Lovable sets up RLS policies automatically when it builds features that store user data, and recommends reviewing them early. Review them under More, Database, Manage, Policies: each policy shows its name, command (read, add, change or delete), who it covers and its condition. The view is read-only, so changes are made by asking Lovable in chat, which means every fix is itself AI-generated and needs re-checking.

1. Inventory exposure: ask the documented question "Which of my tables can people who aren't signed in read or change?" and confirm the answer in the policy list rather than trusting the reply.
2. Check ownership: every table holding per-user data needs a condition comparing the requester's identity with an owner column, not just the authenticated role.
3. Check writes separately: policies govern writes as well as reads; confirm insert, update and delete policies, not just select.
4. Check server code: Edge Functions using service_role bypass RLS; ask "Does my server code check permissions?" and review the function code.
5. Test as an outsider: sign in as a second test user and as an anonymous visitor and attempt to read the first user's rows through the app's API calls, in a test project, before publishing.
6. Re-check after schema changes: Lovable flags RLS issues after schema changes; the Supabase integration page calls missing policies the most common way app data gets exposed.

See the Supabase Security guide for policy patterns and the OWASP API Top 10 API1 Broken Object Level Authorization Guide for testing technique.

Security scans and publishing controls

Lovable's docs state the dependency audit reports only critical vulnerabilities, hides some where exploitation is judged unlikely, and that the scans cannot guarantee complete security; apps handling sensitive data warrant a professional review. Treat a clean Quick scan as a floor, run the Deep scan before every public release, and keep your own authorisation tests.

Data protection settings

• Sensitive data scanning (Enterprise, off by default): detects personal data in chats, uploads and the built-in database; with "Chat send protection" set to log only (default), ask before sending or block.
• Extended-retention models (Enterprise, off by default): when disabled, only zero-data-retention models are used; enabling allows models that retain prompts for at least 30 days.
• Data residency: "Default data hosting region" (Americas, Europe or Asia Pacific) for new projects and "EU inference" (Enterprise) for model requests.
• Code exfiltration: "Code downloads" (Enterprise, on by default) and "Editor project transfers" (off by default) control source leaving the workspace; neither affects connected Git repositories.
• Preview links and external viewers: restrict "Preview link sharing" and "External viewer invites" to approved domains.

See the Generative AI Data Loss Prevention Guide.

Logging and detection

Audit logs are Enterprise only, viewed under Workspace settings, Security, Audit logs, with an organisation-level view across workspaces. They cover membership, settings and ownership, groups, identity changes (domains, SSO, SCIM, API keys), secrets and integrations, project activity, Lovable Cloud configuration and authentication events; API actions show the key used. Retention is about 90 days, and the docs note logs before 26 February 2026 may be incomplete. Manual export is JSONL; scheduled data exports deliver to Splunk, Azure Log Analytics, Amazon S3, Google Cloud Storage and Azure Blob Storage.

Alert on: changes to Default published app access or Block publishing settings; projects published publicly; new or removed secrets; Supabase organisation links; new MCP connectors; SSO or SCIM configuration changes. For the apps themselves, monitor the database for anonymous reads of user tables and spikes in row counts returned, which map to T1190 Exploit Public-Facing Application and T1530 Data from Cloud Storage.

Metrics: share of published apps that are public and the share approved through policy; open critical findings across the Security center; percentage of projects with a Deep scan in the last 30 days; tables holding personal data without an owner-based policy (target zero); days of audit history retained outside Lovable.

Hardening baseline

1. Identity: verify your domain, configure OIDC SSO, enforce it, map groups to roles and enforce MFA at the IdP; enable SCIM on Enterprise.
2. Publishing defaults: set Default project access to Restricted, Default published app access to Workspace, and turn on Block publishing with critical issues.
3. Policies (Enterprise): require approval to publish externally and for apps using connectors; block publishing by external collaborators.
4. Data: enable Sensitive data scanning, keep Extended-retention models off unless approved, set hosting region.
5. Connectors: limit Remote MCP connectors and Third-party MCP clients to approved use; disable local desktop MCP servers where not needed.
6. Per app before first publish: owner-based RLS on every table, no secrets in VITE_ variables, service_role use reviewed, Deep scan clean.
7. Test and roll back: pilot settings in one workspace; version history lets you preview and revert project versions, and Lovable Cloud offers database backups, but rehearse a restore before relying on it.

Common misconfigurations

• Authenticated-only policies: any user who signs up can read every other user's rows.
• Read policies checked, write policies ignored: attackers can alter or insert data even where reads are restricted.
• Secrets in VITE_ variables or front-end code: the docs say secrets in front-end code should be considered compromised.
• Edge Functions using service_role without checks: RLS does not apply, so the function becomes an open data API.
• Publishing with the default audience: internal prototypes go public because Default published app access is Anyone.
• Sharing one Supabase project across apps: secrets overwrite each other and access boundaries blur.

Practitioner checklist

• Enforce SSO with MFA at the IdP and map IdP groups to Lovable roles.
• Set Default published app access to Workspace and turn on Block publishing with critical issues.
• On Enterprise, require approval for external publishing and connector apps.
• Review every table's policies for owner-based conditions on select, insert, update and delete.
• Test as an anonymous visitor and a second user before each public release.
• Keep credentials in project secrets; allow only public values in VITE_ variables.
• Run a Deep scan before every public publish and track open critical findings.
• Enable Sensitive data scanning and keep extended-retention models off by default.
• Export audit logs to your SIEM; alert on publishing and secrets changes.

Standards and references

• Lovable: Security overview
• Lovable: Database access and RLS
• Lovable: Secrets
• Lovable: Privacy and security settings
• Lovable: Workspace policies
• Lovable: Connect to Supabase
• Lovable: Audit logs

Related NHI Mgmt Group resources: AI App Builder Security Guide · Supabase Keys Security Guide · Vibe Coding Security Guide · Top 10 Vibe Coding Security Risks