You are a CEO of Rykita, a worldwide manufacturer of power tools used by millions. You wake up invigorated and ready for action only to see the news headlines “Rykita injures more than a thousand customers”, “Calls for Rykita to blunt their tools”, “Rykita customers bleed profusely”, “Users of Rykita tools risk infection if injured”, and “Loyal customer uses Rykita nail gun to shoot themselves in a foot”.

That’s what the reports about Power Apps portals leaking the data looked like this morning. I encourage you to ignore all clickbait headings like “Microsoft Spills 38 Million Sensitive Data Records” and go straight for the original analysis and report by UpGuard By Design: How Default Permissions on Microsoft Power Apps Exposed Millions. While I disagree with some of their assessments, credit is where credit’s due: UpGuard’s behaviour throughout the incident, the analysis, and the report are nothing but professional.

Not all of the affected parties have welcomed the news. Some of the authorities (squinted look in the general direction of state of Indiana) engaged into what I can only classify as a borderline bullying behaviour towards the security company. So what is the kerfuffle all about?

The problem

Power Apps portals have a list feature what is a “data-driven configuration that you use to add a webpage that will render a list of records without the need for a developer to surface the grid in the portal”. To put it simply, lists allow maker to take a Dataverse view and render it on a web page.

Canvas and model-driven Power Apps use Dataverse security roles and privileges to manage users’ access to the tables (see Security concepts in Microsoft Dataverse). Power Apps portals, by definition, provide access for external users (who can be either authenticated or anonymous), and the concepts of security roles and privileges are replaced with web roles and table permissions (see Set up security in portals with table permissions).

One of the important but understated properties of the list has always been the “Enable table permissions”, buried way way down the list form.

That box does exactly what it says: it applies table permissions to the list. Let put it this way: if this box is unchecked then the list will return the data as defined by the view, regardless of who the portal user is. But if this box is checked and no permissions are defined for the underlying table, users will get “Access denied” error, authenticated or not, and that includes administrators as well. Any table permission granted needs to be explicit and associated with one of the user’s web roles. (Make sure you have some additional bedtime reading about securing the lists)

Why it has never been a big deal? Because traditionally lists are used as part of a web page and access to the web page can and usually is secured separately, using page permissions. No page access – no data to leak. Simples!

Why is it now a big deal? As the use of the portals grew, makers discovered new techniques and found new applications for the portal technology. One of the features of the portal lists is ability to publish the table data as OData feed.

Hit the https://foobar.powerappsportals.com/_odata/entitysetname from anywhere and get back json containing the view data. With couple mouse clicks and absolutely no code you get yourself a RESTful web service to be used from client-side javascript, in data integration scenarios, you name it.

And here is the problem. If “Enable table permissions” is not checked, anyone can get to that data feed. And that’s exactly what UpGuard folks have uncovered. But wait a minute! How did they get the list of Power Apps portals? The answer is in this quote:

First we identified the addresses of Power Apps portals. Power Apps portals are assigned a subdomain of the site “powerappsportals.com,” so using common subdomain enumeration techniques generated a list of customer portals.

UpGuard

The key is “common subdomain enumeration techniques”. There are plenty of references on the interwebs for those who are interested, and some of the techniques are indeed extremely clever. In short: it’s possible to find out if not all then most of the subdomains that are in active use. Especially if they start pinging services like Google Analytics and start appearing in the search results. That’s just the nature of the public web.

Microsoft response

The official position is quite straightforward

Our products provide customers flexibility and privacy features to design scalable solutions that meet a wide variety of needs. We take security and privacy seriously, and we encourage our customers to use best practices when configuring products in ways that best meet their privacy needs.

Honestly, I wouldn’t expect anything more than that from a company of Microsoft’s size. On a microscale, from what I know, Microsoft folks are working closely with the affected customers to ensure portal settings are consistent with the customers’ needs. To be fair, it’s a very, very small subset of the customers.

The warning has been plastered all over OData feeds documentation for quite some time:

Customers who had anonymous feeds did received email notifications:

If customer’s security admins were doing their job they would have noticed MC277597 in the Message Center within the Microsoft 365 admin center:

Admittedly some of the actions above seem to be the direct result of UpGuard discovery but the response seems to be well coordinated and targeted.

Power Apps portals Studio, the primary maker experience, have strong settings baked in, and the table permissions are enabled for the lists by default. For the makers still using the Power Apps portal management app (I know I still do every now and then), the latest version will enforce new, more secure defaults where table permissions are checked for new lists.

Even better news is that any new portal provisioned after 15 August 2021 will not allow to disable table permissions when OData feed is enabled:

Note: that means new portals and not just new tables created within an existing portal.

Quick check

Do you have a Power Apps portal and would like to know if you have a problem? Have you provisioned the portal after 15 August 2021? If yes then you do not have the problem. Otherwise use one of these methods:

1. Open https://foobar.powerappsportals.com/_odata in InPrivate mode. Any collection listed there is a potential security leak. See Anonymous access available to OData feed for step-by-step instructions.
2. Run Portal Checker. It will flag anonymous access to forms, lists, and OData feeds in one go.
3. Since portal configuration is stored in Dataverse, Nick Doelman suggested a clever query: find all Lists where Enable Table Permission is not set to Yes.
   

General advice. If you can, avoid using blunt tools like OData feeds. Instead, opt for finesse and precision of hand-crafted liquid to return JSON or XML. The upside is that liquid cannot bypass table permissions so you won’t be able to leak the data, not by accident, anyway.

In closing

Despite the clickbait headlines floating around, we are not talking about data breach but rather data leak that is the direct result of the portal misconfiguration. UpGuard did an excellent job in locating and analyzing the leaks, no doubt about that. They did acknowledged in the article that these leaks are the results of the customer configuration choices, and that tooling and documentation exist to avoid and mitigate such a situation.

In the hindsight, Microsoft should’ve enforced the table permissions long time ago. The enforcement could’ve been done, for example, as the portals moved from microsoftcrmportals.com domain to powerappsportals.com. The new portal version does address the weakness, I just wish it was done earlier, perhaps at the expense of a few broken sites (beats the leak in my books).

It’s important to understand who’s the target audience of the mitigation efforts. Many people discussing the incident, including UpGuard, conflate users and makers. Portal users are not the same as portal makers. While we can’t expect users to even remotely be concerned with OData or table permissions, we hold makers to a much higher standard. They should have known better, low code or not. Documentation and training exist for a reason:

• Get Started with Power Apps portals – Learn | Microsoft Docs
• Administer Power Apps portals – Learn | Microsoft Docs
• Work with Power Apps portals – Learn | Microsoft Docs
• Power Apps – Zero to portals | 365.Training
• Power Apps portals Security Deep Dive | 365.Training
• Building Power Apps portals | 365.Training

Sometimes we have no choice but to sell power tools into the hands of users who are not sufficiently trained. The best we can do in these situations is to make sure the sharp tools are sheathed and some of the more dangerous ones have additional security features like Dead man’s switch.

And if you run a workshop that uses Rykita Power Tools©️ , make sure your employees are up to date with training and certification, read documentation, follow safety instructions, know best practices, and do not toss emails from Rykita Security away. At the same time, keep your first aid kit ready in case someone runs with scissors.