What should you check before launching an AI-built app?
Check that production secrets stay server-side, browser security headers are present, session cookies are hardened, all resources use HTTPS, source maps are controlled, and every data operation enforces authorization. Then test authenticated business logic separately because a public-surface scan cannot cover it.
Remove server secrets from client code
A browser bundle is public. Move production secret keys, service-role tokens, database credentials, and privileged operations to a server-only environment. Rotate any credential that has already shipped.
Verify: Search the production HTML and first-party JavaScript, then confirm only documented public client identifiers remain.
Set a Content Security Policy
Start with default-src 'self', block object embedding, restrict framing, and allow only the script, style, image, font, and connection origins the application actually needs.
Verify: Inspect the production response header and test sign-in, checkout, analytics, uploads, and embedded media without adding wildcard sources.
Harden session cookies
Use Secure on HTTPS, HttpOnly for server-managed sessions, and an explicit SameSite policy. Keep session lifetime and domain scope as narrow as the product permits.
Verify: Inspect every Set-Cookie response in production and verify sign-in and sign-out behavior across supported browsers.
Prevent insecure transport
Serve the application over HTTPS, enable HSTS after every required subdomain supports HTTPS, and remove HTTP resources and form actions from secure pages.
Verify: Check the final response after redirects and review the browser network panel for mixed-content warnings.
Disable public production source maps
Do not publish source maps with customer-facing bundles unless their exposure is intentional. Upload maps privately to the error-monitoring provider when readable traces are required.
Verify: Inspect deployed JavaScript for sourceMappingURL comments and confirm map URLs are unavailable to anonymous visitors.
Keep privileged data access on the server
Supabase anon keys and Firebase client configuration are designed to be public. Security depends on row-level rules, authorization checks, and server-side use of privileged credentials.
Verify: Test authorization as an anonymous user and as two different accounts. Confirm each user can access only the records and operations intended for that role.
What this checklist does not replace
A public-surface review cannot validate access control, payment logic, dependency vulnerabilities, cloud permissions, database rules, or private APIs. Products handling sensitive or regulated data should add threat modeling, dependency review, authenticated testing, infrastructure review, and professional security assessment as appropriate.