Security Patch: Sanitize Error Responses to Prevent Internal Schema and Data Leakage

[ArshVermaGit]

Description

This Pull Request resolves a moderate-severity information disclosure vulnerability where the global error handler indiscriminately returned raw err.message, err.details, and internal error structures directly to the client. Attackers could deliberately trigger validation failures and edge-case errors to extract internal schema structures (via Zod validation details), server file paths (via stack traces), database constraint names, and dependency information — effectively providing a free reconnaissance roadmap of the application's internals.

Key Changes

• Rewrote errorHandler.js (backend/middlewares/errorHandler.js) with a three-tier error classification strategy:
  • ZodError (validation): In production, returns only { error: "Validation failed" } with zero field-level details. No schema names, types, constraints, or enum values leak. In development, full err.errors are included for debugging convenience.
  • HttpError (intentional): These are thrown by our own code with controlled, safe messages. The message is always returned to the client. The err.details property (which may contain internal context like retry hints) is only included in development.
  • Unknown errors (library crashes, DB failures, etc.): Fully masked in production using a SAFE_STATUS_MESSAGES lookup map. The client only ever sees generic messages like "Internal server error." — never raw err.message, err.stack, file paths, or database constraint details.
• Request ID correlation: All errors are logged server-side tagged with req.requestId, enabling full debugging via server logs without exposing any information to clients.
• Development toggle: Verbose error details (including stack traces) are automatically included when NODE_ENV !== "production", preserving a smooth local debugging experience.

Resolved Issue

Resolves #674

Verification Steps

1. Set NODE_ENV=production and send a request with an intentionally malformed body to a validated endpoint. Confirm the response contains only { "error": "Validation failed" } with no details or field names.
2. Trigger an unexpected server error (e.g., disconnect the database). Confirm the response contains only { "error": "Internal server error." } with no stack traces, file paths, or library-specific error formats.
3. Set NODE_ENV=development and repeat. Confirm that full error details, Zod field errors, and stack traces are now visible in the response for debugging.
4. Check server logs in both modes and confirm the full error is always logged with the request ID for correlation.

[vercel]

@ArshVermaGit is attempting to deploy a commit to the durdana3105's projects Team on Vercel.

A member of the Team first needs to authorize it.

[ArshVermaGit]

Hi @durdana3105 ! The issue assigned to me has been resolved in this PR . Please consider reviewing it and merging it under GSSoC. Thanks!