Respuestas que exponen propiedades internas

Cuando un controlador devuelve el modelo tal cual, el framework lo convierte a JSON con todas sus columnas, salvo las que el modelo excluya. La aplicación luego pinta tres o cuatro de esos campos, y el equipo cree que el resto «no se ve». Pero la respuesta completa llega al dispositivo de quien pregunta: cualquiera la lee en las herramientas de desarrollo del navegador o en el tráfico de su propio teléfono.

El Top 10 de seguridad de APIs de OWASP de 2019 lo llamaba exposición excesiva de datos; la edición de 2023 lo unió con la asignación masiva en API3:2023, porque los dos son la misma pregunta hecha en dos direcciones: qué propiedades de este objeto puede ver o cambiar esta persona. MITRE tiene para la exposición, entre otras, CWE-213 (información sensible expuesta porque las políticas no coinciden), que su propia ficha marca como en estudio para retirarse por solaparse con otras; antes de etiquetar con ella, compara con la entrada de exposición de datos personales.

Abre el laboratorio, entra en la carpeta pulsoandino-respuestas y lee EntrenadorController.php y Entrenador.php. El modelo usa una lista negada para la salida: excluye la clave y el token de recordar sesión, y deja salir todo lo demás. Después abre respuesta-entrenadores.json.

Compara la respuesta con pantalla-entrenadores.txt, que dice qué campos usa la app. Lo que la app no usa es lo que la respuesta no debería traer.

La exposición pesa más cuando la ruta no pide sesión: entonces la respuesta la puede leer cualquiera. Cruza rutas-api.txt con las respuestas guardadas y busca qué ruta sin middleware de autenticación anida al socio completo.

En la carpeta hay un ejemplo que ya está bien: PerfilResource.php construye la respuesta del perfil con los campos elegidos uno por uno, y respuesta-perfil.json muestra el resultado. Es la lista de permitidos aplicada a la salida.