The big news this week is the data breach at the Microsoft Power Apps platform, leading to the disclosure of up to 38 million records with Personally Identifiable Information (PII). The details range from names and email addresses to COVID-19 vaccination status, and even Social Security numbers. The breach was discovered by researchers at UpGuard, who detail the underlying issue, the entities impacted, and the response from Microsoft in their recent blog.

Researchers discovered that an OData API that Power Apps used for accessing data publicly exposed sensitive user data which should have been private. The access to data is controlled with the setting called table permissions, which can be set to restrict access to sensitive records. Unfortunately, Microsoft had opted to switch off table permissions by default, meaning that they were publicly accessible unless users realized to switch it on. Microsoft did warn users on the impact of leaving this setting off, but as the breach shows, this might not have been the best call:

Article1_OData

Upon their discovery, UpGuard notified Microsoft about the issue. The initial response was that this public accessibility was by design, not a vulnerability. Not the first time we see this excuse with reported API vulnerabilities, often dressed up in the guise of “improved user experience”.

UpGuard then proceeded to notify the impacted entities, many of whom took swift action to remove the leaked PII data. To add insult to injury, many core Microsoft portals were also affected, and subsequently Microsoft appears to have notified impacted government cloud customers of the issue.

Since the disclosure of the breach, Microsoft has changed their stance here:

They have changed the default setting so that new lists enforce table permissions to protect underlying data.
They have provided a dedicated tool, Portal Checker, for finding OData lists that allow anonymous access.

The lessons learned here include:

This is a classic example of Broken Authentication on an API — the impact of having unauthenticated APIs can lead to unintended data disclosure. You could also argue that this falls under API7:2019 — Security misconfiguration, too.
As a developer, always ensure you understand the full impact of your chosen default settings and permissions.
As a platform designer providing API service, always ensure strict access restriction (deny-by-default, least privilege…). Allowing full anonymous access to data or other resources is not a sensible default, regardless of any warnings that you glue on top.
Subscribe to API Articles