La mayoría de los codificadores "vibe" siguen lanzando aplicaciones sin seguridad alguna. Se enfocan en las funciones, el diseño y lanzar rápido. Lo aburrido les parece tarea escolar.
Algunos están pagando el precio. Facturas de Supabase de $200 de la noche a la mañana. Inundaciones de spam desde el día uno. Unos pocos están recibiendo cartas de cese y desistimiento que no vieron venir.
Y luego está ese pequeño grupo que ejecuta en silencio una lista de verificación de 30 minutos antes de cada lanzamiento. El tipo de cosas que no se ven en tu demo, pero que determinan si tu aplicación sobrevive a sus primeros usuarios reales.
Primero compartí una versión rápida de esto como una publicación. Obtuvo más de 900,000 visitas, y las respuestas y mensajes directos pedían todos lo mismo: el análisis profundo completo. El contexto de agencia. Las partes que tuve que recortar para ajustarme a los límites de caracteres. Así que muchos de ustedes lo pidieron, y aquí está, ahora actualizado para donde realmente estamos en 2026.
He construido más de 60 MVP en la agencia en casi 2 años. He lanzado productos en 21 días que fueron directamente a producción. Y he aprendido que la seguridad no es algo que se agregue después. Es algo que se integra antes del lanzamiento, o se paga con apagones de incendios, reembolsos y daños a la reputación.
Este artículo es la versión completa. Empieza con lo que un desarrollador con más de 20 años de experiencia compartió en Reddit, y luego lo apila con todo lo que ejecutamos en cada proyecto de la agencia antes de dejar que algo salga a producción.
Aquí está el desglose completo.
Lo que la publicación de Reddit acertó (y lo que omitió)
Un desarrollador con más de 20 años de experiencia compartió recientemente una lista de verificación previa al lanzamiento en Reddit que se volvió viral en la comunidad de codificación "vibe". Era concisa. Cinco categorías. Indicaciones reales que puedes copiar en Claude o Cursor.
Acertó en lo fundamental.
→ Protégete legalmente antes de recopilar un solo correo electrónico
→ Usa IA para auditar tu propia postura de seguridad en 2 minutos
→ Alíneate con OWASP, no solo con los encabezados de seguridad
→ Verifica filtraciones de datos en el frontend y en las rutas de la API
→ Nunca envíes claves de API al navegador
Pero después de auditar docenas de aplicaciones codificadas "vibe" antes de cotizar reconstrucciones para clientes, hay una capa debajo que casi todos los constructores pasan por alto.
La publicación de Reddit cubrió la superficie. Este artículo cubre los cimientos debajo. Ambos importan. Si solo haces uno, sigues expuesto.
El problema con cómo la mayoría de los codificadores "vibe" abordan la seguridad
La mayoría de los constructores tratan la seguridad como una función que agregarán en la versión 2.
No es una función. Es el piso.
La IA te permite lanzar un producto en un fin de semana. Esa misma velocidad te permite lanzar un pasivo en un fin de semana. El código se ve limpio. La interfaz se ve pulida. La demo funciona perfectamente. Nada de eso te protege cuando alguien abre las herramientas de desarrollador y lee toda tu base de datos.
Cuando los fundadores vienen a nosotros en la agencia pidiéndonos que reconstruyamos un MVP roto, las mismas cinco categorías de falla aparecen casi siempre. Bases de datos abiertas. Flujos de autenticación que filtran información. Claves de API en los paquetes del frontend. Sin límites de tasa en endpoints costosos. Mensajes de error que mapean todo el esquema para cualquier atacante que los active.
La solución no es la paranoia.
La solución es una lista de verificación de 30 minutos que ejecutas antes de cada lanzamiento. Cinco categorías. La misma que ejecutamos en la agencia. La misma que te voy a explicar.
Sección 1: Protégete a ti mismo, no solo a tu aplicación
En el momento en que recopilas datos de usuario, estás en territorio legal. GDPR. CCPA. Términos de servicio de la plataforma.
La mayoría de los codificadores "vibe" no piensan en esto hasta que es demasiado tarde.
Tres mínimos.
→ Una política de privacidad real, incluso si es generada. Termly y PrivacyPolicies.com hacen esto gratis en menos de 5 minutos.
→ Saber exactamente dónde viven tus datos de usuario. Región de Supabase, región de Vercel, cualquier servicio de terceros que toque los datos.
→ Nada turbio. Sin vender datos de usuario. Sin exportarlos a tu correo personal. Sin mantener contraseñas en texto plano.
No perfecto. Solo no imprudente.
Este es el trabajo de 10 minutos más barato que harás en todo el año y es la diferencia entre un lanzamiento normal y recibir un correo de cese y desistimiento en la segunda semana.
Lo que cambió en 2026, y por qué esta sección importa más ahora.
El terreno legal para las aplicaciones construidas con IA cambió este año, y la mayoría de los constructores no se han puesto al día.
→ La Corte Suprema dejó en pie el fallo sobre autoría humana. El código escrito puramente por IA no puede tener derechos de autor en EE. UU. Si un competidor clona tu aplicación construida con IA línea por línea, es posible que no tengas base legal para detenerlo.
→ Si tu IA incorpora silenciosamente código de código abierto bajo una licencia como GPL, puedes ser forzado a abrir todo tu código fuente, o enfrentar una reclamación por infracción. Obtienes toda la responsabilidad y ninguna de las protecciones.
→ El caso de derechos de autor de IA más grande hasta la fecha terminó en un acuerdo de $1.5 mil millones, y obtuvo la aprobación final del tribunal esta semana. Los abogados no vienen. Ya están aquí.
Nada de esto significa que dejes de construir. Significa que dejes de lanzar a ciegas. El resto de esta lista de verificación es cómo hacerlo.
Sección 2: Bloquea tu base de datos
Esta es la sección en la que pasamos más tiempo cuando auditamos proyectos entrantes. Casi todas las aplicaciones codificadas "vibe" que hemos abierto fallan al menos en una de las tres verificaciones a continuación.
Seguridad a nivel de fila (RLS) en Supabase.
Sin RLS, cualquiera puede abrir las herramientas de desarrollador del navegador, ejecutar una consulta y leer toda tu base de datos. No es un hackeo. No es una explotación. Solo abrir la consola y escribir un comando.
Ve a tu panel de Supabase. Haz clic en Authentication, luego en Policies. Si ves cero políticas, tu aplicación está desnuda.
La solución es simple. Agrega políticas que restrinjan quién puede leer, insertar, actualizar o eliminar filas según el usuario autenticado. Si usas Lovable o Bolt, solo pídele al agente que habilite RLS y escriba políticas para tus tablas. Generará el SQL automáticamente.
5 minutos. La diferencia entre una aplicación segura y una violación de datos a punto de ocurrir.
Validación del lado del servidor en cada formulario.
Zod en el cliente no es seguridad. Es experiencia de usuario.
Los atacantes deshabilitan JavaScript, abren Postman y envían lo que quieran directamente a tu API. Si tu única validación está en el frontend, pueden enviar datos malformados, intentos de inyección SQL o scripts. Si tu formulario escribe en la base de datos, valídelo NUEVAMENTE en el servidor. Verifica los tipos de datos. Verifica los límites de longitud. Sanea las entradas.
Esto es lo básico. No es opcional.
Mensajes de error que no filtran datos.
Mensaje de error malo: "SELECT * FROM users WHERE email falló."
Eso le dice a un atacante los nombres de tus tablas, nombres de columnas y lógica de consulta.
Mensaje de error bueno: "Usuario no encontrado."
Registra los errores completos del lado del servidor con contexto. Muestra mensajes genéricos a los usuarios. Nunca expongas trazas de pila en producción. Seguridad operativa básica. La mayoría de las aplicaciones fallan en esto desde el día uno.
Los mensajes malos entregan tu esquema a los atacantes. Los mensajes buenos no revelan nada.
Un indicador. La mayoría de tus vulnerabilidades OWASP señaladas en 30 segundos.
Sección 3: Prueba los casos de fallo en la autenticación
La mayoría de los desarrolladores solo prueban el camino feliz. Registrarse con un correo válido. Iniciar sesión. Lo dan por terminado.
Las aplicaciones se rompen cuando las cosas salen mal. Ahí es exactamente donde los atacantes prueban primero.
Aquí está la prueba de 4 puntos de casos de fallo exacta que ejecutamos antes de dar el visto bueno a cualquier proyecto.
→ Inicia sesión con la contraseña incorrecta 5 veces seguidas. ¿Bloquea la cuenta? ¿Muestra un error genérico o confirma que el correo existe?
→ Restablece la contraseña para un correo que no existe. ¿Revela si el correo está en el sistema?
→ Haz clic en el enlace de verificación de correo dos veces. ¿Rompe el flujo o lo maneja con elegancia?
→ Regístrate con un correo que ya está registrado. ¿Filtra que el usuario ya existe?
10 minutos de prueba. Atrapa el 80% de las vulnerabilidades de autenticación antes de que salgan a producción.
Hemos ejecutado esta misma prueba en cada auditoría entrante que hemos hecho este año. Ha detectado problemas en aproximadamente 7 de cada 10 bases de código. Los codificadores "vibe" con interfaces hermosas fallaron esto todas las veces.
Sección 4: Las 4 indicaciones de IA que ejecutas antes de cada lanzamiento
Esta es la parte que la publicación de Reddit acertó. Estas cuatro indicaciones cubren el 80% de la auditoría de seguridad superficial y toman alrededor de 8 minutos en total.
Las ejecutas dentro de Claude Code, Cursor, o cualquier agente con el que construyas. Guárdalas. Hazlas parte de tu ritual de lanzamiento.
Indicación 1. Postura de seguridad base.
Revisa mi aplicación como un especialista en seguridad y asegúrate de que tenga
encabezados de seguridad sólidos y una postura de seguridad base sólida.
2 minutos. Corrige las brechas obvias. Los encabezados solos no son suficientes, pero son el piso.
Indicación 2. Verificación de estándares OWASP.
Revisa mi aplicación contra los estándares OWASP y resalta las vulnerabilidades.
Aquí es donde realmente se detectan la inyección SQL, XSS y problemas de autenticación.
Indicación 3. Auditoría de filtraciones de datos.
Revisa mi aplicación en busca de cualquier fuga de credenciales o datos sensibles en
el frontend o rutas de la API.
El código generado por IA filtra datos en 3 lugares casi siempre. Valores de .env que terminan en el código del frontend. Respuestas de API que devuelven demasiados datos. Secretos que aparecen en registros.
Indicación 4. Verificación de exposición de claves de API.
Asegúrate de que no haya claves de API expuestas en el código del frontend o en llamadas de red.
Si tu clave está en el navegador, asume que ya ha sido tomada. Este solo error ha agotado proyectos independientes completos en un solo fin de semana.
Profundizando en las claves de API.
Esa indicación detecta los casos obvios. Aquí está la regla que ejecutamos en cada proyecto más allá de eso.
Las claves públicas pueden permanecer en el frontend. Las claves anónimas de Supabase, las claves publicables de Stripe, cualquier cosa explícitamente marcada como pública. Están diseñadas para estar expuestas.
Las claves secretas deben permanecer del lado del servidor. Las claves de rol de servicio, las claves secretas de Stripe, las claves de OpenAI, cualquier cosa sin un prefijo "publicable". Guárdalas en los Secretos de las Funciones Edge de Supabase o en las variables de entorno de Vercel. Nunca las confirmes en el control de versiones. Nunca las pegues en tu código del frontend.
Si crees que una clave puede haber sido expuesta, regenérala inmediatamente. No esperes. No esperes que nadie la haya encontrado. Los repositorios públicos de GitHub son rastreados en busca de claves en cuestión de minutos.
Dos minutos para saber si tus encabezados de seguridad están haciendo algo.
Sección 5: Protege tu infraestructura
Esta es la sección que protege tu billetera, no solo tus datos.
Límites de tasa en cada endpoint.
Esta es la forma más rápida en que una aplicación codificada "vibe" vacía tu billetera. Sin límites de tasa, alguien puede enviar spam a tu API 10,000 veces en un minuto. Tal vez forzando un inicio de sesión por fuerza bruta. Tal vez raspando tu base de datos. Tal vez solo siendo malicioso.
He visto personalmente una factura de Supabase saltar de $20 a $200 en un solo día en un proyecto secundario porque un endpoint no tenía límite de tasa. Ocurre rápido.
Tres mínimos.
→ Limita la tasa de cada endpoint que golpee una API paga (OpenAI, Anthropic, Stripe, Resend)
→ Establece límites diarios duros en los paneles de OpenAI y Anthropic
→ Configura alertas al 50% de tu límite diario para detectar un pico antes de que te golpee por la mañana
Para las Funciones Edge de Supabase, Upstash es la solución de límite de tasa más fácil. 100 solicitudes por minuto por IP para endpoints públicos, 1,000 por minuto para usuarios autenticados es una línea base sensata.
CAPTCHA en cada formulario público.
Formularios de contacto, páginas de registro, listas de espera. Sin CAPTCHA, los bots te inundan desde el día uno. Hemos visto formularios de contacto recopilar 500 envíos de spam en una hora en aplicaciones sin protección.
Cloudflare Turnstile es gratuito y centrado en la privacidad. La integración toma 10 minutos.
Restricciones CORS en tu API.
Por defecto, muchos frameworks permiten solicitudes API desde cualquier lugar. Bien para desarrollo local. Desastre en producción.
Especifica exactamente qué dominios pueden acceder a tu API. Permite tu dominio de producción. Permite localhost para pruebas. Bloquea todo lo demás. 2 minutos. Previene la falsificación de solicitudes entre sitios y el acceso no autorizado a la API.
Límites duros y alertas. La configuración de 3 minutos que salva tu factura mensual.
Ejecuta el escaneo de seguridad integrado al final
Las 4 indicaciones de la Sección 4 son manuales. Las pegas y lees lo que devuelve. Desde hace 3 días, tienes algo mejor para la puerta final.
Anthropic acaba de lanzar un plugin de seguridad de Claude para Claude Code.
Está en beta, lanzado el 22 de julio, y no es una sola indicación. Es un escáner de vulnerabilidades multi-agente que se ejecuta directamente en tu terminal. Instálalo dentro de una sesión de Claude Code:
/plugin install claude-security@claude-plugins-official luego /reload-plugins. Eso te da un comando, /claude-security.
Lo que lo hace diferente de pegar una indicación.
→ Un equipo de agentes mapea tu arquitectura, construye un modelo de amenazas, luego busca en 4 categorías: inyección, autenticación y acceso, memoria, y criptografía y secretos
→ Cada hallazgo tiene que sobrevivir a un panel adversarial de 3 agentes antes de llegar a tu informe, para que no tengas que lidiar con falsos positivos
→ El informe te da severidad, ID de CWE, y el archivo y línea exactos, y puede convertir los hallazgos en archivos de parche que revisas y aplicas tú mismo
→ El modelo detrás ya ha encontrado más de 500 vulnerabilidades de alta severidad previamente desconocidas en bases de código de código abierto
Necesitas un plan pago de Claude Code (v2.1.154 o más reciente), y los escaneos usan los tokens de tu plan.
Cursor y constructores visuales como Lovable también envían sus propios escáneres que señalan configuraciones incorrectas de RLS, secretos expuestos, dependencias vulnerables y patrones inseguros. Ejecuta el que tenga tu stack.
Arregla todo lo que señalen. No envíes con advertencias. No te digas a ti mismo que lo arreglarás después. La deuda de seguridad se capitaliza más rápido que la deuda de funciones.
Trata este escaneo como la puerta final antes del despliegue. Las indicaciones manuales detectan lo que el escáner pasa por alto. El escáner detecta lo que olvidas indicar. Ahora que Anthropic ha construido uno real en Claude Code, no hay excusa para saltarlo.
Cuándo usar esta lista de verificación
Esta lista de verificación está diseñada para el 80% de los constructores que envían MVP, SaaS, herramientas de IA, o cualquier cosa con datos de usuario.
Úsala cuando:
→ Estés lanzando cualquier aplicación que recopile datos de usuario, incluso un correo electrónico
→ Estés ejecutando en Supabase, Firebase, o cualquier backend con acceso a la base de datos
→ Estés llamando a APIs pagas (OpenAI, Anthropic, Stripe) desde tu base de código
→ Estés a punto de compartir tu aplicación públicamente por primera vez
Introdúcela gradualmente cuando:
→ Estés lanzando herramientas internas usadas solo por tu propio equipo detrás de autenticación
→ Estés trabajando con un equipo de seguridad que ya ejecuta una auditoría más completa
→ Estés en modo de exploración previa al MVP y no estés recopilando ningún dato de usuario
Para la mayoría de los codificadores "vibe" que lanzan algo real, cada elemento de esta lista aplica. Saltarse cualquiera de ellos es asumir una responsabilidad que no necesitas.
Qué tener en cuenta
Algunas banderas honestas antes de que trates esto como la palabra final.
Esta lista de verificación te lleva a una línea base segura, no a un cumplimiento de nivel empresarial. Si estás almacenando datos de salud, datos financieros o cualquier cosa regulada, necesitas una auditoría de seguridad real además de esto.
Las indicaciones y escáneres de IA detectan problemas superficiales. No detectan vulnerabilidades de lógica de negocio, errores complejos de estado de autenticación o ataques de inyección sofisticados. Trátalos como el piso, no el techo.
La deuda de seguridad se capitaliza. Cuanto más esperes, más dolorosa será la limpieza. Ejecuta esto antes de cada lanzamiento, no solo una vez al principio.
Las políticas de RLS son fáciles de escribir incorrectamente. Pruébalas intentando acceder a datos como un usuario diferente. Solo habilitar RLS sin probar es peor que no tenerlo porque crea una falsa confianza.
Lo que esto realmente significa
Aquí está mi opinión honesta.
La economía de la codificación "vibe" está madurando rápido. Hace un año podías lanzar cualquier cosa y a nadie le importaba. Ahora las plataformas están haciendo cumplir políticas de seguridad. Los usuarios lo esperan. Los inversores lo están verificando. Los tribunales han trazado líneas reales este año, y los abogados han comenzado a aparecer.
Los 30 minutos que te saltas antes del lanzamiento te costarán 30 días de apagones de incendios cuando algo se rompa. Lo hemos visto desarrollarse en múltiples auditorías entrantes este año, donde los fundadores vinieron a nosotros pidiendo una reconstrucción después de que su primera versión comenzara a filtrar datos o quemar efectivo.
En la agencia tratamos esta lista de verificación como el despliegue. No es opcional. Es parte del lanzamiento. Y con Anthropic integrando ahora un escáner de seguridad directamente en Claude Code, la brecha entre los constructores que ejecutan esto y los codificadores "vibe" que lo saltan se va a ampliar aún más rápido.
No necesitas ser paranoico. No necesitas seguridad de nivel empresarial desde el día uno. Solo necesitas esta lista de verificación.
Ejecútala antes de cada lanzamiento. Hazla parte de tu flujo de trabajo. Trátala como las pruebas o el despliegue.
Porque las aplicaciones que sobreviven en 2026 no son solo las que se lanzan rápido. Son las que se lanzan rápido y no se rompen cuando llegan los usuarios reales.
2026 va a ser INJUSTO para los constructores que tratan la seguridad como un flujo de trabajo en lugar de una ocurrencia tardía.
TLDR
→ Los codificadores "vibe" están siendo demandados, multados y agotados. La mayoría aún no se ha dado cuenta.
→ Nuevo en 2026: El código solo de IA no puede tener derechos de autor en EE. UU., la contaminación GPL puede obligarte a abrir todo tu código fuente, y el acuerdo de derechos de autor de IA más grande de la historia ($1.5 mil millones) acaba de obtener la aprobación final del tribunal. Protégete primero.
→ Paso 1. Protégete legalmente. Política de privacidad, ubicación de datos, sin manejo turbio.
→ Paso 2. Bloquea tu base de datos. RLS en Supabase, validación del lado del servidor en cada formulario, mensajes de error que no filtren datos.
→ Paso 3. Prueba los casos de fallo en la autenticación. Contraseña incorrecta 5 veces. Restablecimiento de contraseña para un correo falso. Enlace de verificación clickeado dos veces. Registro con correo existente.
→ Paso 4. Ejecuta las 4 indicaciones de seguridad de IA. Postura de seguridad. OWASP. Filtraciones de datos. Exposición de claves de API.
→ Bloquea las variables de entorno. Las claves públicas pueden vivir en el frontend. Las claves secretas van en los Secretos de las Funciones Edge de Supabase o en las variables de entorno de Vercel. Si se exponen, regenera inmediatamente.
→ Paso 5. Protege tu infraestructura. Limita la tasa de cada endpoint. Establece límites duros en APIs pagas. CAPTCHA en formularios públicos. Restricciones CORS en tu API.
→ Ejecuta un escáner real como tu puerta final. El nuevo plugin de seguridad de Claude de Anthropic ejecuta un escaneo multi-agente directamente en tu terminal. Beta, planes pagos de Claude Code.
→ Esto toma 30 minutos. Ejecútalo antes de cada lanzamiento.
→ La brecha entre los constructores que ejecutan esto y los que lo saltan se va a ampliar rápido en 2026.
Publicación completa de Reddit que desencadenó esto. https://www.reddit.com/r/vibecoding/comments/1sthzcj/if_youre_about_to_launch_a_vibe_coded_app_read/
Captura de pantalla esto. Ejecútalo antes de cada lanzamiento.
¡Vamos!
