The short version
A working app and a safe app look identical from the outside. You have to go looking.
01
Secret keys that end up in the browser
Your app talks to other services — payments, email, an AI API — using secret keys that prove it is you. Those keys must live on a server. When a key ends up in code that runs in the visitor's browser, every visitor has your key, and they can read it in about two keystrokes. This is not theoretical: bots exist that do nothing but scan public code for keys, and stories of overnight five-figure API bills are common. Open your live site, view the page source, and search for key, secret, token and sk-. If you find a long random string, rotate that key immediately — deleting the code is not enough, because it has already been published.
02
A database anyone can read
Modern database services start with permissive access so beginners are not blocked, on the assumption you will tighten the rules before launch. Nothing forces you to, and the AI rarely raises it unprompted. The result is a live app whose entire database — every user record, every message, every email address — can be read by anyone who knows the address, while the app itself looks completely normal.
03
Trusting whatever the browser says
If your checkout sends the price from the browser to the server, someone can change that price before it is sent. If your admin page is protected only by not being linked anywhere, it is not protected, it is unlisted. Anything the browser sends can be altered by the person using it, which means the server has to re-check everything, every time. This is one of the most common gaps in AI-built apps because the happy path works perfectly and nothing signals the hole.
04
Why the AI does not warn you
You asked for a feature and you got a feature. Security was not part of the request, and the model optimises for producing something that works rather than something that holds up against someone actively trying to break it. It will often produce genuinely good security advice — but usually only when asked directly and specifically.
05
The review worth running before launch
Start a fresh session, so a long conversation is not crowding out the files it needs to see, and ask for a security review explicitly: secrets reachable from browser code, database rules that allow public read or write, any place the server trusts a browser-supplied value, missing access control on admin pages, and unvalidated input. Ask for a severity rating and the exact change for each. Then verify the important ones yourself rather than taking the all-clear on faith.
Go deeper
This is one chapter of a much longer story
Build Your First Real App is the next step: a 120-page prompting course where you build a mini marketplace one checked feature at a time, plus the Northstar visual kit to build against.
See the course — $29.99FAQs
Quick answers
How do I check for an exposed key without knowing how to code?
On your live site, right-click and choose View Page Source, then press Ctrl+F and search for key, secret, token and sk-. Anything that looks like a long random string is worth investigating immediately.
Is it safe to take card payments in an AI-built app?
Only through a hosted checkout such as Stripe Checkout or PayPal, where the customer enters card details on the provider's page. Card numbers should never reach your own servers.
I found a key in my code. What now?
Rotate it — generate a new key and revoke the old one — before you fix the code. Once a key has been published, removing it from the page does not make it secret again.