Security checklist for AI startups

AI-generated apps often place values wherever the app can reach them. That is dangerous when private keys end up in browser-visible code.

• No private API keys are in frontend code or browser-exposed variables.

• No Supabase service_role key, Stripe secret key, OpenAI key, or webhook secret ships to the browser.

• Public keys are understood as public, not mistaken for secrets.

• Any leaked secret has been rotated, not merely removed from the code.

Use which environment variables get exposed to the browser and public .env files and exposed secrets to review this area.

Login is not the same as authorization. The app must enforce who can read, write, edit, approve, or delete each record.

• Sign up, login, logout, and password reset work cleanly.

• A user cannot view another user's records by changing an id in a URL or request.

• Admin actions are checked on the server or database, not only hidden in the UI.

• Supabase tables with real data have RLS enabled and scoped policies.

• Invite, team, workspace, and role logic has been tested with separate accounts.

For more detail, use the authentication security checklist and Supabase RLS checklist.

Payment systems and AI APIs usually rely on private keys and webhook secrets. Those values must stay server-side, and webhook handlers must verify the sender.

• Stripe or payment secret keys are server-only.

• Webhook signatures are verified before changing subscription or account state.

• Usage limits, credits, and plan permissions are enforced server-side.

• AI provider keys are not called directly from the browser unless intentionally public and restricted.

Your public app should not expose files or paths that were useful during development but dangerous in production.

• No .env, .git, config, backup, or source map files are publicly reachable.

• HTTPS works and redirects HTTP traffic securely.

• Baseline security headers are present.

• Robots.txt and sitemap.xml expose only intentional public pages.

• Demo, debug, staging, and admin routes are removed or protected.

Run a free website security scan as the outside-in pass, then review the HTTP security headers checklist.

Security is not a one-time launch chore. Keys get added, routes change, and deploy settings drift.

• Rescan before launch and after major deploys.

• Set up alerts for downtime or public exposure if the app is live.

• Review findings after auth, database, payment, or domain changes.

• Keep a short written launch checklist so fixes are repeatable.

What security checks should an AI startup do before launch?

Before launch, an AI startup should check for exposed secrets, browser-visible API keys, public .env files, weak auth flows, missing authorization checks, open database access, unsafe payment webhook handling, risky admin routes, weak security headers, HTTPS issues, and missing monitoring. Run an external scan, then manually test user access and sensitive workflows.

Are AI-built apps less secure?

AI-built apps are not automatically insecure, but they often ship with gaps because the tool optimizes for a working demo. Common issues include secrets in the frontend, database policies that are too open, admin routes protected only by UI, and missing launch hardening.

What is the biggest security risk for an AI startup?

The biggest early risks are exposed private keys and broken authorization. A leaked service key can grant broad access immediately, and weak authorization can let one user see or change another user's data even when the UI looks correct.

Do AI startups need a security audit before launch?

Some do, especially if they handle sensitive data, regulated workflows, enterprise customers, payments, or high-risk integrations. Many early startups should scan first, fix obvious public exposure, manually test auth and data access, then decide whether a deeper audit is needed.