AppInspected

Fix guides

A security checklist for apps built with AI.

Last reviewed October 16, 2026 against the providers' current documentation.

The short version

Before launch, make sure no secret key is in your browser code, every database table or collection is protected by rules, no .env or .git file is downloadable, production source maps are off, and your site is served over HTTPS. Each item below links to a step-by-step fix.

Why it matters

AI app builders are good at making things work and less careful about who else they work for. The same mistakes come up again and again: a secret key pasted into frontend code to get past an error, a database left open so a page would load, a build setting left on. None of them show up when you use your own app, but all of them are visible to anyone who looks.

Fix it, in this order

  1. No secret keys in the browser

    Anything in your frontend JavaScript is public, including values from VITE_…, NEXT_PUBLIC_… and EXPO_PUBLIC_… variables. Keys that can spend money or reach private data (Stripe secret keys, OpenAI and Anthropic keys, the Supabase service_role or secret key) belong on a server. Fix guides: Supabase service_role key, Stripe secret key, OpenAI key.

  2. Know which keys are meant to be public

    The Supabase anon or publishable key, the Firebase web config and the Stripe publishable key are designed to be in your frontend. They're only safe when the database rules behind them are right. See Is the Supabase anon key safe?

  3. Supabase: Row Level Security on every table

    Every table in the public schema needs RLS turned on, sensible grants, and a policy for each operation the app performs. See Supabase RLS disabled.

  4. Firebase: no test-mode rules

    Firestore rules that say if true, only check a date, or only check that someone is logged in leave your data open. See Firestore test mode rules.

  5. No .env or .git files on your site

    Open /.env and /.git/HEAD on your live domain in a private window. Neither should download. See .env file exposed and .git folder exposed.

  6. Production source maps off

    Public .map files hand out a readable copy of your frontend code. See Source maps exposed.

  7. HTTPS and basic security headers

    Serve the site only over HTTPS and send Strict-Transport-Security so browsers keep using it. A Content-Security-Policy limits which scripts can run, and X-Content-Type-Options: nosniff plus framing protection (frame-ancestors or X-Frame-Options) close off a few more tricks. Most hosts let you set these in their config file.

Or ask your AI tool to do it

Paste this into Lovable, Bolt, Cursor, Claude Code or whichever tool built your app. Review what it changes before you deploy.

Do a pre-launch security review of this app and report back before changing anything. 1) List every API key or secret referenced in client-side code or in VITE_, NEXT_PUBLIC_ or EXPO_PUBLIC_ variables, and say which are meant to be public (Supabase anon/publishable, Firebase web config, Stripe publishable) and which must move to the server. 2) If the app uses Supabase, list every table in the public schema with its RLS status, grants and policies. 3) If it uses Firebase, show the current Firestore and Storage rules and flag any that allow access with if true, a date check, or request.auth != null alone. 4) Check that no .env file or .git folder can end up in the deployed output, and that production source maps are off. 5) List the security headers the site sends and propose HTTPS, Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options and frame-ancestors settings for our host. Then fix the items I approve, one at a time.

How this happens

Each tool makes the same trade: get it working first. When something fails, the fastest fix is often to remove a safety check rather than add the right permission. A checklist before launch catches what those shortcuts leave behind.

Run the outside checks in 20 seconds

The free check covers the items on this list that are visible from outside: secret keys in your JavaScript, .env and .git files, source maps and security headers. It also names the Supabase or Firebase project your app uses so you know which rules to review.

Check my app free

Questions

Does this checklist apply to Lovable, Bolt, v0, Replit and Cursor apps?

Yes. The checks are about what your deployed app exposes, not which tool wrote it. Some items, like Supabase RLS or Firestore rules, apply only if your app uses that backend.

Is passing the free check the same as being secure?

No. The free check reads what any visitor's browser can see: keys in your JavaScript, .env and .git files, source maps and headers. It can't see your database rules or server code. A clean result means none of these problems were visible from outside; it isn't a full security audit.

Sources

Related guides