Notifications
Clear all
Topic starter
01/08/2026 8:58 pm
TL;DR: GraphQL and third-party API flaws in a FinTech platform let researchers submit unauthorized transactions and retrieve customer PII, according to SALT. The real lesson is that transport encryption and authenticated sessions do not compensate for missing request-level authorisation and partner API governance, illustrating broken authentication, broken object level authorization, and excessive data exposure in API-driven mobile services.
NHIMG editorial — based on content published by SALT: Salt Labs research on GraphQL API vulnerabilities in a FinTech platform
By the numbers:
- Lack of credential rotation is cited as the top cause of NHI-related attacks by 45% of organisations, followed by inadequate monitoring and logging at 37% and over-privileged accounts at 37%.
Questions worth separating out
Q: What breaks when GraphQL APIs do not enforce object-level authorization?
A: The application can authenticate a user and still allow that user to access or change records they do not own.
Q: Why do mobile and partner APIs increase fraud and data-exposure risk?
A: Mobile and partner APIs expand the number of trust boundaries that must be governed, and attackers look for the weakest one.
Q: What do security teams get wrong about certificate pinning?
A: Teams often treat pinning as a simple hardening layer, when it is really a trust governance decision with operational consequences.
Practitioner guidance
- Enforce object-level authorization on every sensitive mutation Map each GraphQL mutation and nested resolver to the specific identity and entitlement required for that object, then test identifier swapping and cross-account access attempts in runtime.
- Bind high-risk API actions to server-verified identity claims Reject request bodies that change the target account, recipient, or transaction owner unless the backend verifies the caller’s rights against authoritative session state.
- Review partner and nested API responses for data minimisation Strip account identifiers, addresses, and receipt details from responses unless the calling function genuinely needs them, and require authenticated access for every downstream lookup.
What's in the full report
SALT's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step walkthrough of the GraphQL request chain used to alter transaction targets and retrieve receipts.
- The exact API call sequence behind the BOLA, broken authentication, and excessive data exposure findings.
- Examples of how the researchers reversed mobile client behaviour and bypassed client-side protections.
- Mitigation guidance for validating third-party API endpoints and tightening authorization at the business-action layer.
👉 Read SALT's analysis of GraphQL authorization failures and PII exposure →
GraphQL authorization gaps: what IAM and API teams need to know?
Explore further
01/08/2026 9:05 pm
API authorisation failure is now an identity governance problem, not just an application bug. The article shows a system that authenticated the caller but did not reliably authorise the action on the target object. That is exactly where API security and IAM converge: the identity may be valid, but the entitlement to perform a specific transaction is not. Practitioners should treat request-level authorisation as part of access governance, not as a separate engineering concern.
A question worth separating out:
Q: How should organisations govern sensitive API actions in digital supply chains?
A: They should treat partner APIs as part of the access-control boundary, not as a separate technical integration. That means approving only the minimum data needed, requiring authentication for every lookup, validating entitlement server-side, and monitoring for anomalous access patterns across internal and external services. Governance must follow the transaction, not just the endpoint.
👉 Read our full editorial: GraphQL authorization failures expose transaction and PII risk
