Fix: vibe coding × seguridad

La IA construyó todo lo que pediste.
La brecha está en lo que no pediste.

Un desarrollador web en r/VibeCodeDevs lo resumió en una línea: 'la IA hace lo que le pedís. Solo que nunca piensa en lo que no le pediste'. La historia canónica dio la vuelta por Hacker News — el SaaS vibe-coded de un founder filtró su lista de usuarios en el frontend, un hacker sacó la key de Stripe y le emitió un reembolso a cada cliente, y el founder ahora está contratando un desarrollador para apuntalarlo. No necesitás volverte ingeniero de seguridad para evitar ese final. Necesitás una base donde las preguntas que no hiciste ya tengan respuesta.

Un solo patrón detrás de cada brecha en apps hechas con IA

La herramienta importa poco. El reporte 2025 de Veracode sobre seguridad de código GenAI encontró que los asistentes de IA eligieron implementaciones inseguras en cerca del 45% de los casos de prueba cuando tuvieron la opción. Las fallas riman en todos lados: secrets en código del cliente, checks de tenancy que existen en algunas queries y en otras no, auth que renderiza una pantalla de login sin verificar las llamadas a la API, handlers de webhooks que le creen a lo que llegue. El mercado ya le puso precio a este dolor — una industria entera de 'rescate de vibe code' hoy cotiza sus auditorías y parches en miles de dólares, y las propias comunidades se pusieron estrictas: un consenso de r/vibecoding con 195 upvotes califica de 'tremendamente irresponsable' lanzar al público un backend hecho con IA sin auditar. Nada de esto dice que estuvo mal construir como construiste. Dice que la app se ganó un backend de verdad.

La auto-auditoría de 20 minutos

Buscá en tu propio bundle

Abrí tu app deployada, mirá el código fuente y buscá 'sk_', 'secret' y 'key'. Toma dos minutos y es el primer movimiento exacto de un atacante. Cualquier hit significa rotar la credencial hoy.

Pedí los datos de otro

Logueate con tu cuenta, anotá un ID de cualquier respuesta de la API, y pedí un ID distinto que no sea tuyo. Si vuelven datos, tenés un agujero de tenancy — y también lo tiene cada cuenta de tu base de datos.

Cambiá tu contraseña, dejá la pestaña vieja

Reseteá tu contraseña y después usá una sesión que ya estaba abierta. Si sigue andando, las sesiones robadas sobreviven a los intentos de tus usuarios de echar a los intrusos.

Repetí un webhook

Mandá el mismo evento de pago a tu endpoint de webhooks dos veces. Si tu app lo procesa dos veces — crédito doble, email doble, cambio de estado doble — los reintentos reales del provider te van a hacer esto en producción.

Martillá tu propio login

Scripteá 30 intentos con contraseña incorrecta en un minuto. Si nada te frena, las listas de credential stuffing corren contra tus usuarios a máxima velocidad, y sus contraseñas reusadas se vuelven tu brecha.

La pared: cómo debería verse el intento número cinco

En useDeploy, los endpoints de auth tienen su propio tier de rate limit con dos buckets — por IP y por email — así que una corrida de stuffing choca la pared sin importar cómo distribuya el tráfico. Es uno de varios bordes que fallan cerrados: la respuesta a '¿alguien agregó throttling?' es sí, porque estaba antes de tu primer commit.

terminal — credential stuffing contra el tier de auth
 1  $ ./stuff-credentials.sh [email protected]   # 50 intentos
 2  attempt 01  →  401 Unauthorized
 3  attempt 02  →  401 Unauthorized
 4  attempt 03  →  401 Unauthorized
 5  attempt 05  →  429 Too Many Requests
 6  attempt 50  →  429 Too Many Requests
 7  
 8  # saltó el limiter por email; el tier por IP también contaba.
 9  # auth, lectura y escritura tienen cada uno su propio bucket.

Cada punto de la auditoría de arriba, ya cerrado

Nada secreto en el bundle

Los secrets existen solo en el env del server, validados por un schema de Zod al boot — el server ni siquiera arranca con una credencial faltante, y el cliente nunca recibe ninguna.

El ID de otro recibe un 404

Repositorios org-scoped más un query guard de Prisma hacen que los requests cross-tenant devuelvan 404 — ni los datos, ni siquiera la confirmación de que el recurso existe.

Sesiones que controlás desde el server

Las sesiones son filas en Postgres, revocables a voluntad. Cerrar todas las sesiones concurrentes cuando cambian las credenciales es un flag documentado que activás — no un subsistema que construís después de un incidente.

Los replays de webhooks se absorben

Los webhooks de billing entrantes dedupean por externalOrderId sobre un outbox durable; los salientes van firmados con HMAC para que los receptores verifiquen que los mandaste vos.

Auth con las partes difíciles hechas

2FA TOTP, magic links, OAuth y RBAC scopeado por organización con API keys — vía BetterAuth, cableado y testeado en vez de bosquejado.

450+ tests montando guardia

Los comportamientos de arriba los asertan 450+ tests automatizados más un gate E2E de Playwright en CI. Un cambio que reabre un hueco cerrado rompe el build antes de shippear.

Ruta de migración: la haya hecho la herramienta que sea

El patrón es el mismo en todos los AI builders, así que la migración también. Exportá tu código — toda herramienta grande tiene sync a GitHub o descarga. Quedate con el frontend donde se gana su lugar; suele ganárselo, porque la UI es lo que estas herramientas hacen genuinamente bien. Después reconstruí el piso sobre la base, en orden de radio de daño: rotá cada credencial que alguna vez tocó código de cliente generado, mové el acceso a datos detrás de la API tipada donde el tenant guard scopea cada query, dejá que BetterAuth reemplace el auth que se haya improvisado, y enchufá el billing al pipeline de webhooks idempotente. Tu herramienta de IA sigue en el loop — la base shippea reglas para agentes, contratos tipados y fronteras enforzadas por lint justamente para que puedas seguir construyendo a prompt, ahora adentro de paredes. Si sabés qué herramienta hizo tu app, las guías por herramienta cubren Lovable, Bolt, v0, Replit y Cursor en detalle.

Apps vibe-coded × seguridad, sin vueltas

¿Tengo que tirar mi app?+
Casi nunca. El frontend y el pensamiento de producto — flujos, pantallas, copy — son trabajo real que vale conservar. Lo que se reemplaza es el backend improvisado: auth, tenancy, billing y secrets se mudan a una base donde ya están construidos y testeados.
¿Qué filtración arreglo primero?+
Las credenciales expuestas, siempre — rotálas antes de tocar cualquier código, porque borrar una key del repo no la revoca. Después tenancy (¿los usuarios pueden leerse los datos entre sí?), después sesiones y webhooks. La auto-auditoría de arriba está en orden de prioridad.
¿Cómo está vetada la base en sí?+
Es código a la vista que podés leer, con 450+ tests automatizados y un gate E2E de Playwright en CI cubriendo el comportamiento de auth, tenancy y billing. Eso es evidencia de ingeniería, no un certificado de compliance — si necesitás SOC 2, la base es un cimiento sobre el cual construirlo, no un sustituto.
Mi herramienta no es Lovable, Bolt, v0, Replit ni Cursor.+
El consejo vale igual — el patrón de falla es el mismo en todos los AI builders porque la causa es la misma: la IA construye lo que pedís, y la seguridad es lo que nadie pidió. Corré la auto-auditoría, rotá lo que encuentre y migrá el piso de la misma manera.

Una licencia. Dos formas de tenerla.

CORE

Founder

$99pago único

Un snapshot congelado de UseDeploy. Tuyo para siempre, sin updates.

  • Descarga del zip con versión frozen
  • Código completo, uso comercial, proyectos ilimitados
  • Los 800+ tests · todas las páginas de docs
  • Refund a 14 días
RECOMMENDED

LATEST + UPDATES

Lifetime

$199$249pago único

Siempre el último UseDeploy. Re-descargá cada release, gratis.

  • Zip de la última versión — re-descargable para siempre
  • Cada release futuro sin cargo extra
  • Soporte Discord priority
  • Los 800+ tests · todas las páginas de docs
  • Refund a 14 días

La app la construiste vos. Ahora cerrala.

Quedate con lo que hiciste — ponelo sobre una base donde las sesiones, la tenancy, los secrets y el billing ya están blindados y 450+ tests los mantienen así.