Reflected input in API validation error messages (/api/address/balance)
The /api/address/balance endpoint reflected untrusted user input from the `network` query parameter directly into validation error responses without truncation or normalization, creating downstream injection risk if consumed by a UI or log pipeline.
Description
The endpoint /api/address/balance reflected untrusted user input from the network query parameter directly into the returned validation error message. When an invalid network value was provided, the API response included the attacker-controlled value in contents.errors[].message without truncation.
Example request:
GET /api/address/balance?address=<valid>&network=solanaLorem%20ipsum...
Host: www.mynth.ai
Origin: https://www.novaswap.io
While this behavior is common in validation frameworks, reflecting arbitrary input can increase downstream risk if the message is rendered in a UI component, forwarded to logs or monitoring systems, or processed by downstream services that do not properly escape content.
Impact
Low on its own. Becomes meaningful in the presence of a downstream consumer that renders error bodies into HTML or rich text, or where extremely long reflected strings could be used to craft log-injection payloads or response-splitting variants.
Recommendation
- Avoid reflecting raw user input in error strings where possible.
- If reflection is needed for debugging, truncate reflected values to a safe maximum length (50 to 100 characters) and normalize / escape untrusted content before including it in messages.
Novaswap: Confirmed. Zealynx: Fixed.