Microsoft Power Apps Portals Default Public Table Exposure

Microsoft Power Apps Portals exposed tables to the public by default, showing how a setting used for an integration can leak data when the access controls are elsewhere. Microsoft closed the original OData gap in 2021, including on existing portals, but later exposures reveal the larger problem. Safe defaults help, but owners must keep public data access secure for as long as a portal is in use.

How Power Apps Portals expose Dataverse tables through OData feeds

Power Apps Portals, now Power Pages, can expose Dataverse records through OData APIs attached to lists. A list is the portal configuration used to display table data. In the original configuration, restricting access required the developer to enable Table Permissions on that list. That was a separate, opt-in step. The distinction mattered because a working integration and a restricted integration were different outcomes.

A developer opened the list configuration dialog and enabled OData on the “OData Feed” tab to support an integration. The Table Permissions toggle lived on the “General” tab and defaulted to disabled. If the developer left it there, enabling OData made the list publicly accessible. No single control said “make this public,” and no warning linked the two settings.

The newer Power Pages Web API offers another way to expose the same data. Its endpoint, /_api/<EntitySetName>, exposes table data according to the permissions assigned to web roles. Granting Read at Global scope to the Anonymous Users web role makes the full table publicly readable through that endpoint. This route remains relevant after the deprecation of OData feeds. The access comes from a permission grant rather than from the original disabled-permissions default.

Why the split-control design turned a feature into a recurring structural trap

The original design made the unsafe state the path of least resistance. Every new list began with Table Permissions disabled, so a deliberate act to enable an integration could activate exposure through an unrelated omission. The developer had asked for connectivity. Yet the interface treated the missing restriction as permission to publish. Two tabs had quietly become one security decision.

Anonymous access is needed for content meant for the public. The design critique is therefore not that portals should prohibit it, but that public access should require an explicit assignment to the Anonymous Users role. That would make the insecure state a deliberate choice rather than the consequence of leaving a default untouched. Low-code tools sharpen this concern because their audience includes “citizen developers” without specialist security knowledge. A technical footnote is a thin guardrail for that audience.

Microsoft’s documentation states that access to Dataverse records is automatically restricted through forms, lists, Liquid, the Portals Web API, and other components, with access opened through table permissions. Microsoft framed the issue as misconfiguration. UpGuard agreed that it was not strictly a software vulnerability but argued that a platform issue requiring code changes belonged in the same workstream as vulnerabilities. That tension matters because the label influences who is expected to prevent recurrence. UpGuard also documented governmental bodies that had conducted security reviews without finding the exposure, showing that ordinary review processes did not reliably settle the question.

The 2021 mass exposure: what widespread record exposure across 47 organizations revealed

The affected organizations included government agencies, airlines, and Microsoft itself. That range made the incident more than a warning about one badly configured application. The same configuration pattern had reached organizations with different purposes and different kinds of sensitive data.

The NYC MTA’s “EmployeeEsa” list contained tens of thousands of records with full names, dates of birth, email addresses, phone numbers, union membership, and work locations. A separate “VaccinatedEmployees” list exposed additional records. Microsoft’s own Global Payroll Services Portal exposed hundreds of thousands of records, including full names, personal phone numbers, email addresses, and employee IDs. These were not merely public pages with more generous visibility than intended. They were routes into detailed records about people.

The “msemr_appointmentemrset” pattern illustrated the significance of common structures across deployments from the Power Apps catalog. When organizations reuse a schema or template, they can inherit its unsafe defaults as readily as its useful functions. With so many records exposed, Microsoft’s response raised a practical question: would changing the default also close the exposure on existing portals?

What Microsoft's 2021 default change fixed and what it left open

Microsoft’s version 9.3.7.x changed the original OData behavior in a meaningful way. Table permissions became enabled by default for new portals. Crucially, Microsoft’s documentation says that lists on all websites, new or existing, with OData feeds enabled required appropriate table permissions for those feeds to continue working. Describing this as a fix only for new portals would understate what Microsoft changed.

That distinction separates a surviving deployment from a surviving vulnerability path. Existing portals still needed attention to their permission settings, but they were not simply exempt from the OData enforcement change. Microsoft also released a self-diagnostic tool to help owners identify misconfigurations. Those measures addressed a concrete product behavior. They did not amount to a review of every role assignment or every route into Dataverse.

In particular, the OData fix did not block excessive Anonymous Users permissions through the newer Web API. It also left open a separate risk from open registration, where a visitor can gain the Authenticated Users role and get more access than they should have. These are permission risks even when enforcement is switched on. Microsoft’s built-in security scan also remained a point-in-time tool. The fix closed an important door, but it was not a census of every entrance.

Why the exposure keeps resurfacing: detection gaps that outlast the original fix

A vulnerability scanner looks for a different kind of problem from an excessive permission grant. No CVE is assigned to a permission an organization intentionally configured. A portal can run current software, respond exactly as configured, and still return sensitive records to the public. In that case, the configuration is the finding. A clean vulnerability scan does not answer whether the application should have served the data.

A review scoped to identity, endpoint, mail flow, and data loss prevention can miss portal permissions held in Power Platform configuration. The controls under review and those that expose data are in different configuration layers. Confidence in one layer does not establish safety in the other.

Application lifecycles make the gap harder to see. A permission added to make a form work during development can survive into production, while a Web API setting can remain enabled after its dependent component has gone. A public site can also outlive its original owner and stop being treated as an active application. Even then, an old portal may still connect to a live Dataverse environment. Because a point-in-time scan cannot report changes made afterward, these conditions can persist until someone returns to the portal’s actual permission state.

The 2024 NHS exposure and the 2026 ExfilSquad campaign show the problem is still active

AppOmni identified insecure Power Pages permissions at a large shared business service provider for England’s National Health Service in September 2024. The exposure affected information about over 1.1 million NHS employees, including email addresses, phone numbers, and home addresses. AppOmni also had permission to test other organizations and government bodies, where it found several million sensitive records. This was three years after the OData change. The case showed the importance of the Web API path and permission lifecycle rather than a return of the original disabled-permissions default.

The 2026 ExfilSquad campaign added evidence of criminal exploitation, although its claims require care. On July 26, 2026, the previously unknown data extortion group posted a leak-site update on an anonymity network naming private companies, municipalities, school systems, and government bodies across multiple countries. The group stole data and threatened to publish it unless victims paid a ransom. Fortra researchers corroborated breach claims, and the leaked material appeared related to misconfigured Power Pages portals allowing unauthorized public read access to Dataverse. That evidence backed the proposed route but did not prove every claim the group made.

ExfilSquad also named Microsoft as a victim and posted a screenshot recognizable to Dataverse practitioners. At the sources’ publication date, however, no proof of actual data theft from Microsoft had been established. FINRA’s August 25, 2026, cybersecurity alert identified an ongoing ExfilSquad campaign affecting multiple sectors, including financial services, and noted many potentially vulnerable public-facing instances. The California Department of Financial Protection and Innovation issued its own alert on September 8, 2026.

What a complete remediation actually requires across new and legacy portals

Complete remediation requires four connected tracks, namely new portal defaults, legacy portal audits, Web API permissions, and registration access. For portals created after version 9.3.7.x, the first task is to configure which web roles receive which access. Table permissions being enabled does not mean those permissions are correctly scoped.

Next, audit legacy portals, including those that are no longer being developed. Review every list with OData enabled and the tables made accessible through enabled Web API settings. Check that Table Permissions are enabled and scoped to appropriate roles. The Anonymous Users web role should not have Read at Global scope on any table containing personal data. A dormant portal belongs in this audit because its Dataverse connection can remain live even after development stops.

Then review the Web API surface separately. For every table accessible through /_api/<EntitySetName>, confirm that Anonymous Users has no Global Read permission where sensitive records are present. After that, examine self-registration wherever it is allowed. Check the permissions that come with the Authenticated Users role so that signing up does not also give users access to sensitive Dataverse tables. Correct anonymous permissions alone cannot close an over-permissioned authenticated route.

Finally, keep these reviews connected to changes in the portal. Microsoft’s built-in scan is a useful place to start, but someone must run it again to see permissions that change later. Portal permissions need to be monitored continuously to catch drift. Runtime visibility tools address that gap when they can detect configuration changes that open data access. Their role is to maintain visibility across all four tracks, each of which remains necessary.

The governance lesson that extends beyond Power Pages

Low-code platforms put data-publishing capabilities within reach of people who are not security specialists, which is useful and also moves security decisions into places that established review processes may not cover. When the integration switch and the restriction switch are separated, their interaction becomes an organizational responsibility as well as a design concern. If restriction also defaults to off, ordinary omissions can become repeated exposures. Platform design distributes authority through the arrangement of controls.

Cloud hosting does not remove that responsibility. Organizations may scrutinize a custom-built application more closely because a hosted platform appears to arrive with security already settled. Vendor improvements can reduce risk without settling every application-specific access decision. The 2026 FINRA and DFPI alerts also signal that platform misconfiguration is becoming an organizational accountability issue in regulated sectors. A vendor’s corrected default is not a substitute for knowing what an organization’s live configuration permits.

The practical response is to treat platform permissions as part of the continuous security surface. Reviews must cover the configuration layer that decides who can read the data, and runtime detection must catch permission drift between reviews. This extends the meaning of application ownership beyond keeping software current or confirming that authentication works.