API exposure and zero-auth tokens are turning drive-thru systems into breach paths

At a glance

What this is: This is an analysis of how exposed APIs and unauthenticated token generation turned drive-thru and hiring systems into data exposure paths, with a second example showing the same pattern in McHire.

Why it matters: IAM, API security, and identity governance teams need to treat API inventory, authentication, and runtime controls as part of the access model for customer and worker data.

Context

APIs often become the hidden control plane for customer-facing and workforce systems, which means a weak API layer can bypass the safeguards teams think are protecting identity, data, and business workflows. When APIs are left discoverable, unauthenticated, or over-permissive, the result is not just application exposure but direct access to credentials, records, and operational functions.

This article sits at the intersection of API security, identity governance, and data protection. The identity angle matters because token issuance, authentication bypass, and privilege escalation all change who can act on a system, not just what data the system stores. In this case, the governance gap is an access model that trusts API paths too much and validates them too little.

Key questions

Q: What breaks when APIs can mint tokens without authentication?

A: Authentication collapses when a public endpoint can issue valid tokens, because the session it creates looks legitimate to downstream systems. Attackers can move from anonymous access to privileged actions without stealing a password. The safest response is to separate account creation from credential issuance and require policy checks before any token is minted.

Q: Why do exposed API keys often lead to privilege escalation instead of immediate data theft?

A: An exposed API key may not grant direct access to sensitive records, but it can provide an attacker with authenticated entry into a trusted environment. From there, the attacker can enumerate services, test permissions, and look for misconfigurations or weaker accounts. That makes the key a foothold, not the end goal, especially in environments where identity controls are uneven.

Q: What are the signs that API visibility is failing in a production environment?

A: Common signs include delayed releases caused by unresolved API risks, low confidence in inventory accuracy, missing or outdated documentation, and production APIs exposing sensitive data without clear controls. Shadow and zombie endpoints are also strong indicators of failure because they show that discovery is not keeping pace with deployment and decommissioning activity.

Q: Should teams prioritise API discovery or enforcement first?

A: Discovery comes first when shadow endpoints or incomplete inventories exist, because enforcement cannot protect what the team has not identified. Once the exposed surface is known, prioritise the most sensitive and most attacked APIs for schema validation, bot controls, and runtime enforcement.

Technical breakdown

How exposed GraphQL and open signup paths expand attack surface

GraphQL introspection makes schema and mutation structure easier to enumerate, which is useful for developers but equally useful for attackers looking for high-value operations. When open signup is enabled, the attacker does not need prior trust to begin interacting with the API. The result is a broad, discoverable surface where hidden functions, token issuance endpoints, and admin paths can be tested at scale. This is not a front-end problem alone. It is a failure to treat API inventory and exposure as part of the security boundary.

Practical implication: inventory and restrict API discovery points before they become attacker reconnaissance tools.

Why zero-auth token issuance breaks access control

A token endpoint that issues credentials without authentication collapses the first control in the chain. If an attacker can create a token, the system has effectively turned an unauthenticated request into an authenticated session, often with enough structure to probe authorization flaws next. That is especially dangerous when tokens are accepted across multiple roles or environments. The core issue is not simply weak login logic. It is an access model that allows identity creation and privilege assignment to occur without trust establishment.

Practical implication: require authentication before token creation and validate role scope at issuance time.

How privilege escalation and runtime abuse turn exposure into breach

Once an attacker has a valid token, poor authorization boundaries can let them move from customer-level access to administrative functions or sensitive data paths. In API-heavy environments, the damage often accelerates because attackers automate requests, harvest records, and pivot across workflows before defenders notice. Runtime protection matters here because static checks do not stop a live abuse sequence. Rate limiting, behavioural detection, and blocking rules need to operate on the same paths that carry business traffic, not around them.

Practical implication: enforce authorization and runtime blocking on the same API paths that process real customer and workforce data.

Threat narrative

Attacker objective: The attacker objective was to obtain authenticated access, escalate privileges, and reach customer or applicant data without going through normal identity controls.

1. Entry occurred through exposed API surfaces, including GraphQL introspection and open signup paths that let attackers map available operations.
2. Credential abuse followed when a zero-auth createToken mutation issued credentials without verifying identity or session trust.
3. Escalation happened as valid tokens enabled privilege growth from ordinary customer access to administrative functions and sensitive data retrieval.
4. Impact included access to live drive-thru audio and customer PII, with a parallel example showing candidate data exposure through McHire APIs.

Breaches seen in the wild

• McHire default password flaw 2025: A forgotten test admin account with the password 123456 and an API flaw exposed McDonald's McHire applicant records to researchers.

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

API discovery has become an identity control problem, not just an application inventory problem. When attackers can find forgotten GraphQL endpoints, shadow APIs, or mutation paths, they are effectively mapping the organisation’s real access model. That makes API inventory part of governance over who and what can act on business systems. Practitioners should treat undiscovered APIs as unmanaged access paths, not mere technical debt.

Zero-auth token issuance is a governance failure because it collapses trust establishment into a single unaudited step. If an unauthenticated request can mint a credential, the organisation has created a machine-speed identity creation path with no meaningful proofing or assurance. That is why API authentication cannot be separated from identity governance. The control failure is not only in login logic, but in letting credential issuance happen before trust is established.

Drive-thru and hiring workflows expose the same structural risk when APIs are the real business interface. Once the API becomes the front door, classic perimeter thinking misses the true control point. Access decisions must be enforced at the API boundary, with scope, authorisation, and runtime restrictions aligned to actual business actions. Practitioners should assume any externally reachable workflow API can become a breach path if discovery and issuance are weak.

Runtime blocking is now part of the access-control stack for high-volume API environments. In fast, automated abuse scenarios, detection after the fact is too late because the attacker can farm tokens and extract data in seconds. The right governance model is to pair authentication and authorisation with behavioural enforcement at execution time. Security teams should measure whether the API layer can stop abnormal access patterns before records or credentials leave the system.

API exposure and zero-auth token abuse fit the broader secret-sprawl challenge. The article shows how an issuer can behave like an unmanaged secret factory when endpoint discovery and authentication are weak. That creates a governance blind spot where credentials appear valid even though the trust chain behind them is not. Practitioners should fold API token paths into the same control thinking they use for NHI secrets and service credentials.

What this signals

API governance now sits on the same critical path as identity governance. When token issuance, discovery, and authorisation are weak, the API layer becomes an access-control bypass rather than a business enabler. Programmes that still separate API management from IAM will miss the control point where attackers actually gain usable access.

Discoverability is the first weakness to close in high-volume consumer workflows. GraphQL introspection, forgotten mutations, and open signup endpoints let attackers learn the shape of the system before any authentication challenge appears. The practical lesson for security teams is to treat undocumented API surfaces as live exposure, not theoretical risk.

Runtime enforcement must be aligned to business traffic, not bolted on after abuse begins. Automated attacks move too quickly for post-event review to be the primary control, especially when valid tokens can be minted and used in the same sequence. The programme signal is clear: blocking, rate limiting, and anomaly detection need to operate where the business logic executes.

For practitioners

• Map every externally reachable API and mutation path Build a complete inventory of customer-facing, workforce-facing, and internal APIs, including GraphQL schemas, hidden mutations, and forgotten endpoints. Treat untracked API paths as unmanaged access surfaces that need ownership and review.
• Require authentication before token issuance Block any create-token or session-minting flow unless identity is verified and the requested scope is explicitly authorised. Review whether tokens can be created, refreshed, or exchanged without a trusted user or workload context.

Key takeaways

• Exposed APIs can turn customer-facing and workforce-facing systems into direct breach paths when discovery, authentication, and authorization are weak.
• The RBI case shows how zero-auth token issuance can combine with privilege escalation to expose live operational data and PII.
• Security teams need complete API inventory, authenticated token creation, and runtime enforcement if they want to reduce the blast radius of API abuse.

Key terms

• API Discovery: API discovery is the process of finding and cataloging APIs across an environment so security teams know what exists, what data it exposes, and how it behaves. It is essential because shadow, zombie, unmanaged, and third party APIs are frequent blind spots that attackers can exploit without being noticed.
• Token Issuance: Token issuance is the process of creating OAuth2 or OpenID Connect tokens that represent an authenticated identity for downstream systems. It is narrower than identity management because it focuses on brokered credentials and session flow, not user lifecycle, access policy, or application authorization.
• Method-Level Authorization: Method-level authorization restricts access at the business method rather than only at the route or page level. Java frameworks use annotations such as `@PreAuthorize` and `@Secured` to enforce this. It is a defence-in-depth control that helps prevent users from reaching sensitive actions through alternative paths.
• Runtime Protection: Runtime protection is a control model that observes application behavior while software is running and blocks unsafe actions as they occur. In Java estates, it helps distinguish active exploit paths from dormant vulnerable code, which is essential when patching is delayed or impossible.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.