Canonical: https://dokima.net/insights/security-review-lovable-supabase-app/ Updated: 2026-11-04T23:30:51+00:00 [← All insights](https://dokima.net/insights/) AI-built Applications # How to security-review an app built with Lovable and Supabase A practical Lovable and Supabase security checklist: review database access rules, privileged functions, secrets and file storage before launch. AI-built Applications4 November 20267 minute read ## 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](https://docs.lovable.dev/integrations/github) 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](https://docs.lovable.dev/features/security) 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](https://supabase.com/docs/guides/database/postgres/row-level-security) 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](https://supabase.com/docs/guides/getting-started/api-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](https://dokima.net/docs/agent-setup/) 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](https://dokima.net/insights/fix-dokima-findings-with-claude-code-or-codex/). 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. Next step ## Evaluate this workflow on your own codebase. Dokima runs locally on Linux and macOS using Claude, Codex or OpenCode, with staged architecture mapping, adversarial challenge, deterministic deduplication and developer-ready HTML reports. The 21-day free trial starts on first activation and requires no payment card. [Start 21-day free trial](https://dokima.net/account/?view=register)[View sample report](https://dokima.net/sample-report/)[Browse all insights →](https://dokima.net/insights/) Try Dokima on your repositories ## Give your engineering team a repeatable AI source-review workflow. Start a full-product 21-day trial with no payment card required, or inspect the complete sample report. [Start free trial](https://dokima.net/account/?view=register)[Buy Dokima](https://dokima.net/buy/)[View sample report →](https://dokima.net/sample-report/)