Skip to main content

38 million records exposed, Microsoft Power Apps blamed

Microsoft logo at Ignite
Microsoft logo at Ignite (Image credit: Windows Central)

What you need to know

  • The default settings of Microsoft's Power Apps were blamed for 38 million records being exposed.
  • Leaked data includes Social Security numbers, COVID-19 vaccination statuses, and other pieces of sensitive information.
  • Microsoft has since changed its default settings for Power Apps.

Thousands of web apps left sensitive data exposed online due to misconfigured settings for Microsoft Power Apps. Thirty-eight million records appeared online, including social security numbers, COVID-19 vaccination statuses, home addresses, and phone numbers. American Airlines, J.B. Hunt, Microsoft, and several government bodies are among the affected organizations. UpGuard notified 47 entities regarding the data exposure and reached out to Microsoft about it as well (via WIRED).

The data leaks came as a result of organizations using Microsoft's Power Apps. These can be used to create websites and to manage data, but if misconfigured can result in security risks. Power Apps can be used to manage data that organizations would like to have public, such as the locations of vaccination centers, as well as data that should remain private, such as Social Security numbers. The default settings for Power Apps left data publicly accessible until a recent change from Microsoft.

While Microsoft's service listed the implications of these settings, they were not made clear, according to UpGuard:

The number of accounts exposing sensitive information, however, indicates that the risk of this feature– the likelihood and impact of its misconfiguration– has not been adequately appreciated. On one hand, the product documentation accurately describes what happens if an app is configured in this way. On the other hand, empirical evidence suggests a warning in the technical documentation is not sufficient to avoid the serious consequences of misconfiguring OData list feeds for Power Apps portals.

Source: Upguard (Image credit: Source: Upguard)

Microsoft has since enabled table permissions by default (opens in new tab). The company has also provided a tool (opens in new tab) to help Power Apps users diagnose the security of their portals.

Upguard summarizes its thoughts and findings, which spreads blame across multiple parties:

While we understand (and agree with) Microsoft's position that the issue here is not strictly a software vulnerability, it is a platform issue that requires code changes to the product, and thus should go in the same workstream as vulnerabilities. It is a better resolution to change the product in response to observed user behaviors than to label systemic loss of data confidentiality an end user misconfiguration, allowing the problem to persist and exposing end users to the cybersecurity risk of a data breach.

Upguard also states that "Microsoft has done the best thing they can" by switching to enable table permissions by default and providing a diagnostic tool for users.

Sean Endicott
News Writer and apps editor

Sean Endicott brings nearly a decade of experience covering Microsoft and Windows news to Windows Central. He joined our team in 2017 as an app reviewer and now heads up our day-to-day news coverage. If you have a news tip or an app to review, hit him up at (opens in new tab).

  • This is on Microsoft. You are trying to make coding easy (low/no code). If you are going to do that, you need to build in security.
  • Sort of -- It's probably better that they've changed the default, but if anyone is building their own apps, that developer clearly bears primary responsibility. I agree with your point that this is a little different from Visual Studio and that it doesn't require as much training to use as, say, C++. On the other hand, building with Power Apps is also not like creating Excel macros in VBA, where you expect the security to be provided by Excel. This is real development. Having recently been hiring Power Apps developers and reviewing their salary expectations (they're quite in demand), I can state that with confidence. If this happened at our organization, I would attribute the problem, at least primarily, to the developer, not to MS.
  • This is a multifaceted and a very nuanced issue as by reducing the complexity of app development - the “barrier of entry” is lowered. The low barrier of entry is an advantage if the app is coded / configured properly. When it's not, it's a negative as the coder needs to have the prequiste knowledge of potential ramifications of misconfiguration. Additionally, Microsoft should have a automated quality assurance check at each stage of the power app configurator and creation. Also, a automatic dialogue box where the user selects their skill level prior to the creation of any power app - higher the skill level == the reduced number of configuration / test prompts. By adding these two elements Microsoft would have absolved themselves of any liabilities. But as it stands, they are also partially liable for the consequences. The rest of the liabilities (this is why companies need to have employers' liability, public liability, product liability and contract work liability insurance - government departments are still liable too - they are not exempt) does indeed fall on the companies whose employees didn't take the relevant steps to configure the Power Apps properly. As it ultimately falls down to poor Internal department Quality Compliance checking, poor Skill Vetting by HR and inadequate training. Unfortunately, all three are prevalent in every industry and sector.
  • "[Don't] label systemic loss of data confidentiality an end user misconfiguration" Basically people failed to configure correctly.
  • Ya, my take was that people misconfigured the setting but that Microsoft could have done a better job making things clear. The fact that Microsoft changed the default setting for table permissions suggests that the company agrees it could have made it clearer.