Bolt App Security: Protect Your API Keys

Bolt app security depends on the boundary between browser code and the backend. A credential can be stored in an environment setting and still become public if the frontend build embeds it or a server response returns it.

Start by identifying your actual architecture. Bolt now offers Bolt Cloud, and projects can also use other integrations and hosting arrangements. Do not apply a Vite or Supabase checklist until you have confirmed that those tools are part of your app. Bolt’s introduction describes its current database and hosting options.

Classify configuration before changing code

Make a list of the values your app uses without recording their contents. For each name, identify the service, purpose, environment and permitted execution location.

Public configuration might include a site URL or a provider key explicitly designed for browser use. Private configuration includes server credentials for billing, email, storage administration or privileged database access. Check the provider’s documentation instead of deciding that every value containing the word “key” is a secret.

A useful review question is: could an ordinary visitor perform a privileged action with this value alone? When the answer is unclear, investigate the provider’s permission model before moving or renaming it.

Check the frontend build system

For a Vite-based app, variables with the VITE_ prefix are exposed to client code. They are appropriate for public configuration, not private credentials. The Vite environment-variable guide explains this behavior.

Inspect references to those variables and the code paths that use them. A hypothetical VITE_EMAIL_API_SECRET used by a browser component needs a server-side design. Changing the name alone will not create that design; the frontend request and backend handler must change together.

Use a non-sensitive marker in a staging build if you need to verify what gets embedded. Inspect the deployed browser resources for that marker. Do not insert a real private key just to test the build process.

Make the server enforce the action

Suppose a contact form sends email. Moving the provider credential to a server function prevents the browser from receiving the credential, but that function still needs rules governing what a visitor can request.

Review recipient selection, message size, abuse controls and error handling. For authenticated actions, verify the caller and the resource they are allowed to change. The server should derive permission from trusted state, not accept a client-supplied “admin” flag.

Ask Bolt for a bounded change:

Trace the email integration from the browser to the provider. List configuration names without values. Move any private credential use to a server function. Validate the request, restrict the action to its intended purpose and add tests for denied requests. Explain the deployment settings needed for this backend.

Review the proposed files and the test cases before publishing. A successful form submission only confirms the happy path; also test oversized input, unexpected recipients and repeated requests in your own staging environment.

Verify the deployment you actually use

Confirm that production settings belong to the production deployment and that the frontend calls the intended backend. Check preview and production independently. A preview that works with test credentials can conceal a missing production secret or an accidentally public configuration value.

If you discover an exposed private credential, rotate or revoke it, deploy the corrected flow and check the provider’s available activity records. Also inspect old public build artifacts you control; a newer build does not erase an older copy automatically.

Use the Bolt security scanner page for public-URL checks, and the scan-results guide to turn evidence into a repair plan. VibeShield’s free instant scan is limited and passive; verified account checks have a broader scope.

Common questions

Are all Bolt apps built with Vite and Supabase?

No. Identify your project’s framework, database and deployment setup first. Apply configuration-specific advice only when it matches the app.

Is a public source map automatically a leaked secret?

No. It can expose readable source, but the impact depends on what that source contains and your intended publication policy. Review the evidence instead of treating every source-map finding as a credential incident.