Autenticación y autorización en apps generadas con IA: por qué el inicio de sesión no es suficiente

Una app generada con IA puede tener un inicio de sesión perfecto y seguir siendo vulnerable. El usuario entra con Google, GitHub, correo/contraseña, Auth0, Supabase Auth o Firebase Authentication; la sesión se crea; el panel de control muestra solo los botones previstos. Pero todo esto demuestra una sola cosa: la app sabe quién es el usuario. No demuestra qué puede leer, modificar, borrar, exportar o administrar ese usuario.

El riesgo surge cuando el código generado por la IA confunde autenticación y autorización. La autenticación responde a la pregunta “¿quién eres?”, mientras que la autorización responde a la pregunta “¿qué puedes hacer sobre este objeto, en este tenant, con este rol, en este estado del flujo de trabajo?”. En las aplicaciones web, SaaS y herramientas internas creadas rápidamente con IA, esta segunda parte es a menudo la más frágil.

El control decisivo antes del lanzamiento (go-live) es sencillo de describir pero difícil de improvisar: un usuario autenticado debe poder acceder solo a los datos, archivos, funciones, informes, pedidos, proyectos, espacios de trabajo y acciones que realmente le pertenecen. Si basta con cambiar un ID en una solicitud para obtener datos ajenos, el inicio de sesión no está protegiendo el producto.

[Callforaction-WAPT]

AuthN y AuthZ: la distinción que decide la seguridad

AuthN (autenticación) significa identificar al usuario; AuthZ (autorización) significa aplicar permisos. Muchos proyectos generados por IA implementan bien la primera parte porque los proveedores y frameworks lo hacen rápido: login social, magic links, sesiones, tokens de actualización, middleware básico. La segunda parte, en cambio, requiere conocimiento del dominio: roles, propiedad, tenants, estados, acciones permitidas y límites entre clientes.

La IA puede generar un panel que muestre solo los registros del usuario actual, pero esto no basta si la consulta real acepta un user_id desde el cliente. Puede ocultar el botón “eliminar” a los usuarios estándar, pero esto no basta si el endpoint DELETE /api/users/123 no verifica el rol en el servidor. Puede crear una página de administración separada, pero esto no basta si la ruta es accesible con cualquier sesión.

La regla básica es que la autorización debe estar en el backend, en las políticas y en los controles del lado del servidor, no solo en la interfaz de usuario (UI). Cada solicitud que lee o modifica datos debe verificar la identidad, el rol, la propiedad, el tenant y el estado del objeto.

BOLA e IDOR en apps generadas por IA

Broken Object Level Authorization (BOLA) es uno de los problemas más comunes en las API modernas: un usuario autenticado manipula un identificador y obtiene acceso a un objeto que no le pertenece. IDOR (Insecure Direct Object Reference) describe el mismo problema desde el punto de vista del identificador expuesto y modificable.

Ejemplos típicos son las URL y los cuerpos de solicitud con user_id, account_id, tenant_id, organization_id, project_id, document_id, order_id, invoice_id, ticket_id, message_id, workspace_id. Si la API usa ese ID sin verificar que pertenezca al usuario o al tenant, un atacante autenticado puede leer o modificar datos de otros.

Las apps generadas con IA están particularmente expuestas a este riesgo porque el código tiende a seguir el camino más directo: tomar un ID de la ruta, hacer una consulta y devolver el resultado. Funciona en la demo y pasa el test feliz, pero falta el control que vincula ese objeto con la identidad real del usuario.

La prueba más sencilla: cambiar el ID

Antes de publicar, crea dos usuarios y al menos dos conjuntos de datos similares. Si la app es B2B, crea dos tenants o espacios de trabajo. Accede con el primer usuario, intercepta una solicitud y sustituye el ID por el del segundo usuario, probando la lectura, actualización, eliminación, exportación y descarga.

Esta prueba debe hacerse en las API, no solo en la UI. Usa las herramientas de desarrollador del navegador, proxies, curl o clientes de API y prueba endpoints de detalle, listas, búsquedas, archivos adjuntos, informes, exportaciones CSV, funciones de administración, invitaciones, pagos, pedidos, notificaciones y webhooks. Las vulnerabilidades más graves se encuentran a menudo en rutas que la interfaz no muestra directamente.

El resultado esperado es siempre el mismo: 403, 404 controlado o respuesta denegada. Si la app devuelve datos, actualiza un registro, borra un archivo o produce una exportación, la autorización está rota.

Aislamiento de tenants: el problema B2B más subestimado

En las apps SaaS y herramientas internas multi-cliente, el límite más importante no es solo entre usuarios, sino entre organizaciones. Un usuario pertenece a un tenant, espacio de trabajo, empresa, equipo, proyecto o cuenta de cliente, y cada consulta debe respetar ese límite.

El riesgo surge cuando el código filtra por user_id pero olvida el tenant_id, o cuando acepta el tenant_id desde el frontend en lugar de derivarlo de la sesión o de una membresía verificada. Un endpoint de exportación, un panel de administración, una función de búsqueda o una consulta agregada puede exponer datos entre tenants incluso si las páginas principales parecen correctas.

Para probar el aislamiento de tenants, crea dos organizaciones con datos y roles similares, luego intenta leer documentos, pedidos, informes, usuarios, archivos, facturas y registros del tenant equivocado. Prueba también acciones de modificación: invitar usuarios, cambiar roles, borrar datos, exportar informes, crear claves de API, visualizar registros de auditoría. Un solo endpoint olvidado puede comprometer todo el modelo B2B.

Controles solo del lado del cliente: UI limpia, API abierta

Los generadores de apps con IA son buenos creando interfaces convincentes: muestran componentes diferentes según el rol, ocultan botones, deshabilitan campos, protegen páginas con guardias de ruta y generan menús separados para administradores y usuarios estándar. Estos controles mejoran la experiencia del usuario, pero no protegen la app si el backend sigue siendo permisivo.

Un usuario no debe estar autorizado porque el botón no aparece, sino porque el servidor rechaza la acción cuando el permiso, rol, propiedad o tenant no coinciden. Cada control del lado del cliente debe considerarse una comodidad, no una barrera de seguridad.

La prueba práctica consiste en llamar directamente a las API detrás de la UI: si un usuario estándar no ve “exportar”, intenta de todos modos el endpoint de exportación; si no ve “eliminar”, intenta una solicitud DELETE; si no ve el panel de administración, intenta acceder a la ruta; si un campo está deshabilitado en el formulario, modifica el cuerpo de la solicitud.

Broken Function Level Authorization

BOLA se refiere a los objetos; la Broken Function Level Authorization se refiere a las funciones. Un usuario puede no lograr leer datos de otros, pero sí lograr ejecutar acciones que corresponden a un rol superior: invitar usuarios, cambiar roles, aprobar solicitudes, emitir reembolsos, publicar contenidos, borrar espacios de trabajo, generar exportaciones o suplantar una cuenta.

En las apps generadas con IA esto ocurre cuando los roles se implementan en la UI pero no en las rutas: el código verifica que el usuario haya iniciado sesión, pero no que sea administrador, propietario, gestor de facturación, soporte o miembro autorizado. O bien, utiliza un campo role enviado por el cliente en lugar de leer los permisos desde un token verificado o desde la base de datos.

Para cada función sensible, define la matriz mínima: quién puede ejecutarla, sobre qué objetos, en qué estado y con qué límites. Luego prueba la acción con un rol inferior. Las funciones de administración deben fallar por defecto, no permanecer disponibles hasta que alguien note el problema.

Roles, permisos y claims: dónde confiar y dónde no

Los roles y permisos pueden provenir de Auth0, Supabase, claims personalizados de Firebase, bases de datos internas o sistemas corporativos. La parte crítica es dónde se verifican: el backend debe validar el token, la firma, la caducidad, el emisor y la audiencia cuando usa JWT o tokens de acceso, y luego traducir el rol y los permisos en decisiones de aplicación.

No confíes en role, isAdmin, user_id, tenant_id o permissions enviados en el cuerpo desde el frontend. No confíes en el almacenamiento local (local storage) ni en un campo oculto en el formulario: un usuario puede modificar solicitudes y encabezados, por lo que si una decisión de seguridad depende de un valor controlable por el cliente, esa decisión es frágil.

En una app generada por IA, verifica dónde se calcula el rol. Si el código muestra if (user.role === "admin") en el frontend, busca también el control equivalente del lado del servidor. Si no existe, el rol está protegiendo la interfaz, no la acción.

Middleware y nuevas rutas generadas por la IA

Un problema común es la cobertura incompleta del middleware. El proyecto tiene un middleware de autenticación para algunas rutas, pero la IA añade una nueva API, una acción de servidor, una función Edge, una Cloud Function o un endpoint de exportación sin conectarlo al mismo control, y la ruta funciona pero queda olvidada.

Este riesgo aumenta cuando el agente realiza refactorizaciones de múltiples archivos o crea funciones completas: nuevas páginas, nuevos manejadores, nuevos modelos, nuevos endpoints y nuevos tests. Si el patrón de autorización no está centralizado, cada nueva ruta se convierte en una decisión manual.

Antes del lanzamiento, haz un inventario de las rutas y para cada una pregúntate: ¿requiere inicio de sesión? ¿requiere rol? ¿requiere propiedad? ¿requiere tenant? ¿acepta ID del cliente? ¿devuelve datos? ¿modifica el estado? ¿produce exportaciones? Si no puedes responder, esa ruta debe ser probada.

Flujos de trabajo fuera de secuencia

Las vulnerabilidades de autorización no se refieren solo a objetos y roles, sino también al estado del flujo de trabajo. Una invitación puede ser reutilizada, un enlace de restablecimiento de contraseña puede seguir siendo válido, un pedido puede ser modificado después del pago, una solicitud puede ser aprobada dos veces, un reembolso puede ser llamado sin el estado correcto, un documento puede ser publicado antes de la revisión.

El código generado por la IA puede implementar los pasos individuales sin proteger la secuencia: la UI guía al usuario en el flujo correcto, pero la API acepta llamadas fuera de orden. Se trata de un problema de abuso de lógica de negocio, donde el atacante no rompe el inicio de sesión sino que usa funciones legítimas en el momento equivocado.

Para los flujos críticos, verifica el estado y los permisos juntos: no basta con saber que el usuario es el propietario, hay que saber si el objeto está en el estado que permite esa acción. Invitaciones, pagos, aprobaciones, exportaciones, publicaciones, eliminaciones y cambios de rol merecen todos pruebas negativas.

Rutas que a menudo escapan a la revisión

Las vulnerabilidades de autorización se encuentran a menudo en las rutas secundarias, no en la pantalla principal. Una página de detalle puede estar protegida, pero el endpoint de exportación puede devolver más datos de los previstos; un panel puede filtrar por tenant, pero una función de búsqueda global puede consultar toda la base de datos; una carga de archivos puede estar vinculada al usuario, pero la descarga puede depender solo de la ruta del archivo.

Controla con atención los endpoints de autocompletado, búsqueda, exportación CSV, informes, paneles agregados, webhooks, callbacks, notificaciones, cargas, descargas, vistas previas, funciones por lotes, cron jobs, suplantación, invitaciones, restablecimiento de contraseña, facturación, reembolsos y cambios de rol. Son funciones a menudo añadidas para completar el MVP y menos probadas contra abusos.

Las apps generadas con IA pueden crear estas rutas como soporte a la función principal: el prompt pide “añadir exportación”, “añadir panel de administración”, “añadir invitación de usuarios”, “añadir carga de documentos”. El código resultante puede ser funcionalmente correcto, pero no siempre hereda las mismas políticas que las rutas ya existentes.

Ejemplos prácticos de abuso a probar

En un SaaS con espacios de trabajo, un usuario estándar debería intentar leer /api/workspaces/{id}/members de otro espacio de trabajo, exportar pedidos de un tenant diferente, modificar el rol de un colega, regenerar una clave de API que no es suya o descargar archivos cargados por otro cliente. Si uno de estos casos funciona, el problema no está en el inicio de sesión: está en el modelo de autorización.

En una app de comercio electrónico o marketplace, intenta cambiar order_id, seller_id, customer_id, payment_id y refund_id. Un usuario no debe ver pedidos ajenos, modificar precios, acceder a recibos de otros clientes o llamar a funciones de reembolso fuera de su rol. Incluso los webhooks deben ser verificados: una callback no debe actualizar el estado de un pedido sin validar la firma, el estado y la propiedad.

En una herramienta interna generada rápidamente, prueba funciones que parecen inocuas: exportaciones, filtros avanzados, búsqueda, duplicación de registros, cambio de asignatario, acceso a comentarios, descarga de archivos adjuntos y visualización de registros de auditoría. Las herramientas internas a menudo tratan datos empresariales sensibles y tienen menos endurecimiento (hardening) porque no se perciben como productos públicos.

RLS y Security Rules ayudan, pero no bastan por sí solas

Supabase Row Level Security, Firebase Security Rules y controles similares son defensas importantes y pueden bloquear accesos directos a la base de datos o al almacenamiento cuando la app usa SDK del lado del cliente. Sin embargo, no sustituyen la lógica de autorización de la aplicación en API, funciones del lado del servidor, exportaciones, agregaciones, roles y flujos de trabajo.

Si una API del lado del servidor usa una clave de servicio o un rol privilegiado, debe aplicar la autorización antes de ejecutar consultas o devolver datos. Si una función produce un informe agregado, debe respetar el tenant y los permisos. Si un endpoint exporta datos, debe tener controles al menos tan fuertes como los de las pantallas que muestra.

El modelo más sólido combina varios niveles: políticas en la base de datos donde sea necesario, controles centralizados del lado del servidor, pruebas manuales en API y roles, registro de acciones sensibles y revisión del código en las áreas de control de acceso.

Cómo corregir sin multiplicar parches frágiles

Cuando encuentres una BOLA o una función accesible al rol equivocado, evita corregir solo el endpoint específico con una condición local. Si el problema surge de un patrón recurrente, es necesario centralizar el control: middleware, ayudantes de autorización, políticas compartidas, constructores de consultas seguros o capas de servicio pueden reducir el riesgo de que la próxima ruta generada por la IA repita el mismo error.

La remediación debería partir del modelo: qué roles existen, qué objetos protegen, qué tenants separan, qué acciones están permitidas y qué estados del flujo de trabajo son válidos. Luego, el código debe aplicar ese modelo de manera uniforme, porque si cada ruta decide autónomamente qué significa “administrador” o “propietario”, la seguridad depende de la memoria del desarrollador individual o del prompt utilizado por el agente.

Por cada error corregido, añade una prueba negativa. Si un usuario podía leer un documento de otro tenant, la prueba debe demostrar que ahora recibe una respuesta denegada. Si un rol bajo podía llamar a un endpoint de administración, la prueba debe permanecer en el pipeline. La corrección se vuelve fiable solo cuando el comportamiento incorrecto no puede volver sin fallar un control.

Pruebas negativas que no deben faltar

Las pruebas generadas por la IA cubren a menudo el camino feliz: inicio de sesión exitoso, usuario correcto, dato existente, rol previsto. Para las autorizaciones se necesitan pruebas opuestas, en las que cada función crítica demuestre que el usuario equivocado no puede ejecutar la acción.

Prepara casos para usuario no autenticado, token caducado, rol insuficiente, tenant diferente, objeto de otro usuario, ID inexistente, método HTTP diferente, cuerpo manipulado, estado no válido, invitación ya usada, enlace caducado, exportación no autorizada, carga fuera de ruta y eliminación no permitida.

Estas pruebas no deben quedarse solo en manuales: después de encontrar un problema, conviértelo en una prueba de regresión. Las apps generadas por IA cambian rápidamente, por lo que si un agente modifica el middleware o las consultas, una prueba negativa debe detectarlo.

Cuándo se necesita una verificación independiente

Una revisión interna puede bastar para prototipos sin datos reales, sin usuarios externos y con pocas rutas. Se necesita, en cambio, una verificación independiente cuando la app está expuesta en línea, gestiona datos reales, tiene roles diferentes, usa tenants o espacios de trabajo, expone API, produce exportaciones, gestiona pagos, usa funciones de administración o deriva de modificaciones amplias generadas por IA.

El WAPT es particularmente útil porque prueba el comportamiento real desde el exterior y como usuario autenticado: no se limita a leer el código, sino que prueba ID manipulados, rutas ocultas, roles insuficientes, tenants cruzados y flujos fuera de secuencia. La revisión de código (Code Review) es útil cuando hay que entender por qué falta el control: middleware no aplicado, consulta incorrecta, rol leído por el cliente, política incompleta, lógica duplicada. Los dos enfoques suelen ser complementarios: uno demuestra el abuso, el otro identifica la causa.

Cómo ISGroup puede verificar auth, roles y API

ISGroup puede probar las autorizaciones de una app generada con IA partiendo del comportamiento real: usuarios, roles, API, tenants, objetos, funciones de administración, exportaciones, cargas y flujos de trabajo críticos. El objetivo es demostrar si un usuario autenticado logra salir de su perímetro antes del lanzamiento.

Si la app generada con IA tiene…	Riesgo principal	Control recomendado
Web app, API, login, roles, tenants o cargas expuestas en línea	BOLA, IDOR, auth bypass, abuso de roles	Web Application Penetration Testing
Middleware, consultas, controladores, acciones de servidor o políticas en el código	Controles del lado del servidor incompletos	Code Review
Supabase, Firebase, Auth0, RLS, Security Rules o callbacks	Políticas y configuraciones no coherentes con la lógica de la aplicación	Cloud Security Assessment
Múltiples versiones generadas con IA sobre auth y API	Regresiones repetidas en el control de acceso	Software Assurance Lifecycle

¿Tienes una web app generada con IA con login, roles, tenants o API expuestas? ISGroup puede verificar si los usuarios autenticados logran acceder a datos o funciones fuera de su perímetro antes del lanzamiento.

Evidencias a preparar

Prepara las URL de los entornos, repositorios, lista de rutas y API, roles, tenants o espacios de trabajo, proveedor de auth, esquema de datos, políticas de base de datos, middleware, funciones de administración, exportaciones, cargas, pagos y partes generadas o modificadas con IA.

Se necesitan cuentas de prueba realistas: al menos dos usuarios estándar, un administrador, dos tenants o espacios de trabajo si están presentes, datos similares entre usuarios y objetos con ID conocidos. Para cada rol, indica qué acciones debería poder hacer y cuáles deben ser denegadas.

Si hay áreas inciertas, tráelas pronto a la revisión: rutas añadidas por la IA, controles duplicados, middleware no centralizado, RLS no verificada, claims usados en el lado del frontend, exportaciones creadas para demos, funciones de administración no documentadas.

Decisión antes del lanzamiento

Bloquea el lanzamiento si:

• Un usuario autenticado puede leer, modificar, borrar o exportar datos de otros usuarios o tenants.
• Un rol bajo puede acceder a funciones de administración.
• La API confía en ID o roles enviados por el cliente.
• Una ruta sensible no verifica la sesión y los permisos.
• Un flujo de trabajo crítico puede ser ejecutado fuera de secuencia.

Puedes planificar después del lanzamiento solo mejoras que no expongan datos o funciones: refactorización del modelo RBAC, documentación de los roles, aumento de la cobertura de pruebas, centralización progresiva del middleware. Los hallazgos sobre BOLA, IDOR, aislamiento de tenants y funciones de administración no autorizadas deben corregirse antes de tener datos reales y usuarios externos.

Lista de verificación de auth y autorizaciones

• Enumera todas las rutas que leen, modifican, borran o exportan datos.
• Asocia cada ruta al rol, propiedad, tenant y estado requerido.
• Prueba ID manipulados: user_id, tenant_id, project_id, order_id, document_id, invoice_id.
• Prueba diferentes usuarios, diferentes tenants, tokens ausentes, tokens caducados y roles bajos.
• Llama a las API directamente, sin pasar por la UI.
• Verifica funciones de administración: invitar, exportar, borrar, cambiar rol, suplantar, reembolsar, aprobar.
• Controla que el backend no lea el rol o el ID de usuario desde el cliente.
• Verifica el middleware en nuevas rutas, acciones de servidor, funciones y webhooks.
• Añade pruebas negativas por cada error encontrado.
• No publiques si un usuario puede salir de su perímetro.

Preguntas frecuentes

• Si uso Auth0, Supabase Auth o Firebase Authentication, ¿estoy protegido?
• No. Estas herramientas autentican al usuario, pero tu app debe autorizar de todos modos el acceso a datos, objetos, roles y funciones.
• ¿Cómo sé si tengo una BOLA?
• Accede como usuario A, intercepta una solicitud con el ID de un objeto y sustitúyelo por un ID del usuario B. Si recibes datos o logras modificar el objeto, tienes un problema.
• ¿Es suficiente ocultar un botón en la UI?
• No. La API detrás de ese botón debe rechazar la solicitud incluso si se llama directamente, independientemente de lo que muestre la interfaz.
• ¿Bastan las RLS o las Firebase Security Rules?
• Son controles importantes, pero debes verificar también las API del lado del servidor, exportaciones, funciones de administración, almacenamiento, flujos de trabajo y middleware.
• ¿Cuándo se necesita el WAPT?
• Cuando las apps y API están expuestas en línea o están a punto de estarlo. El WAPT prueba roles, objetos, tenants y rutas como lo haría un atacante autenticado.
• ¿Cuándo se necesita la Code Review?
• Cuando debes entender si los controles del lado del servidor, middleware, consultas, roles y políticas están implementados correctamente en el código generado o modificado por la IA.

[Callforaction-WAPT-Footer]

Fuentes y referencias útiles

• OWASP API Security Top 10: https://owasp.org/www-project-api-security/
• OWASP Broken Access Control: https://owasp.org/Top10/en/A01_2021-Broken_Access_Control/
• OWASP ASVS: https://owasp.org/www-project-application-security-verification-standard/
• OWASP Authorization Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html