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

At a glance

What this is: This is an independent analysis of how exposed APIs, unauthenticated token creation, and privilege escalation can turn customer and applicant platforms into data exposure paths.

Why it matters: It matters because IAM, PAM, and API governance teams need to treat API endpoints as access surfaces, especially when customer data, worker data, or privileged functions sit behind weak authentication.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
• 64% of valid secrets leaked in 2022 are still valid and exploitable today, proving that detection alone is not enough without automated revocation.
• 28% of secrets incidents now originate outside code repositories, in Slack, Jira, and Confluence, and are 13% more likely to be categorised as critical than code-based leaks.

👉 Read Salt's analysis of insecure APIs, zero-auth tokens, and drive-thru data exposure

Context

APIs are now part of the identity control plane, not just application plumbing. When endpoints can mint tokens, expose schemas, or return customer records without proper authorization, the failure is not only in application security but in how access is discovered, issued, and constrained. For IAM and PAM teams, the key question is whether API access is governed with the same discipline as human and non-human identity.

The article’s examples show a familiar pattern: visibility gaps, weak authentication, and overbroad privilege combine into a fast-moving exposure path. That is typical of modern API abuse, where automation can enumerate endpoints, test token workflows, and move from public access to privileged data retrieval in minutes.

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 APIs create identity risk even when the application code is secure?

A: APIs create identity risk because the code can be clean while the credentials behind it remain exposed, over-privileged, or reused. Attackers usually target the secret, not the endpoint. Once they have a valid key or token, they can impersonate the workload and inherit whatever access that identity already has.

Q: How can security teams tell whether API discovery is actually working?

A: API discovery is working when newly created or changed endpoints appear quickly in the inventory, each has an accountable owner, and sensitive-data handling is visible in the same record. A healthy programme also shows that posture checks, encryption reviews, and access controls are triggered from the inventory rather than applied after incidents or audits.

Q: How should teams respond when API abuse is coming through trusted integrations?

A: They should narrow the trust boundary, reduce standing access, and review what each integration can read or invoke. Trusted does not mean safe when the caller is overprivileged or compromised. The immediate priority is to contain blast radius by tightening scopes, rotating exposed secrets, and segmenting high-risk API paths.

Technical breakdown

How unauthenticated token issuance becomes an access-control failure

When an API endpoint issues tokens without verifying identity, it becomes an authentication bypass rather than a convenience function. In practice, the createToken-style pattern collapses the boundary between account creation, authentication, and authorization. If schema discovery is available, attackers can enumerate mutations, identify the credential-minting path, and abuse it at machine speed. The real risk is not just data exposure but the creation of a valid session that downstream controls treat as legitimate. That makes token service design a governance issue as much as an application flaw.

Practical implication: require authenticated, policy-based approval for any endpoint that can mint or exchange credentials.

Why API discovery and GraphQL introspection matter for secret exposure

API discovery tools and introspection controls exist because undocumented or forgotten endpoints often carry the highest privilege. GraphQL introspection can reveal schema structure, mutation names, and object relationships that attackers use to map high-value actions before exploitation. Once an API is discoverable, it can be tested for open signup, weak authorization, and data-return behaviour. This is especially dangerous when the API fronts identity-linked workflows such as hiring, customer support, or order systems, because the endpoint can become a direct path to PII or operational abuse.

Practical implication: inventory every exposed API and disable introspection or restrict it to trusted development and test contexts.

Runtime protection for API abuse and privilege escalation

Runtime API protection focuses on behaviour, not just known signatures. That matters because attackers often move from sign-up abuse to token farming, then privilege escalation, then data access in one short chain. Rate limiting, anomaly detection, and response blocking help interrupt that progression when the same source creates many accounts, requests unusual fields, or accesses privileged functions in an abnormal sequence. For identity teams, the lesson is that authorization cannot stop at login. Session behaviour, function-level entitlements, and data-return controls all need continuous enforcement.

Practical implication: monitor token generation, privilege changes, and high-risk data access as a single abuse pattern rather than isolated events.

Threat narrative

Attacker objective: The attacker wants to obtain valid access tokens and use them to reach privileged data and live operational systems without being challenged.

1. Entry occurs through exposed API endpoints and open signup paths that allow anonymous interaction with credential-bearing functions.
2. Escalation follows when the attacker uses unauthenticated token creation and weak authorization to move from customer-level access to administrative or privileged actions.
3. Impact occurs when the attacker retrieves customer PII or live audio data, turning API abuse into direct confidentiality and trust failure.

NHI Mgmt Group analysis

API governance is now identity governance by another name. When APIs can mint tokens, expose live schemas, or return sensitive data without strong authorization, they function as unmanaged identity surfaces. IAM programmes that stop at login miss the real enforcement point, which is the API action itself. Organisations should treat API endpoints as access-bearing objects and govern them accordingly.

Secret sprawl is not only a credential problem, it is an access-path problem. Exposed keys, anonymous token functions, and forgotten endpoints each create a different route to the same outcome: illegitimate but valid access. The named concept here is credential minting exposure, where a system that can issue credentials without checking identity becomes a breach multiplier. Teams need to focus on how credentials are created, not just how they are stored.

Runtime controls matter because API abuse is usually faster than human review. Once attackers can automate enumeration, sign-up, token requests, and privilege probing, the control gap becomes temporal as much as technical. Static inventories and periodic reviews are useful, but they do not stop a live abuse sequence. Practitioners should anchor API security in continuous enforcement, especially where customer data or identity-linked workflows are involved.

Identity-adjacent applications need PAM-style thinking even when no human admin is present. A customer-facing API that can escalate privileges or surface sensitive records is effectively a privileged system. That means function-level authorization, strong separation of duties, and tight control over token issuance are not optional. The governance lesson is simple: if an API can change what a user can see or do, it belongs inside the privileged access conversation.

The market is moving toward converged discovery, posture, and runtime enforcement. The article’s control stack points to a broader pattern in security tooling, where visibility alone is insufficient and response must happen in-session. For identity and API governance leaders, the implication is that inventory, policy, and behavioural blocking need to work together. The best answer is not more dashboards, but more enforceable control at the point of request.

What this signals

Credential minting exposure should become a formal risk category in API governance. When systems can create sessions or privileges without strong identity checks, the issue is not just exposure, it is delegation without assurance. Teams should combine API inventory, authentication policy, and behavioural blocking so that access cannot be created faster than it can be governed.

The practical signal for IAM and PAM teams is that API security now depends on request-time enforcement, not periodic review alone. If an endpoint can escalate privileges or surface sensitive data, it belongs in the same control conversation as service accounts, tokens, and other non-human identities. That is where discovery, authorization, and runtime controls converge.

For practitioners, the next step is to treat exposed schemas and token workflows as breach precursors. That means pairing internal control testing with external references such as the OWASP Non-Human Identity Top 10 and the MITRE ATT&CK Enterprise Matrix when modelling abuse chains across APIs and identity-linked services.

For practitioners

• Inventory every credential-bearing API Map endpoints that can create sessions, mint tokens, return PII, or trigger privileged actions. Prioritise undocumented GraphQL and chatbot-backed APIs because they often evade standard asset inventories. Use this inventory to assign owners and review cadence for each access-bearing endpoint.
• Disable or restrict GraphQL introspection Turn off introspection in production or limit it to trusted networks and authenticated developers. Where introspection must remain enabled, require explicit approval and logging so schema disclosure does not become a recon aid for attackers.
• Enforce authenticated token creation Require identity verification and policy evaluation before any endpoint can issue, exchange, or refresh credentials. Separate account creation from token minting so anonymous sign-up cannot become a shortcut to privileged access.
• Apply runtime blocking to abnormal API behaviour Detect mass sign-ups, token farming, unusual query sequences, and privilege probing as one attack chain. Block or step up challenges when the same source combines high-frequency requests with access to privileged fields or sensitive outputs.

Key takeaways

• APIs that can create tokens or elevate privileges are identity surfaces, not just application interfaces.
• Attackers move from exposed endpoints to valid sessions quickly, which makes discovery and runtime blocking critical controls.
• Identity, PAM, and API governance need to converge where customer data, worker data, or privileged actions sit behind APIs.

Key terms

• Credential Minting Exposure: A failure mode where a system issues valid credentials or sessions without adequate identity verification. It matters because the attacker does not need to steal an existing secret if the platform will create one on demand. In practice, this turns an API or workflow into an unauthorised access broker.
• API Coverage: API coverage describes how much of an application’s user, entitlement, and activity data is available through programmable interfaces. In SaaS management, limited API coverage constrains automation and forces teams to use manual or hybrid controls for parts of the application estate.
• API Edge Protection: A security approach that inspects and controls API traffic at the point where it enters the enterprise. It combines authentication, rate control, risk scoring, and behavioural analysis to stop malicious requests before they reach backend services or data stores.

What's in the full article

Salt's full article covers the operational detail this post intentionally leaves for the source:

• How Salt Illuminate maps shadow, zombie, and forgotten APIs before attackers find them.
• How the platform enforces authentication and authorisation for token-issuing endpoints.
• How behavioural analysis flags mass sign-ups, token farming, and suspicious chatbot activity.
• How runtime blocking and rate limiting are applied to stop live API abuse.

👉 Salt's full post covers the attack chain, exposed endpoints, and runtime defence model in more operational detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives practitioners a common language for controlling access surfaces that sit outside traditional human IAM.