Why Bolt apps leak secrets
Bolt.new gets you from idea to a running app in one session, and it wires up integrations for you. The catch is that a generated project can place an environment value where it ends up in the client bundle, which means it ships to every visitor. Anything that reaches the browser is readable, so a key that felt private in the editor can be public the moment you deploy.
A scanner that checks the live URL sees the built site, but it cannot always tell an intentionally public value from a secret that leaked into the bundle, and it never sees the repository files or commit history. ShipSafeScan reads the source directly, so it can point at the exact file and line where a secret was committed.
You get a reproducible score and a short list of what to fix. Move real secrets to server-side environment variables, keep only truly public values in client code, and re-scan to confirm the leak is closed.
Common Bolt security mistakes
Secrets bundled into client code
A value placed in a client file is compiled into the site and readable by anyone. Keep secrets in server-side environment variables, not in the bundle.
Hardcoded keys in generated files
Generated integrations sometimes inline a working key so the demo runs. Replace it with an environment variable and rotate the exposed key.
Missing .gitignore for env files
Without a proper .gitignore, local env files get committed. They remain in Git history, so rotate any credential that was pushed.
Source scan vs live-site scan
Some checks only look at your deployed site. That view misses two things that matter for a Bolt project: files that never render in the browser, and your Git history. A secret can be gone from your live app and still sit in an old commit in a public repo. ShipSafeScan reads the repository source, so it can flag those cases and point you at the exact file and line.
Bolt security: frequently asked questions
How do I check if my Bolt.new app leaked a secret?
Paste your public GitHub repository URL into ShipSafeScan. It scans the source and Git history for hardcoded and bundled secrets, masks what it finds, and reports it with a score so you can rotate and move any exposed key.
Why would a Bolt.new key be exposed in the browser?
If an environment value is placed in client-side code, the build compiles it into the site, where anyone can read it. Secrets need to stay in server-side environment variables so they never reach the browser.