Security Checklist Before You Launch an AI-Built App

Speed is the point of building with AI. But the same speed that gets a product live in a weekend also gets secrets into public repositories and databases onto the open internet. Security researchers and founders keep finding the same handful of mistakes in AI-built apps. The fixes are not hard; they just are not automatic.

This is a plain-language checklist for founders who are not security engineers. It does not replace a professional audit for apps that handle money or sensitive data, but it closes the most common holes.

1–3. Secrets and API keys

1. No secret keys in frontend code. Anything shipped to the browser is public. Search your built JavaScript for strings like sk_, secret, service_role and api_key. Secret keys go into a server or serverless function and are read from environment variables.
2. No secrets in Git. Add .env to .gitignore before your first commit. GitHub's free secret scanning and push protection help catch mistakes in public repositories.
3. Rotate anything that leaked. If a key was ever committed or shipped, revoke it and create a new one. Removing it from the latest commit does not remove it from history.

4–5. Database access rules

4. Turn on access rules for every table. Hosted databases such as Supabase and Firebase are designed to be called from the browser with a public key; the protection is in the rules. In Supabase that means enabling row level security on each table and writing policies; in Firebase it means security rules that are not set to allow everything.
5. Test as a stranger. Open your app in a private window, sign up as a new user and try to read or change another user's data by changing an ID in a request. If it works, your rules are wrong.

6–8. Authentication and admin

6. Check permissions on the server, not only in the UI. Hiding an admin button is not protection. Every request that changes data must verify who is asking.
7. No secret admin URLs. An unlinked /admin page is found quickly. Put it behind real login and role checks.
8. Use a proven auth provider instead of a hand-rolled password system. Most hosted databases and frameworks include one for free.

9–10. Forms, uploads and payments

9. Treat every input as hostile. Validate on the server, limit sizes and file types for uploads, and add basic spam protection and rate limits to public forms.
10. Let the payment provider handle cards. Use hosted checkout pages and verify payment webhooks with their signature. Never decide that an order is paid based only on what the browser says.

11–12. Updates and backups

11. Keep dependencies updated. Turn on free automated dependency alerts and update regularly; AI assistants sometimes suggest outdated packages.
12. Have a backup and a way back. Know how to restore your database and roll back to the previous deploy. Test it once before you need it.

Make the AI review its own work

AI assistants are good reviewers when asked directly. After each feature, ask: "Review this change for security problems: exposed secrets, missing authorization checks, unsafe input handling, and database access rules. List concrete issues with file and line." Then verify each issue yourself. Asking for security up front ("store the key server-side, enable access rules") prevents most problems in the first place.

The launch security checklist

• No secret keys in frontend code or Git history
• Leaked keys rotated
• Access rules enabled and tested on every table
• Permissions checked on the server for every write
• Admin area behind real authentication
• Server-side validation, upload limits and form spam protection
• Hosted checkout and verified payment webhooks
• Dependency alerts on, backup and rollback tested

In the Ship Index Grow program, week three covers building with AI and deploying safely on your own domain. Read the full path in how to build and launch a product with AI in six weeks.

Questions people ask

Is code written by AI insecure?

Not by definition, but AI assistants optimize for code that runs, and they often take shortcuts such as putting keys in the frontend or skipping access rules unless you ask. Review security explicitly, as you would with any fast junior developer.

Where should API keys go in a web app?

Secret keys belong on a server, in a serverless function or in your hosting provider's secret settings, never in frontend code or a public repository. Only keys designed to be public, such as a publishable or anon key protected by database rules, may appear in the browser.

What is row level security?

Row level security (RLS) is a database feature, used by Supabase and PostgreSQL, that decides which rows each user may read or change. Without it, anyone who has your public database key can often read or modify all data.

What should I do if I leaked an API key?

Revoke or rotate the key immediately in the provider's dashboard, then remove it from the code. Deleting the commit is not enough, because the key stays in Git history and may already be copied.