Put security review at three points in the AI build loop: before publish, immediately after deployment, and before a sensitive workflow becomes real. That rhythm keeps the fast feedback loop while adding checks where the available evidence is strongest.
Security review does not need to mean a week-long pause after every prompt. It does need to exist as a named step. If “the page works” is the only release condition, browser-visible exposure and server-side authorization decisions are both easy to miss for different reasons.
Gate 1: use the platform checks before publishing
Start with the checks your build platform already has. Lovable, for example, documents separate analysis for RLS, database configuration, application code, and dependencies. It also says those tools support secure development but do not replace a review appropriate to the app’s risk. That is a useful division of responsibility, not a reason to dismiss native tooling.
At this gate, resolve known critical findings, inspect environment-variable changes, and ask a simple question: did this change introduce a new trust boundary? Authentication, payments, file uploads, invitations, admin actions, and cross-tenant data access deserve more than a visual smoke test.
Primary reference: Lovable’s security overview.
Gate 2: check the deployed app from the outside
A build-time check sees source and configuration. A public scan sees the artifact a visitor actually receives. The two views overlap, but they are not interchangeable.
The free scan is the low-friction entry point: submit a live URL, attest that you are authorized to scan it, and inspect the submitted page plus the assets it references. Useful evidence includes missing security headers, public source maps, development artifacts, browser-visible configuration, provider-aware credential patterns, and endpoints named in public code.
The free result should also create a useful next step. A missing header can be confirmed from the response. A privileged-looking token pattern in a bundle may need owner verification. An RLS question is marked Not tested because the free scan does not query the database. Clear unknowns are part of the product: they show where source access or approved runtime validation would add value.
Gate 3: add source and authorized validation before high-risk use
The planned Authorized source scan is the deeper automated product. It will require an account, a ZIP or read-only GitHub connection, explicit authorization, and verified control of the deployed domain. With those gates in place, it can compare source-defined routes with the live app and perform bounded checks that the public scan intentionally avoids.
That additional access matters for questions such as:
- Does every sensitive endpoint reject unauthenticated requests?
- Do ownership and tenant checks apply in the API, not only in the UI?
- Do Supabase RLS policies cover the tables and roles the app actually uses?
- Does the server recalculate prices and privileges instead of trusting client input?
- Are rate limits present on the specific operations approved for testing?
OWASP describes access control as the policy that prevents users from acting outside their intended permissions. A public bundle can reveal that an endpoint exists, but it cannot prove how the server enforces that policy. See OWASP Top 10:2025 — Broken Access Control.
Use a change-triggered review rhythm
A small app does not need ceremony for its own sake. It needs explicit triggers. This is a practical starting point; the vibe coding security checklist turns the same idea into a launch checklist.
| Change | Minimum review | Why |
|---|---|---|
| Copy or layout only | Normal functional review | No new trust boundary if data flow is unchanged. |
| New dependency or environment variable | Platform checks + deployed public-surface scan | Public bundles and deployment output may change. |
| Authentication, roles, or tenant data | Source review + approved role tests | Correctness depends on server-side enforcement. |
| Payments, exports, admin actions, recovery | Human security review of the relevant workflow | Business logic and impact need context. |
The point is not to slow every iteration equally. It is to spend review effort where a change alters who can do what, with which data, under which identity.
What this article does not establish
This is a workflow recommendation, not SafeForProd scan data. It makes no claim about how frequently AI-built apps contain a given issue. Tool capabilities also change; check the vendor documentation for the project you are using.
For a control-oriented review framework, the OWASP Application Security Verification Standard provides a requirements base that can help turn “review security” into specific checks.