Reflected user input in API validation error messages (POST /api/address/generate)

The POST /api/address/generate endpoint reflected attacker-controlled request body values directly in validation error messages returned to the client. Invalid values supplied in fields such as source.blockchain, source.token, target.blockchain, and price were echoed verbatim in the error response.

Example body:

{
  "price": "foo",
  "source": { "blockchain": "solanafoo", "token": "MynthbcejYyY3yg8fzgPv2Y7NZrF2S4Y13wdGzAZPMvfoo" },
  "target": { "address": "0x8fA08A667dDa20Ef8110CDfE5ba58eAfa4373b50", "blockchain": "basefoo", "token": "0x26D3CDD9F4cc4c130097b6afdebe4f5e497E6Bdf" },
  "providerId": "novaswap"
}

The response echoed solanafoo, basefoo, and foo directly into the error string.

Low on its own. Reflecting raw user input in error messages can chain into downstream injection or log-injection risk depending on consumers.

Avoid reflecting raw user input in error messages. Where echoing the invalid value is helpful for debugging, restrict the reflected value to a safe-character whitelist and a hard length cap.

Novaswap: Confirmed. Zealynx: Fixed.