The security checklist before you go live
Seven checks before a stranger opens your project. Who can get in, what is in the code, what happens to input, who sees what, whether everything is encrypted, what happens when things go wrong, and what an AI in your project may read and do. None of the seven needs a specialist. Each takes half an hour and the willingness to look at your own project from the outside, as someone who does not belong there.
The list is in the order in which the checks deliver the most. The first two prevent the damage that occurs most often in AI-built projects: someone who gets in with your account or your key. The last one applies only if there is a language model in your project, and then it applies firmly.
- two-step login on every service
- no keys or passwords in the code
- every input checked before it does anything
- each person sees only their own data
- https only, default passwords gone
- backup restored, error message without details
- what the AI reads cannot control the AI
Who can get into your project and your services?
Anyone who can get into your accounts. A project that is live depends on a handful of services: the host, the database service, the registrar of your domain, your version control, perhaps a payment service and an email service. Whoever logs in to one of those accounts can redirect, empty or take over your project. So the first check is not technical. It is a list of every service with an account, and per service the question of whether someone gets in with only your password.
Turn on the second step on every service, with an app or a key and not with a text message if you can. Use a separate password per service from a password manager. Keep the recovery codes you get somewhere other than your phone, because the day you lose it is the day you need them. And check whether there are old ways in: a test account, a friend who helped for a while, a link to a tool you no longer use.
This is the check with the biggest effect and the least technology. Most projects that get taken over are taken over through an account, not through the code.
- A list of every service with an account.
- Second step on, a separate password per service, recovery codes away from your phone.
- Old access and links removed.
Is there anything in the code that does not belong there?
Keys, passwords and connection addresses with a password in them. An AI that wants to build fast likes to put such a value straight into the code, because then it works. As soon as that code is in a repository, the key is in it too, in every version, even after you have removed it. And as soon as someone else sees the code, they have access to the service the key is for.
The place where such values belong is the configuration of your host, as an environment variable, and locally a file that is not in version control. Your project reads them when it starts instead of containing them. Every host has a screen for this and every build tool documents how you refer to it.
Check it like this: ask your AI to search the code for anything that looks like a key or password, and read the list. If there is something, remove it and put it in the right place. Then ask the service for a new key, because the old one is in the history and the history forgets nothing. Then add a rule to your version control that excludes the configuration file, so it does not happen again.
- Keys in the configuration of the host, not in the code.
- Find what is there, remove it, and ask for a new key.
- Exclude the configuration file from version control.
What happens to what a visitor types in?
Everything a visitor can type, upload or put in an address is a door. Three classic holes: a form that passes its input to a database without a check, a page that shows someone else's input without making it harmless, and an upload that accepts any file. An AI that steers towards working code creates them without saying so.
The rule is that your project trusts nothing from outside. Every value is checked for what it should be (an email address, a number within a range, a text of at most so many characters) before it does anything. Everything you show from someone else's input is made harmless first. Most frameworks do that last part by default; check that this is also the case in your project and that it has not been switched off somewhere.
Test it yourself. Type something into every field that does not belong there: a piece of code, a very long text, a negative number, a file with a different extension. If your project responds neatly, with an error message and without doing anything, that is a check most prototypes do not pass.
- Trust nothing from outside; check every value before it does anything.
- What you show from someone else's input: make it harmless first.
- Test it yourself with input that does not belong there.
Does each person see only what is theirs?
A logged-in visitor may see and change their own data, not someone else's. That sounds obvious, and it is the mistake found most often in projects that were built fast. The check then sits in the screen: you see only your own list. It is not in the layer underneath, and with a different number in the address you see someone else's list. An AI builds the screen well, and sometimes not the layer underneath.
The check belongs where the data comes from: at the database, in the rules per table, or in the layer of your project that talks to the database. The article about the database describes how to review that per service.
Test it with two accounts. Create two, put something in one, and try to reach it from the other, also by changing a number in the address. If that works, this is the first thing you fix, before there is a third account.
- The check is not in the screen but in the layer underneath.
- Rules per table at the database, or in the layer that talks to it.
- Two accounts, and trying to reach each other.
Is everything encrypted, and are the default settings gone?
Everything that travels between visitor and server travels encrypted, or it does not travel. Your host arranges the certificate as soon as your domain is connected. You check that the unencrypted variant redirects to the encrypted one, and that no link in your project points to anything unencrypted. That last point also applies to the connection with your database and your other services.
Default settings are the second half. A database service with an administrator password you never changed, an admin page at a predictable address that is open to everyone, a setting that was on allow everything during the build and stayed there. Go through every service for what is on or open by default, and close what you do not use.
Also look at what your project tells about itself. An error message with the full technical details, a file with version numbers, a page that shows the structure of your database: they are small things that together make it easy for someone with bad intentions.
- Encrypted only, also to your database and your services.
- Default passwords gone, admin pages closed, build settings reverted.
- No technical details going out.
What happens when things go wrong?
Something goes wrong. Not maybe; at some point. The question is whether you notice and whether you can go back. Noticing means you get an alert when your project stops responding or when suddenly a lot happens. Most hosts have something for that, and otherwise there are simple services that request your address every few minutes. Being able to go back means a backup you have restored once and a version of your code you can return to.
Also think about what a visitor sees when things go wrong. A tidy error page without technical details, and a way to reach you. That is not security in the strict sense, but it is the moment when people decide whether they trust you.
And write down what you do when things go wrong, in five lines: where you look, whom you call, how you restore. Not because it is complicated, but because you will no longer remember when the time comes.
- Noticing: an alert when the project does not respond.
- Being able to go back: backup restored, code in version control.
- A tidy error page and five lines for yourself.
Is there an AI in your project, and what does it read?
Does your project use a language model to read texts from others, such as an email, a web page or an uploaded document, and does it then do something? Send a reply, look something up, change something? Then there is a door that the other six checks do not cover. A text can contain instructions that the model follows as if you gave them. That is called prompt injection, and it tops the OWASP list of risks for applications with language models.
The core of the defence is separation: what the AI reads may not control the AI. External text goes into the model marked, as data and not as an instruction. The model gets no more rights than it needs for its task. And every action with consequences (sending something, deleting something, paying something) first asks a person for approval. The article about prompt injection goes deeper into this.
If there is no AI in your project, this check is done. If there is, this is the check you cannot leave to the build tool, because the build tool is one itself.
- If your AI reads text from others and then does something, this applies.
- External text as data, not as an instruction; least rights; a person for consequences.
- No AI in your project: done. If there is one: read the article about prompt injection.
Sources
Checked on 5 September 2026. The seven checks are a working method and not law; the seventh relies on the OWASP list.
Further reading
Three places that connect to this.
From first prompt to tax return.
The platform opens later. Questions or comments can be sent to info@basestep.io.