Is My AI-Built App Secure Enough to Launch?

“Secure enough” starts with the app’s purpose and data

A public marketing site, a private customer portal and an app that holds sensitive records have different review needs. List what your product stores, who should see it and which actions can change money, access or business records. That list tells you which boundaries to check. Knowing which tool generated the first version does not answer those questions.

Keep a record of the version tested, the environment, the expected behavior and what the reviewer saw. One passing check does not show that the whole application is safe. When the code changes, decide which checks need to run again.

What Lovable’s security scans can and cannot establish

Lovable now documents Quick and Deep security scans. Its security overview describes checks for access rules, dependencies, exposed secrets, application logic and other risks. They are worth the time to run and review. Some advice says the platform’s checks only warn you about whether RLS is enabled. That advice is incomplete.

Lovable also says its scanning tools do not replace a thorough review. Treat each finding as work to investigate, fix and retest against the deployed app. A scan with no findings does not show that every customer role, integration and operating process behaves correctly. Ask what was checked and what was left out of the review.

Build a permission matrix before testing the interface

Write down the expected access for signed-out visitors, customers, staff and administrators, each on its own line. If customers belong to organizations, include the organization boundary. Specify reads and changes independently: someone allowed to view a record is not automatically allowed to edit it, export it or change its owner.

Use synthetic accounts and records in an environment you control. For each protected action, check the intended path and also a request that should be rejected. OWASP recommends checking authorization on every request and testing the logic. Ask your reviewer to trace where the server or database enforces the rule. Which controls the interface displays is not enough to go on.

Example review matrix for an app with private customer projects

Test identity: Signed-out visitor
Expected access: No private project access
Evidence to collect: Protected reads and changes are rejected

Test identity: Customer A
Expected access: Only Customer A’s permitted records
Evidence to collect: Own-data tasks work; Customer B’s private records stay inaccessible

Test identity: Customer B in another organization
Expected access: Only the permitted organization’s records
Evidence to collect: Cross-organization reads, exports and changes are rejected

Test identity: Staff user
Expected access: Only documented staff actions
Evidence to collect: Administrative actions outside that role are rejected

Test identity: Administrator
Expected access: Only the privileges the business assigned
Evidence to collect: Sensitive changes are attributable and can be reviewed

Example review matrix for an app with private customer projects
Test identity	Expected access	Evidence to collect
Signed-out visitor	No private project access	Protected reads and changes are rejected
Customer A	Only Customer A’s permitted records	Own-data tasks work; Customer B’s private records stay inaccessible
Customer B in another organization	Only the permitted organization’s records	Cross-organization reads, exports and changes are rejected
Staff user	Only documented staff actions	Administrative actions outside that role are rejected
Administrator	Only the privileges the business assigned	Sensitive changes are attributable and can be reviewed

Supabase RLS and server-side checks solve different parts

In Supabase, row-level security controls which rows an applicable database role can access. Switching it on does not tell you whether a policy expresses the correct business rule. Test the policies against how your product handles ownership and organizations, including creating, updating and deleting records, and any other route in through a view or function.

Privileged server code needs its own review. A server endpoint that uses elevated database access may bypass the row restrictions that protect ordinary user requests. It has to verify who is calling and check that they are allowed to do what they asked. Moving code to the server helps protect credentials, but it does not make every operation private.

A public API key is not always a leaked secret

Supabase distinguishes publishable client keys from privileged secret keys. A publishable key is designed for client use with the appropriate access controls. A secret or legacy service-role key belongs on servers you trust. A visible project URL or client key is not proof of a breach on its own. Find out which type of credential it is and what it permits.

If a privileged credential was exposed, deleting it from the current file is only part of the fix. Find everywhere it appeared, replace or rotate it through the provider’s process, and check that the app still works with the new one. Keep secret values out of support tickets, public repositories, screenshots and review worksheets.

An app’s access boundary extends beyond its main tables. Uploaded files, generated reports, shared links, email attachments and logs can reveal information through a different route. Decide who may upload, download and share each kind of file. Then test those paths with synthetic files, because a protected dashboard does not mean the storage behind it is protected.

If the product sells access, follow the payment state the server confirmed through to the access it grants. In the provider’s test mode, go through a successful purchase, a failed payment, a cancellation, duplicate notifications and retries. A success screen in the browser should not be what grants paid access. The review should show how the stored state ends up at the correct result.

Background jobs and AI features need boundaries too. Work out who can trigger an action, what data it can use and what happens when a provider fails. For an AI assistant, test the action it is connected to and its permissions, as well as the answer it gives. A well-worded answer does not make up for an unauthorized operation.

Make restoration and incident ownership part of launch

Confirm that your business controls the source and provider accounts, including recovery access. Write down who watches for failures and who can respond. Backups only help if the team knows what they cover and can demonstrate restoration in an isolated environment. You do not want to find out about missing access in the middle of an incident.

Keep a short release record: the version deployed, the checks you ran, the findings still open, who owns each follow-up and which users you decided may use the release. For a sensitive or high-stakes workflow, agree the review requirements with a qualified reviewer before you open access wider. A restricted pilot can limit exposure while the remaining work gets done.

What to ask an application-security reviewer to deliver

Ask for the scope before the review begins. It should name the application, environments, roles and integrations it covers, the tests the reviewer will use and the exclusions. A review of a static client bundle is a different job from one that includes the server, database policies and deployment configuration. Either one should say plainly what it did not look at.

Each finding should explain the action affected, what could happen, the evidence and the recommended fix. Give each fix an owner, and ask for the important repairs to be retested on the version you plan to release. We scope app security reviews around those decisions. If the main problem is a broken Supabase build, the rescue assessment may be the better place to start.

UpGig product interface built by Twin Designs & Tech — From our work / UpGig
UpGig handles employer records, candidate data and hiring workflows. It shows why a product’s roles and data boundaries matter as well as its screens. Using it as an example does not certify any other app, and this article does not audit it.
Read the UpGig case study

Bring evidence to the launch decision

What you want at the end is a record of the boundaries tested and the work still open. A percentage score cannot make the launch decision for you.

List the data, customer roles, organization boundaries and privileged actions.
Record the deployed version and test environment with synthetic accounts.
Run relevant platform scans and preserve the findings and exclusions.
Assign corrections and verify important repairs through a retest.
Keep an operating owner, recovery access and a tested restoration plan.

How we can help

We can handle your launch security review.

Bring us the goal and the current state. TDAT will define the scope for your launch security review, explain the responsibilities and carry out the agreed work with testing and a clear handover.

Book a free consultation

On the project call, we’ll discuss the problem, your existing tools and what TDAT should take off your hands. Then we can define the scope and next steps.

Or call (919) 289-1231

Questions before we start

Are Lovable or Bolt apps automatically insecure?

No. Assess the code you have, the data it holds and its access rules. Which builder you used does not prove the app is secure or insecure.

Is a clean Lovable scan enough to launch?

A clean scan is useful, but it does not show that every boundary specific to your application and every operating process was reviewed. Find out what the scan covers, then test the relevant roles, integrations and deployment.

Should my Supabase key be visible in the browser?

A publishable client key is designed for browser use with appropriate access controls. Privileged secret and legacy service-role keys must not be exposed in the client. Identify the key type before treating it as a finding.

Does following a security guide certify my app?

No. A guide explains what to examine. It does not connect to your app, run tests, inspect code or approve a launch. A scoped review needs evidence from the actual application and environment.

Should I rebuild if the review finds a security problem?

Not automatically. Find the boundary that is affected, decide whether a focused repair can be maintained, and retest it. A larger rebuild needs evidence that the existing structure cannot support the product you need.