Skip to content

User and proposal creation should keep generated ids server-owned (SnowfallHD reissue via #743) #5948

@SnowfallHD

Description

@SnowfallHD

Bug Description

POST /api/users and POST /api/proposals forward request bodies into services that construct records as { id: generated, ...payload }. Because caller payload fields are spread last, a client can provide an id field and override the server-generated user or proposal id.

Expected Behavior

User and proposal ids should be server-owned. Client-controlled id values should be ignored so callers cannot create records with arbitrary, duplicate, or misleading identifiers.

Reproduction

  1. Start the API.
  2. Send POST /api/users with { "id": "usr_attacker_controlled", "name": "Example User", "email": "user@example.com" }.
  3. Send POST /api/proposals with { "id": "prp_attacker_controlled", "jobId": "job_123", "freelancerId": "usr_123", "coverLetter": "I can complete this job." }.
  4. Observe that the responses can return caller-supplied ids instead of generated ids.

Proposed Fix

  • Assign generated user and proposal ids after spreading caller payload fields.
  • Add regression tests proving caller-controlled user/proposal ids are ignored.
  • Include a short demo video showing the focused tests and diff proof.

Parent bounty: #743

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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions