How to security-review an app built with Lovable and Supabase

Key takeaways

• Connect the source, database policies and server functions so the review covers the application behind the screens.
• Test with two ordinary accounts: being signed in should never grant access to another customer’s records.
• Use Lovable’s built-in scans alongside ongoing Dokima review and checks against your deployed configuration.

A Lovable app can look ready to launch while a permission rule still lets one customer read another customer’s data. The screens work, sign-in works and the right records appear in normal use. The question is what happens when someone requests a record the interface never offered them.

For an app built with Lovable and Supabase, start with three things: who can access each record, which server functions can act with extra privileges, and where credentials are used. Then follow those checks through to files, payments and background tasks.

1. Bring the whole application into the review

Use Lovable’s GitHub integration to sync the project to a private repository. Clone it into your review workspace and record the commit you intend to release. Check the sync status before reviewing; a local checkout from last week is not the current app.

Include the frontend, Supabase database migrations and policies, and Edge Functions: the server-side functions handling tasks such as payments or privileged data changes. If you manage access rules directly in the Supabase dashboard, obtain their current definitions too. A source review can assess the definitions you provide; separately compare them with the deployed database.

Write a short DOKIMA.md explaining the app’s roles and ownership rules. For example: “Each customer belongs to an organisation. Members may read their organisation’s invoices. Only administrators may invite members or change billing.” That gives the reviewer a concrete rule to check across the code.

Run Lovable’s built-in security scans and review their findings. Lovable provides database and dependency checks as well as deeper application-code review. Keep those controls in place when adding Dokima.

2. Test who can read and change each record

Supabase’s row-level security, usually shortened to RLS, controls access to individual database rows. Enabling it is the start; the policies must enforce the ownership rules your app needs. Supabase’s RLS guide explains how the policies work.

For each sensitive table, ask who may read, create, update and delete a record. Then check the answer using two test accounts in separate organisations and a signed-out session. Use a staging project with synthetic data.

Illustrative example: a customer portal stores invoices with an organisation_id. Its read policy allows any signed-in user. Alice’s screen filters to her organisation, so ordinary browsing looks correct. But changing the invoice ID in a direct request returns Bob’s invoice from another organisation.

The fix is to enforce membership at the database or trusted server boundary used by that request. A browser filter cannot enforce it. An update rule also needs to prevent Alice from moving a record into another organisation by changing its ownership field.

Check the fix by confirming that Alice can still read her own invoice, cannot read Bob’s, and cannot create or move an invoice into Bob’s organisation. Apply the same check to exports and search results.

3. Follow privileged functions and secrets

A server function can undo careful database policies if it uses elevated credentials and trusts the caller’s requested organisation or role. Trace each privileged action from its incoming request to its database operation:

• Does it verify the caller’s identity?
• Does it check that caller’s membership and permission for this action?
• Does it choose the organisation from trusted membership information?
• Can a background job or alternate endpoint reach the same operation without those checks?

Supabase distinguishes publishable and secret keys. A publishable key is intended for client use with appropriate access policies. Secret keys, and legacy service_role keys, belong on the server because they can bypass RLS. Finding a publishable key in a browser bundle is different from finding a privileged secret there.

Check the built frontend as well as source. Keep payment-provider and other private API credentials in server-side secret storage. If a real secret has reached a public bundle or repository, rotate it and investigate its use; deleting the string from the latest commit is only one part of recovery.

4. Check files, sharing and paid actions

Repeat the two-account test for storage buckets and download links. A protected database row is little help if its attachment is publicly readable. Decide which files are deliberately public, who may upload replacements, and whether a temporary sharing link still works after access is removed.

For paid features, check that a trusted server verifies payment before granting access. Browser-supplied prices, success-page visits and hidden buttons should not decide entitlement. Also check upload size limits and administrative actions; both can be easy to overlook during a successful prototype demo.

5. Keep the review connected to development

Set up Dokima on a dedicated Linux VPS, VM or user account with the repository and chosen runner. Include the policy and function definitions in the review workspace, explain the expected boundaries in DOKIMA.md, and start a full review.

For each finding, inspect its evidence, affected operation and suggested fix. Apply the change on a development branch, repeat the relevant two-account checks, then confirm the corrected policy or function actually reaches the deployed environment. Keep Dokima reviewing as Lovable adds screens, tables and server functions.

You can use Claude Code or Codex to work through Dokima findings. Finish with a short release record: reviewed commit, policy changes, checks run and the person who approved the result. That makes the next launch easier to review too.