Cómo Asegurar Código Generado por IA — Lista de Verificación de Seguridad Vibe Coding

Si codificaste por intuición una app con Claude o Cursor y estás a punto de entregarla a un cliente que te pagará, 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 que cualquier usuario vea los datos de todos los demás. Estos no son casos extremos. Ocurren en casi todas las bases de código generadas por IA en el primer intento.

Esta guía es la lista de verificación de seguridad previa al lanzamiento. Síguelo paso a paso antes de que cualquier usuario real toque tu app. Está escrito para el stack de vibe coding más común (Next.js + Supabase + Vercel), pero los principios aplican sin importar cuáles sean tus herramientas.

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

Los modelos de IA optimizan para "¿funciona?" no "¿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 desarrollador del navegador, o añadir limitación 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 tiempo 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 apps codificadas por intuición. Busca en cada archivo de tu proyecto 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 se vea aleatoria. Verifica estos archivos específicamente: 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 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 confirmes este archivo)
SUPABASE_SERVICE_ROLE_KEY=tu-clave-secreta
DATABASE_URL=postgres://...

# Estos está bien exponerlos 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 incluya .env.local. Si ya has confirmado secretos a Git, están en tu historial aunque los borres — rota (regenera) cada clave expuesta inmediatamente.

Paso 2: Habilita Row-Level Security en Supabase

Este es el paso más crítico si usas 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 a la API.

La solución: Habilita Row-Level Security (RLS) en cada tabla, luego crea políticas que restrinjan el acceso.

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

Para una app típica donde los usuarios deben ver solo 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 frecuentemente 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 de rol de servicio solo debe existir en código del lado del servidor (rutas API, acciones de servidor) y nunca exponerse 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 predeterminados de Supabase generalmente están bien, pero verifica). Asegúrate de que cerrar sesión realmente invalida la sesión, no solo borra la cookie local.

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

Rutas protegidas: Cada página que muestre 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 login. No confíes solo en verificaciones del lado del cliente — un usuario puede omitirlas accediendo directamente a tu API.

Verificación de correo: Habilita la confirmación de correo en la configuración 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 Toda la Entrada

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

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 — se puede omitir enviando solicitudes directamente a tu API. Usa una librería de validación como Zod (para TypeScript) para definir esquemas para cada datos que tu app acepte.

Sanitiza HTML en cualquier contenido generado por usuarios que se muestre. Si tu app tiene comentarios, descripciones, o cualquier campo de texto que se renderice 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 (cross-site scripting / XSS).

Limita el tamaño y tipo de archivo si tu app acepta cargas de archivos. Los manejadores de carga generados por IA frecuentemente 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 apps) 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 app 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 frecuentemente 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á permitido 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 la propiedad en cada acceso a datos.

Limitación de velocidad. Sin limitación 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 limitación de velocidad básica usando una librería como rate-limiter-flexible o usa la limitación de velocidad integrada de Vercel en Edge Functions.

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 responder también a solicitudes DELETE a menos que explícitamente la hayas diseñado para hacerlo.

Paso 6: Verifica Tu Configuración de Despliegue

Tu plataforma de despliegue tiene configuración de seguridad que la IA no configura por ti.

Configuración de Vercel a verificar: Habilita "Deployment Protection" (requiere autenticación para ver despliegues previos — previene que clientes compartan accidentalmente URLs de vista previa que expongan trabajo en progreso). Configura límites de gasto para prevenir cargos inesperados si tu app 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 app de 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 embebido en iframes para ataques de clickjacking), Strict-Transport-Security (fuerza HTTPS). Estas son adiciones de una sola vez que previenen clases completas de ataques.

Paso 7: Ejecuta un Escaneo de Seguridad Final

Antes de entregar cualquier cosa a un cliente, ejecuta estas verificaciones gratuitas:

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

Lighthouse: Abre tu sitio desplegado en Chrome, abre DevTools, ejecuta un auditoría Lighthouse. Verifica la puntuación "Best Practices" — 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 a API. Intenta enviar formularios vacíos, entradas demasiado grandes, y caracteres especiales (como payloads XSS codificados). Si alguno de estos funciona, tienes problemas que arreglar.

La Lista de Verificación Previa al Lanzamiento

Imprime esto y verifica cada elemento antes de lanzarte:

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

El Resumen Final

Asegurar una app codificada por intuición no se trata de convertirse en un experto en seguridad. Se trata de ejecutar una lista de verificación que detecta las brechas predecibles que la IA deja atrás. Los pasos anteriores toman 2–4 horas y previenen las vulnerabilidades más comunes. Para una app dirigida al cliente, esto no es opcional — es la diferencia entre trabajo profesional y una responsabilidad legal.

Si estás construyendo tu primera app codificada por intuición, comienza con nuestra guía completa para codificación por intuición. 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, consulta 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. Consulta nuestra política completa de divulgación.