Bug Description
The DELETE /api/questions/:id endpoint returns error.message in its 500 error response:
res.status(500).json({ message: 'Server error', error: error.message })
This leaks internal implementation details (stack traces, database errors, file paths) to clients in production, which is a security risk.
Steps to Reproduce
Trigger a 500 error in the delete handler (e.g., invalid MongoDB ObjectId that somehow bypasses validation). The response will include the internal error message.
Expected Behavior
500 responses should return a generic error message without internal details:
res.status(500).json({ message: 'Server error' })
Actual Behavior
The raw error.message is sent to the client.
Impact
- Information disclosure: attackers can learn about database structure, internal file paths, or library versions
- Other endpoints in the same file (e.g., GET, PUT) correctly omit
error.message — this is the only inconsistent handler
Suggested Fix
Remove error: error.message from the 500 response on line 371:
// Before
res.status(500).json({ message: 'Server error', error: error.message })
// After
res.status(500).json({ message: 'Server error' })
Environment
- Node.js + Express + MongoDB
- Reproducible on latest
main
Labels
bug, good first issue
Bug Description
The
DELETE /api/questions/:idendpoint returnserror.messagein its 500 error response:This leaks internal implementation details (stack traces, database errors, file paths) to clients in production, which is a security risk.
Steps to Reproduce
Trigger a 500 error in the delete handler (e.g., invalid MongoDB ObjectId that somehow bypasses validation). The response will include the internal error message.
Expected Behavior
500 responses should return a generic error message without internal details:
Actual Behavior
The raw
error.messageis sent to the client.Impact
error.message— this is the only inconsistent handlerSuggested Fix
Remove
error: error.messagefrom the 500 response on line 371:Environment
mainLabels
bug,good first issue