Security scanning for Bolt.new apps

What a Bolt app is made of

• A Vite bundle, usually React
• Whatever backend you connected — often Supabase or Firebase
• Deployed to Netlify, Vercel or a Bolt subdomain

Everything in the browser is public

Building conversationally makes it very easy to put a key where it works rather than where it belongs. If a value reaches the browser it is published, however small the file or however minified the code.

We read the entry bundle, follow its lazily-loaded chunks, and read the source map if one is served — which hands back your original, unminified code including the comments. Fifteen credential formats are checked, from Stripe and OpenAI to Supabase service_role and GitHub tokens.

Keys that are public by design are deliberately NOT flagged. A Supabase anon key and a Firebase apiKey belong in the browser, and telling you your correct setup is a critical would waste your afternoon.

The checks that matter here

• Exposed secret / misconfigurationBundle, chunks and source maps, with fifteen credential formats.
• Database readable by anyoneBoth Supabase row-level security and Firebase rules.
• Missing security headersFast deploys usually skip these entirely.
• Reflected XSSGenerated form handling is where this shows up.

What this does not cover

• We scan the deployed site, not your source. A secret in a private repo that never reaches the browser is not something we can see.
• Anything behind a login needs credentials you supply, and the report states plainly whether the session held for the whole scan.