Bolt.new security checklist: The step-by-step guide to secure your Bolt.new app in 2026.

A Bolt.new security checklist covers six gaps Bolt's frontend-first output leaves open: API keys in client bundles, unprotected Netlify Functions, missing input validation, absent rate limiting, weak CORS rules, and direct browser-to-provider API calls. Moving all paid API keys to Netlify environment variables and proxying every provider call through a server function eliminate the most common and costly Bolt.new vulnerabilities. Bolt generates fast frontend code, which means every API key and paid-provider credential written in that code is visible to anyone who opens DevTools — scrapers find exposed keys within hours of deployment.

Key Security Risks in Bolt.new Apps

Hardcoded API keys in client bundles: Bolt.new generates frontend-first code. If you call OpenAI, Stripe, or any paid provider directly from client code, that key is in the JavaScript bundle and readable by anyone. Scrapers find these within hours of deployment.

Missing auth on Netlify Functions: Bolt scaffolds Netlify Functions as backend handlers, but does not add authentication by default. An unprotected function that reads or writes user data is publicly callable by anyone who discovers the endpoint URL.

Absent backend proxy architecture: Direct client-to-provider API calls expose your credentials and remove usage control. A backend proxy function keeps the key hidden and lets you add rate limits, auth checks, and logging.

Wildcard CORS on sensitive endpoints: Bolt-generated function configurations frequently allow all origins. This means any website can make credentialed requests to your Netlify Functions.

No rate limiting on AI routes: Calling AI providers through an unthrottled endpoint means any user — or bot — can send unlimited requests at your expense.

API Keys & Secret Management

This is the single highest-priority item for any Bolt.new app.

• Never call OpenAI, Anthropic, Stripe, or any paid provider directly from Bolt frontend code.
• Move all paid API keys to Netlify environment variables — not the frontend .env.
• Search your built JavaScript bundle for sk-, service_role, sk_live_, and provider key prefixes before every deploy.
• Rotate any key that appeared in client code, logs, or a preview deployment.

// Wrong — key exposed in client bundle
const response = await fetch('https://api.openai.com/v1/chat/completions', {
  headers: { 'Authorization': `Bearer ${import.meta.env.VITE_OPENAI_KEY}` }
});

// Correct — proxy through Netlify Function
const response = await fetch('/.netlify/functions/ai-chat', {
  method: 'POST',
  body: JSON.stringify({ message })
});
// The Netlify Function holds the key in process.env.OPENAI_API_KEY

Netlify Function Security

• Add auth checks in every Netlify Function that handles user data or paid operations.
• Validate the user identity server-side before any write, mutation, or AI call.
• Block anonymous function calls unless the endpoint is explicitly designed to be public.
• Test token tampering and expired token flows on all protected function routes.

// netlify/functions/ai-chat.ts
export const handler: Handler = async (event) => {
  // Validate auth first
  const token = event.headers.authorization?.replace('Bearer ', '');
  const user = await validateToken(token);
  if (!user) return { statusCode: 401, body: 'Unauthorized' };

  // Then call the AI provider safely server-side
  const response = await openai.chat.completions.create({
    model: 'gpt-4',
    messages: JSON.parse(event.body || '{}').messages
  });
  return { statusCode: 200, body: JSON.stringify(response) };
};

Database & Storage Security

• If using Supabase, enable RLS on all tables and enforce auth.uid() in every policy.
• Prevent direct client writes to privileged tables or collections.
• Scope storage access by owner with signed URLs — not filename secrecy.
• Review Netlify Function-to-database permissions for least privilege.
• Confirm Firebase rules (if used) block unauthorized reads and writes with real negative tests.

Input Validation & XSS

• Validate every request payload in Netlify Functions before processing — do not trust client input.
• Sanitize user-generated content before rendering it in React components.
• Reject oversized payloads and unknown fields to reduce the abuse surface.
• Test stored XSS in message, notes, and profile input flows.

CORS Configuration

• Allow only your production domain and explicit preview URLs as allowed origins.
• Remove wildcard CORS for any function that handles authenticated or paid operations.
• Restrict HTTP methods per endpoint to the minimum required (GET or POST only, rarely both).
• Never expose stack traces or verbose error messages in Netlify Function production responses.

Rate Limiting & Abuse Prevention

• Apply per-IP limits to expensive AI and data export endpoints using Netlify Edge Middleware or Upstash.
• Add user-level throttles on authenticated high-cost routes to prevent individual abuse.
• Protect login and password reset flows against brute-force traffic.
• Log rate-limit hits and alert on burst anomalies — a sudden spike often means key scraping.

// Rate limiting with Upstash in Netlify Edge Function
import { Ratelimit } from '@upstash/ratelimit';
const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),
  limiter: Ratelimit.slidingWindow(10, '1 m'), // 10 requests per minute
});
const { success } = await ratelimit.limit(clientIP);
if (!success) return new Response('Too Many Requests', { status: 429 });

Related Security Checklists

Bolt.new deploys to Netlify and commonly uses Supabase as a backend. After completing this checklist, review the Supabase security checklist for database-layer gaps. For a full pre-launch security sweep covering all AI-built app patterns, use the pre-deploy security checklist for vibe-coded apps.

Run Your Security Audit

Want to know which Bolt.new vulnerabilities were quietly introduced during rapid AI shipping?

Ubserve scans your real codebase for exposed keys in frontend bundles, missing auth on function endpoints, Supabase RLS gaps, and every other pattern on this checklist. Every finding comes with a fix prompt you paste directly into Bolt.new to patch it before launch.

Audit my Bolt.new app for these vulnerabilities

Most Bolt.new incidents are not caused by sophisticated attacks. They are caused by a key in a bundle, found by a scraper, in the first 24 hours after launch.

Run the audit. Fix what it flags. Ship with confidence.

— Mr. Ballaz, Founder of Ubserve