Fundamentos de seguridad
Escáner de seguridad para vibe coding: qué se le escapa
Un escáner de seguridad para vibe coding lee tu app en vivo desde fuera. Qué cubre eso, las cuatro cosas que no puede ver y cómo leer el resultado.

En resumen
- Un escáner de seguridad para vibe coding lee lo que los navegadores de tus visitantes ya descargan: tu bundle, tus cabeceras, tu certificado y las respuestas que tu base de datos le da a un desconocido.
- Eso cubre justo la clase de errores más frecuentes al construir con IA. No cubre nada de lo que ocurre en tu servidor.
- Un resultado limpio significa que toda pregunta que el escaneo pudo hacer desde fuera volvió limpia. Tómalo como una preocupación menos.
Pegas la dirección de tu app en un escáner, esperas unos veinte segundos y vuelve una letra. A, quizá C. Y entonces llega la pregunta que de verdad importa: ¿significa esto que mi app está bien?
Esta es la parte que la mayoría de herramientas de esta categoría te dejan averiguar sola. Un escáner de seguridad para vibe coding lee tu app desde la calle. Ve lo que ve el navegador de cualquier visitante, que resulta ser muchísimo, y se detiene en tu puerta. Lo que tu servidor hace en privado sigue siendo privado también para él.
Saber por dónde pasa esa línea es lo que hace que un escaneo valga la pena. Una A te dice que las puertas que dan a la calle estaban cerradas cuando miramos, y no dice absolutamente nada sobre la habitación de detrás.
¿Qué es un escáner de seguridad para vibe coding?
Una herramienta que carga tu app en vivo como lo haría un visitante y luego lee lo que volvió.
Le das una URL. No pide tu código fuente, ni tu repositorio, ni la contraseña de tu base de datos, ni una cuenta en el builder que usaste. Trae tu página, deja correr el JavaScript para poder ver el código que tu app envía de verdad, lee las cabeceras que llegaron con la respuesta, mira tu certificado y le hace a tu base de datos y a tu almacenamiento de archivos unas cuantas preguntas que podría hacer cualquier desconocido.
Luego anota qué respondió. Esa es toda la forma del asunto, y por eso tarda veinte segundos en lugar de una semana.
Esta categoría existe porque las apps hechas con Lovable, Bolt, v0, Cursor, Replit, Windsurf y Base44 se tuercen en el mismo puñado de sitios, y casi todos esos sitios se ven desde fuera. Una clave secreta en el bundle. Una tabla que le responde a un desconocido. Un bucket de almacenamiento que lista su propio contenido. Nadie necesita tu código fuente para encontrar ninguno, porque tu app se los tiende a cada visitante por diseño.
Qué lee realmente un escaneo
Cinco superficies, y tus propios visitantes descargan cuatro de ellas sin notarlo.
| Qué lee | De dónde sale eso | Qué atrapa |
|---|---|---|
| Tu bundle de JavaScript | Los archivos que un navegador descarga para ejecutar tu app | Claves enviadas al navegador, las rutas de API que llama, nombres de tablas que usa |
| Tus cabeceras de respuesta | Van con cada página que sirve tu alojamiento | Protecciones del navegador ausentes, una regla que responde a peticiones de cualquier web |
| Las respuestas de tu base | La misma API de proyecto que llama tu propia app | Una tabla que entrega filas a una petición sin nadie con sesión iniciada |
| Tus buckets de almacenamiento | La misma API pública de almacenamiento por la que tu app sube | Un bucket que le lista sus propios archivos a un desconocido |
| Certificado y dominio | El apretón de manos TLS y el registro público del registro | Un certificado a punto de caducar, un dominio a punto de vencer |
El bundle es el que sorprende a la gente. El código de tu app tiene que llegar al navegador antes de poder ejecutarse ahí, así que también llega cada clave que lleva dentro, junto con las rutas de API que llama y a menudo los nombres de las tablas que lee. Un escáner pulsa el mismo F12 que pulsaría un visitante curioso. Solo es más rápido, y lee todos los archivos en lugar del primero.
La pregunta a la base de datos es la que todo el mundo espera que sea invasiva, y es lo más manso de la lista. Para averiguar si una tabla es legible por desconocidos, el nuestro le pide a la API un recuento de filas y lee el número en una cabecera de respuesta. Un recuento mayor que cero significa que esas filas son alcanzables. Nunca se trae ninguna fila, y la clave con la que pregunta es la publicable que ya está en tu bundle, que se supone que está ahí.
Las cuatro cosas que un escaneo de URL no puede ver
Todo lo que ocurre en tu servidor, porque nada de eso se envía nunca a un navegador.
Tu código de servidor. Edge functions, rutas de API, funciones de base de datos, todo lo que corre dentro de Supabase o en tu alojamiento. Un escáner puede llamar a un endpoint y leer lo que vuelve. No puede leer el código que lo produjo, así que un fallo que solo aparece con ciertas entradas queda invisible.
Tus variables de entorno. Las claves que dejaste en el servidor, que es justo su sitio. Un escaneo puede decirte que no encontró un secreto en tu bundle. No puede confirmar que el secreto esté bien guardado, porque nunca ve el lugar donde lo guardaste.
Tu historial de versiones. Una clave que subiste en marzo y quitaste en abril ya no está en tu app y sigue en tu repositorio. Cualquiera que pueda ver ese repositorio puede seguir leyéndola, y por mucho que se mire tu sitio en vivo no va a aparecer.
La lógica de tu propia app. Si un usuario con sesión iniciada puede abrir el pedido de otro cambiando un número en la dirección. Si un formulario aceptará un precio que le mandó el navegador. Son decisiones que tu app toma sobre lo que permite, y pillarlas exige iniciar sesión y probar cosas, que es un test de intrusión.
Hay un quinto límite que es nuestro y no de la categoría, y vale la pena conocerlo antes de leer uno de nuestros informes. Supabase ya no le sirve la lista de tablas de un proyecto a una clave publicable, así que un escáner no tiene forma de preguntar cómo se llaman tus tablas. El nuestro trabaja en su lugar con tres fuentes: el índice del proyecto en proyectos más antiguos donde todavía responde, los nombres de tablas que encuentra en tu propio bundle, y una lista de veintiséis nombres habituales en apps hechas con vibe coding. Una tabla abierta con un nombre poco común que nunca aparece en tu código de frontend es una a la que no llegaremos. El advisor del propio Supabase sí llega, y esa es la comparación de dos secciones más abajo.
¿Un escaneo limpio significa que mi app es segura?
No. Significa que toda pregunta que el escaneo pudo hacer desde fuera volvió limpia, y esa es una frase más pequeña de lo que suena.
Parte del motivo son los cuatro puntos ciegos de arriba. La otra parte es que una comprobación puede terminar de tres maneras y solo una de ellas es un aprobado. Una comprobación encuentra algo. Una comprobación pregunta y recibe un no claro. O una comprobación no recibe respuesta alguna, porque la petición expiró, el host la rechazó o la página nunca terminó de cargar.
Ese tercer final es el que decide si un informe merece confianza, y es el más fácil de redondear discretamente a una marca verde. El nuestro escribe «No se pudo comprobar» en la línea y deja tu nota en paz. Una marca falsa sería lo más dañino que este escáner podría poner en una pantalla, porque actuarías sobre ella.
Esa misma honestidad es lo que hace que nuestras propias cifras publicadas sean menos alarmantes de lo que parecen a primera vista. Entre el 12 y el 14 de agosto de 2026 pasamos estas comprobaciones sobre 30.998 apps en vivo hechas con vibe coding, y el 99 % volvió con al menos un hallazgo. Casi todo eso es una sola línea: cabeceras de seguridad del navegador que la plataforma de alojamiento nunca pone, y que la mayoría de propietarios en un subdominio de builder no pueden activar por su cuenta. Contarlas es correcto. Leer el 99 % como «casi todas las apps están en peligro» no lo es.
¿Escaneo de URL, de repositorio o el advisor de Supabase?
Leen tres cosas distintas, así que la pregunta útil es cuál de ellos puede ver el problema que tienes.
| Tipo | Qué lee | Qué te pide | Dónde está ciego |
|---|---|---|---|
| Escáner de URL | Tu app en vivo, desde fuera | Una URL | Todo lo que tu servidor se guarda para sí |
| Escáner de repositorio | Tu código fuente y su historial | Acceso a tu repo | Si ese código está desplegado y qué hacen tus reglas en producción |
| Supabase Security Advisor | La configuración de ese proyecto | Tu cuenta de Supabase | Todo lo de fuera del proyecto: bundle, cabeceras, otros proveedores |
Se solapan mucho menos de lo que sugieren los nombres. El advisor de Supabase recorre tu proyecto e informa de problemas de configuración, entre ellos tablas con la Row Level Security mal puesta. Un escaneo de URL lee la consecuencia, que es si esas filas están llegando ahora mismo a desconocidos. Las dos se separan más a menudo de lo que esperarías, porque activar el ajuste no es lo mismo que estar protegido.
Un escáner de repositorio es el único de los tres que puede encontrar la clave que borraste el mes pasado. También es el único que no puede decirte si el código que acaba de leer es el que tienes desplegado.
Cómo leer la nota
La letra queda limitada por el peor hallazgo del informe, así que una buena puntuación nunca rescata a uno grave.
Cada escaneo empieza en 100. Un hallazgo crítico cuesta 40 puntos, uno alto 15, uno medio 5, uno bajo 1. Después se posa un techo sobre la aritmética: un hallazgo crítico limita la nota a D, dos la limitan a F, y un solo hallazgo alto la limita a C. Una app por lo demás impecable con una única tabla abierta sale como D, y ese es el comportamiento buscado.
Lo que hiciste bien aparece en el informe y no te cuesta nada. Tu clave publicable de Supabase, ahí en tu bundle, figura como correcta, porque para eso está, y pintarla de rojo es la manera en que una herramienta te enseña a ignorar el rojo.
Qué hacer con el resultado de un escaneo
Qué hacer
- Lee primero las líneas que dicen «No se pudo comprobar». Esas son las preguntas que siguen abiertas, y no son aprobados.
- Trabaja por gravedad. Un hallazgo crítico significa que hoy se puede llegar a tus datos; una cabecera ausente es un ajuste que nadie ha activado.
- Ocúpate del interior aparte: guarda las claves secretas en el servidor, busca en tu propio historial de versiones las claves que borraste, e inicia sesión como usuario de prueba para ver hasta dónde llega.
- Vuelve a escanear después de cada despliegue, y siempre que alguien toque una regla de la base de datos. Ese es el cambio del que nada te avisa.
- Si tu app cobra pagos o guarda datos de salud, contrata un test de intrusión en algún momento. Una comprobación externa automática no es una auditoría, y ninguna ausencia de hallazgos es una garantía.
Nuestro escáner de seguridad web gratis ejecuta nueve comprobaciones de solo lectura sobre cualquier URL en vivo en unos veinte segundos, sin cuenta. Lee, nunca escribe y nunca inicia sesión.
Si prefieres recorrerlo primero a mano, la checklist de seguridad de 10 minutos cubre el mismo terreno en el orden en que vale la pena hacerlo.
Preguntas frecuentes
¿Qué es un escáner de seguridad para vibe coding?
Una herramienta que carga tu app en vivo como lo haría un visitante y lee lo que vuelve: el JavaScript que tu app envía al navegador, las cabeceras que tu alojamiento añade, el certificado y las respuestas que tu base de datos y tu almacenamiento de archivos dan a una petición de un desconocido. Necesita una URL y nada más. Informa de lo que encontró en la superficie pública de tu app, que es justo donde las apps hechas con IA fallan más a menudo.
¿Es seguro escanear mi propia app?
Sí, siempre que el escáner solo lea. El nuestro hace el mismo tipo de peticiones que un visitante corriente, nunca inicia sesión, nunca escribe, crea ni borra nada en ningún sitio, y nunca descarga los datos de tus usuarios. Para comprobar si una tabla de la base de datos es legible, pide un recuento de filas y lee el número, sin traer ni una sola fila. El tráfico es un puñado de peticiones, menos que una persona navegando por tu sitio durante un minuto.
¿Un escaneo necesita mi código fuente o la contraseña de mi base de datos?
No. Un escáner de URL trabaja enteramente desde fuera, así que no hay nada que conectar ni credenciales que entregar. Ese es también su límite: solo ve lo que tu app ya le muestra a cualquier visitante. Una herramienta que lee tu repositorio o se conecta a tu cuenta de base de datos ve cosas distintas, y el artículo de arriba pone las tres una al lado de la otra.
¿Funciona con Lovable, Bolt, Cursor, Replit, v0, Windsurf y Base44?
Sí, y con cualquier otra cosa que ponga un sitio en internet, porque el escaneo mira lo que está desplegado y no lo que lo escribió. El builder importa para el arreglo más que para la comprobación: reparar una tabla abierta es una secuencia de clics distinta en Lovable que en Replit, y por eso el texto del arreglo nombra tu builder.
¿Qué no comprueba un escáner de seguridad?
Todo lo que se queda en tu servidor. Tu código de servidor y tus funciones de base de datos, las variables de entorno que mantuviste fuera del navegador, la clave que subiste y luego borraste del repositorio, y los fallos de tu propia lógica, como que un usuario con sesión iniciada pueda abrir el pedido de otro cambiando un número en la dirección. Encontrar ese último grupo exige iniciar sesión y probar cosas, y eso es un test de intrusión y no un escaneo.
¿Un escáner de seguridad para vibe coding es gratis?
El nuestro lo es, al menos el escaneo en sí: obtienes la nota, la puntuación y el número de hallazgos en pantalla en unos 20 segundos, sin cuenta, y los hallazgos detallados con sus arreglos después de dar un correo. Hay planes de pago para lo que un escaneo puntual no puede hacer, que es enterarse de que algo cambia el mes que viene. Una nota es cierta en el segundo en que la tomas.