Saltar al contenido

// guía de seguridad

Seguridad para apps hechas con Bolt.new

Bolt.new genera apps full-stack con StackBlitz WebContainers ejecutando todo en el browser. Eso permite iteración rapidísima, pero introduce patrones específicos: el código y los datos viven en el mismo sandbox, y el deploy a hosting externo requiere ajustes que el asistente no siempre incluye.

// contexto del stack

Contexto de Bolt.new

Bolt soporta múltiples frameworks (Astro, Next, Remix, SvelteKit, Vite). La convención de variables depende del framework elegido. Common pitfall: copiar variables del WebContainer al deploy sin filtrar las secretas. La magnitud del problema se ve en los datos: Escape.tech reportó más de 400 secretos expuestos al analizar 5.600 apps construidas con vibe coding, exactamente el tipo de leak que produce arrastrar variables del sandbox al deploy.

// hallazgos frecuentes

Vulnerabilidades más comunes en Bolt.new

01 Migration del WebContainer al deploy con variables sin filtrar

Bolt corre con todo en un WebContainer donde "no hay secretos reales". Cuando deployás a Cloudflare Pages o Netlify, las mismas variables se exponen al cliente si tienen prefijo público.

→ cómo arreglarlo

Antes de deploy, separá claramente variables públicas (con prefijo VITE_/NEXT_PUBLIC_/PUBLIC_) de secretas (sin prefijo). Configurá ambas en el dashboard del hosting, no en archivos commiteados.

02 Supabase / Firebase sin reglas

Las apps Bolt con backend-as-a-service tienen el mismo problema que Lovable: el modelo genera el schema y el frontend, pero olvida las políticas RLS o Firestore rules.

→ cómo arreglarlo

Habilitar RLS en Supabase o configurar rules estrictas en Firestore antes de hacer público. Para Firestore: `allow read, write: if request.auth != null && request.auth.uid == resource.data.userId`.

03 Endpoints API sin autenticación

Bolt genera endpoints API rápidamente para prototipar (ej. `/api/admin`). En el sprint el guard se "agrega después" y a veces nunca aparece.

→ cómo arreglarlo

Cada endpoint API debe pasar por un middleware de auth. Si tu app permite signup público, no asumas que "estar logueado" alcanza — agregá role checks donde aplique.

04 CORS permisivo

Para que el WebContainer comunique con APIs externas, Bolt sugiere configuraciones CORS amplias. En producción esto puede quedar como `Access-Control-Allow-Origin: *` con `credentials: true`, que es la peor combinación posible.

→ cómo arreglarlo

Listá orígenes explícitos en CORS. Si tu API no necesita cookies del usuario, dejá `credentials: false`. Si necesita cookies, restringí orígenes a tu dominio y `www.tudominio.com`.

05 Headers de seguridad ausentes

Bolt no configura security headers por default. Al deploy, queda al hosting agregarlos.

→ cómo arreglarlo

Configurá CSP, HSTS, X-Frame-Options en tu hosting. Plantilla completa en nuestro post de security headers.

// checklist pre-launch

Checklist pre-launch para Bolt.new

  1. Filtrar variables del WebContainer antes de configurarlas en el hosting
  2. Separar claramente variables públicas (con prefijo) de secretas (sin prefijo)
  3. Si usás Supabase: habilitar RLS y agregar políticas explícitas
  4. Si usás Firebase: configurar Firestore rules con auth checks
  5. Auditar endpoints API por presencia de auth middleware
  6. Restringir CORS a orígenes explícitos
  7. Configurar security headers en el hosting
  8. Stripear console.log y debugger en build de producción
  9. Auditar con VibeAuditt antes del launch

// lectura relacionada

Posts relacionados

// escaneá ahora

Audita tu app Bolt.new gratis

VibeAuditt detecta automáticamente los errores de este checklist en menos de un minuto. Sin tarjeta, sin instalación.

Empezar auditoría