A security checklist for your AI-built app.

When an app built with an AI tool gets broken into, the story is usually a dull one. Nobody wrote a clever attack. A private page answered anyone who asked for it, or a password for a paid service sat in a place the public could read, and a stranger walked through. That is good news for a founder who cannot code, because open doors can be listed and each one can be checked.

A common response is to paste a long security prompt into the builder, full of terms copied from somewhere else, and trust the reply that says everything is now secure. The tool may well have changed something. The trouble is that you cannot check what you cannot name, so you have no way to tell a real repair from a confident sentence. This page gives you names in plain words, and a test for each, so the answer no longer rests on trust.

Six things matter most, and the rest of the page takes them in order. Each user reaches only their own data. Sign-in comes from a trusted service. The keys your app uses to pay for other services stay out of the code. Admin pages open for you and nobody else. Wrong password guesses are limited. The ready-made parts your app is built from are kept up to date.

Use the table as your working list. Read across each row, run the check with accounts and an app that belong to you, and write down what happened. The last column is a guide for an app that already has real users. If yours holds only test data, every row can wait until before launch, and none of them can wait until after it.

Sign-in should come from a service whose whole job is sign-in. Storing passwords safely, sending reset emails and remembering who is signed in are each easy to get slightly wrong, and a slight mistake here hands over accounts. Hosted platforms such as Supabase include a sign-in service, and there are others that do only this. Ask your builder a direct question: which service handles sign-in in this app, and does the app store any passwords itself? If the answer is that the app keeps its own password table, plan to replace it with a trusted service.

Admin pages need a lock that holds when somebody types the address directly. A link that is missing from the menu keeps honest users away and stops nobody who is curious. Copy the address of your admin page, open a private window and paste it while signed out. Then make an ordinary account and paste it again. Both attempts should end at a sign-in screen or a refusal. If either one shows the admin page, close this door before the others on the list.

Password guessing is done by programs that try thousands of common passwords against a sign-in form. The defence is a limit: after a handful of wrong attempts the app makes the person wait, or locks the account for a while. Trusted sign-in services commonly include this, which is one more reason to use one. To see whether yours has it, enter a wrong password on your own account many times in a row. An app that lets you carry on at full speed has no limit.

An API key is the password your app uses to reach a service you pay for, such as an AI model, an email sender or a payment provider. Whoever holds the key can use the service as you. A stranger who finds one spends your money, and with some services can also read the data held there. Keys belong in the settings area your host provides for secrets, which stays private. They should never be typed into the code itself, because code gets copied, shared and sometimes published.

Here is the step people skip. The place your code is stored, GitHub for example, keeps every earlier version of every file. That history is what lets you go back to last week's working copy. It also means that a key removed from today's code is still sitting in an older version, readable by anyone who can see the project. Deleting a leaked key from the code is not enough.

The repair has two parts and happens outside the code. Go to the service that gave you the key and issue a new one. Then turn the old one off in the same place, so it stops working everywhere at once. Put the new key in your host's secret settings and confirm the app still runs. While you are signed in to that service, look at recent usage and billing for activity you do not recognise.

A checklist passed in the spring says little about the app you have in the autumn. Each new feature adds pages and data, and the builder that left a door open the first time can leave the same one open on the new page. Repeat the two-account check every time something new is added, on the new screens in particular. Ask for the audit again after a large change, and whenever a key has been shared with someone who has since left the project.

Get help when the checks show that real customers' data or money was within reach, when a repair to one door keeps breaking a screen somewhere else, or when the audit lists problems you cannot follow even in plain words. The same goes for an app that handles health, payment or children's information, where a miss costs more. If you believe someone has already used an open door, replace the keys first, keep the logs your host and services hold, and ask for advice on what you are required to tell your users. This page is not legal advice.

Our Diagnostic is a fixed-price written plan. We read the code, its history and the accounts it depends on, list which doors are open and who could reach what, and set out the repairs in order, with the fee credited to the build if you go ahead with us. The work is done in your accounts, and your repo and accounts stay yours.