Bolt.new Security Guide: 7 Vulnerabilities to Fix Before Launch

Quick answer: Review a Bolt.new app’s secret handling, database permissions, and server-side access controls before launch. For a Supabase backend, test the applicable roles and policies. SimplyScan checks selected public exposures; application-specific authorization also needs source review and tests with the intended users.

By Paula C · Kraftwire Software

Keep secret API credentials in a server-side function or API route, and enforce authentication and authorization for protected operations. If your Bolt app uses Supabase, configure table privileges and RLS for the intended access model. For privately owned rows, auth.uid() can help express ownership; shared records need policies that reflect their membership rules.

Why Do Bolt.new Apps Need a Security Audit?

Bolt generates applications from prompts and provides a browser-based development environment using WebContainers. Review the generated code and the deployed application separately from the development preview.

A working interface does not establish that secrets are protected or that private actions reject unauthorized requests. Inspect those controls and test them directly before launch.

7 Security Areas to Review

1. API Keys Bundled in Client-Side JavaScript

Inspect client-side source, including components and files such as utils/api.ts, for secret credentials. A secret embedded in JavaScript delivered to visitors is accessible to them, regardless of which tool generated the file.

The Danger:

• Account abuse: A leaked provider credential may authorize paid requests or other actions within its scope.
• Database access: A service_role credential bypasses RLS, subject to its database privileges.
• Email abuse: A credential with mail-sending permissions may let an attacker send messages through your account; that does not by itself transfer control of your domain.

How to Fix It:

• Move secret credentials to server-side functions or API routes and restrict access to those actions.
• Use only credentials intended for public clients, such as the Supabase anon key, in the frontend; configure the permissions behind them.
• If a secret was committed to a repository or deployed, revoke and replace it.
• Use SimplyScan to check for recognized secret patterns in the public assets it fetches, alongside repository and configuration review.

2. Missing or Weak Row-Level Security (RLS)

Review table privileges, RLS state, applicable policies, and bypass roles.

RLS Cases to Test:

• Authentication alone: A SELECT policy allowing auth.role() = 'authenticated' does not itself restrict rows to their owner. Applicable privileges and other policies still affect access.
• Missing policies: With RLS enabled and no applicable policies, roles subject to RLS are denied access. Configure the intended policies instead of disabling RLS to make a query work.
• Other operations: Test INSERT, UPDATE, and DELETE permissions as well as SELECT.

How to Fix It:

• For private rows with a user_id ownership column, USING (auth.uid() = user_id) can restrict which rows a policy permits. Check the policy command, roles, and checks on new values; shared-data policies need a different access model.
• Use the SimplyScan RLS guide to review table permissions.
• Test with separate accounts: private data for Account A should be inaccessible to Account B unless sharing is intended.

3. Broken Access Control on Protected Routes

If your app includes an /admin route, test whether its underlying data and actions require an administrator role. A visible dashboard or a hidden navigation link does not establish that the server enforces this restriction.

The Risk:

If the server returns private data without checking permissions, a caller may access it by requesting the endpoint directly. Hiding the page’s URL does not protect the underlying action.

How to Fix It:

• Use a ProtectedRoute component for navigation behavior if appropriate, but do not rely on it to authorize data access.
• Verify the caller’s identity and permissions on the server or database for every protected operation.
• Review the relevant controls with an application security checklist.

4. Exposed Service-Role Keys and Connection Strings

The Supabase anon key is intended for client use. Inspect browser bundles for service_role secrets or credential-bearing database connection strings such as postgres://..., and review the anon role’s privileges and policies.

The Danger:

A service_role credential bypasses RLS. Its database privileges determine the operations it can perform, so leaking it can grant access beyond a normal user’s permissions.

How to Fix It:

• Inspect references to service_role and credential-bearing strings such as postgresql:// in your codebase.
• Keep privileged credentials server-side and limit the actions exposed by that server.
• Use SimplyScan’s secret scanner for supported secret patterns, and review assets or configuration outside its coverage.

5. Vulnerable or Malicious Dependencies

Review each suggested package before installation: confirm the name, maintainer, version, and purpose. A dependency may have a known vulnerability, and a convincing package name alone does not establish its authenticity.

How to Fix It:

• Run npm audit in your Bolt terminal regularly.
• Keep your dependencies lean; if Bolt added a library you don't need, remove it.
• Check for vulnerable dependencies before every major deployment.

6. Client-Side Authorization Logic

Test server-side permissions independently of what the UI shows. For example: {user.isAdmin && <DeleteButton />}. While this hides the button, it does nothing to stop an attacker from calling the delete API endpoint directly.

The Danger:

A caller can alter browser-side behavior or bypass the UI entirely. Whether a UI state changes from isAdmin: false to isAdmin: true must have no effect on the permissions the server grants.

How to Fix It:

• Make the API or database enforce the access rule independently of the UI.
• Where you use Supabase RLS and custom claims, validate the trusted identity and policy behavior for each role.
• Read more on broken access control for tests of server-side authorization.

7. Missing Security Headers (CSP, HSTS, XFO)

Inspect the response headers served by your deployment. Browser security policies complement safe input handling and output encoding; they do not replace them.

Headers to Review:

• Content-Security-Policy (CSP): Restricts resources and script execution according to its directives; an overly permissive policy may offer little protection.
• Strict-Transport-Security (HSTS): Directs supporting browsers to use HTTPS after learning the policy; first-visit protection requires separate consideration such as preloading.
• X-Frame-Options: Restricts framing in supporting browsers according to the configured value. CSP frame-ancestors is another framing control.

How to Fix It:

• Configure headers using the mechanism your host supports, such as vercel.json on Vercel or a supported _headers file.
• Use the SimplyScan CSP generator to draft a policy, then test it against your application’s required resources.
• Inspect the deployed response with our security headers tool.

Pre-Launch Review Checklist

Before you share your Bolt.new URL on social media, run through this checklist:

Secrets

Are all sk- keys and service_role keys removed from the frontend?

Database

For tables exposed through your Supabase API, are privileges and RLS policies appropriate? Where ownership uses auth.uid(), do the tests cover allowed and denied access?

Auth

Do protected operations reject unauthorized calls even if a caller skips the /login page?

Logic

Is authorization checked on the server/API, not just the UI?

Headers

Does the site have a valid CSP and HSTS configuration?

Audit

Have you investigated the SimplyScan findings and checked the risks outside its scan coverage?

Review the Deployment Before Sharing It

Test the deployed behavior after changes to credentials, policies, and headers. A fix in the editor or preview may not match the configuration served at the public URL.

Use this guide to review security risks before deploying your prototype.

Frequently Asked Questions

Is Bolt.new safe for building production apps?

Production readiness depends on the application and its controls; a manual audit alone does not establish safety. Review secrets, database access, and server-side authorization, then test the permitted and denied operations before launch.

Is the Supabase anon key safe to expose in Bolt?

The anon key is intended for client-side use. Review table privileges and RLS policies to determine what requests using it can access. With RLS disabled, access depends on table privileges; it is not automatically public. A service_role credential bypasses RLS; its database privileges still determine which operations it can perform. Keep it out of client-side code.

Why is RLS enabled but my data still feels unprotected?

Enabled RLS does not by itself establish the intended permissions. Inspect applicable policies and role privileges, including roles that bypass RLS. For private rows, a check such as auth.uid() = user_id can express ownership; shared records need rules for the intended participants.

How do I check my Bolt.new app for exposed API keys?

Inspect production JavaScript using browser DevTools and search for credential patterns such as sk- or Bearer, then determine whether a match is a secret. SimplyScan checks recognized secret patterns and selected public files in about 30 seconds; it does not inspect every asset or prove that none remain.

Does checking user.role === 'admin' in React protect my app?

No. A caller can bypass the UI and send requests directly to an API. Enforce permissions on the server or database using the authenticated identity and the intended access rules.

How long does it take to secure a Bolt.new app?

The time depends on the application and findings. Work may include replacing exposed credentials, correcting access rules, and testing response headers. SimplyScan can flag selected observable exposures, but a URL scan does not identify every source file, line, or vulnerability.

These live figures describe all scanned sites. They do not establish prevalence for an AI-built subgroup, compare development methods, or attribute findings to AI generation.

30% of the 119 live sites SimplyScan has scanned (36 sites) have at least one high or critical security issue.