Skip to content

How Do I Know If My App Is Secure Enough to Launch?

7 min read

You do not need a professional penetration test to launch a beta. You need to check the five holes that catch out almost every agent-built app: exposed data, leaked secret keys, routes with no login check, users who can read each other's records, and unlimited abuse of anything that costs you money. If those five are clean, you are secure enough for your first real users. Here is how to check each one yourself.

Why an agent-built app has these gaps

An AI agent builds exactly what you ask for and nothing you didn't. You asked it to "let users save their profile," so it built the save. You did not ask "and make sure a stranger can't read everyone's profile," so it didn't. The app works perfectly in your demo, because in a demo you are the only user and you follow the happy path. Security holes only appear when someone who is not you, and not being polite, shows up. That is precisely what a beta is.

None of this means the agent did a bad job. It means the demo and the launch are two different bars, and nobody moved you from one to the other.

The five checks

Run these against your real, deployed project, not localhost.

1. Can a stranger read your database?

If you use Supabase, open the Table Editor and look for any table marked "RLS disabled." If you use Firebase, check whether your rules are still in test mode. Either one means the data is world-readable. The two-minute proof and the fix are in Can anyone read my Supabase database from the browser?.

2. Is a secret key exposed?

Open your site, open the browser network tab, and search the loaded scripts for service_role, sk_live, sk_test, and SECRET. Any hit is a real leak. Also check your GitHub repo: if you ever committed a .env file, the key is compromised even if you deleted it later. Full recovery steps are in I accidentally pushed my API keys to GitHub.

3. Does every private route check who is asking?

Find one API route that returns private data. Sign out, then call it directly with curl or by pasting the URL into a fresh browser. If you get data back while signed out, that route trusts the browser and checks nothing.

curl https://your-app.com/api/orders

A signed-out request to a private route should return a 401, not your data.

4. Can one user read another user's records?

Sign in as one test user, open a record, and note the ID in the URL or request. Then sign in as a second user and request that first ID. If the second user sees the first user's record, your backend trusts the ID the browser sends instead of checking ownership. This is the most common serious bug in agent-built apps, and it has its own walkthrough: Someone could change the user ID in my API request.

5. Can someone run up your bill?

Anything that costs money per use, an AI feature, an email sender, an SMS code, needs a limit. Try calling that endpoint ten times in a row. If nothing stops you, a bot can do it ten thousand times while you sleep.

The fix, in order

  1. Turn on Row Level Security (or real Firebase rules) for every table. Data exposure is the highest-impact hole and the easiest to miss.
  2. Rotate any leaked key and move it to server-only environment variables. A leaked key is compromised the moment it is public, so rotate first, tidy later.
  3. Add an authentication check to every private route, and an ownership check on top of it so a signed-in user still only sees their own rows.
  4. Add basic rate limiting to anything expensive or abusable, including signup.
  5. Re-run all five checks and confirm each now fails safely.

The trap to avoid

Do not treat a clean npm audit or an SSL padlock as "the app is secure." Those check the plumbing, not your actual data access. Every one of the five holes above can be wide open on an app with zero dependency warnings and a perfect green padlock. The padlock means traffic is encrypted in transit; it says nothing about whether a stranger can query your database once it arrives.

Where this fits

This list is the security core of being beta-ready. Working through it by hand is absolutely doable, and it is also exactly the kind of check that is easy to half finish, because you cannot see the hole you forgot. The free Readiness Report runs all five against your real project and tells you which are open before a stranger finds them for you. If you would rather have the fixes handed to you in priority order, that is what the Finishing Pass is for.