La violación de Moltbook: Cuando la vibra de codificación se convierte en una pesadilla de seguridad

¿Qué sucedió realmente en Moltbook?

Déjame desglosar exactamente qué salió mal, porque los detalles importan.

Moltbook fue construido usando Supabase — una popular alternativa de código abierto a Firebase que proporciona bases de datos PostgreSQL alojadas. Supabase se ha convertido en el backend de elección para aplicaciones codificadas con vibe porque maneja autenticación, bases de datos y almacenamiento con mínima configuración.

El problema: alguien (o alguna IA) puso una clave API de Supabase directamente en el código JavaScript del lado del cliente. Este es un error de seguridad fundamental. Las claves API pertenecen al servidor, nunca en código que se ejecuta en el navegador de un usuario.

Pero se pone peor.

Esa clave de API tenía acceso de lectura y escritura completo a toda la base de datos. Y Moltbook no había habilitado Seguridad a Nivel de Fila (RLS)—una característica de Supabase que controla quién puede acceder a qué datos. RLS es tan opcional como un cinturón de seguridad. Podrías pensar que no lo necesitas hasta que te estrelles.

Investigadores de seguridad en Wiz encontraron la clave expuesta dentro de minutos de mirar el sitio web. Podrían haber:

• Descargadas todas las 1.5 millones de claves API (incluidas claves para OpenAI, Anthropic y otros proveedores de IA)
• Accedió a mensajes privados entre agentes de IA
• Modificado o eliminado cualquier dato en la base de datos
• Cuenta de usuario secuestrada
• Generar facturas masivas usando claves de API robadas

El quid de la cuestión: el fundador admitió que "completamente vibe-codeó" toda la plataforma. Sin revisión de código. Sin auditoría de seguridad. Solo instrucciones a una IA y copiando y pegando los resultados.

Por Qué Esto Sigue Sucediendo

Esto es lo frustrante de esta historia: no es única.

¿Recuerdas cuando DeepSeek tuvo sus claves de API expuestas? ¿O Base44? El patrón se repite porque la filosofía de vibe coding desalienta activamente las prácticas que previenen estas brechas.

La filosofía central de la programación vibe es: muévete rápido, enfócate en los resultados, no te preocupes por los detalles. Es seductora porque—honestamente—funciona para construir prototipos. Puedes crear una aplicación funcional en horas.

Pero las aplicaciones de producción viven en un mundo diferente. Manejan datos reales de usuarios, pagos reales, amenazas de seguridad reales. La misma mentalidad que te ayuda a enviar un prototipo en un fin de semana hará que tu aplicación de producción sea hackeada el día uno.

Hablé con un investigador de seguridad especializado en código generado por IA. Esto es lo que le quita el sueño:

• Sin comprensión de lo que está pasando: Cuando le pides a una IA que "construya un sistema de inicio de sesión", obtienes código que parece un sistema de inicio de sesión pero podría tener defectos sutiles que solo un experto detectaría
• Confiar en la IA: Los usuarios asumen que el código generado por IA es seguro porque... es de una IA? Esa suposición es completamente errónea
• Faltan fundamentos: los coders de vibe a menudo no saben lo que no saben sobre seguridad

El problema del 45%

Déjame darte un número que debería mantenerte despierto por la noche: 45%.

Ese es el porcentaje de código generado por IA que contiene vulnerabilidades de seguridad, según la investigación de Veracode sobre seguridad de software generado por IA^[1].

Esto no se trata de modelos de IA malos o desarrolladores incompetentes. Se trata de la naturaleza fundamental de la generación de código. Los modelos de IA están entrenados con código existente, que incluye código inseguro. Reproducen patrones que han visto, incluyendo vulnerables.

Vulnerabilidades comunes en código generado por IA incluyen:

La brecha de Moltbook fue en realidad dos problemas: una clave de API codificada (secretos codificados) Y falta de RLS (configuración insegura). Cualquiera de los dos solos habría sido malo. Juntos, crearon una catástrofe.

Lo Que Nadie Te Dice Sobre Vibe Coding

Déjame ser real contigo. He vibe coded muchos proyectos. Ha cambiado genuinamente cómo construyo cosas. Pero también he aprendido algunas lecciones duras de la manera difícil.

Todavía Necesitas Entender Seguridad

Aquí hay una verdad incómoda: no puedes usar herramientas de IA para construir aplicaciones seguras si no entiendes la seguridad tú mismo. La IA no conoce tu modelo de amenazas. No sabe qué activos estás protegiendo. Solo genera código que parece razonable.

No necesitas convertirte en un experto en seguridad. Pero sí necesitas entender:

• Nunca pongas secretos en código del lado del cliente
• Siempre habilita Seguridad a Nivel de Fila en bases de datos
• Utiliza variables de entorno para la configuración sensible
• Implementar validación de entrada adecuada
• Ejecuta escaneos de seguridad en el código generado

Prototipar Rápido, Luego Ingeniería

Mi flujo de trabajo actual:

• Codificar el prototipo con vibes — Conseguir algo funcional, validar la idea con usuarios reales
• Identificar ajuste producto-mercado — Antes de invertir en nada
• Refactorizar para producción — Aquí es donde realmente ingenierías la seguridad, el rendimiento y la mantenibilidad

El error es enviar prototipos codificados con vibe directamente a producción sin el paso de refactorización. No estás ahorrando tiempo — estás acumulando deuda técnica que te costará más tarde.

Usa la herramienta adecuada para el trabajo

Esto podría ser controvertido, pero no creo que la programación por vibes sea apropiada para:

• Aplicaciones que manejan datos sensibles del usuario (salud, finanzas)
• Sistemas que procesan pagos
• Cualquier cosa con requisitos de cumplimiento regulatorio
• Aplicaciones donde fallos de seguridad podrían causar daño real

Para herramientas internas, MVPs y prototipos? Haz lo que quieras. Para sistemas de producción que manejan datos reales de usuarios? Ingeniéralo adecuadamente.

Cómo Protegerte

Si vas a codificar por vibra de todos modos (y honestamente, deberías hacerlo: es increíblemente poderoso), aquí está cómo evitar convertirte en el próximo titular:

Para Tu Supabase/Backend

javascript
// WRONG - Never do this
const supabase = createClient('https://xxx.supabase.co', 'YOUR_ANON_KEY_HERE')
// Your service_role key is also exposed here!

// CORRECT - Use environment variables, server-side only
const supabase = createClient(
  process.env.SUPABASE_URL,
  process.env.SUPABASE_ANON_KEY
)

Lista de Comprobación de Seguridad Esencial

• [ ] Habilitar Seguridad a Nivel de Fila en TODAS las tablas de base de datos
• [ ] Almacena claves de API en variables de entorno, nunca en el código
• [ ] Ejecutar un escaneo de seguridad en todo el código generado (Snyk, CodeQL, o GitHub Advanced Security)
• [ ] Nunca expongas claves service_role al cliente
• [ ] Implementa una validación de entrada adecuada en todas las entradas del usuario
• [ ] Configura límite de tasa para prevenir abuso
• [ ] Consigue una prueba de penetración antes de lanzar cualquier cosa con usuarios reales

Herramientas Que Ayudan

Qué Significa Esto para la Industria

Sinceramente estoy preocupado por hacia dónde vamos.

Estamos en medio de un cambio masivo en cómo se construye el software. Los fundadores no técnicos ahora pueden crear aplicaciones sofisticadas. La barrera de entrada se ha derrumbado. Eso es genuinamente emocionante.

Pero también estamos creando una generación de aplicaciones sin que nadie vigile la tienda.

Aquí está lo que creo que necesita suceder:

• Las herramientas de codificación con IA necesitan mejores valores predeterminados de seguridad — Deja de generar código con vulnerabilidades incorporadas
• Las comunidades necesitan hablar más de esto: Cada publicación de blog sobre codificación por vibe debería mencionar seguridad
• Necesitamos mejores herramientas — El escaneo de seguridad automatizado debería estar integrado en cada flujo de trabajo de codificación con IA
• Los fundadores deben asumir la responsabilidad — No puedes culpar a la IA cuando algo sale mal

El futuro del desarrollo de software no es elegir entre velocidad de IA y seguridad. Es aprender a usar ambos juntos.

Preguntas frecuentes

La conclusión

Moltbook no es una anomalía. Es una preview de lo que viene.

A medida que más fundadores lanzan aplicaciones codificadas con vibe sin comprender los fundamentos de seguridad, veremos más violaciones. Más claves de API filtradas. Más bases de datos expuestas. Más víctimas.

Esto no es un argumento contra la codificación por vibes. Es un argumento para ser honesto sobre sus limitaciones.

Envía rápido. Prueba ideas. Muévete rápido. Pero antes de poner datos reales de usuario en riesgo, ralentiza y haz el trabajo de seguridad. Tus usuarios te están confiando su información. Esa confianza no debería ser borrada por codificación por vibra.

Posts Relacionados

• ¿Qué es el Vibe Coding? La guía completa de 2026
• Cursor vs Windsurf para Programación Vibe: ¿Quién Gana en 2026?
• Cómo Crear una Aplicación de IA en 7 Días (Paso a Paso
• Cómo Conseguir 100 Usuarios Beta Rápido

¿Listo para lanzar tu aplicación de forma segura? Publica tu aplicación en GetFree—un directorio curado donde los desarrolladores comparten códigos promocionales y acceso beta con miles de probadores específicos.

Fuentes

Originalmente publicado en Blog de GetFree.APP — Última actualización: 17 de febrero de 2026