How to Prompt a Secure Site (and Actually Use Your Platform's Security Checks)

You can ship a working site in an afternoon now. You can also ship a site that hands your users' email addresses to anyone who knows how to open a browser console, in the same afternoon, without ever seeing an error.

That is the uncomfortable shape of building with AI. Broken code shouts at you. Insecure code works perfectly. The page loads, the form submits, the data saves, and nothing tells you that every row in your database is readable by the entire internet. Security is the one category of bug that looks exactly like success.

The good news: most of it is preventable with a handful of sentences you say up front, plus a few checks your platform will run for you if you bother to press the button. No security background required.

Why AI writes insecure code by default

Three reasons, and none of them are the model being lazy.

You asked for the feature, not the boundary. "Let users save their favorite sites" is a complete feature request and a completely silent security request. Nothing in that sentence says only that user may read their own favorites. So the AI builds the shortest thing that satisfies your words, and the shortest thing is usually wide open.

Demo code is training data. Tutorials skip authorization on purpose so the example stays short. Millions of those examples went into the model. The average snippet on the internet is a demo, and demos are insecure by design.

It works, so nobody looks again. You test your own account, see your own data, and move on. You never test what the account you do not own can see. That test is the whole job, and it is the one nobody runs.

Security is not a feature you add later. It is a constraint you state early, or a breach you find late.

The prompts that actually change the output

Say these things. They are not magic words, they are missing requirements. Paste them in your own voice.

1. Name who is allowed to see each thing.

"Only the signed-in user who created a row may read, edit, or delete it. Nobody else, including other signed-in users. Enforce this in the database with row level security, not just in the interface."

This single sentence prevents the most common real breach in AI-built apps: data protected only by the fact that the interface does not show a link to it. Hiding a page is not protecting it.

2. Put the real check on the server.

"Check permissions on the server, at the point where the change actually happens. Assume someone will call this directly without using my pages."

Anything decided in the browser can be edited by whoever is in that browser. A disabled button is a suggestion. A server that verifies who you are before it writes is a rule.

3. Ban secrets in the frontend.

"Never put API keys, tokens, service keys, or passwords in client-side code or in the repository. Read them from server-side environment variables only, and tell me which ones I need to set."

If a key ends up in your built site, it is public. Anyone can view source. Treat any key that ever shipped to a browser as already leaked, and rotate it.

4. Validate input on both sides.

"Validate every input on the server as well as the client, with length limits and type checks. Reject anything that does not match instead of trying to clean it up."

Client validation is for helping honest users. Server validation is for everyone else.

5. Ask for admin to be a role, not a guess.

"Store roles in a separate roles table checked on the server. Do not decide admin status from a field on the user profile, from local storage, or from anything the browser can change."

A profile column called is_admin that the user can update is not a permission system, it is a promotion button.

6. Say what should never be logged or returned.

"Never log or return passwords, tokens, full email lists, or other people's personal data. Error messages shown to users should not include internal details."

7. Ask for the attack list before you ask for the code.

"Before you build this, list how someone could abuse it and what you are doing about each one."

This is the highest-value prompt in the article. You will get a short list, and you will immediately notice the two things you had not thought about. Ten seconds of reading, one class of bug avoided.

Use the security checks your platform already has

Most modern AI build platforms ship security tooling and most people never open it. Look for these four things in whatever you are using. Names differ, the ideas do not.

A security scan or review. Many platforms, including this one, can scan your backend for tables without access rules, rules that are too permissive, and exposed sensitive columns. Run it after every feature that touches data, not once at the end. Read every finding rather than skimming the count. Some findings are intentional, a public list of products for example, and you are allowed to decide that. What you are not allowed to do is not know.

A database linter. Related but narrower: it flags configuration mistakes like access rules switched off entirely. Passing the linter does not prove you are secure. Failing it almost always means you are not.

A dependency check. Your site pulls in other people's code. Ask your platform or run the package audit to list known vulnerabilities in what you installed, then update the ones flagged. Do it again whenever you add packages.

Secret storage. If your platform offers a place to store API keys as environment variables, use it for every private key, every time. Never paste a private key into a chat message, a code file, or a config file you commit.

Then ask directly. You are allowed to say:

"Review this project for security problems: who can read and write each table, where permissions are checked, whether any secrets are exposed, and what an attacker could do with a stolen account. Tell me the risks in plain language, worst first."

An honest review will come back with things to fix. That is the tool working.

The five-minute test you can run yourself

No tools, no jargon. Open your site and try to break your own rules.

1. Sign out and load a private page directly by URL. Type the address of something only you should see. If it loads, your protection was a hidden link. 2. Make a second account. Can it see, edit, or delete the first account's data anywhere? Try the obvious: change an ID in the address bar. 3. Look for keys in the page source. Open view-source or the network tab and search for key, secret, and token. Publishable or public keys are fine. Anything labeled secret or service is an emergency. 4. Submit rubbish into every form. A 5,000 character name, a script tag, an empty required field. Nothing should crash, and nothing should save. 5. Ask yourself what the worst leak would be. Whatever you just named, go check the rules on exactly that table first.

If all five pass, you are ahead of most sites in any directory, including plenty of professional ones.

Before you ship

• Every table with personal data has access rules, and the rules name the owner.
• Every write is checked on the server, not only in the interface.
• No private keys in client code or in the repository.
• Admin is a role checked on the server.
• Inputs are validated server-side with limits.
• Security scan run, findings read, decisions deliberate.
• Dependency audit run, flagged packages updated.
• A second test account cannot reach the first one's data.

The point

AI removed the excuse that security is too technical to attempt. You do not need to know how an attack works to say who is allowed to read this row, and you do not need to read a scanner's source to press run and read the output.

The makers whose sites do not end up in a breach post are not smarter. They just said the boundary out loud before they said build it, and they opened the checks the platform handed them for free.

Say it out loud on your next feature. It costs you one sentence.