Bug

POST /api/users lets a caller override the server-generated user id. apps/api/src/services/userService.js creates the user object with id first, then spreads the caller payload afterward:

const user = { id: `usr_${Date.now()}`, ...payload };

Because the payload is applied after the generated id, a request body can replace the server-owned id.

Reproduction payload:

{
  "id": "usr_attacker",
  "email": "user@example.com",
  "name": "User"
}

Observed behavior from current origin/main:

HTTP 201
{ "success": true, "data": { "id": "usr_attacker", "email": "user@example.com", "name": "User" } }

Impact

• Public user creation can choose a server-owned identifier.
• Callers can create confusing or colliding user ids.
• Downstream records that trust user ids can be associated with client-controlled identifiers.

Expected behavior

The server should always own the generated user id. Caller-supplied id values should not override the generated usr_... value, while normal user payload fields should still be preserved.

Proposed fix

• Apply caller payload fields before server-owned fields in user creation.
• Add endpoint regression coverage proving caller-supplied id is ignored.
• Keep the change scoped to user creation behavior.

This issue is limited only to the creator of this issue. This means that only the issue author can attempt to solve this issue. If you would like to work on it, please create another issue with the same contents and refer to issue #743 for more information.

Parent bounty: #743.