For the second time in a few years, Power Pages is making the news for all the wrong reasons. In mid-November 2024, Aaron Costello of security firm AppOmni published an article describing what he called “a significant data exposure issue within Microsoft Power Pages”. Let’s look at what he discovered.
But first, let’s go back to August of 2021, where Power Pages (then known as Power Apps Portals) was again making the news. The headline on CNN.com read: “Data leak exposes tens of millions of private records from corporations and government agencies”. This time it was security firm UpGuard who first reported the problem.
Microsoft scrambled to plug the leak. But the problem wasn’t that there was a bug with the system. Power Pages was behaving exactly as designed and documented. The problem was is the product made it a little too easy for someone to expose data without intending to.
There were two main contributing factors to this first leak. This leak was related to the List (previously known as Entity Lists) functionality of Power Pages. This lets you expose business data from Dataverse (a core database technology within Microsoft’s Power Platform) to users of your site. Primarily used to display tables of data to users within a web browser, the List functionality also included a feature that allowed you to expose that data in a more computer-friendly format, known as Odata. All you needed to do was check one box, and boom, the data from the list was available via this other format.
That alone wouldn’t have been so bad. But if the person building the site also happened to uncheck another checkbox, that’s where the trouble started. When unchecked, this other checkbox allowed you to disable permission enforcement for the list, meaning that anyone who looked at the list, or that special computer-friendly format, could see all the data, not just what the permissions were setup to allow them to see.
Again, both of these checkboxes worked exactly as designed and documented. The argument, however, was that it was much too easy for someone to accidentally enable the computer-friendly format and disable the permissions. So, in addition to lots of communication and in-product messaging about the potential problem, Microsoft made some changes to Power Pages, the main one being removing the functionality that allowed you to disable permissions for a list. Now, if you wanted people to see all the data, you had to explicitly give them permission. Eventually, Microsoft also ended up deprecating the functionality to display the data in the computer-friendly format, as other newer functionality was available to handle those types of needs.
In the end, the product got better – better security by default, and more messaging in case someone accidentally set it up in a way that was likely not what they intended.
Fast forward three years, and history is repeating itself again. AppOmni’s report of a data leak with Power Pages has been picked up by various online publications:
The problem is almost the same. Remember how I said that Microsoft deprecated the OData computer-friendly format because newer functionality was available? That newer functionality is the Power Pages Web API, and that is exactly where this new leak is occurring.
There is one big difference though. With the first leak, all it took was for two checkboxes to be set in order to have problem. In this newer case, as Mr. Costello points out in his “Technical proof of concept” section, in order to have a leak, you need to configure multiple Site Settings, as well as table permissions. This is a much higher bar to reach in order to have problems. Unfortunately, Mr. Costello’s research has indicated the bar still wasn’t high enough for many organizations.
Another similarity between the leaks was that there was no bug in the Power Pages code. It was acting exactly as documented and designed. So why are we even calling this a leak if nothing was broken? In my opinion, this is because of how this product is marketed.
Power Pages is marketed as a low-code/no-code development tool. Often the term “citizen developer” is used as the target audience for these tools. Citizen developers are people who aren’t formally trained in developing software, and are often tech-inclined business super users that are empowered by the low-code/no-code tools to build solutions for their organizations.
While I’m a fan of removing unnecessary barriers preventing people from contributing to building business-critical software solutions, these data leaks highlight the importance of having people who know what they are doing. Does this mean they need an advanced degree and 20 years of experience? Absolutely not. But it does mean that they should be familiar with concepts like security, and that they are offered proper training on the platforms they are using. Of course.
Often I see the option of low-code/no-code being compared to pro code development. But that’s not our problem here. The problem is that we are dealing with amateurs versus professionals. You can be a professional while using low-code and no-code platforms. And I’ve definitely seen amateurs in the pro-code world. But I do think its easier for amateurs to get further with low-code/no-code platforms without others realizing they are amateurs.
Let’s keep in mind what it took to accomplish this latest leak. First, you needed to configure the Web API for a particular table (which is turned off by default). Then, you need enable table permissions for that table for the Anonymous Web Role. Both of these steps require many clicks and/or keyboard input (unlike the first leak, which could happen with two wrong clicks). I have a hard time believing that anyone would do it accidentally. Certainly someone may not have realized the implication of their actions, but it still requires that someone go in and perform these actions.
So to me, the lesson here is whether you are using a low-code/no-code platform, or pro code, you need to be on the watch out for amateurs. They’ll hurt you regardless of what technology you are using. But I think the likelihood of having an amateur on the project is probably higher when using technology often targeted at people without a formal background in technology.
And, to be clear, when I talk about amateurs versus professionals, I’m not just talking about people. I’m also talking about processes and organizations. Someone with a formal education in computer science might be an amateur when it comes to low-code/no-code solutions, especially if their organization and its processes are not experienced with the platform, and don’t take the responsibilities associated with developing software, using code or not, seriously.
Leave a Reply