This week, we’re sharing two articles focused on input validation best practices, exploring how weak validation can leave APIs exposed. We also take a closer look at some recent claims about API discovery that risk distracting from real security issues, plus a review of recent API security incidents reported at McDonald’s and Cisco.
Article: How Discovery Hype Is Undermining API Security
An article on API sprawl highlights real risks that emerge when API governance policies aren’t enforced. But a misleading claim about “discovery” really stands out:
“API security is never the problem, it is always the discovery. Once you’ve discovered it, you’ll fix it.”
If only that were true. Unfortunately, decades of experience prove the opposite.
In reality, most API breaches involve known APIs that were simply not properly secured. And the persistent factors driving these failures are a lack of secure development skills and under-resourced security teams.
For instance, OWASP API Security Top 10 issues like BOLA and mass assignment are hard to prevent without secure coding awareness, and hard to detect without dedicated AppSec involvement and targeted testing. These are not “discovery” problems; they are design, development, and validation problems.
To be clear, for teams that have lacked strong API governance in the past, discovery can be a useful recovery tool to bring unmanaged APIs into scope. However, discovery by no means guarantees security, and sweeping statements like “API security is never the problem” risks downplaying the real effort required to secure APIs, and giving teams a false sense of progress.
Vulnerability: Another API BOLA at McDonald’s
Researchers Ian Carroll and Sam Curry published a new report detailing API vulnerabilities in a chatbot-based recruitment platform used by 90% of McDonald’s franchises.
They first gained admin access to a test account via weak credentials (username: 123456, password: 123456). From there, they began probing the platform’s APIs, which returned data on job candidates.
By simply decrementing a candidate ID in API requests, they were able to access real candidate information across McDonald’s franchises. The API relied on predictable IDs (classic IDOR) and failed to enforce authorization, allowing a test account to retrieve production data. Broken Object Level Authorization (BOLA) is number one on the OWASP API Security Top 10 and a common cause of API breaches.
Notably, this isn’t McDonald’s first BOLA exposure. In Issue 262, we covered a McDonald’s API that allowed researchers to modify other customers’ McNugget orders: “Unauthorized API access to McNuggets”.
These recurring BOLA flaws reinforce the need to enforce authorization checks at the object level. Without secure coding practices and robust API authorization testing, the same vulnerabilities will continue to be exploited.
Article: Blocking API Attacks with Input Validation
API vulnerabilities can exist at many layers of the stack, but most vulnerabilities are ultimately exploited through the API request.
For example, common API attacks involve:
- Malicious injection patterns in HTTP headers
Use of invalid or stolen access credentials
Input properties deliberately crafted to break or exploit API logic
An allow-list approach to input validation can significantly reduce this attack surface by restricting inputs to the strict requirements of the underlying service. For example, if an API expects a user-supplied UUID, it should immediately reject anything that isn’t a valid UUID.
A recent NordicAPI’s article highlights this best practice, sharing real-world examples, some of which we’ve also covered in previous issues, demonstrating how input validation can block API attacks to prevent serious breaches and data leaks.
Worth a read.
Breach: Weak Input Validation Exposes Cisco APIs
Multiple critical API vulnerabilities have been discovered in Cisco’s Identity Services Engine (ISE) that are now actively under attack. These API flaws stem from insufficient input validation, allowing unauthenticated attackers to upload and execute arbitrary files or code as the root user.
Cisco’s advisory suggests that at least one of the API flaws exposes a path traversal vulnerability:
“This vulnerability is due to a lack of file validation checks that would prevent uploaded files from being placed in privileged directories on an affected system.”
Path traversal allows an attacker to force an API to place files in unintended and potentially sensitive locations on the server. For example, an attacker could exploit a vulnerable endpoint using a URL like:
http://some_site.com.br/get-files?file=../../../../some dir/some file
The Cisco ISE platform is used to manage access control for enterprise networks, meaning these API vulnerabilities pose a serious risk to the security and integrity of business-critical resources, and highlights again the importance of robust input validation and secure coding practices when designing and deploying APIs.
Article: Tightening the first line of defense
In a post on the Hackernoon website, a developer shares his experiences from working on legacy NestJS projects and the risks exposed through poor data validation in the code.
Any validation is better than no validation, but loose validation can still expose software to a range of different attack vectors such as SQL injection and path traversal attacks, not to mention subtle business logic attacks that are more difficult to discern through content inspection.
The writer shares an example of the classic “isString()” validation check, which, while useful, still leaves hackers with plenty of room to test and probe software for vulnerabilities.
This underscores the need for solid input validation, not just checking types, but enforcing additional constraints like length, format, patterns, and value ranges. For APIs the OpenAPI format provides a standard way to define data constraints up front in an API contract,
The contract then acts as a blueprint: developers use it to build proper validation into the API, and security teams use it to test whether those validations are actually enforced. It’s a simple way to catch invalid input and keep APIs tight, predictable, and secure.
Industry Event: Black Hat USA
Next month, all cybersecurity roads lead to the Black Hat USA event in Las Vegas. If you are attending the event this year, be sure to visit the 42Crunch booth (#1967) where our team will be on hand to answer all your API security-related questions. If you would like to book some time with the 42Crunch team, simply reserve a slot here.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
