Autenticación y autorización no son lo mismo y es justo la segunda la que se queda a medias en las apps hechas con IA. La autenticación es el registro, el inicio de sesión, el restablecimiento de contraseña. La autorización a su vez decide qué tienes permitido hacer una vez que ya estás dentro de la aplicación. Puedes ver los datos de otra persona? Puedes editar algo que tú no creaste? No debería.
Los 5 prompts de abajo sirven exactamente para eso, para comprobar en tu propio proyecto quién tiene acceso a cada función.
Cada función de tu app (cargar un perfil, borrar un pedido, actualizar un dato) vive en el backend como una función independiente. Cada vez que una función del backend recibe una petición, tiene que decidir dos cosas: quién la pide (autenticación) y si esa persona en concreto tiene permiso para esa acción en concreto (autorización). Este pack revisa la segunda.
Qué es: Cada función que toca un dato ligado a una persona recibe un id (el pedido número 482, el usuario número 35) y tiene que comparar ese id contra quien hizo la petición, no solo comprobar que viene de alguien que inición sesión.
Para qué: La mayoría de las apps tienen autenticación, pero no autorización. Son dos comprobaciones distintas y falta la segunda con mucha más frecuencia de lo que parece.
Prompt: Busca toda función que lea, edite o borre algo que pertenece a una persona en concreto (un pedido, un perfil, un mensaje, un archivo). Para cada una dime si comprueba que el id pertenece a quien ha iniciado sesión o si solo comprueba que hay una sesión iniciada, sin mirar de quién es el id. Si es lo último, señálalo como fallo.
Qué es: Esta prueba consiste en repetir la misma petición cambiando solo el id, para comprobar si el servidor detecta el cambio o lo deja pasar.
Para qué: Es la forma más rápida de comprobar si ese fallo existe en tu app, en vez de asumir que la IA ya lo había detectado.
Prompt: Crea 2 usuarios de prueba en la aplicación. Inicia sesión como el primero y guarda el id de algo suyo (un pedido, un documento, un mensaje). Ahora, sin cerrar esa sesión, intenta acceder a ese mismo recurso, pero sustituyendo el id por uno que pertenezca al segundo usuario. Dime exactamente qué respuesta da la aplicación: carga el contenido ajeno, dice que no existe o dice que no tienes permiso.
Qué es: Un control de permisos se puede poner en dos sitios: en el frontend o en el backend. En el frontend, como mucho se puede ocultar un botón para que no lo presionen. Cualquiera puede saltarse ese botón y mandarle la misma petición al servidor a mano. En el backend, en cambio, se puede rechazar esa petición aunque llegue. Solo el backend cuenta como protección real, porque el frontend no lo controlas tú, sino quien usa la app.
Para qué: Ocultar un botón no protege nada por sí solo. La protección real está en que el backend rechace una petición, venga de donde venga.
Prompt: Busca en la parte visual cualquier acción que solo aparezca para ciertos usuarios, como un botón de administrador o una opción de borrar. Para cada una, comprueba si esa protección vive solo en la pantalla o si también está comprobada en el servidor, de forma que, aunque alguien llame a esa función directamente sin pasar por el botón, la aplicación la rechace igual.
Qué es: Toda función que carga una lista tiene que añadir una condición del tipo 'solo lo que pertenece a este usuario' dentro de la propia consulta a la base de datos. Sin esa condición, la base de datos entrega todo y la única barrera que queda es que la pantalla decida qué enseñar.
Para qué: Es el mismo problema que el punto 1, pero en vez de afectar a un solo dato, afecta a una lista entera. Si alguien le pide los datos directamente al servidor, ve la tabla completa en vez de solo lo suyo.
Prompt: Busca las funciones que devuelven varios elementos a la vez, como ver mis pedidos, ver mis mensajes o cualquier panel con una lista. Comprueba si esa consulta a la base de datos filtra explícitamente por el usuario que hace la petición o si trae todos los registros.
Qué es: La pantalla para actualizar tu perfil solo te deja cambiar tu nombre y tu foto. Pero la petición que se manda al servidor puede que no esté limitada solo a esos 2 datos. Alguien puede modificar esa petición antes de enviarla y meter un dato de más, por ejemplo, "Soy administrador". Si el servidor no revisa qué datos le llegan, ese dato de más se guarda también.
Para qué: El ataque no necesita hackear nada, solo edita la petición antes de enviarla y añade una línea de más. Si el servidor no tiene una lista explícita de qué campos acepta, acepta cualquiera.
Prompt: Busca los formularios que actualizan datos de un usuario, como su perfil, su plan o su cuenta y mira qué campos acepta esa función del servidor. Dime si acepta cualquier campo que le llegue, incluidos los que no deberían venir del usuario, como su rol o su plan de pago.
La autorización no se construye sola por usar una IA. Tienes que pedirlo explícitamente. Los 5 prompts de este pack te ayudan a entender los fallos de autorización de tu aplicación.
