Feat/stage

[AdriGeorge]

enterprise node

General approach: Avoid returning raw exception messages directly to HTTP clients in a way that can be rendered as HTML. Instead, send a generic, non-sensitive message and log the detailed error server-side. If the client needs details, prefer structured JSON with sanitized content, and explicitly set a non-HTML content type.

Best targeted fix here:

• In the catch block of directCommandRoute.post, replace res.status(500).send(err.message) with a safe, fixed response body (e.g., “Internal server error”) and optionally a JSON shape that does not expose internals.
• Keep logging err.message (or the full error) to HTTP_LOGGER so server operators still see the details.
• Optionally, ensure we treat err as unknown and coerce to string safely for logging, but avoid using that string in the response.

Concretely, in src/components/httpRoutes/commands.ts:

• Modify lines 136–139 (the catch block) to:
  • Type err as any or unknown (we can keep any to avoid broader changes).
  • Log something like HTTP_LOGGER.error(err instanceof Error ? err.message : String(err)).
  • Respond with res.status(500).json({ error: 'Internal server error' }) or a similar generic message, instead of sending err.message.
• No changes are needed in validateCommands.ts for this issue; it only affects log messages and standard 400 responses that are not derived from thrown exceptions.

This single change ensures all the alert variants—each concerned with err.message being sent—are addressed, because the exception text will no longer be reinterpreted as HTML in the client.

---

In general, to fix this type of vulnerability, you should avoid returning raw exception messages directly to the client, especially when they may contain user input. Instead, return a generic, constant error message to the client (e.g., “Internal Server Error”) and log the detailed error message server-side. If you do need to expose some error details, encode or escape the message appropriately for the output context (HTML, JSON, etc.).

For this specific code, the best minimal fix that doesn’t change core functionality is to stop concatenating error.message into the HTTP response and send a static error message instead, while still logging the detailed error via HTTP_LOGGER. This preserves current behavior from the client’s perspective (still a 500 with an “Internal Server Error” message) but removes the XSS vector. Concretely, in src/components/httpRoutes/logs.ts, in the /log/:id route’s catch block, replace res.status(500).send('Internal Server Error' + error.message) with res.status(500).send('Internal Server Error'). No new imports or helper methods are needed because detailed error info is already captured by HTTP_LOGGER.error.