Raw error objects leaked in 500 responses across several controllers

p5.js version

No response

What is your operating system?

None

Web browser and version

No response

Actual Behavior

Multiple catch blocks in server controllers send the raw err object
straight into res.json(). This means stack traces, mongoose internals,
and whatever else lives on the error can end up in the response body.

Affected spots:

• server/controllers/user.controller/signup.ts L79, L161 → res.status(500).json({ error: err })
• server/controllers/user.controller/userPreferences.ts L36, L64 → same
• server/controllers/user.controller/authManagement.ts L204 → same
• server/controllers/user.controller/helpers.ts L70 → res.status(500).json({ error }) (shared saveUser helper, so this one fans out)
• server/controllers/project.controller.js L349 → res.status(500).json(error) — the error is the response body, no wrapping at all

Why the global error handler doesn't help here:

The fallback at server.js L199 sends a safe generic string, but it
only fires for errors passed through next(). All the spots above call
res.json() directly and never hit next(),..so the middleware is
completely bypassed.

Expected Behavior

500s should return something like { error: "Internal Server Error" }
and the real error should just be console.error'd

Steps to reproduce

Trigger any DB error in the affected routes (e.g., kill mongo mid-request, send malformed data to /preferences, etc). Check the network tab, you'll see the full error object with stack trace in the response body instead of a sanitized message

Start by reviewing the listed catch blocks in server/controllers/user.controller/signup.ts, userPreferences.ts, authManagement.ts, helpers.ts, and server/controllers/project.controller.js, then compare them with the fallback in server.js. Trigger a database failure and confirm affected 500 responses contain only a generic error while the real error is logged rather than serialized.