Skip to main content
Two things control access to your app’s data: the policies that decide which rows each signed-in user can see, and the database password that direct connections use. Lovable sets both up when it builds your app. You can review the policies and rotate the password at any time.

Row level security (RLS) policies

Row level security (RLS) controls which data users can access across your database, storage, and realtime features, the live updates your app pushes to users. A policy is a rule that decides which rows a signed-in user can see or change, for example “users can only read their own orders”. Lovable sets up these rules automatically when it builds features that store user data, so that one user’s private data is not served to another. To review the rules, go to More → Database, select Manage, then Policies. The policies view lists each policy with:
  • Policy name: what the rule is for.
  • Command: the action the rule applies to. SELECT is reading data, INSERT is adding it, UPDATE is changing it, and DELETE is removing it.
  • Applies to: which users the rule covers, such as signed-in (authenticated) or anonymous (anon) users. See Who a policy applies to.
  • Rule expression: whether the rule has a condition. Expand the row to read the SQL condition that must be true for the action to be allowed.
You can filter by section (All policies, Tables, Storage, or Realtime) and by table. The policies view is read-only. To change a policy, ask Lovable in the project chat, for example:

Who a policy applies to

Every request your app sends to your database comes in as one of three database roles. A database role is the identity a request uses. Each policy names the roles it covers and what those roles can read or change. The Applies to column in the policies view shows the roles for each policy.
  • anon: a request from someone who is not signed in, such as a visitor on a public page.
  • authenticated: a request from someone signed in to your app.
  • service_role: privileged access for your app’s server code. Your RLS policies do not apply to service_role requests.
Your app’s pages use a publishable key to read and write your database. Anyone using your app can see the publishable key, and that is intended, because the key gives no privileged access. Requests made with the publishable key come in as anon, or as authenticated after someone signs in, so your policies still apply to them. A role shows only whether someone is signed in, not who the person is or whether they are an admin of your app. If a policy checks only for authenticated, every signed-in user gets the same access to every row that policy covers. To keep one user’s data from another, a policy has to compare the person making the request with something in the row, such as the row’s owner. For example, a policy that checks the row’s owner shows each user only their own orders. Your policies do not apply to service_role, so server code that uses service_role must check permissions itself. Ask Lovable in the project chat whether your app’s server code checks permissions. See Database security with RLS. To review what each role can reach, ask Lovable in the project chat, for example:

Rotate the database password

Your project’s database has a password that Lovable manages for you, so you do not need to see or store it. You can ask Lovable to rotate it at any time as a routine security measure. For example, prompt Lovable:
Lovable generates the new password and asks you to confirm before applying it. Lovable does not show the new password, and your app continues to work without changes. Any tool a developer connected with the old password, such as a business intelligence (BI) tool or a script, stops working until they update it. Anyone who can manage the project’s settings can rotate the password. Lovable rotates the password only for the built-in backend, not for a connected Supabase project. On Enterprise plans, every rotation is recorded in your workspace audit log.

FAQ

Ask Lovable in the project chat to review your database access. Lovable reads:
  • Your RLS policies, which decide the rows each user can reach.
  • The database roles, and what each one may do.
  • How your database functions run, which decides whose permissions they use.
  • Which parts of your database your app’s API exposes.
The Policies view on its own is not a full report. The view shows the policies, not the permissions underneath them. See Who a policy applies to.For server code that has to respect a user’s policies, have it act as that user rather than with privileged access. Lovable does not offer a separate, restricted database login for server code.
Yes. Your app’s code contains your backend address and a publishable key, and anyone using your app can read them. Neither gives privileged access on its own. Your RLS policies protect your data, not the secrecy of the address, and the key works from anywhere, not only from your app.Newer apps also have a server-only admin client that uses the service role and skips your policies. Use it only in server code, and never share the service role key or other private secrets. See Who a policy applies to.

Troubleshooting

Contact support with the exact URL, the response body, and the header names, with secrets removed. A table request that works does not mean the API root accepts the same key.Do not put a service role key in browser code to work around it: that key skips every policy you have.