Is your AI-built app safe for real customers? 9 checks

An app you built with Lovable, Bolt or Cursor feels finished the moment it does what you wanted. That is exactly the problem: security is the one part whose absence you do not notice. Everything keeps working. No error appears when everyone can reach all the data, because at that moment you are the only one logging in.

Below are nine checks you can do yourself, without a developer and without understanding the code. They are ordered by how often I see them go wrong. The first three are the ones that really matter; if you do not get through those, the other six are not yet the issue.

1. Are there keys in your browser?

Open your app, press F12, go to the Network tab and click around. Look at the headers and the contents of the requests that appear. If you see something that looks like a long key with the word service, secret, admin or private in it, you have a problem: anything the browser sends can be read by a visitor. A public key belongs there, a secret one never does.

This is the most common mistake in AI-built apps, because the fastest way to get something working is to use the powerful key. Works immediately, and then sits there for anyone to read.

2. Can user A reach user B's data?

Create a second account with a different email address. Log in with it and try to reach the first account's data: change a number in the URL, or open a detail page whose address you know. If you see something you should not, the shielding is only in the screen and not in the database.

In Supabase the mechanism meant to prevent this is called Row Level Security. It is on by default for new tables, and during the build it gets switched off just as routinely because it is in the way. What happens after that is known only to whoever switched it off.

3. Is the price calculated on the server?

If your app sells anything, this is the check that costs money when the answer is no. Find the request in the Network tab that starts the order or the payment. If the amount is in there, sent from the browser, then somebody can change that amount before it is sent. It should be the other way round: the browser sends what was ordered, the server decides what it costs.

4. Can you see who did what?

Ask yourself how you would find out that something was deleted yesterday, and by whom. If the answer is that you cannot see it, you have no audit log. That is manageable as long as things go well, and it is the difference between an unpleasant morning and an unsolvable situation the moment something goes wrong.

5. Is there a backup, and has it ever been restored?

Almost everyone has a backup because the hosting provider makes one automatically. Almost nobody has ever tried restoring one. A backup you have never tried is an assumption, not a provision. Restore one once into an empty environment and you know.

6. Can somebody submit the form a thousand times?

Every public form and every public address your app listens on is an invitation. Without a limit on the number of requests, a simple script costs you a full mailbox, a flooded database or a bill from the service you pay per request. With AI features that last one is not theory: that bill runs up fast.

7. Is your test data mixed in with your real data?

• Is there one environment for testing and real use?
• Are there still accounts in there named test, asdf or your own address with a plus in it?
• Can you try something out without a customer seeing it?

Three wrong answers means you only dare work outside office hours. That is not a security hole in itself, but it leads to one: whoever is afraid to touch anything leaves updates undone.

8. Do you know what happens to personal data?

Where does your database physically sit, which external services get to see your users' data, and do you have anything on paper with those parties? For most small apps this is sorted faster than feared, hosting in the EU and a processing agreement with two or three suppliers, but it rarely happens by itself, and an AI tool does not ask.

9. Can you get back to yesterday's version?

If this afternoon's change breaks something, how are you back to how it was this morning within ten minutes? If you cannot answer that, there is no real version control, only a list of prompts. This is the point at which building on gets slower than starting over, and it is fixable in an afternoon.

Security is the only part of your app whose absence does not produce an error. Which is why you only find it when you go looking for it explicitly.

And if some checks do not pass?

That is no reason to throw away what you have. What you built is a working answer to the question of what you actually wanted, and that is the part most projects fail on. Every one of the nine points above can be solved without the app having to look any different than it looks.

The order I tackle them in myself: keys out of the browser first, then permissions on the database, then amounts to the server. Those three together are usually a matter of days and take away the biggest risk. The rest can follow, at the pace your growth calls for.