Reeve ¿Es segura tu app de Bolt?
¿Es seguro construir con Bolt? El código rara vez es el problema. Lo que decide es si las tablas que Bolt escribió por ti llegaron a cerrarse.
Los logotipos son propiedad de sus respectivos dueños y se muestran solo para indicar compatibilidad.
En resumen
- Una app de Bolt suele ser segura por el lado del código. Lo que decide es si las tablas que generó Bolt llegaron a cerrarse alguna vez.
- Las tablas creadas ejecutando SQL no reciben Row Level Security por defecto, y escribir SQL es como Bolt las crea.
- Una clave publicable en tu app es correcta. sb_secret_… o service_role llegando al navegador es la que hay que renovar hoy.
Bolt escribe el proyecto entero: las pantallas, el cableado y las tablas de base de datos que hay debajo. Esa última parte es la que nunca ves, y es donde empieza en realidad casi toda historia de «mi app de Bolt está filtrando datos».
Aquí está lo que guía tras guía cuenta mal: el código que escribió Bolt rara vez es el problema. El problema suele ser un único interruptor por tabla en tu base de datos que nunca se encendió, por la forma en que se crearon las tablas y no porque nadie se equivocara.
Qué le entrega Bolt a un visitante y qué se guarda
Dos mitades, y solo una es privada.
Piénsalo como una tienda. Bolt te construye un escaparate (páginas, botones, formularios), y ese escaparate entero se le entrega a cada visitante que carga tu web. Tiene que ser así. Un navegador no puede mostrar una página que no le han dado, así que no existe ninguna versión en la que la fachada de tu app sea secreta. Detrás hay un almacén, tu base de datos de Supabase, un edificio aparte con su propia cerradura.
La suposición que sale cara es que el escaparate manda sobre el almacén. No manda. Tu base de datos está en internet con su propia dirección, y esa dirección está impresa en el escaparate porque así es como la alcanza tu propia app. Quien lea tus archivos publicados lee también la dirección, y a partir de ahí puede hablar con el almacén sin pasar nunca por tu tienda.
¿Es un problema que mi app de Bolt lleve una clave de API dentro?
Normalmente no. Depende por completo de cuál sea, y hay dos que se parecen casi exactamente.
Una clave publicable nombra tu proyecto y nada más. Supabase la llama
sb_publishable_… en los proyectos nuevos y anon en los antiguos, y está hecha
para vivir en un navegador donde cualquiera puede leerla. Una clave secreta
(sb_secret_…, o service_role antes del cambio de nombre) es lo contrario.
Ignora todas las reglas que hayas escrito y lee y escribe cada fila de cada
tabla.
Están una junto a otra en el panel de Supabase, tienen una longitud parecida y se comportan igual mientras construyes. No se rompe nada si se copia la equivocada, que es justo por lo que sobrevive hasta producción. La versión larga de cómo distinguirlas se lee en un minuto.
El interruptor que decide a quién responde tu base de datos
Row Level Security, un ajuste por tabla en Supabase que decide, fila a fila, quién puede leer qué. Apagado, tu clave publicable devuelve la tabla entera. Encendido, con una política escrita, devuelve solo las filas que esa política permite.
Ahora la parte que se aplica específicamente a un proyecto de Bolt. Supabase activa Row Level Security por defecto en las tablas creadas en el Table Editor del panel, el de hacer clic. Las tablas creadas ejecutando SQL no lo reciben y hay que activarlas a propósito.
Bolt crea tus tablas escribiendo SQL.
Así que la forma habitual de un proyecto de Bolt es un conjunto de tablas generadas que llegaron sin cerrar, junto a lo que añadiste luego a mano, que no. Las dos son indistinguibles en el editor y las dos funcionan perfectamente. Y activar el ajuste tampoco es la meta: una tabla con Row Level Security encendido y una política que permite a todo el mundo está abierta mientras se declara cerrada.
Cómo revisar tu propia app de Bolt en unos diez minutos
Lee tu lista de políticas. En Supabase, Authentication → Policies muestra cada tabla con el estado de Row Level Security. Empieza por lo que aparezca como desactivado; eso lo puede leer cualquiera que tenga la dirección de tu proyecto.
Confirma qué clave publicaste. Settings → API en Supabase muestra las dos. La publicable en tu app es correcta y no necesita nada. Si alguna vez se pegó una clave secreta en el proyecto, renuévala ahí antes de tocar el código: borrar la línea no cierra la puerta, porque el valor antiguo sobrevive en las copias en caché de tu web.
Revisa tus buckets de almacenamiento. Un bucket marcado como público lo puede listar y descargar cualquiera, enlace o no tu app a los archivos que hay dentro.
Y luego mira desde fuera. Todo lo anterior te dice qué está configurado. No te dice a qué llega de verdad un desconocido, que es otra pregunta y la que importa. Nuestro escaneo gratuito lee tu web en vivo igual que lo haría cualquier visitante y te da una nota en unos 20 segundos, sin cuenta: escanea tu app.
Qué hacer
- Todo lo que Bolt envía a un navegador lo puede leer cualquiera. Así funcionan los navegadores, y esconderlo no es un camino que valga la pena.
- Una clave publicable en tu app es correcta. Una clave secreta (
sb_secret_…oservice_role) es la que hay que renovar hoy. - Las tablas creadas ejecutando SQL no reciben Row Level Security por defecto, y escribir SQL es como Bolt crea tablas.
- Encender el ajuste es el paso uno. Una política que permite a todos deja la tabla abierta mientras el panel la muestra como protegida.
- Que tu app funcione no es prueba de que esté cerrada. Desde dentro, los dos estados se ven idénticos.
Abre Authentication → Policies en Supabase y lee la lista de arriba abajo. Si algo dice que Row Level Security está desactivado, esa tabla es por donde empezar, y la lista de seguridad en 10 minutos cubre el resto de la superficie cuando lo hayas hecho.
Qué puede salir mal de verdad con una app de Bolt
Nada de esto significa que hicieras algo mal: son los efectos secundarios habituales de construir rápido. Esto es lo que vale la pena comprobar:
Una clave secreta acabando en el navegador (la trampa VITE_)
Las apps de Bolt suelen construirse con Vite, que tiene una regla que pilla a la gente: cualquier ajuste cuyo nombre empiece por VITE_ se hornea en el código que se ejecuta en el navegador de tu visitante, donde cualquiera puede leerlo. Llama a un secreto real VITE_ALGO y se publica. Algunas claves se supone que deben ser públicas (como una clave «anon» de Supabase), lo cual está bien: Reeve distingue las seguras de las peligrosas, así que sin falsas alarmas.
Tu base de datos abierta (RLS de Supabase desactivado)
Bolt a menudo conecta tu app a Supabase para los datos. Supabase tiene un interruptor llamado Row Level Security (RLS) que decide quién puede leer o cambiar cada fila. Si está desactivado, tus tablas pueden ser legibles, o editables, por cualquiera que encuentre la dirección. Es el problema serio más común en apps hechas por IA, e invisible a menos que lo compruebes.
Un archivo .env o de configuración expuesto
El archivo .env guarda las claves y contraseñas de un proyecto. A veces se publica por accidente junto con la app desplegada. Si es accesible desde fuera, es un atajo a todo lo sensible. Reeve comprueba si el tuyo está accesible sin que lo sepas.
Almacenamiento de archivos público
Si la gente sube archivos a tu app, estos viven en «buckets» de almacenamiento. Un bucket dejado público significa que cualquiera puede listar o descargar lo que hay dentro, así que una subida privada puede acabar visible para todos. Reeve comprueba si tus buckets son listables; nunca descarga los archivos de nadie.
Source maps dejados activos
Un «source map» es un archivo de ayuda que revela el código original de tu app. Útil mientras construyes, pero si llega a producción entrega a extraños un mapa legible de cómo funciona tu app, haciendo más fácil de encontrar cualquier otra puerta. Poca urgencia, pero conviene ordenarlo.
Cabeceras de seguridad ausentes y endpoints abiertos
Pequeños ajustes que le dicen a los navegadores cómo proteger a tus visitantes, más si tus endpoints de datos responden a cualquiera o a cualquier sitio. Menores por sí solos; juntos amplían la brecha. Reeve señala los que faltan.
Qué es Reeve, y qué no
Reeve es una comprobación gratuita, de solo lectura y desde fuera, como un inspector que rodea el edificio y prueba las puertas. Es rápida y detecta los errores comunes de alto impacto. No es una auditoría de seguridad completa, y una nota limpia no es garantía. Significa que las puertas obvias están cerradas.
Bolt y StackBlitz siguen mejorando lo que se genera, y si tu app usa Supabase, el propio asesor de Supabase señala problemas de base de datos en su panel. Ambos ayudan. Lo que Reeve añade: tú vives en Bolt, no en un panel, y esas herramientas hablan en lenguaje de desarrollador. Reeve mira toda tu app desplegada desde fuera, como lo haría un extraño, y te dice lo que encuentra en palabras con las que puedes actuar. Y si prefieres no pensar en ello, podemos vigilarla por ti.
¿Quieres que se gestione, no solo que se compruebe?
Reeve Care sigue vigilando tu app, respalda tus datos y te ayuda a arreglar cosas cuando se rompen, para que puedas seguir creando en vez de preocuparte.
Conoce Reeve CarePreguntas frecuentes
¿Mi app de Bolt es segura por defecto?
Bolt te da una app que funciona rápido, pero «seguro por defecto» depende de cómo esté conectada, especialmente de tus variables de entorno y, si usas Supabase, de las reglas de tu base de datos. La única forma de saberlo es comprobar qué está realmente expuesto, que es lo que Reeve hace gratis en unos 20 segundos.
¿Por qué se filtró mi clave de API en una app de Bolt?
Normalmente porque estaba guardada en un ajuste que empieza por VITE_. Vite incrusta esos a propósito en el bundle del navegador, así que cualquier secreto con ese nombre se hace público. Reeve lee el código cargado de tu app, encuentra las claves y te dice cuáles son seguras de exponer y cuáles deben moverse al servidor.
¿Bolt usa Supabase, y es seguro?
Bolt conecta apps a Supabase con frecuencia. Supabase es seguro cuando Row Level Security está activado y solo tu clave pública «anon» está en el front-end. Si el RLS está desactivado o se filtró una clave «service_role», tus datos pueden quedar expuestos. Reeve comprueba ambos sin leer nunca tus datos reales.
¿Analizar mi app de Bolt cambiará algo?
No. Reeve solo mira lo que ya es público desde fuera. Nunca inicia sesión, nunca cambia nada y nunca descarga tus archivos. Solo lectura, como comprobar si una puerta está cerrada sin entrar.
Bolt escribió mis tablas de base de datos. ¿Están cerradas por defecto?
A menudo no, y el motivo es mecánico. Supabase activa Row Level Security automáticamente en las tablas que creas haciendo clic en el Table Editor, pero no en las creadas ejecutando SQL. Un builder crea tablas ejecutando SQL, así que esas tablas llegan con el interruptor apagado a menos que algo lo encendiera después.
La vista previa funcionaba y la app publicada funciona. ¿Significa que está bien configurada?
No, porque las dos funcionarían igual en cualquier caso. Una app sin reglas en su base de datos se comporta exactamente como una app con las reglas correctas, hasta el momento en que alguien consulta la base directamente en vez de pasar por tus pantallas. Que funcione no es la misma prueba que que esté protegida.
¿Dónde miro para saber si mi proyecto de Bolt tiene este problema?
Abre tu proyecto de Supabase y ve a Authentication, luego a Policies. Ahí aparece cada tabla del esquema public con el estado de Row Level Security. Cualquier tabla que figure como desactivada la puede leer quien tenga la dirección de tu proyecto y tu clave publicable, y ambas cosas están dentro de la app que publicaste.