Exposición excesiva de datos y límite de tasa

La entrada API3 de OWASP, autorización a nivel de propiedad de objeto rota, reúne dos fallos: devolver propiedades que quien llama no debería ver (exposición excesiva de datos) y aceptar modificar propiedades que no debería poder cambiar. Un patrón típico es que la API devuelve el objeto completo y la aplicación móvil solo pinta unos campos. El resto sigue viajando, visible para cualquiera que mire la respuesta con una herramienta, una cuenta de prueba o un proxy.

La corrección no está en la aplicación: el servidor debe devolver solo las propiedades que ese rol necesita, con una lista explícita, no «todo el objeto menos lo que se me ocurra ocultar».

No todos los campos sobrantes pesan igual. Un rol interno es una pista; una nota interna es un dato de negocio; el resultado de una función de derivación de una contraseña es un secreto de la cuenta que, aunque sea irreversible en teoría, facilita ataques sin conexión si se filtra. Se prioriza por lo que permite hacer a quien lo lea.

Abre respuesta_de_obtenerCliente, que recoge el cuerpo completo que devolvió el servidor a la cuenta de prueba, y localiza el campo que guarda el resultado de la función de derivación de la contraseña.

La entrada API4, consumo de recursos sin restricciones, incluye operaciones que se pueden repetir sin límite. OWASP cita explícitamente la validación de códigos de un solo uso y la recuperación de contraseña como operaciones que deben tener un tope por usuario en una ventana de tiempo. Un servidor que protege su inicio de sesión con un límite y deja sin límite la validación del segundo factor tiene el candado en la puerta equivocada.

Cuando el límite funciona, el servidor responde con el código 429, «demasiadas peticiones». La prueba de tasa de Tamarindo se hizo una vez, con 120 peticiones por minuto, el tope que fija el alcance, por operación. Consulta prueba_de_tasa y localiza la operación que nunca respondió 429.

Para el informe, el riesgo se expresa con una cifra que el cliente entienda. La ráfaga de la prueba admitió 120 intentos por minuto sin freno. Si esa velocidad se mantuviera una hora, ¿cuántos intentos de validación admitiría el servidor? Es un cálculo de exposición, no un intento: la cifra se compara con el espacio de códigos posibles para decidir la gravedad.

Otra forma de consumo sin restricciones es el tamaño de página. Si un parámetro permite pedir cien mil registros de una vez, una sola petición vale por cientos y descarga lo que hace falta en lotes grandes. La defensa es fijar en el servidor un máximo razonable de registros por respuesta, no confiar en el valor por defecto que usa la app.

Mira parametros_de_listado, que recoge qué máximo aceptó cada listado antes de rechazar la petición.