Prevent raw simulation/host error leakage through parseContractError

[Ehonrie]

Difficulty: Expert
Category: Security

Context: parseContractError's final fallback (return errorMessage || "Unknown error during simulation") surfaces the raw error message string directly to end users whenever it doesn't match a known Error(Contract, #N) or HostError: Error(WasmVm, pattern. Raw Soroban host/simulation errors can include internal details (memory addresses, contract storage keys, host function names) that shouldn't be exposed in a user-facing dapp — an information-disclosure smell, especially notable given recent commits specifically cleaned up contract-side error naming/grammar for user-facing clarity.

// dapp/src/utils/contractErrors.ts
export function parseContractErrorSafely(error: unknown): string {
  // !todo: Replace the unconditional raw-message fallback (contractErrors.ts:43) with
  //        an explicit allowlist of recognized error patterns; anything unrecognized
  //        should map to a generic safe message, with the raw detail logged
  //        (not displayed) for debugging.
  // !todo: Must not regress the existing HostError/WasmVm-specific messages
  //        (contractErrors.ts:18-41) — those stay, this only changes the final fallback.
  // !todo: Must audit contractErrorMessages (constants/contractErrorMessages) against
  //        contracts/tansu/src/errors.rs's ContractErrors enum for completeness/staleness
  //        (e.g. confirm NoProposalOrPageFound's renamed message is correctly reflected here).
  // !todo: Edge case: error objects with no .message and a toString() that itself
  //        leaks internals (e.g. stack traces stringified) must also be sanitized.
  throw new Error("Not implemented");
}

What contributors need to know:

• Problem: contractErrors.ts:4-44, specifically line 43's unconditional fallback.
• Related code: contracts/tansu/src/errors.rs (ContractErrors enum, 30 variants across 6 categories), dapp/src/constants/contractErrorMessages, dapp/scripts/validate-contract-errors.js (already exists — check whether it validates completeness of the mapping, which this issue should extend).
• Suggested approach: run dapp/scripts/validate-contract-errors.js first to see what it currently checks; extend or complement it rather than duplicating.
• Acceptance criteria: an unrecognized/malformed error input produces a generic safe message with no raw internals in the returned string; a test asserting every ContractErrors variant in errors.rs has a corresponding, non-stale entry in contractErrorMessages.

[beebozy]

Hi, could you please assign me this issue?. I would love to work on it

[Akshola00]

can i work on this