GraphQL authorization failures expose transaction and PII risk

At a glance

What this is: This is Salt Labs research showing how GraphQL and third-party API weaknesses enabled unauthorized transactions and customer PII exposure in a FinTech platform.

Why it matters: It matters because IAM, API, and fraud teams need to treat request-level authorisation, session continuity, and third-party API trust as control problems, not just application bugs.

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%.

👉 Read SALT's analysis of GraphQL authorization failures and PII exposure

Context

GraphQL and partner APIs often collapse many business actions into a small number of requests, which makes authorisation mistakes harder to spot and easier to exploit. In this case, the primary issue was not encryption or transport security. The failure was at the access-control layer, where the application did not reliably prove that the caller was allowed to act on the target record. For IAM teams, that is the same governance problem seen when service-to-service trust is assumed rather than continuously validated.

The article also shows why API security and identity governance increasingly overlap. Third-party APIs, mobile clients, and backend services can all become part of the access path, and a weak link anywhere in that chain can expose account data or permit fraudulent actions. This is typical of modern API-driven application stacks, not an edge case, which is why request-level authorisation and partner trust review need to sit inside broader identity and access control programmes.

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 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. If a backend or third-party endpoint accepts request parameters without strong authentication and authorisation, it can reveal PII, receipts, or account identifiers that support fraud. Shared responsibility must include response minimisation and logging.

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. The mistake is assuming the pinned value will remain valid for the full lifespan of the application or device. In reality, certificate change is normal, and pinning can make that change difficult to survive.

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.

Technical breakdown

Broken object level authorization in GraphQL

Broken object level authorization, or BOLA, happens when the server accepts a valid request but fails to confirm that the caller is entitled to access the specific object being targeted. GraphQL can make this harder to detect because a single query or mutation may touch several nested objects and backend services. If authorisation is checked only at the session or endpoint level, an attacker can change identifiers in the payload and act on another user’s data. The risk is not the protocol itself, but weak enforcement at the object boundary.

Practical implication: enforce object-level checks on every mutation and data-return path, not only at login or endpoint entry.

Broken authentication and trust in client-controlled parameters

Broken authentication in modern API systems often shows up when the application relies too heavily on client-supplied identifiers, tokens, or request context. In this case, the API accepted parameters that should have been validated against server-side identity state, allowing the researchers to manipulate transaction targets. Client-side protections such as certificate pinning can slow inspection, but they do not replace server-side verification. Once the backend trusts the request body more than the authenticated identity, the control plane is already weakened.

Practical implication: bind every sensitive API action to server-verified identity claims and reject caller-controlled identity substitutions.

Excessive data exposure through third-party APIs

Excessive data exposure occurs when an API returns more sensitive information than the calling function needs, especially when a partner endpoint can be reached without strong authentication. Here, a receipt lookup endpoint exposed names, addresses, account identifiers, and transaction data using only a transaction identifier. That is a governance failure as much as a coding defect, because downstream services inherit the trust and data-handling assumptions of the first-party application. In API supply chains, hidden data exposure paths are often where investigations should start.

Practical implication: review every partner and nested API response for minimum-necessary data and authenticated access requirements.

Threat narrative

Attacker objective: The attacker’s objective is to move money or reuse exposed identity and account data to enable fraud against other customers.

1. Entry occurred through exposed API functionality in a mobile and GraphQL-backed application where request parameters could be manipulated by the caller.
2. Credential or identity abuse followed when the backend trusted client-supplied identifiers instead of validating the caller’s right to act on the target record.
3. Impact came through unauthorized transaction submission and the exposure of PII that could support fraud, de-anonymisation, and further account abuse.

NHI Mgmt Group analysis

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.

GraphQL query consolidation creates an authorisation fan-out problem. When one request can traverse multiple objects and backend services, the blast radius of a single authorisation mistake increases. This article exposes the named concept of authorisation fan-out: the more backend paths a request can reach, the more places where a missing check becomes exploitable. Teams should assume that nested queries amplify governance complexity and require deeper policy enforcement.

Partner API trust is a hidden extension of the identity perimeter. The third-party receipt endpoint was part of the attack path, yet it was outside the main application’s direct control. That pattern matters because digital supply chains often inherit weak assumptions about authentication, data minimisation, and logging. Security leaders should govern partner APIs with the same scepticism they apply to privileged internal services.

Transport security does not compensate for missing access control. The research makes clear that TLS and certificate pinning can protect the channel while leaving the transaction itself vulnerable. That is a persistent mistake in modern API programmes: defending the pipe while ignoring the semantics of who can do what. Practitioners need layered controls that verify identity, entitlement, and data scope at the business action level.

This pattern will keep recurring wherever mobile apps, GraphQL, and external services intersect. The combination makes endpoint discovery harder, runtime behaviour more complex, and review coverage less reliable. That means governance must move from static endpoint inventories to continuous validation of sensitive actions and response data. The control gap is not visibility alone, but enforcement depth at the transaction boundary.

What this signals

The practical signal for security and identity programmes is that API governance now needs the same discipline as privileged access governance. If a business action can be executed by changing an identifier, the problem is not merely API testing but entitlement verification, partner trust, and runtime monitoring across the transaction path.

Authorisation fan-out: this is the control challenge created when one request can traverse multiple objects, resolvers, and partner services. The more layers a single action touches, the more likely one missing check will become a fraud or privacy incident. Teams should align API review with NIST SP 800-53 Rev 5 Security and Privacy Controls and the principles behind MITRE ATT&CK Enterprise Matrix to keep identity checks tied to actual behaviour.

For programmes that already manage NHIs and service accounts, the lesson is to extend governance into API callers and partner lookups. The same visibility problem that affects machine identities also appears in third-party API chains, where unused access, overexposed data, and weak logging make abuse hard to spot until after the fact.

For practitioners

• 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.
• Test mobile and GraphQL flows for runtime abuse Reverse-engineer representative client flows, replay them outside the app, and check whether certificate pinning, token checks, and backend authorisation all still hold under manipulation.
• Add continuous monitoring for cross-account transaction attempts Alert on repeated UID or TID changes, failed ownership checks, and receipt lookups that occur without a matching authenticated application session.

Key takeaways

• GraphQL and partner API flaws can turn valid sessions into unauthorised account actions when object-level authorisation is missing.
• The exposure was not limited to payments. The same weak controls also revealed PII, account identifiers, and receipts that can fuel fraud.
• Teams need server-side entitlement checks, data minimisation, and continuous monitoring across partner APIs before those paths become an incident.

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 Fan-out: The expansion of authorisation checks required when one GraphQL request can touch many nested objects, resolvers, and backend services. The risk grows when policy is enforced inconsistently across layers, because a single missed check can expose multiple records or business actions.
• Excessive Data Exposure: Excessive data exposure occurs when an API returns more information than the caller actually needs. The issue is usually a design and authorization problem rather than a coding typo, and it increases breach impact because a stolen credential can reveal far more data than intended.
• API Trust Boundary: An API trust boundary is the point at which a system decides whether to accept, reject, or constrain a request based on identity, policy, and context. It is where authentication becomes governance, because the boundary determines what data can move and under what conditions.

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.

👉 SALT's full post covers the attack sequence, exposed fields, and mitigation steps in detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle controls. It gives security practitioners a practical way to connect access governance across workloads, services, and AI-driven systems.