Is your AI-written app safe to put online?

You have built something, it works, and real people are about to use it. Here are seven checks in the order things actually go wrong, each testable in minutes — and the point where you should stop and pay somebody.

This is the pre-launch version. The measured research behind why these specific things fail is a separate article, and the definitions are over here.

1. Who can actually read the data?

The most common failure by a distance, and the one with a CVE attached to it.

Your screen shows each user their own records. That proves nothing, because the screen is not what enforces it — the database is. If nobody wrote the rule, anyone who asks the database directly gets everything.

The test: make a second account. Log in as that second user. Now try to reach the first user's data two ways — by changing an id in the address bar, and by querying the database directly with the public key your app ships to the browser. If either gives you data that is not yours, you do not have access rules. You have a user interface that hides things.

In Supabase this is row-level security, and it is off until you turn it on. Other databases call it something else and behave the same way. The prompt I use for this check is on what can a stranger read.

2. What can the browser see?

Everything the browser downloads is public. All of it — your scripts, your configuration, any key inside them.

The test: open your site, open the developer tools, and search the downloaded code for anything resembling a secret. Then check your environment variable names: most frameworks only expose variables carrying a particular prefix to the browser, and putting a private key behind that prefix publishes it.

If you find one, rotating the key is not optional. Assume anything that was in there has already been read by somebody.

3. What happens to what people type?

User input ends up somewhere — a page, a query, a log, an email. If it arrives unchanged, someone can type something that changes what that instruction does.

The test: put ' and " and a script tag into every field you have, submit, and look at where it comes out. You want to see it displayed as literal text. If a bracket disappears, or something executes, or a page breaks in an interesting way, you have found it.

This is the category that performs worst in testing: cross-site scripting passed roughly 15% of the time in the Veracode measurements, which is not a near miss.

4. Can a stranger destroy something?

Reading is the famous risk. Writing and deleting are the expensive ones.

The test: as your second, ordinary user, try to delete or modify something belonging to the first user. Then try it without being logged in at all. Any endpoint that changes data has to check who is asking — and "the button is only shown to the owner" is not a check, it is decoration.

5. What do your errors give away?

Error pages in development are chatty on purpose: file paths, query fragments, library versions. In production that is a map.

The test: deliberately break something — a malformed id, a missing parameter — and read what comes back. A visitor should learn that something went wrong. They should not learn your stack trace.

6. Can you undo a bad day?

Not a security question, but it belongs here because it decides how bad every other item gets.

• Is everything in GitHub, with the working version tagged?
• Does your database have backups, and have you ever actually restored one?
• Can you roll back a deployment in one action?

An untested backup is a belief, not a backup.

7. Would you even notice?

The quiet one. Most small projects have no idea anything is wrong until a person complains, and most people do not complain — they leave.

The minimum worth having: an alert to yourself when a payment succeeds but delivery fails, and some visibility of errors. It does not need to be sophisticated. It needs to exist, because the alternative is finding out from an angry email a week later, and I speak from experience on that one.

The whole thing, in order

Under an hour and a half, once. Most of it stays done.

When should you stop and pay somebody?

Three situations, and none of them is about how big the project is:

• You hold data that would hurt someone if it leaked. Health, finance, anything about children, anything private.
• You handle card details directly instead of sending people to a hosted checkout. If you use Stripe Checkout, card data never touches your code, which is the entire reason to use it.
• The business depends on it. Not a side project — the thing that pays you.

In any of those, a review by someone who does this for a living costs less than the incident. The honest comparison is not "a review versus free". It is "a review versus the week you spend on a breach, plus the email you have to send your customers".

What about the code itself?

Worth saying plainly, because it is the question behind the question: AI-written code is not uniquely doomed. It fails differently. It tends to be syntactically clean, internally consistent and plausible-looking, with the security consideration simply absent — because nothing asked for it.

Human code fails too. The difference is that a human usually knows which corners they cut. An agent does not report the corner, because from where it sits there was no corner: you asked for a working feature and you got one.

Which points at the cheapest fix available. Ask for it. A standing instruction — when a change touches user input, output, logging, queries, money or login, state the security requirement first and then meet it — changes what comes back. That is one line in a file the agent reads every session: how to brief an agent once.