An app built with Lovable, Bolt.new, Cursor, Claude Code, Replit or v0 can look finished and still be open. The tools write code that works; they rarely say what they left unprotected. The same handful of problems account for most of what a scan finds.
The five things to check
| Check | What goes wrong | How you would see it |
|---|---|---|
| Database rules | Supabase tables without Row Level Security, or Firebase rules that allow reads without signing in | Anyone with your public key can read the data |
| Keys in the front end | An OpenAI, Anthropic, Stripe or AWS secret key pasted into code that ships to the browser | The key is in your JavaScript bundle |
| Public files | .env, .git, backups or source maps left on the server | A request for the file returns it |
| Access control | One signed-in user can open another user’s records by changing an ID | Swapping /orders/41 for /orders/42 shows someone else’s order |
| Security headers | No Content-Security-Policy, HSTS or frame protection | Missing from the response headers |
Check them from the outside
A black-box scan tests exactly what an attacker can see, with no access to your code. Paste your URL into SecScan for a graded report. It tests the five areas above, says which tests ran and which it skipped, and writes a fix prompt you can paste back into the tool you built the app with.
Two of these need your account to test properly. Active tests (injection, access control) run only on a domain you have verified you own, and the access-control test needs two ordinary accounts so it can compare what each one can read.
Related guides
- Supabase Row Level Security exposure
- API keys exposed in JavaScript
- Firebase security rules left open
- Exposed .env files and source maps
Last reviewed 2026-09-26