>_ Black Engine

Checklist de seguridad para app hecha con IA: 26 puntos

Por Black Engine · 6 de noviembre de 2026

Esta checklist de seguridad para app hecha con IA reúne los puntos que más fallan en apps creadas con Lovable, Bolt, Replit, v0, Cursor o ChatGPT. Revísala antes de publicar o, si ya publicaste, hoy mismo. Cada punto dice qué revisar y cómo saber si está bien. Marca con ✅ lo que pase y anota lo que no.

Haz estas pruebas solo en tu app. Nunca en apps de otras personas.

1. Base de datos

  • RLS activado en todas las tablas (si usas Supabase). RLS son las reglas que deciden qué filas puede ver cada usuario. En el panel, Table Editor muestra si cada tabla lo tiene. Si te falta contexto: qué es RLS en Supabase.
  • Políticas que de verdad filtran. Una política using (true) deja ver todo a todos; es casi lo mismo que no tener RLS.
  • Security Advisor sin errores críticos. En Supabase, revisa los avisos del asesor de seguridad (por ejemplo “RLS disabled in public”).
  • Firebase: las reglas de Firestore/Storage no dicen allow read, write: if true;.
  • Prueba con dos cuentas: con la cuenta A intenta ver o editar datos de la cuenta B (cambia el id en la URL). No debería poder.

Consulta rápida en el SQL Editor de Supabase para encontrar tablas sin RLS:

select tablename from pg_tables
where schemaname = 'public' and rowsecurity = false;

¿Por qué este bloque va primero? Porque es el error más documentado: en mayo de 2025, la vulnerabilidad CVE-2025-48757 mostró que 170 de 1,645 apps de la vitrina de Lovable dejaban leer o escribir tablas con la llave pública anon.

2. Llaves y secretos

  • Ninguna llave secreta en el frontend. Abre tu app, F12 → Sources, y busca service_role, sk_live, sk- o secret. La llave anon de Supabase puede estar ahí; la service_role, nunca.
  • Secretos en variables de entorno del servidor o de tu plataforma (Vercel, Netlify, Supabase Edge Functions), no escritos en el código.
  • El archivo .env no está en GitHub. Revisa que .env aparezca en tu .gitignore.
  • Si alguna llave se filtró alguna vez, ya la rotaste (generaste una nueva y revocaste la vieja). Pasos en API key expuesta: qué hacer.
# Revisa si alguna vez subiste un .env a tu repositorio
git log --all --oneline -- .env

3. Inicio de sesión y permisos

  • Las páginas privadas no cargan datos sin sesión. Cierra sesión y entra directo a /dashboard o /admin.
  • El rol de administrador se valida en el servidor o en la base de datos, no solo ocultando un botón.
  • Confirmación de correo activada si tu app la necesita, y límites contra registros masivos.
  • Recuperar contraseña funciona y el enlace caduca.
  • Los usuarios no pueden cambiar su propio rol editando su perfil (prueba editar tu perfil y ver si el campo role o is_admin se puede modificar).

4. Pagos

  • El precio se calcula en el servidor, no se toma de lo que manda el navegador.
  • El pedido se marca como pagado solo con el webhook de Mercado Pago o Stripe (el aviso que manda la pasarela a tu servidor), no porque el usuario llegó a la página de “gracias”.
  • Llaves de prueba fuera de producción y llaves de producción fuera del frontend.

Si aún no conectas pagos, revisa cómo elegir pasarela de pago para tu app.

5. Archivos y formularios

  • Los buckets de almacenamiento no son públicos salvo que deban serlo (por ejemplo, fotos de productos sí; identificaciones de clientes no).
  • Se limita tipo y tamaño de archivo que los usuarios pueden subir.
  • Los formularios validan en el servidor longitud y formato de los datos.

6. Dominio, HTTPS y dependencias

  • HTTPS activo en todo el sitio, sin avisos de “No seguro”.
  • Dependencias actualizadas. Si tienes el código, corre:
npm audit

y revisa las vulnerabilidades marcadas como high o critical.

  • No hay paquetes raros que no reconozcas en package.json.

7. Respaldos y registros

  • Hay respaldo de la base de datos y sabes cómo restaurarlo. Ver cómo hacer una copia de seguridad de tu página web.
  • El código está en GitHub (o similar), no solo en la plataforma de IA.
  • Sabes dónde ver los logs de tu app y de la base de datos si algo raro pasa.

Cómo priorizar si fallan varios puntos

Prioridad Qué corregir Por qué
Urgente (hoy) Tablas sin RLS, llaves secretas expuestas Cualquiera puede robar o borrar datos ahora mismo
Alta (esta semana) Permisos de admin, pagos validados en servidor Fraude y acceso indebido
Media Buckets, formularios, dependencias Reduce la superficie de ataque
Continua Respaldos, logs, actualizaciones Te permite recuperarte

Errores comunes al usar esta checklist

  • Preguntarle a la IA “¿mi app es segura?” y aceptar el “sí”. Haz las pruebas tú.
  • Probar solo con tu cuenta de administrador. Los fallos aparecen con cuentas normales o sin sesión.
  • Desactivar RLS para que deje de salir un error. Arregla la política en vez de apagarla.

Cuándo pedir una revisión profesional

Si fallaste puntos del bloque 1 o 2, si tu app maneja datos personales, salud, dinero o información de menores, o si ya tienes usuarios reales, conviene una revisión más profunda que esta lista. Aquí explicamos más sobre los riesgos de seguridad del vibe coding. En Black Engine revisamos tu app hecha con IA por WhatsApp y te entregamos qué corregir, en orden de urgencia.

Preguntas frecuentes

¿Qué es lo primero que debo revisar en una app hecha con IA?

Que tu base de datos tenga reglas de acceso (RLS en Supabase) en todas las tablas y que ninguna llave secreta esté en el código que se descarga al navegador.

¿Puedo hacer esta checklist sin saber programar?

La mayoría sí: son pruebas con dos cuentas de usuario, revisiones en el panel de Supabase o Firebase y búsquedas en el navegador. Algunos puntos sí requieren leer código.

¿Esta checklist sustituye una auditoría?

No. Cubre los errores más comunes, pero una auditoría revisa el código completo, la lógica de negocio y la configuración del servidor con más profundidad.

¿Sirve para apps de Lovable, Bolt, Replit y Cursor?

Sí. Los nombres de los menús cambian, pero los riesgos son los mismos: base de datos, llaves, autenticación, pagos y respaldos.

Pide ayuda por WhatsApp