A Lovable app can look ready long before its data permissions are ready.
The interface works. Sign-up works. A user can create a record and see it again. That proves the happy path works. It does not prove that User A cannot read, update or delete User B’s records.
If your Lovable build uses Supabase, that boundary is where Row Level Security matters.
Supabase describes RLS as database-level authorization: policies decide which rows a request is allowed to access. For a founder, the practical question is simpler: if the wrong user changes the request, does the database still say no?
This is not a replacement for a full security review. It is the minimum access-control check I would want answered before putting real customer data behind an AI-built product.
What RLS is doing in a Lovable + Supabase app
A typical frontend needs to ask Supabase for data. That might be a profile, booking, invoice, project, message or order.
Without a trustworthy authorization boundary, hiding another user’s data in the interface is not enough. A user can still change requests outside the UI.
RLS moves the decision closer to the data. Instead of relying on a page to say “only show this user’s records,” the database can enforce the rule for every matching request.
Supabase’s current documentation explains that Data API access has two layers: grants decide whether a role can perform an operation on an object, while RLS policies decide which rows that operation can touch. Both matter.
That distinction is important because “RLS is on” is not the same as “our authorization model is correct.”
The five checks I would make before launch
1. List every table the client can reach
Do not start by asking whether the app has RLS somewhere. Start with an inventory.
For each table exposed to the client, write down:
- who should be able to read it
- who should be able to create records
- who should be able to update records
- who should be able to delete records
- whether anonymous visitors need any access
- whether managers or admins need broader access than normal users
A profiles table, for example, may need very different rules from a public plans table or a private payments table.
The access rule should come from the product, not from whatever policy happened to be generated first.
2. Check RLS and grants together
Supabase recommends enabling RLS on tables exposed through the Data API and granting each role only the operations it actually needs.
Think of the two controls differently:
- a grant answers “may this role attempt SELECT, INSERT, UPDATE or DELETE here?”
- an RLS policy answers “which rows may this request actually affect?”
If a signed-out visitor should never modify a table, do not give the anonymous role unnecessary write privileges and hope a complicated policy saves the design.
Use the smallest access surface that still lets the product work.
3. Test with two real user identities
This is the check many prototype reviews miss.
Create two test accounts: User A and User B. Give each account its own records. Then test the actions your product supports.
User A should be able to perform every legitimate action on User A’s data. Then deliberately try the same operations against User B’s record identifiers.
Test at least:
- reading another user’s record
- updating another user’s record
- deleting another user’s record
- creating a record that claims another user’s identity or ownership
- accessing a privileged manager/admin action as a normal user
The expected result is not merely “the UI doesn’t show the button.” The request itself should be rejected or return no unauthorized data.
This is why I treat authorization as a system behaviour rather than a screen behaviour.
Supabase’s current RLS guidance goes further and recommends automated allow-and-deny database tests for exposed tables. Even if you begin manually, the mindset is useful: every rule needs a positive case and a negative case.
4. Know which Supabase key is in the browser
Seeing a Supabase key in frontend code does not automatically mean you found a leaked secret.
Supabase’s current key model distinguishes publishable keys, which are designed for public components, from secret keys, which have elevated access and belong only in developer-controlled backend components.
Older projects may still use the legacy anon and service_role names. Supabase says the legacy anon key behaves like the public/publishable side of the model, while service_role bypasses RLS and must not be exposed in the browser.
So the useful audit question is not “is there any Supabase key in the frontend?”
It is:
What kind of key is this, what role does it get, and what can that role do when RLS is applied?
If a secret or service-role credential has reached client-side code or a public repository, treat that as a serious issue and rotate it rather than simply hiding the visible string later.
For related key-handling context, see Lovable Environment Variables vs Secrets.
5. Check the routes that bypass the normal user path
The most dangerous access path is often not the ordinary screen you have been clicking during development.
Review server functions, admin actions, webhooks, scheduled jobs and integrations separately. Some backend operations legitimately need elevated access. That makes the authorization decision around them more important, not less.
A payment webhook, for example, may need to update data without acting as the customer. An admin action may need access across many users. Those are different trust contexts and should not inherit browser assumptions by accident.
The same principle applies to your wider launch review: test the states the product can enter, not only the state the demo was designed to show.
A simple founder-level RLS test matrix
| Test | What should happen |
|---|---|
| Signed-out visitor requests private user data | Denied or no private rows returned |
| User A reads User A’s record | Allowed |
| User A reads User B’s private record | Denied or no unauthorized row returned |
| User A edits User B’s record | Denied |
| User A deletes User B’s record | Denied |
| Normal user calls an admin-only operation | Denied |
| Backend-only job uses elevated credentials | Allowed only inside the intended trusted backend context |
The exact matrix changes with the product. A marketplace, bookkeeping app and property platform do not have the same ownership rules.
That is the larger point: RLS should model your business rules, not just satisfy a security checkbox.
Common mistakes that make a policy look safer than it is
One mistake is testing with only one account. Everything appears correct because the only records in the database belong to the tester.
Another is confusing authentication with authorization. A valid login tells you who the user is. It does not decide which tenancy, invoice, project or document that user owns.
A third is fixing an RLS error by making the policy broader until the screen works. That can turn a useful denial into accidental over-permission.
And another is putting elevated credentials into frontend code because it makes a blocked query work. Supabase explicitly warns that secret and service-role keys bypass RLS and should never be exposed to customers.
If your AI-generated app keeps producing security or data-access surprises, use the broader AI-Built App Production Checklist rather than treating each error as an isolated bug.
Do you need to rebuild the Lovable app?
Usually, an RLS problem by itself does not mean the product needs to be thrown away.
The better question is whether the product has a coherent ownership model underneath the screens.
If you can clearly state rules such as “a tenant can read documents attached to their active tenancy, a manager can act only on assigned properties, and an owner can see everything they own,” those rules can be reviewed and implemented systematically.
If nobody can explain who owns each resource, which roles exist, or which operations each role should perform, the problem is larger than a missing policy. The product needs an authorization model before more generated code is layered on top.
That is also a good point to decide whether to continue prompting the builder yourself or prepare a developer handoff for the Lovable app.
Before real users arrive
Do not ask only, “Does the app work?”
Ask:
Does it still protect the right data when the user does something the interface never intended?
That is the difference between a convincing prototype and a product with a defensible access boundary.
For the underlying technical rules, use Supabase’s official Row Level Security documentation, Data API security guide, and API key documentation.
If you have an AI-built MVP that works but you are not confident about its permissions, payment states, deployment or production readiness, MVP development support is the natural next step.
