hunt-fintech-graphql

1## Why Fintech GraphQL Is a Different Risk Class
2 
3Generic GraphQL bugs (IDOR, mass assignment, introspection, batching abuse — see `hunt-graphql`)
4still apply here, but the blast radius changes completely: a resolver bug in a SaaS app leaks
5data, the same class of bug in a ledger mutation **moves money**. Three properties make fintech
6GraphQL backends a distinct hunting surface:
7 
8- **Money-movement mutations are almost always resolvers over a double-entry ledger.** A single
9  GraphQL mutation (`transferFunds`, `redeemRewards`, `withdrawToBank`) can trigger multiple
10  ledger writes (debit + credit + fee) that must be atomic. GraphQL's flexible input shape and
11  alias batching make it easy to desynchronize those writes.
12- **Decimals are attacker-controlled input, not display formatting.** Amounts, exchange rates,
13  interest, and rewards points are usually passed as GraphQL scalars (`Float`, `String`, custom
14  `Decimal`/`Money` scalar). How the resolver parses and rounds that value is exploitable surface
15  in its own right — this barely exists in non-financial GraphQL APIs.
16- **KYC/PII fields sit next to routine account fields in the same type.** `User` or `Account`
17  types commonly expose `ssnLast4`, `routingNumber`, `kycStatus`, `governmentIdUrl`, or
18  `linkedBankAccount` alongside `displayName` and `email` — one missing field-level authorization
19  check on a type used everywhere in the schema fans out to every query that touches it.
20 
21---
22 
23## Attack Surface Signals
24…