This week: we share a report about OneLogin suffering an API data leak, we also have Cloudflare’s postmortem on an accidental API DoS. We look at researcher Dirk-jan Mollema’s disclosure of a critical Entra ID vulnerability, also incidents of mass assignment and excessive data exposure in Rancher and Apache Airflow APIs, and finally Nokia platforms hit by authentication bypass via malicious API headers.
Vulnerability: Secrets Leaked by OneLogin API
Researchers at Clutch Security disclosed an incident involving excessive data exposure in OneLogin’s Identity and Access Management (IAM) platform.
The vulnerable API endpoint is designed to list all OpenID Connect applications configured in a OneLogin tenant, and is accessible to any user with valid API credentials. But the researchers found that the response also included the client_secret property in plaintext for every application. This secret functions like a password for authenticating authorized clients, making its exposure highly sensitive.
Image from Clutch Security report
Unfortunately, sensitive credentials leaked in API responses is a common enough problem. In APISecurity.io issue 240, for example, a social networking platform’s leaky API exposed passwords, two-factor authentication tokens, and other confidential data.
Multiple factors can lead to these types of leaks: unsanctioned code changes, misconfigurations, or malicious data injected from upstream third-party APIs, or, increasingly, AI agents and LLMs.
One effective mitigation is using runtime schema validation on your most critical or sensitive APIs, which constrains response data to only the expected and authorized properties, preventing sensitive information from being inadvertently exposed. Read the report
Failure: Cloudflare Outage Caused by API Overload
The term denial of service (DoS) often crops up in news of malicious cyberattacks, but it can also happen by accident. A software bug in Cloudflare’s dashboard frontend code caused it to repeatedly call Cloudflare’s Tenant Services API, quickly overwhelming the service. Javascript developers will be familiar with the risk of unintentional loops from misusing React hooks, which appears to be what happened in this case.
Image from Cloudflare Blog Report
Cloudflare’s postmortem describes how the API outage rippled across their systems, disrupting other services including a critical API authorization function. One of the biggest challenges in managing cascading failures is diagnosing the root cause while simultaneously working to restore availability. In this case, the team set a global rate limit to help regulate the API traffic.
Global rate limiting can help shield infrastructure during a DoS event, whether accidental or malicious, but that can be a blunt instrument. Enforcing limits at the API level, especially for high-value services, can help to reduce the risk of failures spreading to dependent systems, and pinpoint the cause of an outage when similar mistakes, or attacks, occur. Read the report.
Vulnerability: Entra ID Tenants Exposed by Global API Token
Researcher Dirk-jan Mollema recently disclosed a critical access control flaw in Microsoft’s Entra ID that could allow a malicious user to take over other Entra ID tenants worldwide.
Entra ID (formerly Azure Active Directory) is widely used by organizations to manage user accounts and access control policies. Ironically, this case involved an access control platform with a significant access control vulnerability. Exploiting it could give attackers unrestricted access to all downstream services and applications that rely on Entra ID for authentication and authorization.
The root cause stems from use of a global access token called Actor Tokens and a legacy API that failed to enforce proper tenant-level authorization. This flaw allowed a token issued in one tenant to be used to access any other Entra ID tenant, granting full access to the Azure AD Graph API.
Authorization flaws continue to be one of the most common API vulnerabilities, though we don’t often see cases with the potential for such broad and high-impact consequences. This one is worth a full read. Read the report.
Vulnerability: Mass Assignment Flaw in Rancher API
SUSE Rancher is “an open source container management platform built for organizations that deploy containers in production”. One of the platform’s APIs allows update operations on user accounts via PUT requests.
A flaw in this API lets a privileged user modify another user’s username, potentially preventing that user from logging in; effectively causing a denial of service. The risk is particularly severe if the affected account belongs to an administrator.
Image from CyberSecurityNews article
At first glance, this appeared to be an OWASP Broken Function Level Authorization issue, as it seemed the API shouldn’t allow PUT operations on this resource. On further reading though it’s more accurately classified as an OWASP Broken Object Property Level Authorization vulnerability (formerly known as Mass Assignment). The PUT operation should be allowed for privileged users, but the API should restrict updates to the username property once set.
Hackers use mass assignment to exploit hidden features or logic flaws in API code, which can be harder for some security tools to detect than other input-based API attacks like SQL injection or path traversal. OWASP recommends whitelisting allowed API properties and enforcing strict schema validation to prevent these vulnerabilities from being exploited. Read the article.
Vulnerability: Data Exposure from Apache Airflow API
If Mass Assignment is one side of OWASP’s Broken Object Property Level Authorization (BOPLA), then Excessive Data Exposure is the other. Both deal with APIs’ data properties: Mass Assignment concerns unauthorized use of request properties, while Excessive Data Exposure involves unauthorized access to response properties.
A vulnerability recently found in Apache Airflow highlights the latter. A software update unintentionally reversed existing authorization controls, exposing sensitive information in API responses. Users with only Read permissions could suddenly view secrets such as passwords and tokens that should have been hidden.
Just as OWASP advises whitelisting request properties to prevent Mass Assignment (see the previous article), the same security recommendation applies to API responses: enforce strict response schemas so that only authorized properties are returned.
Organizations can also apply API drift testing to detect when a production API’s behavior deviates from expectations, whether due to code regressions, misconfigurations, or overlooked security changes. Read the article.
Vulnerability: Nokia Auth Bypass via Malicious API Header
An API vulnerability in two Nokia networking platforms, Nokia CBIS and Nokia Container Services, allows any user to bypass authentication and gain unauthorized access to management API services.
A recent Cyberpress article describes details of the vulnerability, caused by a logic error in the API’s authentication code and the way user-supplied HTTP headers are handled.
During the authentication sequence, custom headers in the API request are parsed. Depending on their value, the flawed logic can route requests around the authentication check, giving unauthenticated users access to privileged management services on either platform.
“Exploitation requires sending HTTP requests with a header, for example X-Auth-Bypass: <token>, to management API endpoints.”
Nokia resolved the vulnerability by enforcing strict header validation and mandating mutual TLS for management API calls. These security controls, properly implemented, can significantly reduce the opportunity for attackers to exploit and breach APIs. Read the article.
Get API Security news directly in your Inbox.
By clicking Subscribe you agree to our Data Policy
