La comunidad celebra el checklist. Pero hay algo que nadie en ese hilo está diciendo en voz alta.
El ángulo que nadie está contando
Las plataformas de vibe coding tienen un incentivo directo para que no pienses en seguridad antes de lanzar.
Su métrica clave es "tiempo hasta primera app live". Lovable presume de que puedes tener algo en producción en minutos. Replit también. Su modelo de negocio se basa en que el punto de entrada sea cero fricción. Cada paso de seguridad que añades antes del lanzamiento es fricción. Y la fricción mata conversión.
Cuando WIRED contactó a las tres empresas (Lovable, Replit, Base44), sus respuestas fueron prácticamente idénticas en estructura:
- Replit: "Public apps being accessible on the internet is expected behavior."
- Lovable: "How an app is configured is ultimately the creator's responsibility."
- Base44 (Wix): "Disabling those controls is a deliberate, straightforward action any user can do."
Traducción directa: es tu problema, no el nuestro.
Lo interesante es el patrón. Amazon S3 tuvo exactamente el mismo momento en 2017-2019: miles de buckets abiertos expusieron datos de Verizon, WWE y docenas más. Amazon también dijo durante años que era responsabilidad del usuario. Al final tuvieron que cambiar los defaults y añadir advertencias en la consola porque la presión regulatoria y mediática fue suficiente.
Las plataformas de vibe coding están repitiendo ese error deliberadamente. No porque sean incompetentes —saben perfectamente lo que está pasando— sino porque cambiar los defaults añade fricción al onboarding, y su valoración depende del número de apps creadas, no de la seguridad de esas apps.
CVE-2025-48757 ya existe. Fue asignado específicamente a apps de Lovable que se conectaban a Supabase sin row-level security policies configuradas. Un CVE con nombre propio para un patrón predecible que las plataformas podrían haber prevenido con un simple bloqueo por defecto.
El matiz honesto
Esto no significa que vibe coding sea una trampa ni que debas abandonar Cursor o Lovable. Significa que debes entender exactamente qué te están vendiendo y qué no está incluido en el precio.
El checklist de @PrajwalTomar_ es bueno. El prompt de "revisa mi app como especialista en seguridad" funciona. Los modelos actuales son capaces de detectar la mayoría de estos problemas si les preguntas específicamente.
Lo que no funcionan son los defaults de las plataformas cuando tienes cero conocimiento técnico y lanzas una app con datos reales de usuarios porque alguien te prometió que podías hacerlo "en minutos".
A quién le importa esto
Te aplica directamente si:
- Tu app recoge cualquier tipo de dato de usuario (email, nombre, historial, lo que sea)
- Usas Supabase, Firebase o cualquier BaaS como backend sin haber revisado las políticas de RLS
- Tu app llama a APIs externas (OpenAI, Stripe, Twilio) desde el cliente, no desde el servidor
- Estás en Europa o tu audiencia tiene usuarios en Europa → GDPR aplica, punto
No te aplica si:
- Tu app es solo para uso personal sin usuarios externos
- Es un prototipo sin datos reales que no está en un dominio público
- Ya tienes experiencia en producción y has revisado estos puntos
El umbral crítico: si tienes más de 10 usuarios activos con datos reales, ya estás en territorio legal. GDPR no tiene umbral de tamaño para startups en fase temprana —la única excepción es para empresas con menos de 10 empleados y menos de 2M€ de facturación anual en algunos artículos de accesibilidad, pero no en protección de datos.
La pieza que te llevas
Cinco prompts que puedes pasar a Cursor, Lovable o cualquier herramienta de vibe coding antes de pulsar "publish":
1. Review my app as a security specialist. Check security headers and baseline security posture. List everything you find.
2. Review my app against OWASP Top 10 standards. Highlight all vulnerabilities found, ordered by severity.
3. Check my app for any credential or sensitive data leaks in frontend code or API routes. Include .env files, hardcoded strings, and API responses.
4. Ensure no API keys or secrets are exposed in frontend code or network calls. Move any to server-side routes.
5. Review all database queries and API endpoints for missing authentication or authorization checks. List any endpoint accessible without a valid session.
Y uno más que no aparece en ningún checklist habitual:
6. If I'm collecting user data from EU residents, what specific GDPR requirements apply to my app? List the minimum viable compliance steps.
Corre estos prompts en orden. No te lleva más de 20 minutos. Lo que encuentres puede ahorrarte una carta certificada de un abogado alemán especializado en GDPR —y esos no son baratos.
Documentación relevante:
Pirinai Academy6 min de lectura