Vibe Coding Security

Antes de que tuitees tu lanzamiento, ejecuta estas 69 comprobaciones. Se corresponden con los patrones exactos detrás del CVE de RLS de Lovable (CVE-2025-48757, 170+ apps, 2025), la filtración de Moltbook (1,5 millones de tokens de API, febrero de 2026) y la brecha de la plataforma Lovable de abril de 2026 (código fuente + claves de servicio de proyectos de otros usuarios, expuestos durante ~2,5 meses).

¿Quieres el kit completo? 50 habilidades de auditoría, 15 .cursorrules, 1 configuración de MCP + 4 recetas CLI, 30 prompts de revisión adversarial, 10 estudios de caso. Instalación en 5 minutos. $10 fijos.

→ rishabhvaai.gumroad.com/l/plddbd

---

En una auditoría publicada en octubre de 2025, Escape.tech escaneó 5.600 aplicaciones reales generadas por IA en 14.600 activos (metodología). Informaron de 2.038 vulnerabilidades críticas, más de 400 secretos filtrados y 175 casos de PII expuesta en 1.400 de esas aplicaciones (hallazgos). Los secretos salieron directamente de los bundles del frontend: claves de Stripe, OpenAI y Supabase que estaban en el JavaScript del lado del cliente. Y no ha mejorado desde entonces: el informe de GitGuardian de 2026 contabilizó 28,6 millones de secretos nuevos en GitHub público en 2025 (+34 % interanual), los secretos de servicios de IA subieron un 81 % y los commits coautorados por agentes de codificación filtran secretos a aproximadamente el doble de la tasa humana. Esta es una lista de verificación de 69 elementos específicos y comprobables. Cada uno se corresponde con un patrón real de incidente. Si puedes marcar los 69, publica. Si no puedes, arregla lo que te lo impide.

No es un SaaS. No es un escáner. Una lista plana que repasas antes de hacer push a producción.

---

Lista de verificación de seguridad de 69 puntos previa al lanzamiento

Estás a 30 minutos de publicar. Detente. Ejecuta esto primero.

Solo la vulnerabilidad de RLS de Lovable (CVE-2025-48757, 2025, CVSS 9.3) expuso más de 170 aplicaciones en producción. Moltbook expuso 1,5 millones de tokens de API en febrero de 2026 — consultables con un solo curl. No fueron casos límite: fueron lanzamientos normales y corrientes.

Esta lista agrupa 69 elementos específicos y comprobables en autenticación, secretos, APIs, bases de datos, frontend, IA/LLM, herramientas de agentes y despliegue. Si no puedes marcar los 69, no publiques.

---

Autenticación (8 elementos)

• 1. La seguridad a nivel de fila (RLS) de la base de datos está habilitada en todas las tablas de tu base de datos.
• 2. Existen políticas de RLS para cada tabla y cada rol (anon, authenticated, service_role).
• 3. Los tokens JWT se validan en el servidor en cada ruta de API protegida (nunca confíes en el frontend para validar la autenticación).
• 4. Las sesiones se rotan o invalidan después del inicio de sesión (protección contra CSRF y fijación de sesión).
• 5. Los magic links (autenticación sin contraseña) son de un solo uso, caducan en <15 minutos y están vinculados a la IP del usuario o a la huella del dispositivo.
• 6. No puedes actualizar ni eliminar usuarios, pedidos o registros sensibles basándote únicamente en IDs proporcionados por el usuario. Prueba: intenta actualizar el registro de otro usuario cambiando el ID en la solicitud.
• 7. Los tokens CSRF se validan en solicitudes que cambian el estado (POST, PUT, DELETE) mediante cookie de doble envío o SameSite=Strict.
• 8. Las cookies de sesión tienen configuradas las banderas HttpOnly, Secure y SameSite=Strict.

Secretos y entorno (7 elementos)

• 9. No hay secretos en variables NEXT_PUBLIC_*, archivos .env de Vue/React ni cadenas hardcodeadas. Haz grep de NEXT_PUBLIC_ y audita todas las variables.
• 10. .env, .env.local y .env.*.local están en .gitignore y nunca se commitean. Revisa el historial de git: git log --all -p | grep -i "api_key\|secret".
• 11. La clave service_role de Supabase está SOLO en el .env del lado del servidor (Node, Python, Go, etc.), nunca en bundles del frontend ni en .env.local. La clave service_role elude RLS por completo: una sola filtración implica lectura/escritura total en todas las tablas.
• 12. Claves de Stripe: clave pública en NEXT_PUBLIC_*, clave secreta solo en el servidor, firma de webhook verificada.
• 13. Las claves de API de OpenAI, Anthropic y xAI nunca están en el código del frontend; siempre se enrutan mediante proxy a través de tu API.
• 14. No hay claves de API, URLs de base de datos ni credenciales hardcodeadas en ningún lugar del código fuente (incluidos comentarios y código sin usar).
• 15. Los secretos se rotan después del lanzamiento o si alguna vez se expusieron en el historial del código fuente.

Endurecimiento de API (10 elementos)

• 16. La limitación de tasa está activa en /api/auth/*, /api/login, /api/register. Prueba: 100 solicitudes/minuto deberían devolver 429.
• 17. Todas las entradas de usuario hacia /api/* se validan con Zod, Yup o similar antes de tocar la base de datos. No se pasa req.body en bruto a las consultas.
• 18. Sin asignación masiva: el usuario no puede establecer admin=true, role=admin u otros campos sensibles enviándolos por POST.
• 19. Las firmas de los webhooks se verifican (compara la cabecera de firma HMAC-SHA256 con el valor esperado usando una comparación en tiempo constante).
• 20. CORS no está configurado como *. Los orígenes permitidos están hardcodeados y no incluyen localhost en producción.
• 21. Las consultas SQL usan únicamente sentencias parametrizadas. Sin concatenación de cadenas con entrada de usuario en SQL.
• 22. Las consultas NoSQL (MongoDB, Firebase, etc.) no concatenan entrada de usuario en filtros o selectores.
• 23. Las subidas de archivos se validan (tipo MIME + tamaño), se almacenan fuera de la raíz web y se renombran para prevenir path traversal.
• 24. Las redirecciones después del inicio de sesión están en lista blanca. No se puede redirigir a un dominio externo mediante open redirect.
• 25. La API no realiza solicitudes externas sin validar. Asegúrate de que las URLs usadas en solicitudes del lado del servidor provengan de tu lista de permitidos, no de la entrada del usuario (prevención de SSRF).

Base de datos (6 elementos)

• 26. RLS está APLICADA en todas las tablas. El rol anon no puede hacer SELECT/INSERT/UPDATE/DELETE en ninguna tabla sin una política explícita que se lo conceda.
• 27. El rol público anon tiene cero permisos por defecto. Las políticas conceden solo lo necesario. Solo lectura en listas públicas, nunca escritura.
• 28. La clave service-role se usa SOLO en código del lado del servidor. Verifica: grep -r "service_role" src/. Debería devolver cero resultados en archivos del frontend.
• 29. Aislamiento de datos de usuario: las consultas siempre filtran por auth.uid() o team_id. Ninguna consulta devuelve todos los registros de todos los usuarios.
• 30. Los borrados suaves (bandera is_deleted) o las tablas de archivo previenen la pérdida accidental de datos. Los borrados duros se registran con actor + marca de tiempo.
• 31. Existen copias de seguridad de la base de datos y están probadas. Has verificado que puedes restaurar desde una copia de seguridad antes de este lanzamiento.

Frontend (8 elementos)