// GUIDE
How do I secure my AI-built app before I launch it?
Updated 2026-08-07 · 10 min read
Harden in this order: lock down the database, get every secret off the client and rotate anything exposed, move auth and payment checks to the server, secure file storage, tighten CORS and headers, update dependencies, clean git history, then re-test the whole thing as an outsider. This is a sequence, not a menu, the early steps stop the biggest leaks, so do them first. Give yourself an afternoon, not five minutes.
Before you start: what "secure enough to launch" means
You are not trying to reach the security posture of a bank. You are trying to make sure that on launch day a stranger cannot download your customers' data, spend your money, or unlock paid features for free. That bar is achievable in an afternoon for a typical AI-built app.
The steps below are ordered deliberately. If you run out of time, the work you have done still covers the biggest risks first. Have your project open in Supabase or Firebase, your payment provider dashboard (Stripe or Polar), and your hosting/deployment settings ready before you begin.
Step 1, Lock down the database
Start here because an open database is the fastest way to leak everything. In Supabase, turn on Row Level Security for every table that holds user or business data and add a policy scoping each row to its owner ("auth.uid() = user_id"); make sure no policy is "using (true)". In Firebase, replace any "allow read, write: if true" with rules that require "request.auth != null" and check ownership.
Then prove it: log out or use a second account and confirm you cannot read data that is not yours. Do not move on until this passes, everything else matters less than this.
Step 2, Get secrets off the client and rotate what leaked
Open your live site and search the loaded JavaScript for "sk_", "service_role", and "secret". Any secret key you find in the browser must be treated as compromised: rotate it (generate a new one) first, then move it to a server-side environment variable or a serverless/edge function. Only publishable keys, Stripe "pk_", Supabase "anon", are allowed to remain in the frontend.
Rotate before you refactor. A key that has shipped in a public bundle is public forever; changing where it lives does nothing until the old value is revoked.
Step 3, Move auth and permission checks to the server
Walk through your protected areas, admin pages, paid features, account settings, and ask: what actually stops an unauthorised user here? If the answer is "the button is hidden" or "the page redirects," that is a client-side check and it can be bypassed by visiting the URL directly.
Enforce every real permission on the server: in your database rules (RLS / Firebase) or inside your API routes. Keep the client-side hiding for a clean experience, but never rely on it for security. Test by trying to reach each protected URL as a logged-out user and as a basic (non-admin) user.
Step 4, Secure payments and storage
Payments: confirm your webhook verifies the provider signature before granting anything. If your Stripe or Polar webhook accepts events without checking the signing secret, anyone who finds the URL can fake a successful payment. Add signature verification and confirm the amount and currency match what you expected.
Storage: check every Supabase/Firebase bucket. Anything private (IDs, invoices, user uploads) must be in a private bucket with owner-scoped rules, served via short-lived signed URLs, not public links. Test by opening a stored file URL in an incognito window with no login.
Step 5, Tighten CORS, headers, dependencies, and git
- CORS: restrict your API to your own domain(s) instead of "Access-Control-Allow-Origin: *", especially on authenticated endpoints.
- Security headers: add HSTS, X-Content-Type-Options, and a Content-Security-Policy, most hosts (Vercel, Netlify, Firebase Hosting) let you set these in one config file.
- Dependencies: run "npm audit" (or "pnpm audit"), then update anything flagged high or critical, prioritise packages in your auth, payments, and server code.
- Git history: search history for a committed ".env", key, or service-account file. If you find one, rotate the secret first, then purge it from history and confirm ".env" is in ".gitignore".
Step 6, Re-test as an outsider, then launch
Finish by attacking your own app the way a curious stranger would. Open the network tab and use the app normally: is your database returning only your rows? Are there any secret keys in the bundle? Can you open a private file logged out? Can you reach a protected URL you should not? Can you hit the webhook with a fake event?
If all of those fail, meaning the app correctly refuses, you have cleared the bar for launch. Re-run this same test after every significant change, because AI tools can reintroduce a hole in a single "fix." Continuous monitoring exists precisely because the next deploy can undo today's work.
Security is not a one-time launch task. Every time you ask your AI tool to change a feature, it can loosen a rule again, re-test, or have something watching each deploy.
Key takeaways
- Harden in order of blast radius: database first, then secrets, auth, payments/storage, CORS/headers/dependencies/git, then re-test.
- An open database is the biggest launch risk, do not move past step 1 until you can confirm you cannot read data that is not yours.
- Rotate any secret that has appeared in the browser before doing anything else; moving it server-side does not undo the leak.
- Real permissions and payment checks must run on the server; client-side hiding is UX, not security.
- Re-test as an outsider using the browser network tab, and re-test after every change, AI tools can reopen a hole in one edit.
- "Secure enough to launch" means a stranger cannot take your data, spend your money, or unlock paid features, an afternoon of work, not a rewrite.
Frequently asked
How long does pre-launch hardening take?
For a typical small AI-built app, an afternoon. The database and payments steps take the most time; the browser-based tests take minutes. Rushing the database step is the most common mistake.
Do I need to hire a security engineer before launch?
For most indie and early-stage AI-built apps, no. The steps here cover the holes that actually get exploited. Hire an expert if you handle especially sensitive data (health, financial) or face specific compliance requirements.
What is the single most important step?
Locking down the database (Supabase RLS / Firebase rules). It is step 1 because an open database leaks every customer record, which is the worst-case launch-day outcome.
I already launched without doing this, what now?
Run the same sequence now, starting with the database and rotating any exposed secrets. If a hole was open while you had real users, closing it and rotating keys is urgent; in the worst cases you may also need to consider notifying affected users.