GET /users/{userId} in application/backend/src/controllers/UsersController.ts returns the raw password hash and emailHash fields in the response body. Any authenticated admin (OrganisationAdmin or StudyAdmin) can retrieve any user's password hash by calling the endpoint with their user id.
PR #878 (Constrain User api response) addressed this class of bug for /users, /users/admin, and /users/admin/deleted by adding omit: { password: true, emailHash: true } to the Prisma queries. It also updated the type annotation on getUserById from User to UserResponse (which uses Omit<User, 'password' | 'emailHash'>), but the actual omit clause wasn't added to this endpoint's findUnique call. So the type contract says the response shouldn't include these fields, but at runtime they still are.
Fix: add omit: { password: true, emailHash: true } to the findUnique call in getUserById, matching the pattern used in the other three endpoints that PR #878 handled.

GET /users/{userId}inapplication/backend/src/controllers/UsersController.tsreturns the rawpasswordhash andemailHashfields in the response body. Any authenticated admin (OrganisationAdmin or StudyAdmin) can retrieve any user's password hash by calling the endpoint with their user id.PR #878 (Constrain User api response) addressed this class of bug for
/users,/users/admin, and/users/admin/deletedby addingomit: { password: true, emailHash: true }to the Prisma queries. It also updated the type annotation ongetUserByIdfromUsertoUserResponse(which usesOmit<User, 'password' | 'emailHash'>), but the actualomitclause wasn't added to this endpoint'sfindUniquecall. So the type contract says the response shouldn't include these fields, but at runtime they still are.Fix: add
omit: { password: true, emailHash: true }to thefindUniquecall ingetUserById, matching the pattern used in the other three endpoints that PR #878 handled.