hunt-fintech-graphql

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