Hourly Consulting
Maintenance
Training
Implementation
Microsoft Power Pages
D365 & Power Platform
Websites & Web Applications
Blog
Power Pages Tips
Portals Community Call
Power Pages: How to Avoid Accidentally Exposing Your Data
Nicholas Hayduk
September 30, 2026
4 Min.To Read
Power Pages once again has made the news for the wrong reasons – more confidential data exposed unintentionally. But just like in the past, it wasn’t due to a bug with Power Pages, but instead was due to the misconfiguration of features designed to allow site builders to control exactly who has access to what. In this post, we’ll look at the areas you need to be very careful about when working with Power Pages to ensure you don’t end up on the next list of organizations who have accidentally exposed their data.
Category:
The last time Power Pages was in the news for data leaks was 2024, when a security researcher discovered Power Pages sites that were unintentionally exposing data via the misconfiguration of Web Roles and the Web API. Before that, in 2021, Power Pages was in the news due to a combination of two features of Lists: OData feeds, and the ability to disable the enforcement of Table Permissions (then known as Entity Permissions).
This time, a group known as Exfil Squad has gathered data from multiple organizations, including some government, and threatened to make the data public if their ransom is not paid.
Just like last time, it appears that the data leaks did not occur due to hacking or vulnerabilities in the code. Instead, the data that was gathered was publicly available, if you knew where to look.
Where Are The Bad Guys Looking?
Generally when the bad guys are looking for data, they are looking for large amounts of it. If the headline said “Hackers Steal Data of One Person”, as bad as that is, it’s probably not getting the same coverage as “Hackers Steal Data of One Million People”. So the bad guys are looking at places where large amounts of data might be available.
When it comes to Power Pages, this could be a few places:
- Web API: this is a feature that allows programmatic access to data, including the ability to get a list of all available records for tables that it is enabled for
- Liquid & FetchXML: when used together, these features can be used to create the ability to get a list of all available records, similar to the Web API
- List Download Functionality: if enabled for a List, users can click a button and get a spreadsheet containing all of the data for that List
In the past, there was a fourth option – the List OData functionality, which was the cause of the first leak in 2021. That functionality has since been removed, as the Web API has replaced it.
The bad guys have taken advantage of the first option in the last two sets of data leaks. This is not surprising – the Web API, if not secured correctly, would be the easiest way to gather data. It is easy to use and well documented.
So, if we want to make sure our organization isn’t in the press the next time there is a data leak, we want to focus on those areas to ensure they are not providing more data than we expect.
Why Do Features That Expose Data Even Exist?
These features exist because they make it possible for us to build great things with Power Pages, like web applications with sophisticated interfaces.
We just need to make sure that when these features are enabled that you have appropriate guards in place to prevent accidental data exposure.
A Lethal Combination
A misconfigured Web API alone wouldn’t be enough for a data leak. Even when the Web API is enabled (is it disabled by default, and must be manually enabled to work), there is a second step that is needed to expose data, and that is configuring Table Permissions.
Table Permissions is the security model that control what data is available via the Web API, Lists, Forms, Liquid, and FetchXML. You need to specifically enable access on a per-table basis to your data. Table Permissions need to be created and assigned to Web Roles in order for any data to be available via Power Pages.
The problem that happened in the latest leaks (and in 2024) was that Table Permissions were created and assigned to a special Web Role called Anonymous Users. This means that anyone, even without logging into the site, has access to the data, assuming they have a channel to get to the data, such as the Web API.
So, if you’ve enabled the Web API for a particular table, and create a Table Permission that gives access to that table to anonymous users, now anyone can get your data. This is the lethal combination that results in a data leak.
How to Prevent Exposure
So, if you want to stay out of the news, here are some things to consider on your Power Pages site:
- Is the Web API enabled?
- If so, what tables is it enabled for, and what Table Permissions are enabled for those tables?
- Have you considered alternatives to the Web API that may not offer the same time of exposure?
- Are there other features, such as Liquid & FetchXML or List Download, that are enabled and provides bulk access to data via Power Pages?
- If so, what tables are enabled, and what Table Permissions are enabled for those tables?
- Do you allow Open Registration (allowing anyone to register for your site)?
- If so, you need to treat the Authenticated Users Web Role similar to the Anonymous Web Role, as anyone can easily login
- Do you have any Global scope Table Permissions? Global scope permissions give access to all data in a particular table, as opposed to just a limited set of a particular user’s data.
- If so, understand that this means the user has access to all of the data in the table. We sometimes see Global permissions used when custom security logic is added to the site, but it can be difficult to ensure that custom logic is always applied.
- Is your ALM process capable of deleting permissions in upstream environments?
- Many ALM processes are great at creating new records in upstream environments, but struggle with removing records that have been deleted in development. So if you clean up unneeded permissions in development, make sure those changes make their way to production.
Another thing to watch out for is security through obscurity – thinking that just because data isn’t obviously available, that no one will find it. One of the reasons the Web API is the usual target is that bad guys know where it is. But don’t create your own special way to access the data and leave it open to the public – they may still find it. Always work under the assumption that if data can be accessed, it will be.
Microsoft’s Reaction
One of the features that made this recent leak worse was the ability to specify a wildcard (*) when configuring which columns of a particular table were available via the Web API. Specifying the wildcard character meant all column were available via the Web API. Best practice has always been not to use a wildcard in production, but of course, not everyone followed that advice.
Microsoft has announced that support for the wildcard is ending soon, so if you are using it, hurry up and get rid of it!
