Cómo asegurar una aplicación con código vibe antes de entregarla a los clientes

Si codificaste una aplicación con Claude o Cursor y estás a punto de entregársela a un cliente que paga, detente. El código generado por IA viene con agujeros de seguridad predecibles — claves API expuestas, validación de entrada faltante, permisos de base de datos predeterminados que permiten a cualquier usuario ver los datos de todos los demás. Estos no son casos extremos. Suceden en casi todos los primeros intentos de bases de código generadas por IA.

Esta guía es la lista de verificación de seguridad previa al lanzamiento. Síguelo paso a paso antes de que ningún usuario real acceda a tu aplicación. Está escrito para la pila de vibe coding más común (Next.js + Supabase + Vercel), pero los principios aplican independientemente de tus herramientas.

Por Qué el Código Generado por IA Tiene Problemas de Seguridad

Los modelos de IA optimizan para "¿funciona?" no para "¿es seguro?" Cuando le dices a Claude "construye un gestor de tareas con cuentas de usuario", generará código que crea usuarios, almacena tareas y las muestra. Lo que probablemente no hará automáticamente: asegurar que el Usuario A no pueda ver las tareas del Usuario B, validar que los campos de entrada no puedan aceptar scripts maliciosos, ocultar tus claves API de las herramientas de desarrollo del navegador, o añadir límites de velocidad para evitar que alguien bombardee tus endpoints.

Estos no son fallos de la IA — son brechas en el prompt. La IA construye lo que pediste. Probablemente no pediste seguridad porque estabas enfocado en características. Ahora es momento de volver atrás y añadirlo.

Paso 1: Audita Tus Variables de Entorno

Este es el error más común y más peligroso en aplicaciones vibe-coded. Verifica cada archivo de tu proyecto en busca de claves API codificadas, URLs de base de datos o secretos.

Qué buscar: Busca en tu base de código cadenas que comiencen con sk-, eyJ, sbp_, supabase, postgres://, o cualquier cadena larga que parezca aleatoria. Verifica específicamente estos archivos: cualquier archivo en tu directorio /app o /pages, cualquier archivo de componente, tu next.config.js, y cualquier archivo de utilidad.

La solución: Mueve cada secreto a variables de entorno. En Next.js, solo las variables con el prefijo NEXT_PUBLIC_ se exponen al navegador. Tu URL de base de datos, clave de rol de servicio y secretos de API nunca deben tener este prefijo.

# .env.local (NUNCA hagas commit de este archivo)
SUPABASE_SERVICE_ROLE_KEY=tu-clave-secreta
DATABASE_URL=postgres://...

# Estos están bien para exponer al navegador:
NEXT_PUBLIC_SUPABASE_URL=https://tu-proyecto.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=tu-clave-anon

Verifica: Comprueba que tu archivo .gitignore incluye .env.local. Si ya has hecho commit de secretos en Git, están en tu historial incluso después de eliminarlos — rota (regenera) cada clave expuesta inmediatamente.

Paso 2: Activa la Seguridad a Nivel de Fila en Supabase

Este es el paso único más crítico si estás usando Supabase. Por defecto, las tablas de Supabase no tienen restricciones de acceso — cualquiera con tu clave anon puede leer y escribir cada fila en cada tabla. Esto significa que el Usuario A puede ver los datos del Usuario B con una simple llamada API.

La solución: Activa la Seguridad a Nivel de Fila (RLS) en cada tabla, luego crea políticas que restrinjan el acceso.

Ve a tu panel de Supabase → Editor de Tablas → selecciona cada tabla → haz clic en "RLS Deshabilitado" para habilitarlo. Luego añade políticas:

Para una aplicación típica donde los usuarios solo deben ver sus propios datos, crea una política SELECT: auth.uid() = user_id. Crea políticas similares para INSERT, UPDATE y DELETE.

Pruébalo: Inicia sesión como Usuario A, intenta acceder a los datos del Usuario B a través de la API. Si puedes verlos, tus políticas están mal. Supabase tiene un editor SQL donde puedes probar políticas directamente.

Error común de IA: Claude a menudo genera consultas de Supabase usando la clave service_role (que omite RLS) en lugar de la clave anon con políticas RLS adecuadas. Verifica que tu código del lado del cliente use solo la clave anon. La clave service role solo debe existir en código del lado del servidor (rutas API, acciones de servidor) y nunca ser expuesta al navegador.

Paso 3: Añade Autenticación Correctamente

El código de autenticación generado por IA a menudo funciona pero toma atajos. Verifica estos problemas específicos:

Gestión de sesiones: Asegúrate de que las sesiones expiren. Verifica que tu configuración de autenticación incluya un tiempo de espera de sesión razonable (los valores por defecto de Supabase generalmente están bien, pero verifica). Asegúrate de que cerrar sesión realmente invalide la sesión, no solo borre la cookie local.

Requisitos de contraseña: Si tienes autenticación por correo/contraseña, impone una longitud mínima de contraseña (8+ caracteres). Supabase maneja esto en tus configuraciones de proyecto → Autenticación → Requisitos de Contraseña.

Rutas protegidas: Cada página que muestra datos específicos del usuario necesita middleware de autenticación. En Next.js App Router, crea un middleware que verifique una sesión válida y redirija usuarios no autenticados a la página de inicio de sesión. No confíes solo en verificaciones del lado del cliente — un usuario puede evitarlas golpeando tu API directamente.

Verificación de correo: Activa la confirmación de correo en las configuraciones de Supabase Auth. Esto previene que personas creen cuentas con direcciones de correo falsas y añade una capa básica de validez de cuenta.

Paso 4: Valida Todas las Entradas

Los formularios generados por IA generalmente tienen validación básica (campos requeridos, formato de correo) pero raramente protegen contra entradas maliciosas.

Qué añadir:

Validación del lado del servidor en cada endpoint de API. Nunca confíes solo en validación del lado del cliente — puede ser omitida enviando solicitudes directamente a tu API. Usa una librería de validación como Zod (para TypeScript) para definir esquemas para cada pieza de datos que tu aplicación acepta.

Sanitiza HTML en cualquier contenido generado por usuarios que se muestre. Si tu aplicación tiene comentarios, descripciones, o cualquier campo de texto que se renderiza en el navegador, usa una librería como DOMPurify para eliminar scripts peligrosos. Sin esto, alguien puede inyectar JavaScript que robe las sesiones de otros usuarios (inyección de scripts entre sitios / XSS).

Limita el tamaño y tipo de archivo si tu aplicación acepta cargas de archivos. Los manejadores de carga generados por IA a menudo no tienen límites, lo que significa que alguien podría cargar un archivo de 2GB o un ejecutable. Añade límites de tamaño (5MB es razonable para la mayoría de aplicaciones) y restringe tipos de archivo a lo que realmente necesitas (imágenes, PDFs, etc.).

Paso 5: Asegura Tus Rutas de API

Verifica cada ruta de API o acción de servidor en tu aplicación para estos problemas:

Autenticación en cada endpoint. Cada ruta de API que devuelve o modifica datos de usuario debe verificar la sesión del usuario primero. La IA a menudo genera rutas de API que aceptan solicitudes de cualquiera.

Autorización más allá de autenticación. Incluso después de confirmar que un usuario está conectado, verifica que está autorizado a acceder al recurso específico que está solicitando. "El Usuario A está conectado" no significa "el Usuario A puede editar el perfil del Usuario B." Verifica propiedad en cada acceso de datos.

Límites de velocidad. Sin límites de velocidad, alguien puede enviar miles de solicitudes por segundo a tu API, ya sea para raspar datos o para sobrecargar tu servidor. Añade límites de velocidad básicos usando una librería como rate-limiter-flexible o usa el límite de velocidad incorporado de Vercel en Funciones Edge.

Métodos HTTP. Asegúrate de que tus rutas de API solo respondan a los métodos HTTP que deberían. Una ruta que maneja solicitudes POST no debería también responder a solicitudes DELETE a menos que lo hayas diseñado explícitamente.

Paso 6: Verifica Tu Configuración de Despliegue

Tu plataforma de despliegue tiene configuraciones de seguridad que la IA no configura por ti.

Configuraciones de Vercel a verificar: Activa "Deployment Protection" (requiere autenticación para ver despliegues de vista previa — previene que clientes compartan accidentalmente URLs de vista previa que expongan trabajo en curso). Configura límites de gastos para prevenir cargos inesperados si tu aplicación recibe picos de tráfico. Configura tus dominios permitidos en encabezados CORS.

Dominio personalizado y SSL: Si estás entregando esto a un cliente, configura su dominio personalizado con HTTPS. Vercel y Netlify manejan SSL automáticamente. Nunca entregues una aplicación cliente en un subdominio .vercel.app — se ve poco profesional y el cliente no puede transferirlo fácilmente.

Encabezados: Añade encabezados de seguridad a tu next.config.js o vercel.json: X-Content-Type-Options: nosniff, X-Frame-Options: DENY (previene que tu sitio sea incrustado en iframes para clickjacking), Strict-Transport-Security (fuerza HTTPS). Estas son adiciones únicas que previenen clases enteras de ataques.

Paso 7: Ejecuta un Escaneo de Seguridad Final

Antes de entregar algo a un cliente, ejecuta estas comprobaciones gratuitas:

npm audit: Ejecuta npm audit en tu directorio de proyecto. Señala vulnerabilidades conocidas en tus dependencias. Corrige problemas críticos y de alta severidad. Ejecuta npm audit fix para correcciones automáticas donde estén disponibles.

Lighthouse: Abre tu sitio desplegado en Chrome, abre DevTools, ejecuta una auditoría de Lighthouse. Verifica la puntuación de "Mejores Prácticas" — detecta problemas de seguridad comunes como HTTPS faltante, librerías vulnerables y encabezados inseguros.

Pruebas manuales: Inicia sesión como un usuario, intenta acceder a los datos de otro usuario modificando URLs o llamadas de API. Intenta enviar formularios vacíos, entradas de tamaño excesivo y caracteres especiales (como cargas XSS codificadas). Si alguno de estos funciona, tienes problemas que corregir.

La Lista de Verificación Previa al Lanzamiento

Imprime esto y verifica cada elemento antes de ir en vivo:

• Todos los secretos en variables de entorno (sin claves codificadas)
• .env.local en .gitignore (y sin secretos en el historial de Git)
• Supabase RLS habilitado en cada tabla
• Políticas RLS probadas (el Usuario A no puede ver los datos del Usuario B)
• El código del lado del cliente usa solo la clave anon (clave service role solo del lado del servidor)
• Autenticación en cada ruta de API
• Verificaciones de autorización (verificación de propiedad) en acceso de datos
• Validación de entrada en cada formulario (del lado del servidor, no solo del cliente)
• Límites de carga de archivo (tamaño y tipo) si aplica
• Límites de velocidad en endpoints de API
• Encabezados de seguridad configurados
• npm audit ejecutado y problemas críticos corregidos
• Dominio personalizado con SSL configurado
• Despliegues de vista previa protegidos
• Prueba de acceso de datos entre usuarios pasada

La Conclusión

Asegurar una aplicación vibe-coded no se trata de convertirse en un experto en seguridad. Se trata de ejecutar una lista de verificación que atrapa las brechas predecibles que la IA deja. Los pasos anteriores toman 2–4 horas y previenen las vulnerabilidades más comunes. Para una aplicación orientada al cliente, esto no es opcional — es la diferencia entre trabajo profesional y una responsabilidad.

Si estás construyendo tu primera aplicación vibe-coded, comienza con nuestra guía completa de vibe coding. Si quieres mejorar los prompts que usas con Claude o Cursor, prueba nuestro optimizador de prompts gratuito. Y para un desglose de las mejores herramientas de codificación, ve Claude Code vs Codex.

Divulgación: Algunos enlaces en este artículo son enlaces de afiliados. Solo recomendamos herramientas que hemos probado personalmente y usamos regularmente. Ve nuestra política completa de divulgación.