Security Audit for Bolt.new Apps
Bolt.new builds and runs full-stack apps in the browser using StackBlitz WebContainers, then deploys them in a click. That speed hides an important question: which of your app's rules actually run on a server, and which only run in the visitor's browser where they can be changed.
30-minute intro call · fixed-scope quote · human review, not scanner output. Read client case studies.
What we find most often in Bolt.new apps
Bolt projects usually pair a React or Vite front end with a hosted backend such as Supabase, and deploy to a host such as Netlify. Most serious issues come from trusting the front end.
Business rules that only run in the browser
Price calculations, plan limits, and role checks written into React components can be bypassed by editing requests in the browser. Anything that decides money or access has to be enforced on the server or in database policies.
API keys bundled into the front end
Keys added through prompts or `VITE_` prefixed environment variables are compiled into the JavaScript bundle and are readable by anyone. Secret keys for AI, payment, or email providers must live behind a server function.
Database policies left open
When Bolt wires up Supabase, the browser queries the database directly. Tables without row-level security, or with permissive policies, expose every user's records to anyone holding the public key.
Serverless functions without caller checks
Netlify or Supabase functions that perform privileged work often trust a user ID sent in the request body instead of verifying the session, letting one user act as another.
Payment flows that trust the redirect
Granting paid access on a Stripe success URL, or accepting webhook events without verifying the signature, lets users unlock paid features without a completed payment.
Unreviewed dependencies
Generated projects can pull in many packages, some unnecessary or outdated. Each one runs with your app's permissions, so the dependency list deserves a review before launch.
What a Bolt.new security audit covers
A fixed-scope review of your exported project and backend configuration, delivered as a prioritized report with concrete fixes.
Checks you can run yourself
Start here before you book anything. If any of these fail or you are not sure how to check, that is the signal to get a second pair of eyes.
- Open your deployed site, view the JavaScript bundle in dev tools, and search for `sk_`, `secret`, and third-party API key prefixes.
- List every environment variable prefixed `VITE_` or `PUBLIC_` and confirm none of them is a secret.
- If you use Supabase, confirm RLS is enabled on every table and review any policy that uses `true`.
- Change a price or plan value in a request using dev tools and confirm the server rejects it.
- Confirm paid access is granted only from a verified payment webhook, not the checkout success page.
Want a scored version? Take the free vibe code security check or work through the 25-point launch checklist.