GraphQL authorization failures expose transaction and PII risk

At a glance

What this is: Salt describes GraphQL and third-party API failures that allowed unauthorized transfers and exposed customer PII in a B2B FinTech application.

Why it matters: This matters because IAM and API teams need request-level authorisation, not just authenticated sessions and encrypted transport, when APIs move money or expose sensitive records.

Context

GraphQL is a query layer that can combine multiple data requests into a single call, which makes authorization decisions harder to enforce consistently across a request path. In API-driven FinTech services, the security problem is not only whether a caller is authenticated, but whether every object, transaction, and nested response is authorised for that caller.

This case sits at the intersection of API security and identity governance because the application trusted session presence and client-side controls too much while failing to verify who could act on which account, record, or transaction. That is a common weakness in mobile and partner-integrated services, especially where third-party APIs sit inside the transaction flow.

Key questions

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. In GraphQL, one mutation may touch several objects, so missing checks at any layer can expose data, enable cross-account actions, or allow fraudulent transactions. The fix is server-side entitlement validation on every sensitive object, not just at login.

Q: Why do encrypted API sessions still leak data when authorization is missing?

A: Encryption protects the connection, not the decision about who may access a resource. If the server does not verify object ownership and request scope, an authenticated caller can still request another user’s transaction, receipt, or PII over a fully encrypted channel.

Q: What are the signs that a partner API is creating hidden authorization risk?

A: Look for unauthenticated endpoints, excessive response fields, and receipt or record lookups that work with only a transaction ID. Those signs show the partner service sits outside the same permission model as the primary application and can be used to amplify exposure.

Q: How should teams govern third-party APIs that sit inside payment flows?

A: They should treat them as part of the transaction control boundary, not as simple data sources. That means validating authentication, limiting returned fields, and testing whether the partner endpoint can be used to infer or alter customer activity without explicit permission.

Technical breakdown

Why GraphQL increases authorization complexity

GraphQL can collapse what would otherwise be several REST calls into a single request, often with nested fields and client-selected parameters. That design improves flexibility, but it also means authorization has to be evaluated repeatedly at field, object, and action level. If teams only authenticate the session and check the top-level request, a caller can still pivot to records or actions embedded deeper in the query. In practice, GraphQL turns authorization into a per-path control problem, not a one-time gate.

Practical implication: enforce authorization at every object and resolver boundary, not just at the API edge.

How broken object level authorization enables unauthorized transactions

Broken object level authorization happens when a user can change an identifier in a request and reach another user’s data or action without additional permission checks. In this case, that meant altering account or transaction identifiers in GraphQL calls could submit transfers against other customers. The issue is not transport security or login failure. It is that the server trusted a client-supplied identifier to decide ownership. Once that trust breaks, the API becomes a transaction relay for the attacker.

Practical implication: bind every transaction request to server-side identity context and reject client-controlled object swapping.

Why third-party API exposure compounds the risk

A partner or supplier API can widen the attack surface when it returns more data than the primary application needs, or when it can be queried without strong authentication. Here, a receipt endpoint exposed names, addresses, account identifiers, and transaction details from only a transaction ID. That creates both privacy exposure and attack chaining, because the leaked data can be reused to correlate activity or facilitate further fraud. In digital supply chains, the security of the composite workflow is only as strong as the weakest external endpoint.

Practical implication: treat third-party API responses as part of your authorization boundary and validate partner access controls continuously.

Threat narrative

Attacker objective: The attacker aims to move money between accounts and harvest enough customer and transaction data to enable fraud and identity correlation at scale.

1. Entry occurs through legitimate API access to a GraphQL-backed mobile application and its associated third-party receipt endpoint, not through malware or perimeter compromise.
2. Credentialed session access is then abused because the application fails to verify object ownership and request-level authorization on transaction and receipt requests.
3. The attacker escalates by swapping identifiers to submit unauthorized transfers and retrieve customer PII, which also exposes data needed to target other accounts.
4. The impact is unauthorized funds movement, customer de-anonymisation, and broader fraud enablement through exposed account and transaction data.

Breaches seen in the wild

• SalesBleed Salesforce Agentforce 2026: Three fixed Agentforce flaws let poisoned web leads make AI agents leak CRM data with zero clicks and send phishing under the agent's identity.
• United Nations breach 2021: Sakura Samurai used exposed Git credentials to reach 100,000+ UNEP staff records, then reported the flaw through the UN disclosure programme.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

GraphQL authorization debt is the real control problem here. The issue is not that GraphQL is inherently insecure, but that its flexibility raises the cost of getting authorization right on every resolver and downstream API call. Where teams rely on session authentication alone, they accumulate authorization debt across fields, objects, and partner flows. Practitioners should treat GraphQL as an authorization architecture challenge, not just an API syntax choice.

Broken object-level authorization remains one of the most reliable paths from login to loss. When a caller can alter an object identifier and reach another customer’s transaction or PII, the server has lost control of resource ownership. That failure is especially dangerous in FinTech because the same identifier can support both disclosure and fraudulent action. The practical lesson is that resource binding must be enforced server-side, every time.

Third-party API governance is part of identity governance when the API moves money or exposes PII. The moment a partner endpoint can return receipts, account identifiers, or transaction metadata, it becomes part of the trust boundary around customer identity and account control. Organisations often audit their own application code while leaving supplier endpoints outside the same discipline. That split view is what attackers exploit, so procurement, security review, and runtime monitoring need to cover the full call chain.

Transport encryption can create a false sense of control if request authorization is weak. TLS protects data in transit, but it does not prove that the caller may act on the requested object. In this incident, encrypted traffic still carried unauthorized actions because the server trusted the wrong identity signals. Practitioners should align their assurance model with the object, not the connection.

API security and IAM are converging at the request layer. In modern mobile and BFF architectures, the most important identity decision is often not who logged in, but what that identity is allowed to do against each object and transaction. That means access policy, session handling, and API design must be governed together. Teams that separate them leave a gap attackers can traverse.

What this signals

API authorization now has to be designed as a flow, not a checkpoint. In mobile and GraphQL architectures, the risk sits in the sequence of resolver calls, partner lookups, and object identifiers that travel through the request path. Teams should prepare for control designs that bind permission to each object and each action, not to the session alone.

Partner API exposure turns data minimisation into an access control issue. When receipt services or transaction lookups return account numbers, names, and addresses, the problem is no longer only privacy. It becomes an authorization boundary problem because the returned data can be used to drive further fraud or de-anonymise customers. Security reviews should therefore include downstream response content, not just upstream authentication.

API security architecture is now inseparable from identity governance in financial services. If a platform can move money, the identity question is what the caller may do to which object, through which path, and with what partner dependencies. That means IAM, API security, and third-party governance need one operating model rather than separate review tracks.

For practitioners

• Enforce object-level authorization on every GraphQL resolver Verify resource ownership on each resolver and nested field, especially where a single query can expose or change multiple objects. Do not rely on the authenticated session alone to infer permission for account, receipt, or payment data.
• Bind transaction requests to server-side identity context Compare the caller’s authenticated identity to the target account, recipient, and transaction scope before execution. Reject any request that depends on a client-supplied identifier to decide who may move funds or view another user’s records.
• Review partner API endpoints as part of the authorization boundary Inventory third-party APIs that return receipts, account details, or transaction metadata, then test whether they enforce authentication, least privilege, and response minimisation. Treat externally hosted endpoints as shared trust dependencies, not passive integrations.
• Reduce sensitive data in API responses Strip account identifiers, names, addresses, and other non-essential fields from transaction and receipt payloads unless the caller genuinely needs them for the immediate workflow. Narrow responses limit both privacy exposure and the data available for follow-on fraud.
• Test runtime API flows, not just code paths Use dynamic testing to exercise full mobile, GraphQL, and partner API sequences with altered identifiers and reused session context. Logic flaws often emerge only when the same request chain is replayed as an attacker would use it.

Key takeaways

• GraphQL flexibility can hide authorization failures until an attacker manipulates object identifiers or nested queries.
• The incident showed that unauthorized transfers and customer PII exposure can stem from the same missing control, namely request-level authorization tied to object ownership.
• Server-side identity binding and stricter partner API governance are the controls most likely to prevent this pattern from turning into fraud.

Key terms

• Broken Object-Level Authorization: A failure to check whether an authenticated identity may access a specific object, record, or device. The request succeeds because the credential is valid, but the application does not enforce per-object entitlement. In NHI environments, this turns a legitimate token into cross-resource exposure.
• GraphQL Authorization: GraphQL authorization is the control layer that decides what a caller may read, create, update, or delete within a GraphQL API. It sits alongside authentication and should be enforced consistently across queries and mutations so application logic does not leak access decisions into individual resolvers.
• API Response Minimisation: API response minimisation is the practice of returning only the fields a caller genuinely needs. It reduces the amount of personal, operational, or internal metadata available to an authenticated session and narrows the abuse value of any exposed endpoint.
• Third-Party API Governance: The discipline of validating, limiting, and monitoring external API dependencies that sit inside a business workflow. It covers authentication, data exposure, and operational trust because a partner endpoint can become part of the attack surface even when the primary application is correctly designed.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, IAM, and secrets management. It helps security practitioners connect identity controls to the wider application and API risks that shape modern programmes.