Working is not the same as safe
AI coding assistants such as Cursor and Claude Code are very good at writing code that works. You describe a feature, it appears, you click around and it does what you asked. That is real progress.
But "it works" is tested by using the app the way you meant it to be used. Security problems live in the ways you did not mean: a request sent without your app's screens, a user who changes an id, a setting nobody switched back. An assistant will usually do what you asked, and it cannot know what you forgot to ask for.
The good news is that the gaps tend to fall in the same places, so you know where to look.
Where problems tend to hide
- Keys that took the shortest path. When a feature needs an API key, the quickest way to make it work is often to put the key where the code runs, which may be the browser. Check where every key ends up. Our guide to keys in your front end explains which are safe there.
- Settings loosened to fix an error. A cross-origin error, a permissions error or a blocked request is often "fixed" by allowing everything. The error goes away and so does the protection. Look for wildcard origins, open database rules and disabled checks, and tighten them.
- Development settings in production. Debug mode, detailed error pages, source maps and test accounts are helpful while building and harmful when live.
- Files that should never be served. Settings files, backups and version control folders sometimes end up in the folder your web server publishes. A verified scan checks for exposed files like these.
The check that is easiest to miss
The most serious problems we see in hand-written and AI-written apps alike are about authorisation: checking not just that someone is signed in, but that they are allowed to do this particular thing to this particular record.
A typical example: your app shows a customer their invoice at an address ending in their invoice number. The page checks they are signed in, but not that the invoice is theirs. Change the number, and they see someone else's invoice.
No outside scan can find this reliably, because it depends on what your app means by "theirs". The fix is a habit: every server-side action that reads or changes a record should check who owns it. When you ask your assistant for a feature, ask it to include that check, and ask it to show you where the check is.
Packages you did not choose
Assistants add libraries freely. Each one is code you now run, and some carry known vulnerabilities or are no longer maintained. Occasionally an assistant suggests a package name that does not exist, or that looks like a well-known one, and installing it would pull in whatever someone has published under that name.
Before adding a package, check that it is the one you expect, that it is widely used and that it is still maintained. Keep the ones you have up to date. A survey checks the JavaScript libraries your site sends to visitors for known vulnerabilities.
Habits that catch problems early
- Read the changes before you accept them, at least the parts that touch keys, permissions, database rules and anything with "allow", "public" or "disable" in it.
- Ask for a security review as its own step. A separate request such as "review this feature for authorisation and secret handling problems" catches things the original request did not.
- Test as the wrong person. Keep two test accounts and try to reach one's data from the other.
- Check from the outside after each release. A free survey needs nothing installed and looks at what your visitors' browsers receive.
- Get a second pair of eyes before it matters. If you are about to take payments or store personal data, have a person review the app. That is what our security audit is for.