Before a Bolt.new app goes live, check ten things: exposed keys, sign-in, data isolation between users, database rules, open routes, server-side validation, webhooks, dependencies, production settings, and payment flows. This Bolt.new security checklist explains each one in plain English, how to verify it, how to fix it, and whether it should block your launch.
Bolt gets you from prompt to working product remarkably fast, and that is worth a lot. But a working preview proves the features run, not that the production deployment is safe for strangers.
What Changes When Your Bolt.new App Goes Public?
While you build, you’re the only user, clicking buttons in the order you designed. Nearly every app looks secure under those conditions.
After launch, three things change:
- More than one person is signed in. Every query must answer “whose is this?”, or one customer sees another’s data.
- People skip your interface. Anyone can open browser devtools, read your JavaScript, and call your database or API directly with whatever values they like.
- Keys and bills are real. Live Stripe keys, paid AI API credits, and real email addresses move a bug from awkward to costly.
Bolt projects also differ: Bolt’s docs describe a built-in Bolt Database or a Supabase connection on paid plans, and Bolt hosting by default or Netlify instead. Run each check against your stack.
10 Security Checks Before Launching Your Bolt.new App
1. Check API keys and environment variables for client-side exposure
Risk: Bolt apps are usually Vite projects, and Vite deliberately ships any variable prefixed VITE_ to the browser. A public database URL or anon key belongs there. An OpenAI key or a Stripe secret key does not, and anyone who opens your site can copy it.
Verify: Open your live site, then search the loaded JavaScript in devtools (Sources tab) for sk_, secret, and service_role. Then review every VITE_ variable in the project.
Fix: Store secrets in Bolt’s Secrets settings (or Supabase Edge Function secrets) and call the provider from a server function, never the browser. Rotate any key that ever reached the client.
Blocks launch: Yes, whenever a secret key is visible in the browser.
2. Verify authentication and session handling
Risk: A login screen is not the same as protected data. Generated apps sometimes hide pages in the UI while the data behind them stays reachable.
Verify: Sign out and paste the URLs of signed-in pages into a fresh private window. Test sign-up with an unconfirmed email, request a password reset twice, and check that signing out actually ends the session.
Fix: Use your auth provider’s documented flows instead of custom code, and protect data at the database or server, not only in the router.
Blocks launch: Yes, if signed-out visitors can reach signed-in data.
3. Test authorization and user-to-user data isolation
Risk: This is one of the most common serious problems in AI-built apps: user A, signed in legitimately, can read or edit user B’s records by changing an ID.
Verify: Create two test accounts with different data. As account A, use the Network tab to find a request containing a record ID, replay it with an ID belonging to B, and see what comes back. Try updates and deletes too.
Fix: Enforce ownership where the data lives: row-level rules tied to the signed-in user, or a server-side ownership check before every query. Hiding a button doesn’t count.
Blocks launch: Always, for any app holding personal or business data.
4. Check database security and storage permissions
Risk: A table with permissive or missing access rules can be read by anyone holding your public key, which is in the browser by design. Storage buckets have the same problem.
Verify: Bolt’s project security audit runs from the Publish menu on paid plans, and a lighter database security check is available on all plans. Run one, then confirm manually: on Supabase, check every table has row-level security enabled with sensible policies, and that private buckets aren’t public.
Fix: Default to deny, then grant each table and bucket the narrowest access it needs. Note Bolt’s caveat that restoring an earlier version from history also removes security fixes, so rerun the check after any rollback.
Blocks launch: Yes, for any table or bucket holding user data that an anonymous client can read.
5. Review exposed APIs and admin routes
Risk: An /admin page or a “reset demo data” function built during testing is often still live, and hidden is not protected.
Verify: List every page route and server function in the project. Signed out, and then as a normal user, visit each admin page and call each function directly.
Fix: Delete what you no longer need. For the rest, check the caller’s role on the server, and store roles where users can’t edit their own.
Blocks launch: Yes, if a normal user or visitor can trigger an admin action.
6. Validate inputs on the server
Risk: Form validation in React stops honest mistakes, not deliberate ones. Requests sent straight to your API skip it entirely.
Verify: Replay a form submission from devtools with an empty required field, a 10,000-character string, a negative number, and a <script> tag. Upload a file with the wrong type.
Fix: Validate every input in the server function or database constraint with a schema library such as Zod, and check file type and size on the server.
Blocks launch: Yes, when bad input can change prices, permissions, or other users’ content.
7. Review third-party services and webhook signatures
Risk: Webhooks are public URLs. If your app trusts any request that says “payment succeeded” without checking it came from the provider, anyone can mark an order paid.
Verify: Bolt’s docs say its Stripe integration creates server-side edge functions and verifies webhook signatures for you. Confirm that’s still true in your code, since later prompts can rewrite it, and check any integration you added by hand. Stripe’s guide to verifying webhook signatures shows what correct looks like.
Fix: Reject unsigned or badly signed webhook requests, use separate keys for test and live, and limit each integration key to the permissions it needs.
Blocks launch: Yes, for unverified payment or account webhooks.
8. Scan dependencies for known vulnerabilities
Risk: Your app ships with dozens of npm packages chosen during generation, some with published vulnerabilities.
Verify: Export or sync the project, run npm audit --omit=dev, and read package.json for anything unfamiliar.
Fix: Update packages with critical or high advisories and remove unused ones.
Blocks launch: Yes, for critical advisories in code your app runs.
9. Confirm production hosting, HTTPS, CORS, logging, and error settings
Risk: Settings that are harmless in preview get risky in production: detailed error messages that reveal table names, CORS open to every site, or logs recording tokens and personal data.
Verify: On the live domain, confirm HTTPS works and HTTP redirects to it. Trigger an error and read what users see. Check CORS settings and skim logs for sensitive values. If you moved to Netlify or another host, confirm your secrets exist there.
Fix: Show users generic errors and keep the detail in logs, allow only your own origins, and scrub secrets from log output.
Blocks launch: Yes, if errors or logs expose secrets or personal data. Otherwise, fix it in the first week.
10. Test payments, account deletion, and other sensitive workflows
Risk: The flows that matter most get the least testing: cancelled subscriptions that keep access, and “delete my account” buttons that leave data behind.
Verify: In Stripe test mode, run a full lifecycle: subscribe, upgrade, fail a payment, cancel, refund. Delete a test account and check the database and storage for leftovers. Then switch to live keys and make one small real purchase.
Fix: Grant access from verified webhook events rather than from the success page redirect, and make deletion remove or anonymise data in every table and bucket.
Blocks launch: Yes, for anything involving money or deletion promised in your privacy policy.
Five Warning Signs Your Bolt.new App Needs an Independent Review
- You’ve rolled back to an earlier version since your last security check. Rollbacks can undo fixes without telling you.
- You connected Supabase, Stripe, or another service partway through. Late integrations bring keys and rules the original design never accounted for.
- You have roles. Admins, team owners, or paid tiers multiply “who can do what” past what manual clicking covers.
- A business customer has sent you a security questionnaire. They want evidence from someone other than you.
- You can’t explain where each secret lives. If you can’t say which keys are in the browser, which are server-side, and which are live, nobody has checked.
These match the common risks in AI-built apps whichever tool wrote the code. Building elsewhere too? See our Lovable app security checklist and Cursor app security checklist.
Bolt.new Security Checklist: Quick Pass/Fail Table
| Check | Pass Criteria | Fix Before Launch |
|---|---|---|
| API keys | No secret keys in browser JavaScript | Move to server secrets; rotate exposed keys |
| Authentication | Signed-out users reach no private pages or data | Protect data server-side, not just routes |
| Data isolation | User A can’t read or edit user B’s records | Enforce ownership in database rules or server code |
| Database and storage | No user data readable by anonymous clients | Enable row-level rules; make private buckets private |
| APIs and admin | Admin actions check role on the server | Delete test endpoints; add role checks |
| Input validation | Server rejects malformed requests | Add schema validation to every function |
| Webhooks | Unsigned requests are rejected | Verify signatures; separate test and live keys |
| Dependencies | No critical advisories in runtime packages | Update or remove affected packages |
| Production settings | HTTPS, restricted CORS, generic errors, clean logs | Tighten configuration on the live host |
| Sensitive workflows | Payments and deletion behave correctly end to end | Drive access from webhooks; complete deletion |
How LaunchSure Helps Review AI-Built Apps
Bolt’s built-in audit is a sensible first pass before every publish. What it can’t provide is an independent opinion you can show someone else.
LaunchSure reviews your app against the published LaunchSure security standards. Every tier starts with automated checks: secret and dependency scanning, exposed endpoint and auth checks, and an OWASP Top 10 scan. Higher tiers add a hands-on review by a security engineer covering business logic and access control.
You get findings in plain language, rated by severity, each with a concrete fix. See a sample security report for the format. Apps that pass receive a dated credential that customers can verify for themselves. It attests that the app passed our checks on that date; it isn’t a guarantee that the app is free of vulnerabilities. When you’re ready, check your AI-built app with LaunchSure.
Frequently Asked Questions
Is Bolt.new secure for production?
Bolt.new can build production apps and includes security tooling such as its project audit. Whether your app is secure depends on its configuration: database rules, where secrets live, and how payments and roles were wired. Verify the app itself.
Can I launch a SaaS app built with Bolt.new?
Yes, provided you verify it first. Before taking payments, work through checks 1, 3, 4, 7, and 10 above at minimum, since multi-tenant data isolation and payment webhooks are where SaaS apps most often fail.
How do I check whether my Bolt.new app exposes API keys?
Open your live site, then search the loaded JavaScript in devtools for sk_, secret, and service_role, and review every VITE_ variable in the project. Anything secret that turns up should move to Bolt’s Secrets settings and be rotated with the provider.
Do AI-built apps need independent security audits?
A prototype with no real data doesn’t. Once you handle payments, personal data, or business customers, an independent review catches what your own testing misses and gives customers evidence they can check.
Before You Go Live
Bolt got you to a working product quickly. An afternoon on this checklist gets you to a launch you can stand behind. Want a second set of eyes before real users arrive? Request a LaunchSure check.
Want proof your app is safe to ship?
Check my app