This week, we dive into detailed reports of vulnerabilities impacting Intel, McDonald’s, and the social media app TeaForHer, each with valuable lessons for API security. We also look at the latest news and rising costs from the Optus 2022 API breach. Finally, we highlight an insightful article offering practical tips for designing APIs for efficient AI agent consumption.
Before we dive in this week, a big thank you to everyone who dropped by the 42Crunch booth at Black Hat USA earlier this month and shared your thoughts on the APISecurity.io newsletter.
Hearing your feedback was very encouraging, especially stories from teams using lessons learned from API breaches to improve your own API development. That is exactly why we do this, and so very gratifying to get that feedback!
Vulnerability: API flaws behind Intel websites
I came across a recent report on eaton-works describing multiple API bugs exposing Intel’s internal websites to breaches and corporate data leaks.
From this case alone I noted at least four OWASP API Top 10 vulnerabilities. But the bigger lesson is one we see repeatedly in API incidents: a dangerous tendency to confuse client-side security with server-side security, and it’s the server-side API teams who are negligent.
APIs should always be built and tested under the assumption that attackers will target them directly. Even if an APIs is intended for use only by your own website or apps, hackers can bypass client-side checks, and ‘curl’ their way to your APIs. That’s why authentication, authorization, and request/response validation must be enforced on the server-side, regardless of what checks or constraints the website or app frontend enforces.
The vulnerabilities I noted in the article include:
- API2:2023 Broken Authentication
- API3:2023 Broken Object Property Level Authorization
- API4:2023 Unrestricted Resource Consumption
- API5:2023 Broken Functional Level Authorization
Did you spot others?
Article: Headaches continue for Optus’ 2022 API breach
Australian telecommunications group Optus is back in the news this month over its 2022 API breach, which exposed the personal information of more than 9 million customers. Three years later, the reputational damage and financial costs are still mounting.
We first covered the breach in 2022, and again in 2024 when a third-party investigation revealed the root cause as a coding error in an unused API. Optus had previously identified the same flaw and patched it on one endpoint, but failed to apply the fix consistently, leaving the exploited API unprotected.
Now, the Australia Information Commissioner, the national data protection agency, is seeking penalties against Optus for negligence in failing to adequately protect customer information.
“All organisations holding personal information need to ensure they have strong data governance and security practices.”
Effective governance in this case means maintaining an accurate API inventory, and crucially bringing every API under proper security and lifecycle management controls, making sure to decommission APIs that are no longer in use.
Vulnerability: API docs expose TeaOnHer users private data
TechCrunch researchers discovered API flaws in the gossip app TeaOnHer that exposed users’ personal information, including photos of driver licenses, without requiring authentication.
The app developer, maybe accidentally, published API documentation that defined both user and admin API endpoints. Crucially, some of the endpoints did not enforce authentication, so anyone on the internet could call the APIs to retrieve user information, including contact details, private comments, or photos of a user’s driver’s license.
Notably, even though this case involved a sole developer, it was the same mistake in API security also at the root of breaches at large organizations like Optus and Intel: failing to enforce authentication. It shows there’s a recurring security gap that cuts across API teams of any size. As a security practice, it is crucial to document which APIs require authentication, and then regularly test or scan them to verify authentication controls are in place and effective.
Article: Tips on designing APIs for AI
One of the emerging requirements for safely integrating AI agents with external tools and services is precision in API design. There are two main drivers for this: security and integration.
On the security side, precise design and constraints in the API implementation helps reduce the risk of AI agents misusing or abusing APIs. For example, enforcing strict access controls and validating agent-supplied inputs against allowed structures, formats, and values, helps establish guardrails that prevent unintended or harmful API behavior, even when AI agents behave unexpectedly.
On the integration side, the clearer and more precise an API is designed and documented, the easier it is for AI agents to automatically discover and use it. This is true for all API consumers, but it is particularly critical when working with probabilistic AI systems, where small ambiguities in design can cause major integration and usage issues.
This Nordic APIs’ article highlights how well-structured error messages play a role in making APIs more usable for AI agents. Standardizing API response codes, message structures, and semantics can go a long way to making APIs AI-ready and improve “agent experience” (you definitely don’t want to upset those agents!).
Great article, and worth a read.
Vulnerability: API bug provides more free McNuggests
API vulnerabilities have been reported in a number of McDonald’s apps and platforms by a security researcher in a detailed blog post.
This is the third API security incident involving McDonald’s covered in 2025. In Issue 276 (July), we reported a vulnerability in McDonald’s recruitment platform that allowed unauthorized API access. Earlier, in Issue 262 (January), similar flaws in McDonald’s online order and delivery system let anyone modify other customers’ orders.
In this latest case, a McDonald’s app rewards users with free McNuggets based on their reward points. The researcher found that the Web app only validated points on the client side. By bypassing the client and sending requests directly to the API, which didn’t enforce the same checks, users could claim free McNuggets without any points.
Other flaws identified include:
- API2:2023 – Broken Authentication: APIs missing authentication allowed attackers to overwrite corporate data.
- API3:2023 Broken Object Property Level Authorization: Arbitrary data could be inserted into food order API requests.
- API4:2023 – Unrestricted Resource Consumption: “New member” coupons, intended for one-time use, could be reused indefinitely via direct API calls.
- API5:2023 – Broken Functional Level Authorization: Regular users could access administrator-level services and sensitive information.
If that list looks familiar, take another look at the Intel API case from earlier. Again, there are clear parallels in the types of API vulnerabilities that occur often across teams and industries.
Notably, while investigating these vulnerabilities, the researcher temporarily modified private resources and recruited a friend, a McDonald’s employee, to test whether a regular crew member could access privileged systems. According to the blog post, the employee was later terminated by McDonald’s. Perhaps stretching the bounds of responsible hacking?
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
