Before launching an AI-built app, check the deployed public surface, then review every server-side decision that controls identity, money, or user data. A browser-visible check can find real exposure quickly. It cannot prove that private authorization, Row Level Security, or business logic is correct.
Use this checklist in three passes. The first is suitable for the free scan. The second requires the planned Authorized source scan or an equivalent owner-run review. The third benefits from a Human security review when the consequence of a mistake is material.
Pass 1: inspect what any visitor receives
Run this pass after deploying the exact build you intend to share. Only test a site you own or are authorized to assess.
Response headers
Inspect the submitted page’s response:
curl -sS -D - -o /dev/null https://example.app/Look for a deliberate Content Security Policy, HTTPS enforcement, framing controls, MIME-sniffing protection, a referrer policy, and appropriate cookie attributes. A missing header can be a Confirmed observation. It is usually a hardening gap, not proof of an exploitable vulnerability.
MDN’s Content Security Policy guide explains what CSP can restrict and how report-only mode helps test a policy before enforcement.
Public bundles and source maps
- Confirm that production bundles do not contain private server credentials.
- Check whether referenced source maps return source content you did not intend to publish.
- Remove verbose production errors, development tooling, and internal hostnames that add no user value.
- Treat public configuration by provider role, not by scary-looking variable name.
Vite documents that variables prefixed with VITE_ are bundled into client-side source and must not contain secrets. See Vite: Env Variables and Modes.
Browser-visible routes and storage
- Review endpoints named in public code, but do not call discovered routes as part of the free public-surface check.
- Check whether tokens or personal data are persisted unnecessarily in local storage, session storage, or readable cookies.
- Confirm that role checks in the UI are presentation logic only; real authorization must be server-side.
The SafeForProd coverage page lists the exact free-scan boundary and the result states used in a report.
Pass 2: review source and approved server behavior
These checks cannot be concluded from a live URL alone.
Authentication and authorization
- Inventory every route that reads or changes sensitive data.
- Enforce authentication on the server for each protected operation.
- Check ownership and tenant scope in the query or policy layer, not only in the page component.
- Test approved roles against a verified domain with strict request limits.
- Deny by default when identity, tenant, or role is missing.
OWASP defines broken access control as allowing users to act outside their intended permissions. See OWASP Top 10:2025 — Broken Access Control.
Supabase and data boundaries
- Enable RLS on exposed-schema tables.
- Review
SELECT,INSERT,UPDATE, andDELETEpolicies separately. - Check both
USINGandWITH CHECKconditions for ownership rules. - Keep service-role or secret keys on the server.
- Test only approved roles and tables; do not use a public-scan discovery to query data.
Supabase says RLS should be enabled on tables in exposed schemas and that service keys can bypass RLS. Read the Supabase RLS guide and the SafeForProd guide to Supabase anon keys versus service-role keys.
Server-side trust
- Recalculate prices, discounts, and entitlements on the server.
- Validate file type, size, ownership, and storage location.
- Protect admin actions and account recovery with fresh authorization checks.
- Keep provider secrets and privileged SDKs in server-only code.
- Apply rate controls to authentication, expensive generation, exports, and mutation endpoints.
Pass 3: review the workflows where context matters
Pattern matching is weakest when the code is syntactically valid but the rule is wrong. Ask for a Human security review when the app handles payments, regulated or sensitive data, account recovery, invitations, approvals, role changes, exports, or cross-tenant administration.
A scoped reviewer should trace the workflow end to end, identify trust boundaries, validate the highest-impact findings, and explain the fix order. The scope should name the code paths and test roles reviewed; “human reviewed” must not imply that every line or environment was assessed.
What the free scan can tell you
It can inspect the submitted page, its referenced public assets, response headers, browser-visible configuration, source exposure, and page-load signals. It can attach evidence to a missing header or public file and classify a provider-specific credential pattern.
It does not query data, verify RLS, call discovered APIs, log in, probe hidden paths, introspect GraphQL, or test rate limits. The sample report shows how those unknowns appear as Needs verification or Not tested instead of being presented as confirmed vulnerabilities.
What requires deeper access
The planned Authorized source scan will require an account, a ZIP or read-only GitHub connection, explicit authorization, and verified domain control. That access makes route comparison, source-level auth analysis, dependency review, and bounded runtime validation possible.
The Human security review adds judgment for architecture and high-risk business logic. Neither product should be described as exhaustive or as a guarantee that the app is secure.
Limitations
This checklist is a launch baseline, not a substitute for threat modeling or a scope designed for your app. Vendor features change; verify current platform documentation. A clean free result says only that the inspected public evidence did not produce a reportable signal under the current rules.
For a practical review cadence, read Where security review fits in the AI build loop.
Revision history
- 2026-07-20: Initial publication with free-scan, source-backed, and human-review boundaries.