Notifications
Clear all
Topic starter
02/08/2026 12:26 pm
TL;DR: Restaurant Brands International’s exposed APIs let attackers create tokens without authentication, escalate privileges, and access drive-thru audio and customer PII, while McDonald’s McHire separately exposed candidate data through insecure APIs, according to Salt. The pattern shows that API discovery, authentication, and runtime blocking now matter as much as perimeter security for identity-adjacent systems.
NHIMG editorial — based on content published by Salt covering exposed APIs at Restaurant Brands International and McHire data exposure: insecure APIs, zero-auth tokens, and live data access
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- Inventory every credential-bearing API Map endpoints that can create sessions, mint tokens, return PII, or trigger privileged actions.
- Disable or restrict GraphQL introspection Turn off introspection in production or limit it to trusted networks and authenticated developers.
- Enforce authenticated token creation Require identity verification and policy evaluation before any endpoint can issue, exchange, or refresh credentials.
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.
👉 Read Salt's analysis of insecure APIs, zero-auth tokens, and drive-thru data exposure →
API exposure and zero-auth tokens: are your controls keeping up?
Explore further
02/08/2026 1:25 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: API exposure and zero-auth tokens are turning drive-thru systems into breach paths
