La lista de seguridad del vibe coding, en nueve comprobaciones

Estás a punto de mandarle a alguien la dirección de tu app, y una vocecita te dice que antes deberías revisarla. Así que buscas una lista de seguridad del vibe coding y encuentras una de veinticinco puntos, escrita por alguien que da por hecho que ya sabes qué es una Content Security Policy.

Esta es la parte que lista tras lista se equivoca: casi nada de lo que hay en ellas se puede comprobar. "Usa contraseñas fuertes" es un consejo. "Limpia el código muerto" es orden doméstico. "Sigue el principio de mínimo privilegio" es una frase. Ninguno tiene una prueba, así que ninguno se puede terminar, y una lista que no puedes terminar es una preocupación con números.

Esta tiene nueve puntos. Nueve es la cantidad de cosas que cualquiera puede verificar en una app en marcha desde fuera, sin tu contraseña, sin tu repositorio y sin tu cuenta de Supabase. Cada uno tiene una prueba que puedes hacer tú y cada prueba vuelve con un sí o un no.

Piénsalo como la vuelta que da un piloto alrededor de un avión antes de volar. Es corta, todo lo que hay en ella se ve desde la pista, y no sustituye nada del libro de mantenimiento. La última sección de este artículo trata del libro.

¿Qué debe llevar una lista de seguridad del vibe coding?

Nueve preguntas, y son las nueve que un desconocido podría hacerle a tu app esta tarde, las hayas revisado o no.

Nuestro propio escáner de seguridad gratuito hace las nueve sobre cualquier URL en marcha en unos 20 segundos y sin cuenta, que es la vía más rápida para la primera pasada. Lee, nunca inicia sesión y nunca escribe nada. Cada punto de abajo sigue siendo algo que puedes comprobar a mano, y las pruebas están escritas para que puedas contrastar una línea de nuestro informe con tu propio panel.

Los cuatro antes de compartir la dirección

Claves secretas, reglas de la base de datos, archivos privados y buckets de almacenamiento. En estos cuatro lo que queda expuesto son tus datos o tu dinero, y los cuatro son tuyos para arreglar y no de tu plataforma de alojamiento.

Tres de ellos son las únicas comprobaciones de todo el conjunto que pueden informar de un hallazgo crítico, y la cuarta es aquella en la que lo expuesto es lo que subieron tus usuarios. Entre el 12 y el 14 de agosto de 2026 pasamos las nueve comprobaciones sobre 30.998 apps de vibe coding en marcha, y las cifras de cada sección de abajo salen de esa tanda.

1. ¿Hay una clave secreta en el código que envía tu app?

Busca en todo tu proyecto sk_, sb_secret_, service_role y AKIA. Una coincidencia dentro de cualquier cosa que el navegador descargue es el hallazgo.

Todo lo que tu app necesita para funcionar en un navegador llega a ese navegador, así que una clave que esté ahí llega también. Algunas claves van ahí: una clave de Supabase anon o sb_publishable_ es una dirección y no un permiso, y encontrarla es correcto. Qué claves son seguras en un frontend y cuáles no es esa distinción entera.

Una clave secreta es la otra clase. Una clave de Supabase sb_secret_ o service_role ignora cualquier regla de tabla que hayas escrito jamás. Una clave de Stripe sk_live_ mueve dinero. Encontramos una clave de esa clase en 52 apps de 30.998, que es poco frecuente y lo peor de esta lista cuando ocurre. Si la tuya es una de ellas, rótala antes de hacer nada más: borrar la clave de tu código deja el valor antiguo funcionando.

2. ¿Puede un desconocido leer tu base de datos?

En Supabase, abre el Security Advisor. Cada entrada que diga que una tabla es pública pero la seguridad por filas no está activada es una tabla que le responde a cualquiera que pregunte, y ese aviso exacto tiene artículo propio.

Row Level Security es la regla que decide, fila por fila, quién puede ver qué. Sin ella, la clave pública que hay en tu app basta para leer la tabla, y esa clave está en el navegador de cada visitante por diseño.

Es el hallazgo serio más común de todo el conjunto: 2.096 de las 3.680 apps cuyo proyecto de Supabase nos respondió, o el 57 %, tenían al menos una tabla entregando filas a una petición sin nadie con sesión iniciada. Activarla en todas las tablas es el arreglo. El advisor lee tus ajustes y no las respuestas de tu base de datos, así que termina comprobando desde fuera: una tabla puede tener el ajuste activado y una política que deja pasar a todo el mundo igualmente.

3. ¿Puede cualquiera descargar tus archivos privados?

Abre tuapp.com/.env y tuapp.com/.git/config en una ventana privada. Ninguno de los dos debería abrirse.

Un archivo .env es cada clave que creías a salvo en el servidor, en una lista simple, en una dirección adivinable. Un directorio .git es la historia de tu proyecto. Ninguno está pensado para servirse, y de vez en cuando se sirven, normalmente porque una compilación copió una carpeta que no debía.

Es lo más raro que encontramos: 8 apps de 30.749. También son cinco segundos de trabajo descartarlo, y es de donde salen las filtraciones más dañinas cuando ocurre.

4. ¿Tus buckets de almacenamiento listan lo que contienen?

En Supabase, abre Storage. Lee la columna Public en cada bucket y luego abre las políticas de cualquier bucket que guarde algo que no sea para todo el mundo.

Aquí pasan dos cosas distintas y es fácil juntarlas. Un bucket público sirve cualquier archivo cuyo nombre ya conozca alguien. Un bucket listable entrega los nombres, lo que convierte "alguien tendría que adivinar" en un directorio de las subidas de tus usuarios. Nuestra comprobación prueba lo segundo, porque es lo que cambia lo que un desconocido puede hacer de verdad.

792 apps de 27.269 tenían un bucket que se listó ante nosotros sin sesión iniciada. Qué obtiene un desconocido de esa lista es la versión larga, y el arreglo suele ser un interruptor más una política.

Los cinco que pueden esperar a que tengas usuarios

Cabeceras, source maps, tus propias direcciones de API, el certificado y el dominio. Tres de ellos los fija normalmente quien aloja tu app, y dos son fechas en un calendario.

Ninguno entrega por sí solo una fila de tu base de datos, y por eso están en el segundo grupo. Uno de los cinco merece adelantarse si tu app tiene backend propio, y está señalado abajo.

5. ¿Están activadas las cabeceras de seguridad del navegador?

Es el único punto de la lista sin una versión que puedas hacer desde la barra de direcciones. Un escaneo las lee, o abres las herramientas de desarrollo de tu navegador, vas a la pestaña Red, pulsas la primera petición y lees las cabeceras de respuesta.

Son instrucciones pequeñas para el navegador: carga esta página solo por HTTPS, niégate a que otro sitio te meta en un marco, no adivines tipos de archivo. Su ausencia no expone nada por sí misma. Quita protecciones que hacen más difíciles otros ataques.

Casi nadie pasa este punto y casi nadie puede. A 30.756 apps de 30.981 les faltaba al menos una, y en un subdominio de builder el ajuste es de la plataforma. Si puedes hacer algo con las tuyas depende enteramente de dónde esté alojada tu app.

6. ¿Está publicado tu código fuente original?

Abre tu app en marcha, abre las herramientas de desarrollo de tu navegador y mira el panel Sources. Si tus propios archivos aparecen ahí con el código que escribiste y los comentarios que dejaste, los source maps salieron con la compilación.

Un source map es una tabla de traducción que convierte el archivo comprimido que envía tu app de vuelta en código legible. Los desarrolladores lo usan para depurar un sitio en marcha. Publicado en internet, significa que cualquiera puede leer tu app tal como la escribiste.

3.885 apps de 30.987 publicaron los suyos. No es una filtración por sí misma, y se convierte en una cuando el código contiene algo que dabas por hecho que nadie leería. Qué expone un source map publicado cubre la diferencia y el ajuste de compilación que lo apaga.

7. ¿Tus propias direcciones de API le responden a un desconocido?

Copia una de las direcciones de API de tu app desde la pestaña Red y luego ábrela en una ventana privada donde no tengas la sesión iniciada. Mira qué vuelve.

Este es el punto que conviene adelantar si tu app tiene backend propio, porque cualquier cosa que una dirección entregue a una petición sin sesión es pública, tenga la pinta que tenga la página que hay delante. 3.852 apps de 30.926 tenían al menos una.

El ajuste emparentado es CORS, que decide qué otros sitios web pueden llamar a tu app desde el navegador de un visitante. Un comodín ahí muchas veces está bien y de vez en cuando no, y cuál de los dos tienes merece leerse antes de cambiar nada.

8. ¿Está tu certificado a punto de caducar?

Pulsa el candado de la barra de direcciones, abre el certificado y lee la fecha de "Válido hasta".

Casi todos los alojamientos los renuevan solos y casi todos lo consiguen. 32 apps de 30.851 tenían un certificado caducado, a punto de caducar o no fiable. Cuando falla, los visitantes reciben un aviso del navegador a página completa diciéndoles que tu sitio no es seguro, y la mayoría se va.

9. ¿Está renovado tu dominio?

Entra en tu registrador, lee la fecha de caducidad y comprueba que la autorrenovación está activa y que la tarjeta que hay detrás no ha caducado.

Es el punto menos técnico de la lista y el único que puede sacar tu app de internet por completo. 55 apps de 30.980 tenían un dominio caducado o a punto de caducar. Un nombre vencido también lo puede registrar otra persona, junto con cada enlace que alguien haya hecho hacia él.

Qué llevan otras listas que no es una comprobación de seguridad

Copias de seguridad, monitorización de errores, código muerto y consejos sobre contraseñas. La primera es la que más probablemente te cueste algo, y no es una comprobación de seguridad, porque nada fuera de tu app puede decir si tienes una.

Esa es la razón honesta de que falte entre las nueve. Un escáner lee tu sitio en marcha; una copia de seguridad es una copia de tu base de datos guardada en otro sitio, y ninguna mirada desde fuera a tu app puede decir si existe, si está al día o si se restauraría. Aun así va en tu lista. Va en el tipo de lista que se lleva, no en el tipo que se recorre.

Las copias propias de Supabase dependen de tu plan y se quedan dentro de tu cuenta de Supabase, lo cual está bien hasta que el problema es la cuenta. Las tres vías para tener una copia tuya expone qué cubre cada una.

Si prefieres que ocurra sin ti, eso es Reeve Care. Hace una copia de tu base de datos de Supabase con la frecuencia que fija el plan que tengas, cada noche en el nivel de entrada y hasta cuatro veces al día en el más alto, lee cada copia de vuelta antes de que cuente como copia de seguridad, y la guarda donde Supabase no llega. Cuánto puedes retroceder lo fija el mismo plan. Restaurar es un botón, y toma una instantánea del estado actual antes de empezar, así que pulsarlo en pleno pánico no puede destruir lo que intentabas salvar. Los archivos subidos también entran, en cuanto conectas una credencial de Storage, que se pide por separado porque es la única clave que tenemos capaz de escribir: Supabase no emite una clave de solo lectura para archivos. Care empieza en $49 al mes por una app, y es un precio de lista, así que la página de precios a veces está por debajo de esa cifra y nunca por encima. Cómo se toma, se comprueba y se devuelve una copia está dibujado paso a paso en la página de copias de Supabase.

El resto de lo que llevan esas listas es trabajo de verdad y no este trabajo. La monitorización de errores te dice cuándo se rompe tu app, y eso es operaciones. "Quita las dependencias sin usar" es orden doméstico. "Usa contraseñas fuertes" vale para todo aquello donde hayas iniciado sesión alguna vez.

¿Cada cuánto debo repetir esto?

Después de cada despliegue que tocara tus reglas de base de datos, tus claves o tus ajustes de compilación. Si eso suena a casi todos los despliegues, suele serlo, y ahí está el problema real de una lista que se recorre una vez.

La vuelta al avión ocurre antes de cada vuelo justo por esto. Row Level Security se apaga a medianoche para que una página cargue y nadie la vuelve a encender. Se pega una clave en el frontend para sacar una función antes de una demo. Se abre un bucket para una subida y se queda abierto. Cada una de esas cosas es un martes normal, y cada una basta para convertir un resultado limpio en uno serio.

Reeve Monitor existe para esa brecha. Repite las nueve comprobaciones cada hora en hasta tres apps, mira cada 60 segundos si la app está en pie, te avisa el día en que un resultado cambia en lugar de esperar a que mires, y manda un informe mensual en lenguaje llano. Cuesta $12 al mes de precio de lista, con siete días gratis antes de cobrar, y la página de precios a veces está por debajo de esa cifra y nunca por encima. Monitor vigila y nada más. Las copias de seguridad son el plan Care que hay por encima, y Care guarda una copia de una base de datos de Supabase y de nada más.

Qué no demuestra nada de esto

Que tu app es segura. Nueve comprobaciones que vuelven limpias significan que nueve preguntas hechas desde fuera volvieron limpias el día en que las hiciste.

Cuatro cosas siguen siendo invisibles para cada punto de esta lista, porque ninguna sale jamás de tu servidor. Tu código de servidor, incluidas las funciones de base de datos y las edge functions que nadie de fuera puede leer. Las variables de entorno que mantuviste fuera del navegador, que es exactamente donde deben estar y también por qué un escaneo no puede confirmar que estén bien guardadas. Tu historial de versiones, donde sigue sentada una clave que subiste en marzo y quitaste en abril. Y la lógica propia de tu app, como si un usuario con sesión iniciada puede abrir el pedido de otro cambiando un número en la dirección.

Qué puede ver y qué no un escaneo por URL recorre esa frontera como es debido, incluidas las tres herramientas que leen cosas distintas y dónde está ciega cada una.

Qué hacer ahora mismo

Si tu app guarda sus datos en Supabase, la versión escrita alrededor de ese único stack es la guía de apps de Supabase. Y si prefieres algo para marcar en lugar de algo para leer, la lista de seguridad de 10 minutos es la versión interactiva.