Seguridad de v0: las 1.790 aplicaciones escaneadas sacaron una A

Le describiste una aplicación a v0, viste cómo la construía y te devolvió un enlace que termina en vusercontent.net. Funciona, parece terminada, y puede que ya se la hayas mandado a alguien. Antes de que clientes reales escriban sus datos en ella, buscaste la seguridad de v0, y parte de lo que salió era una historia sobre atacantes que usaban v0 para construir páginas de inicio de sesión falsas.

Esa historia trata de lo que otras personas hacen con la herramienta. Este artículo trata de la aplicación que tú hiciste con ella, y para eso tenemos una medición. Entre el 12 y el 14 de agosto de 2026 pasamos las mismas nueve comprobaciones externas que cualquiera puede lanzar gratis en nuestra página de inicio sobre 30.998 aplicaciones en vivo, y 1.790 de ellas eran aplicaciones v0. Las 1.790 sacaron A.

Esta es la parte que una clasificación entiende mal: esa A dice más sobre lo que había que comprobar que sobre v0. Leída como clasificación, convierte a v0 en el builder más seguro que medimos. Leída con sus denominadores, describe frontends sin nada detrás, y deja de describir el tuyo el día que conectas una base de datos.

¿Es seguro v0?

En todo lo que pudimos medir sobre el propio v0, sí. Su único hallazgo pertenece al dominio desde el que v0 sirve tu aplicación, y no apareció nada más en ninguna de las 1.790, en ninguna de las nueve comprobaciones. Lo que eso no puede decirte es cómo se comporta tu aplicación cuando guarda datos, porque casi ninguna de estas guardaba ninguno.

Piensa en una vista previa de v0 como en un archivador en una sala de exposición. Los cajones se deslizan, las etiquetas están puestas, cualquiera que pase puede abrir uno, y todos los cajones están vacíos. Nuestras comprobaciones probaron cada cajón y no encontraron nada en ninguno, y eso es un informe correcto sobre un archivador vacío.

Cuánto de vacío, lo dicen los números. Solo 17 de las 1.790 nombraban un proyecto de Supabase en algún lugar del código que publican, y en las 17 nuestra comprobación de base de datos no obtuvo una respuesta que pudiera juzgar, así que el recuento de tablas legibles en v0 es cero de cero. Las 1.790 se servían desde vusercontent.net, que Vercel describe en su solicitud a la Public Suffix List como el lugar "donde alojamos el contenido enviado por los usuarios" de v0. Una aplicación que publicas va a una dirección vercel.app o a un dominio tuyo, donde nada la marca como v0 desde fuera, así que esas no están en el recuento. El método y los datos completos están en el informe.

Así que "¿es seguro v0?" son tres preguntas:

1. La herramienta. Lo que v0 revisa en el código que escribe y lo que se niega a publicar. Esa parte es de Vercel, y está documentada.
2. La vista previa. El archivador en la sala de exposición, en su dirección vusercontent.net. Todas las aplicaciones que medimos estaban en esta etapa.
3. La aplicación que llenas. El mismo código cuando guarda los datos de tus clientes, o cuando corre en un dominio propio. Casi nada de lo que medimos había llegado tan lejos.

Lo que cubre la seguridad de v0 antes de publicar

Tres cosas, y la propia documentación de v0 nombra cada una.

Lee el código que escribió. La página de seguridad de v0 dice que todo el código generado "pasa por un análisis de seguridad antes de ejecutarse", y que v0 "analiza el uso de NEXT_PUBLIC_ y avisa a los usuarios de posibles riesgos de seguridad". NEXT_PUBLIC_ es el prefijo que le dice a Next.js, el framework en el que escribe v0, que meta un valor en el código que descarga cada visitante. Lo que ese prefijo le hace a una clave tiene su propio artículo.

Rechaza algunos despliegues. En agosto de 2025 Vercel escribió que v0 había bloqueado más de 17.000 despliegues en los 30 días anteriores solo por secretos expuestos, y más de 100.000 despliegues inseguros desde su lanzamiento. Son cifras de Vercel sobre el bloqueo de Vercel, que se aplica a los despliegues en Vercel. Parte de nuestro cero puede ser obra de ese bloqueo. Desde fuera no podemos saber cuánto.

La integración de Supabase pone el prefijo en el sitio correcto. Conectada a través del Vercel Marketplace, añade una docena de variables de entorno, y solo dos llevan NEXT_PUBLIC_: la dirección del proyecto y la clave publicable, que están hechas para ser públicas. SUPABASE_SECRET_KEY y la contraseña de la base de datos se quedan sin él, en el servidor.

Por qué a una vista previa de v0 le faltan cabeceras de seguridad

Porque las pone el dominio de vistas previas de v0, cada aplicación que vive en él recibe la misma respuesta, y no puedes cambiarla desde dentro de una vista previa.

Las cabeceras de seguridad son instrucciones que un sitio envía con cada página: usa siempre HTTPS, no dejes que otro sitio muestre esta página dentro de la suya, no adivines qué tipo de archivo es esto. Las envía quien sirve la página. Las vistas previas que abrimos el 3 de octubre de 2026 enviaban una de las cinco que busca nuestra comprobación, la que obliga a usar HTTPS, y ninguna de las otras cuatro. Ese es el hallazgo en las 1.790 aplicaciones v0, y es el único.

La sala de exposición decide sus propias puertas y alarmas, y no puedes recablearlas para un solo archivador de su suelo. En cuanto publicas, el archivador está en tu oficina, y las cabeceras son un ajuste en vercel.json o en tu configuración de Next.js. Qué hace cada cabecera, y las dos que no cuestan nada, es otro artículo.

¿Es pública una vista previa de vusercontent.net?

Trátala como pública. Cualquiera que tenga la dirección puede abrirla, y las direcciones viajan.

Cada una de las 1.790 se abrió para nosotros sin iniciar sesión, y no tuvimos que adivinar ninguna: sus direcciones salieron de un archivo web público que ya había guardado una copia de cada una. Los ajustes para compartir de v0 deciden quién puede ver tu chat: privado por defecto, luego tu equipo, cualquiera con el enlace o cualquiera en la web. La documentación no dice que esos ajustes lleguen a la vista previa.

Así que una vista previa es el archivador en la sala de exposición. Sirve para enseñarle el diseño a alguien y no sirve para los documentos reales de nadie. Vercel incluyó vusercontent.net en la Public Suffix List en septiembre de 2024, lo que hace que los navegadores traten cada vista previa como un sitio aparte, así que una vista previa no puede poner cookies para todas las demás. Eso mantiene las vistas previas separadas entre sí, y no hace nada por mantener la tuya privada.

Si estás aquí porque alguien te mandó un enlace de vusercontent.net: el dominio es de Vercel, y la página que hay en él la hizo quien la pidió con un prompt. El 1 de julio de 2025 Okta informó de atacantes que usaban v0 para construir copias de páginas de inicio de sesión reales, y Vercel restringió el acceso a las que encontró. No escribas una contraseña en un formulario de inicio de sesión en una dirección así salvo que lo estuvieras esperando.

Qué cambia cuando conectas Supabase a v0

Empiezas a llenar los cajones, y las comprobaciones que volvieron vacías en v0 empiezan a tener algo que comprobar.

v0 añade Supabase con un clic y, en palabras de su propia documentación, "puede generar y ejecutar SQL. Esto te permite crear, actualizar y eliminar tablas". Así se crean tus tablas. Cada tabla es un cajón, y Row Level Security es la cerradura que tiene: un ajuste por tabla que decide qué filas puede leer la clave publicable de tu página. Esa clave está hecha para ser pública, así que la cerradura es lo único que decide qué recibe un desconocido.

Supabase pone esa cerradura por defecto en las tablas creadas en su Table Editor, y la deja fuera en las tablas creadas ejecutando SQL, que es como las crea v0.

Ahí es donde cayeron los hallazgos graves en todos los demás builders. De las 3.553 aplicaciones Lovable cuya base de datos pudimos consultar, 2.017 entregaron filas a una petición sin inicio de sesión, y los números de Lovable son el aspecto que tienen los resultados de un builder cuando ya hay documentos en los cajones. Una cerradura que abre cualquier llave tampoco es una cerradura: una política que dice using (true) deja pasar a todo el mundo mientras el panel muestra la tabla como protegida. RLS está activado y tu tabla sigue siendo pública cuenta la historia entera.

Si tus datos están detrás de rutas que responde tu propio código de servidor, la misma pregunta se hace a esas rutas: qué significa un endpoint de API abierto.

Qué cambia cuando publicas o despliegas tú mismo

El archivador sale de la sala de exposición y entra en tu oficina, y las decisiones que tomaba el dominio de v0 pasan a ser tuyas.

Publicar desde v0 crea un proyecto de Vercel y pregunta tres cosas, según la documentación de despliegues de v0: el nombre del proyecto, quién puede acceder a la aplicación desplegada y el dominio, ya sea una dirección vercel.app o uno propio. Detente en la segunda. Las opciones que ves dependen de tu plan, y dejar la aplicación solo para tu equipo o detrás de una contraseña hasta que la hayas revisado mantiene fuera a los desconocidos mientras miras.

Tres cosas pasan a ti cuando publicas:

• Las cabeceras. Las puertas y alarmas de la oficina las configuras tú ahora.
• Las variables de entorno. Viven en los ajustes de tu proyecto, y esa lista es donde una clave recibe el prefijo NEXT_PUBLIC_ o no.
• La comprobación de tu despliegue, si sales de Vercel. Vercel describe su bloqueo como algo que detiene despliegues en Vercel, así que el código que descargas y alojas en otro sitio sale sin esa comprobación.

En cualquier caso, has salido de la muestra que medimos. Una aplicación v0 en su propio dominio con una base de datos detrás se parece más a las aplicaciones Bolt que medimos que a estas 1.790 vistas previas.

Cómo revisar tu propia aplicación v0

Cinco cosas, y las tres primeras solo importan cuando ya has conectado una base de datos o publicado. Usa una ventana privada, para que tu propio inicio de sesión no responda por un desconocido.

1. Lee tus variables de entorno. En v0 están en el menú del proyecto, en Settings, Environment Variables. Todo lo que empieza por NEXT_PUBLIC_ está en el código que descarga cada visitante. La dirección de un proyecto y una clave publicable van ahí. Una clave que te cobra, SUPABASE_SECRET_KEY y cualquier cosa que guarde una contraseña, nunca. Si alguna llevó alguna vez el prefijo, rótala primero con el proveedor, porque el valor antiguo sigue funcionando hasta que lo hagas.
2. Lee la cerradura de cada tabla. En Supabase, abre Authentication → Policies y recorre la lista. Una tabla con Row Level Security desactivado la puede leer cualquiera que tenga la dirección de tu proyecto, y esa dirección está en tu página. Una política que lo permite todo a todo el mundo cuenta como desactivada.
3. Elige quién puede verla cuando publiques. Solo tu equipo, o una contraseña, hasta que las dos primeras estén hechas.
4. Pon tus cabeceras cuando el dominio sea tuyo. Dos de ellas son una línea cada una.
5. Luego mira desde fuera. Nuestro escaneo pasa las nueve comprobaciones contra la dirección publicada como lo haría un desconocido, tarda unos 20 segundos y no pide cuenta: escanea tu aplicación gratis.

Un escaneo desde fuera no ve el código que escribió v0, ni el chat en el que lo escribiste, ni una tabla que tus páginas nunca mencionan. Las comprobaciones de v0 ven el código desde dentro y no ven lo que un desconocido obtiene de la dirección. Usa las de v0 mientras construyes, mira desde fuera después de publicar y, si alguna vez no coinciden sobre si una tabla se puede leer, quédate con la respuesta de fuera, porque es la que recibe un desconocido. La versión en lenguaje sencillo para esta plataforma es ¿es segura tu aplicación v0?.

Para que siga así después de publicar

Una A en una vista previa describe una vista previa. El día que conectas una base de datos o publicas en tu propio dominio, tu nota puede cambiar, y nada en tu pantalla te avisa de que ha cambiado.

Reeve Monitor vuelve a pasar las nueve comprobaciones por ti:

• las nueve comprobaciones cada hora, en hasta tres aplicaciones
• si la aplicación responde, cada 60 segundos
• un mensaje cuando un resultado cambia, para que una tabla o una clave nueva no espere a que mires
• un informe mensual de lo que vio

Monitor cuesta $12 al mes de tarifa de lista, con siete días gratis antes de cobrarte. La página de precios a veces está por debajo de la cifra de aquí y nunca por encima.

Si tu aplicación v0 guarda sus datos en Supabase, Reeve Care guarda una copia de tu base de datos de Supabase.

• una copia cifrada cada noche, guardada donde tu proyecto no puede llegar
• cada copia verificada antes de contar, con un recuento de las filas de cada tabla
• una restauración con un clic cuando la necesites
• también tus archivos subidos, en cuanto conectes una credencial de Storage
• todo lo que hace Monitor

Care cuesta $49 al mes de tarifa de lista por una aplicación, con los mismos siete días gratis.

La documentación de v0 dice que puede eliminar tablas además de crearlas, y ninguna de las nueve comprobaciones de arriba traería de vuelta sus filas. El día en que un agente de IA borró una base de datos de producción muestra cómo se ve eso desde dentro.

Qué hacer esta semana

Empieza por las variables de entorno, porque deciden lo que descarga cada visitante. Si todavía estás eligiendo builder, cuál es el builder de apps con IA más seguro pone los cinco uno al lado del otro.