¿Es segura mi app hecha con IA? 12 controles antes de tener usuarios reales

Lovable, Bolt, Cursor, Replit, v0 y Claude permiten montar una app que funciona en un fin de semana. Es un avance real. Pero “funciona” y “es seguro meter aquí datos de personas reales” son preguntas distintas.

Qué dicen los estudios

Los estudios encuentran fallos de seguridad en una parte importante del código generado por IA. El 2025 GenAI Code Security Report de Veracode probó código escrito por muchos modelos de lenguaje para tareas habituales y encontró que alrededor del 45 % de las muestras tenía un fallo de seguridad, sobre todo de clases conocidas del OWASP Top 10, como inyección o cross-site scripting. El informe señala también que los modelos más nuevos y más grandes no eran claramente mejores en seguridad.

Hay un segundo riesgo menos evidente. En el artículo “We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs” (USENIX Security 2025), los investigadores vieron que aproximadamente uno de cada cinco paquetes recomendados en el código analizado no existía. Un atacante puede registrar esos nombres inventados y llenarlos de malware, una técnica que ya se conoce como slopsquatting. Si tu herramienta de IA te dice que instales un paquete del que nadie ha oído hablar, compruébalo antes de ejecutar el comando.

Nada de esto significa que el código de IA sea siempre inseguro. Significa que tienes que revisarlo como el código de un programador junior rápido y seguro de sí mismo que nunca pregunta por la seguridad si tú no lo haces.

Los 12 controles

1. Secretos en el frontend o en el repositorio

Busca en tu código y en tu historial de Git claves de API, contraseñas de base de datos, claves de service role y tokens. Todo lo que está en el bundle del frontend es público: cualquiera puede abrir las herramientas de desarrollo del navegador y leerlo. Las claves de pagos, correo y proveedores de IA deben vivir solo en el servidor o en el gestor de secretos de tu plataforma. Si un secreto llegó a un commit, rótalo; borrar la línea no basta porque Git guarda el historial.

2. Seguridad a nivel de fila en Supabase o Firebase

Este hueco por sí solo puede exponer toda tu base de datos. En Supabase, la clave anónima se envía al navegador por diseño. Sin seguridad a nivel de fila (RLS) activada en cada tabla, y con políticas correctas, cualquiera con esa clave puede leer o cambiar todas las filas. En Firebase, comprueba que las reglas de seguridad no se quedaron en modo de prueba (allow read, write: if true). Pruébalo: entra como un usuario e intenta leer los registros de otro directamente por la API.

3. Autenticación y sesiones

Usa la autenticación que trae tu plataforma en vez de un login hecho a mano. Comprueba que las contraseñas nunca se guardan en texto plano, que las sesiones caducan, que cerrar sesión la termina de verdad, que los enlaces de recuperación de contraseña son de un solo uso y caducan y, si puedes evitarlo, que los tokens de sesión no se guardan donde cualquier script pueda leerlos.

4. Autorización en cada ruta de la API

Estar logueado no es lo mismo que tener permiso. En cada ruta o función de servidor, pregúntate: ¿comprueba que el usuario actual es dueño de lo que pide? El fallo clásico es el IDOR (referencia directa insegura a objetos): cambias /api/invoices/1041 por /api/invoices/1042 y ves la factura de otro. Las herramientas de IA suelen generar el camino feliz y saltarse esta comprobación. Las acciones de administrador necesitan una comprobación de rol explícita en el servidor, no solo un botón oculto.

5. Validación de entradas e inyección

Valida cada entrada en el servidor: tipo, longitud, formato. Usa consultas parametrizadas o tu ORM, nunca SQL construido con cadenas. Escapa la salida para evitar cross-site scripting, sobre todo donde muestras contenido de usuarios o Markdown. Si pasas texto de usuarios a un modelo de IA que puede usar herramientas, trátalo también como no fiable.

6. Límites de peticiones

El login, el registro, la recuperación de contraseña, los formularios de contacto y cualquier endpoint que llame a una API de pago necesitan límites. Sin ellos, alguien puede adivinar contraseñas, inundar tu bandeja de entrada o disparar tu factura de IA o de SMS en una noche. La mayoría de plataformas y CDN ofrecen limitación de peticiones; actívala.

7. Dependencias y paquetes alucinados

Ejecuta la auditoría de tu gestor de paquetes (npm audit, pip-audit o similar) y corrige lo crítico. Después lee tu lista de dependencias: ¿existe cada paquete, es el que querías, tiene uso real y un repositorio mantenido? Quita lo que no uses. Sube un lock file para que los builds sean repetibles.

8. CORS

Las reglas de origen cruzado deciden qué webs pueden llamar a tu API desde un navegador. Access-Control-Allow-Origin: * junto con cookies o credenciales es un atajo frecuente en código generado. Permite solo tus propios dominios.

9. Subida de archivos

Limita el tamaño y el tipo, comprueba el contenido y no solo la extensión, guarda las subidas fuera del directorio de código o en almacenamiento de objetos y nunca las ejecutes. Asegúrate de que los archivos de un usuario son privados por defecto y sírvelos con enlaces firmados o autorizados.

10. Mensajes de error y logs

Los errores en producción no deben enseñar al usuario trazas, consultas SQL ni variables de entorno. En sentido contrario, comprueba que tus logs no recogen lo que no deben: contraseñas, números de tarjeta completos, tokens o más datos personales de los necesarios. Los logs suelen ser la copia peor protegida de tus datos.

11. Copias de seguridad y restauración

Averigua si tu base de datos tiene copias, con qué frecuencia, dónde y durante cuánto tiempo. Después restaura una copia en otro sitio y comprueba que funciona. Muchas plataformas incluyen copias solo en planes de pago o las guardan poco tiempo. Decide cuántos datos podrías permitirte perder y ajusta la frecuencia a eso.

12. Paneles de administración y credenciales por defecto

Busca paneles de administración, consolas de base de datos, rutas de depuración y cuentas de prueba que haya creado la IA o una plantilla. Quita lo que no necesites y protege el resto con autenticación fuerte, mejor con MFA o lista de IP permitidas. Cambia todas las contraseñas por defecto y elimina usuarios de prueba como admin@example.com antes del lanzamiento.

Cómo hacer estos controles

Ve por este orden: primero 1, 2 y 4, porque exponen datos. Luego 3, 5, 6 y 7. Después el resto.

En cada punto, apunta qué revisaste y qué encontraste. Ese registro breve te servirá más adelante, cuando un cliente, un inversor o un socio te mande un cuestionario de seguridad.

Puedes pedir a tu herramienta de IA que te ayude a corregir cada hallazgo. Dale una tarea precisa: “Añade en cada ruta bajo /api/projects una comprobación de que el proyecto pertenece al usuario actual, y un test que falle con el proyecto de otro usuario.” Luego verifica tú la corrección.

Cuándo pedir ayuda

Si tu app maneja pagos, datos de salud, datos de menores o datos personales de personas en la UE, o si estás a punto de levantar dinero o firmar con un cliente grande, merece la pena una revisión independiente. Nuestra auditoría de seguridad de apps hechas con IA cubre estas doce áreas y más, y cada hallazgo viene con una corrección concreta.