critical: POST /transactions submits arbitrary third-party XDR with no source-account binding, idempotency, or rate limits

[EmeditWeb]

Problem

TransactionsService.submitTransaction() (src/modules/transactions/transactions.service.ts, lines 87–112) accepts any well-formed XDR string and immediately submits it to Horizon. It never checks that:

1. Source account == authenticated wallet — the wallet parameter is used only to attribute the persisted record (line 101), not validated against transaction.source. A user can submit transactions signed by entirely different accounts, and the DB records them as that user's activity — poisoning loan/vendor dashboards, audit trails, and the indexer.
2. No submission idempotency — the same XDR submitted twice hits Horizon twice (second may fail on seq, but the race is real for time-bounded txs), and two rows get inserted for one hash.
3. No rate limiting — the endpoint is an open relay to Horizon; spamming costs the API's Horizon quota and lets abusers use the backend as a free transaction proxy.
4. No operation allowlist — arbitrary operations (payments, account merge, set options, trustlines) pass through, including operations that make no sense in StepFi's flows.

Because persistTransactionRecord is fire-and-forget (line 101), Horizon succeeds even when persistence fails — the transaction hash is then unknown to the status-checker/indexer reconciliation paths.

Ground Rules

1. Read context/architecture-context.md, context/code-standards.md, context/progress-tracker.md in full
2. Read SubmitTransactionRequestDto and the transaction-type taxonomy it defines
3. Read src/modules/transactions/transactions.repository.ts and the transactions table usage in getTransactionStatus() before changing persistence

What To Build

1. Parse the XDR, extract the source account (and fee-bump inner source), and reject with a structured error unless it equals the authenticated wallet.
2. Enforce an operation allowlist per declared type (e.g. loan_payment must contain the expected contract-invocation op) — reject mismatched payloads with codes like TRANSACTION_TYPE_MISMATCH.
3. Idempotency: unique constraint on transaction hash + pre-insert existence check; duplicate submissions return the original record instead of re-submitting.
4. Add per-wallet and global rate limits using the repo's established middleware patterns.
5. Make persistence failures surface: retry queue or at minimum return 202-with-warning semantics documented in the DTO — do not silently drop.
6. Tests covering every rejection branch plus the happy path regression.

Files To Touch

• src/modules/transactions/transactions.service.ts
• src/modules/transactions/dto/submit-transaction-request.dto.ts
• src/modules/transactions/transactions.repository.ts
• migration for unique hash constraint
• tests
• relevant docs/progress tracker

Acceptance Criteria

• Third-party-sourced XDR is rejected with a typed error
• Duplicate hashes cannot create duplicate rows or double submissions
• Rate limits active per wallet
• Suite green

Mandatory Checks Before Opening PR

Standard checklist applies. PRs failing any check will be closed without review.

[bobo-24]

Hi! I came across this issue and would love to work on it. I have experience with similar tasks and I'm confident I can investigate, implement a clean solution, and thoroughly test it before submitting a PR. If the issue is still open, I would appreciate it if you could assign it to me. I’ll prioritize this immediately and ensure a reliable solution is delivered as soon as possible. Thank you!

[Jumongweb]

Hi maintainer, i will like to solve this issue

[Marvelg256]

Hi! I'd like to work on this issue. I've reviewed the requirements and believe I have a good understanding of what's needed. I'm confident I can implement a clean solution, test it thoroughly, and submit a PR within 48 hours. If assigned, I'll keep the issue updated with my progress.

[MerlinTheWhiz]

Hello, I'm MerlinThewhiz, a software engineer with a strong background in smart contract, and a couple years in my arsenal. Having read the task requirement, I'd love to work on this issue. Please assign.

[Flames4fun]

Hey, I have a second slot available and this issue looks like a good fit for work I’ve been doing recently.

A couple of my merged OSS fixes are quite close to the trust boundaries involved here. In Vero relayer # 209 I hardened the authenticated rate-limit tier so request-controlled headers could not obtain privileged treatment without a verified HMAC signature. In Vero audit-guard # 324 I worked directly with Stellar/Horizon transaction verification and made the transaction identity and trusted source explicit rather than relying on ambiguous lookup behavior.

What interests me here is that the four problems seem to reinforce each other: the API currently trusts the caller’s attribution, then submits before establishing an idempotent local record, while accepting more operation shapes than the declared StepFi flow actually needs. My first approach would be to put validation ahead of every irreversible boundary: decode the envelope including fee-bump inner source, bind it to the authenticated wallet, validate operations against the declared transaction type, then make the DB hash constraint the authoritative idempotency barrier rather than relying only on a pre-check. I’d keep rate limiting on the repo’s existing middleware path and make persistence failure explicit instead of allowing a successful Horizon submission to disappear from reconciliation.

This one has a little more surface area than a normal bugfix, but if the repository already has the middleware and migration patterns referenced in the issue, I’d estimate around 2–4 hours optimistically for a PR with the rejection-path and regression tests included.

If it’s unclaimed, I’d be glad to work on it.

[grantfox-oss]

🦊 GrantFox — @Marvelg256 has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #117)
2. Your PR will be reviewed by the StepFi-app maintainers

Good luck! Track your progress on GrantFox.