Mass-Assignment Vulnerability in `createProject` — User Field Overwrite

[Nixxx19]

p5.js version

Latest

What is your operating system?

None

Web browser and version

all

Actual Behavior

The createProject function in server/controllers/project.controller/createProject.js uses Object.assign() to merge req.body directly into projectValues. Because Object.assign overwrites existing keys, a user field in req.body replaces the req.user._id value that was set one line earlier. This allows an authenticated user to create a project attributed to any other user.

Location:

• File: server/controllers/project.controller/createProject.js
• Lines 9–13 (createProject) and Line 36 (apiCreateProject)

Vulnerable code in createProject:

let projectValues = {
  user: req.user._id          // set correctly…
};
projectValues = Object.assign(projectValues, req.body);  // …then overwritten by req.body.user

Vulnerable code in apiCreateProject:

const params = Object.assign({ user: req.user._id }, req.body);  // same issue

Note: apiCreateProject has a partial mitigation — it checks req.user.username !== req.params.username at line 63 — but createProject has no such check.

Expected Behavior

The user field should always be set to the authenticated user's ID (req.user._id) and must never be overwritable via the request body.

Steps to reproduce

1. Authenticate as any user
2. Send a POST to /editor/projects with a session cookie and:

   {
     "name": "Test",
     "user": "<victim_user_id>"
   }

3. Observe the response — the created project's user field (or user.username) is <victim_user_id> (or victim's username), not the authenticated user's ID/username

[Nixxx19]

Hi @raclim!

I'd love to work on this issue and submit the fix for it.

[raclim]

Thanks for flagging this as well @Nixxx19!

Since this is similar to the other issue, tagging @Iron-56 for any extra thoughts on this one as well!

[Nixxx19]

Thanks for the tag, @raclim!

Standing by for @Iron-56's thoughts, ready to get started as soon as I'm assigned!

[Iron-56]

@Nixxx19 You have got good eyes! Since your working on this issue, could you try swapping the order? If you have any hard time setting up S3 be sure to ask, thanks to @raclim for tagging along!

[Nixxx19]

@Iron-56 Thanks! I’ll go ahead and swap the order to ensure req.user._id takes precedence and cannot be overwritten by the request body.

I'll reach out if I hit any snags with the S3 setup. Thanks to you and @raclim for the review and the go-ahead!

[Nixxx19]

hi @raclim @Iron-56 !

I've just submitted PR #3889 to address this vulnerability.

I applied the "swapped order" logic to both createProject and apiCreateProject so that req.user._id always takes precedence. I verified this locally by attempting a spoofed POST request in the DevTools console; as shown in the screenshot below, the server correctly ignored the malicious ID and assigned the project to my authenticated account ('nityam').

Standing by for your review!