How to scan your Lovable-generated app before you ship

Lovable builds full-stack apps quickly, and many of them lean on a hosted database and auth layer. That setup has one recurring danger: the difference between a public client key and a privileged server key. The client key is meant for the browser and is limited by access rules, while the privileged key bypasses those rules. If the privileged key ends up in client code or a committed file, anyone who reads your public repo can act with full access. Because the mistake lives in the source and configuration rather than the rendered page, a check of the running site will not reliably surface it.

This guide uses a source scan. ShipSafeScan reads the repository itself and runs 50 checks in four groups: hardcoded secrets, code security anti-patterns, code quality, and repo health. Its 11 secret checks detect hardcoded credentials for more than 10 providers, including AWS, GitHub, Google, Stripe, OpenAI, Anthropic, and Slack, so a privileged key that was pasted into a file is flagged with its exact location. The 21 code anti-pattern checks, split into 14 security and 7 quality, also look for injection and cross-site scripting patterns that a generated data layer can introduce.

Reading the repo matters because the risky value often sits in a file that never renders in the browser. A privileged key in a config file or an old commit is invisible on the live app yet fully readable in a public repo. The scan can point at the file and line, and because the rules are deterministic, the same commit always yields the same score. You can confirm that the client-safe key is the one exposed to the browser and that the privileged key stays on the server, then rescan to verify.

The result is a single score and a focused issue list, so you can act before the app is public. It is free, with no install and no sign-up. If a privileged key is flagged in client code, treat it as compromised: rotate it, move it to a server-side environment variable, and make sure your access rules are turned on for each table. Keep only client-safe values in the browser, then run the scan again on the new commit and confirm the finding is cleared.