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.