Secrets in front-end code
API keys for payment, email or AI services end up in the browser bundle, where anyone can read them.
Check: Search the code for "key", "secret" and "token". Anything sensitive must live on a server or in your platform's secret settings.
Missing authorization
The UI hides a button, but the API behind it accepts the request from anyone.
Check: Log out, or use a second account, and call the action directly. If it works, the check only exists in the UI.
Open database rules
Row-level security switched off or written as "allow all", so any visitor can read every row.
Check: Read the rules for every table. Each one should say who may read and who may write, per row.
Injection
User input concatenated into SQL, HTML or shell commands.
Check: Look for strings built with + or template literals around user input; use parameterised queries and escaped output.
Unvalidated input
Forms trust the browser: negative quantities, huge files, scripts in a name field.
Check: Validate again on the server — type, length, range — and reject what does not fit.
Slopsquatted packages
The model suggests a package that does not exist; an attacker registers that name with malware.
Check: Check every new dependency on the registry: real maintainer, real downloads, real history.
Outdated dependencies
Generated projects pin whatever version the model remembers, including vulnerable ones.
Check: Run an audit (npm audit) before launch and at least monthly after.
Personal data in logs and prompts
Customer records pasted into prompts or printed to logs and analytics.
Check: Use sample data while building; keep real records out of prompts and debug output.
Insecure defaults
CORS set to "*", debug mode on, verbose error pages in production.
Check: Search for "*" origins and debug flags; production errors should say little.
No rate limiting
Login, sign-up and contact forms can be hammered by a script.
Check: Limit attempts per IP and per account on every public form that sends email or checks a password.