Mental model 1: the browser is public
Everything your app sends to a visitor's browser can be read by that visitor. That includes the code, the settings, and any keys placed in it. Hiding a button, a menu or a page does not protect anything, because a determined person can skip the interface and talk to the app's back end directly.
Think of the browser as a shop window. Whatever is in the window, everyone sees. Anything valuable belongs behind the counter.
Mental model 2: the server decides
The part of your app that runs on a computer you control, the server or the database rules, is the only place where a security decision is trustworthy. The interface can ask for something. The server must decide whether the person is allowed to have it.
A simple example: a shopping page sends the price to be charged. If the server simply trusts that number, anyone can change it to one rupee or one dollar. The server should work out the price itself from its own list.
Mental model 3: keys are passwords
A key lets one system act on another: charge cards, send emails, read the database. Some keys are meant to be public, like the publishable key from a payment provider. Others are secret, and anyone holding them can act as you.
A rough rule: if the provider's documentation says never expose it, it must never be in the browser. If a secret key was ever shown in the browser or pasted into a public repository, do not just delete it. Create a new one, switch your app over, and revoke the old one.
Mental model 4: logins are checked every time
Signing in once does not settle things. Every request that asks for private data must also check whose data it is. A common mistake is confirming that someone is logged in without confirming that the record they asked for is theirs. That is how one customer ends up viewing another customer's order by changing a number in the address bar.
What to ask your AI tool
You cannot review the code, but you can make the tool explain its own work. These prompts help, though answers are a starting point, not proof. Verify with the tests in the next section.
- List every database table and tell me which ones have access rules turned on, and what each rule allows.
- Show me every place a secret key or password appears, and whether any of it is sent to the browser.
- For each page or endpoint that shows private data, explain how the server checks that the record belongs to the logged-in user.
- Which storage buckets are public, and what files are in them?
- List every package you added and why. Flag any that are unmaintained.
- Remove test accounts, test routes and debug output before deployment, and tell me what you removed.
What to test with no coding
Only test your own app. These checks need nothing but a browser and two email addresses.
- 1Open the app in a private window without signing in. Try to reach pages that should be private. You should be sent to a sign-in screen.
- 2Create two ordinary accounts, A and B. As A, create something private such as a note or an order. Sign in as B and confirm you cannot see it anywhere.
- 3As B, copy the address of a page that shows A's item, if you can find one, and open it. You should see an error, not the item.
- 4Upload a private file as A. Copy its link, open it in a private window while signed out. If it opens, the storage is public.
- 5Open your live app, right-click, view the page source and search for the words secret, key and password. Any real secret you find is an emergency.
- 6Cause an error on purpose, such as entering odd text in a form. The error page should say something generic, not show technical details.
When to hire a reviewer
Bring in a qualified person when any of these is true: you take payments directly, you store health, financial or identity data, customers are businesses that will ask about your security, you handle children's information, or you failed one of the tests above and do not understand the fix.
A focused review of access rules, secrets and file storage is a smaller job than a full audit, and it is where most of the value lies. Ask the reviewer to look at those three things first and to explain findings in plain language you can act on.
If your app deals with personal data, also speak to a lawyer about your obligations in the countries where your users live. Security review and legal review are different jobs.
A habit worth keeping
Every time the AI adds a feature that touches data, repeat the two-account test. New features are where old protections quietly get bypassed, and it takes five minutes. Making that a routine does more for you than any single audit.
Frequently asked questions
Can I make a secure app without knowing how to code?
You can make a reasonably safe simple app by choosing managed login and payment services, keeping secrets out of the browser and testing with two accounts. You cannot verify everything without code review, so bring in a reviewer once real money or sensitive data is involved.
What is the first thing to check in an AI-built app?
Check that private data is protected from other users. Create two accounts, add private data to one, and confirm the other cannot see it through the app or by changing addresses. This catches the most common serious failure, missing access control.
How do I know if a key is safe to expose?
Read the provider's documentation. Keys labeled publishable or public, such as a payment provider's publishable key, are designed for browsers. Anything called secret, service or private must stay on a server. If the docs are unclear, treat the key as secret.