Power Platform Worst Case – Day 1: Data Leakage - The Phantom of the Environment

Power Platform Worst Case – Day 1: Data Leakage - The Phantom of the Environment

Low-code and citizen-development platforms such as the Microsoft Power Platform promise rapid innovation, agility, and business empowerment. But with that freedom comes risk: on Day 1 of a worst-case scenario we explore the spectre of data leakage — what I call the Phantom of the Environment. In this article we’ll walk through how a seemingly innocuous environment mis-configuration can lead to massive data exposure: the players, the mis-steps, the hidden vulnerabilities, the real-world evidence, and most importantly how you defend against it.

The Setting: Environments, Portals & Citizen Apps

Imagine an environment within Power Platform — one of those sandboxes or production spaces where business users spin up apps, portals, flows, data tables. Because it’s low-code, it’s fast. Because it’s business-led, it’s often outside strict IT change-control. Within that environment you might have a portal exposed to external users (customers, citizens) built on Power Apps Portals, connected to the Microsoft Dataverse database (formerly Common Data Service). Data flows in from forms, automation, connectors. Now imagine default settings, shortcuts, integrations: enabling OData feeds, lists, APIs — all meant to support data display or integration. But what if the default is too open? What if permissions are lax because the stake-holders believe “it’s just an internal portal” or “it will only be used by authenticated users”? In this setting lies the phantom: an environment that appears benign, yet behind the scenes the access boundaries are absent, the data can creep out.

The Mis-Configuration & How it Happens

Here is the anatomy of how the leakage often occurs:

Default permissions and unchecked lists

In one notable case researchers discovered that newly-created lists within Power Apps Portals were by default created with table permissions disabled. That meant unless someone proactively flipped the “Enable Table Permissions” flag, the data was effectively public. When coupled with an OData feed enabled, the list data became reachable by anonymous internet users: e.g. https://myportal.powerappsportals.com/_odata/<list> would expose the contents.

OData feeds and anonymous exposure

The OData endpoint is powerful – it’s designed for integrations, for data retrieval. But it becomes a liability when mixed with public-list permissions. One researcher put it succinctly: “the list’s data is now exposed publicly through an API to the entire Internet.” In many environments, the business user enabled OData without realizing the implication. The app looked “just a form funneling to data”, but behind it lay the API.

External facing portal, internal data

Often, the portal is exposed to external users (customers, citizens). The business model demands external access. But the data model mixes internal-only sensitive attributes (PII, IDs, sensitive metadata). In the reported case, portals for vaccination appointment sign-ups, job applications, etc. were leaking names, email addresses, Social Security Numbers. Because the environment is treated as “business friendly” rather than “lockdown IT system”, mistaken assumptions propagate: “It’s only a portal, not core system”, “we’ll fix later”, “who would query this list anonymously anyway?”

Phantom environment – invisible until audit

Critically, the environment looks normal: apps work, users sign in and out, forms operate. There is no obvious “red blinking light” to say “data is leaking”. The phantom lurks quietly: default permissions, API endpoints publicly exposed. As the researchers noted: multiple governmental bodies reviewed their apps and didn’t catch the exposure because “it has never been adequately publicised as a data security concern before.” Thus the “phantom of the environment”.

Real-World Evidence: 38 Million Records & Counting

This scenario isn’t theoretical. On 24 June 2021 researchers at UpGuard Research discovered that more than 38 million records from 47 different portals built on Power Apps Portals were exposed online. The data spanned names, email addresses, phone numbers, employee IDs, vaccination appointment data, Social Security Numbers. Affected organisations included major private enterprises (e.g., American Airlines, Ford Motor Company), and public bodies (e.g., states of Indiana, Maryland, New York City). The root cause was confirmed: lists with OData enabled and table permissions disabled (or mis-set) were being harvested. The default configuration allowed it. Following disclosure, Microsoft changed the behaviour: table permissions are enabled by default for new portals, and older ones must be reviewed. This starkly demonstrates how quick a low-code, agile environment can become a major data-leak vector.

Why This Matters: Business, Compliance & Operational Risks

Business reputational and financial risk

When sensitive data is exposed, an organisation faces reputational damage, loss of customer trust, regulatory fines, legal exposure. Even if the breach wasn’t caused by malicious hacker action but by mis-configuration, the damage is real. In the Power Platform case, major brands and government entities were implicated. It illustrates that low-code doesn’t mean low risk.

Compliance & data-protection obligations

With data protection laws (such as GDPR in Europe) and regulatory regimes, exposure of personal data triggers obligations: disclosure, mitigation, potential fines. A portal leaking citizen data is a compliance nightmare. Because the platform makes it easy to deploy, it can bypass hardened IT change controls — which means standard governance may not apply.

Shadow-IT & uncontrolled environments

Many organisations view platforms like Power Platform as business-friendly, bypassing traditional IT. That means environments may be spun up without full oversight, governance, auditing. The phantom lives in these shadow-IT corners. Because citizen developers may not have deep security awareness, default safe-guards get overlooked.

Operational resilience and hidden access

Data leakage may not be obvious until after the fact. Attackers (or auditors, researchers) may find public endpoints, data dumps, API responses. That means the operational risk is hidden. The “environment” may look fine (apps working, users logged in), yet external exposure exists quietly. That phantom environment undermines resilience.

Defence Strategy: How to Exorcise the Phantom

To guard against “Day 1 – Data Leakage” in low-code environments, the following strategy is essential:

Inventory and mapping of environments

Identify all environments in Power Platform (production, sandbox, dev, test). Ensure you have a catalog of portals, lists, OData feeds, connectors. For each environment assess: external facing? Public portal? External users? What data does it connect to (Dataverse tables)? Who has access?

Permission-by-default and least privilege

Ensure that for any list or table exposed via portal or API, table permissions are enabled. Confirm that OData feeds are not anonymously accessible unless explicitly required and reviewed. Review default settings: if the platform sets default to “permissions disabled”, treat that as a red flag. In the Power Apps example, it was the default. Enable monitoring of configuration changes, so that if someone turns off table permissions, you are alerted.

Auditing, access logging & anomaly detection

Enable logging for portal and API access (who accessed what list at what time). Run analytics on list/endpoint accesses that appear unusual (e.g., large volumes of records from anonymous or external IPs). Leverage tools that can crawl your portals for OData endpoints or publicly accessible lists — like the “Portal Checker” mentioned by Microsoft.

Governance, training & controls for citizen-dev

Make sure business users who build apps/portals understand the implications of exposing data: links, OData endpoints, external users. Build a governance framework: When building a portal, there should be a “security checklist” that includes verifying table permissions and API exposure. Ensure that citizen-developers know that “rapid build” doesn’t mean “no security”.

Periodic review and testing

Perform periodic audits of all environments, lists, APIs to identify anonymous or external access. Conduct penetration tests on public portals built on low-code platforms. Use external researchers or automated tooling to simulate how an attacker could enumerate endpoints, lists, feeds. In the studied case, researchers discovered large numbers of public portals by sub-domain enumeration.

Lessons & Key Takeaways

• Low-code platforms like Power Platform are powerful, but default settings can be dangerously permissive.
• What looks like a harmless “sandbox” or “business portal” can in fact be publicly accessible data-leak vector.
• The phantom of the environment is the hidden exposure: default permissions, public APIs, overlooked endpoints.
• Real-world incident: over 38 million records exposed in the Power Apps Portals case — names, emails, appointment info, SSNs.
• Defence starts with visibility: you cannot protect what you do not know exists. Inventory, map, review.
• Governance must extend to the business-led side: citizen-dev, portals, APIs. Security cannot be an after-thought.
• The “environment” is not just the code/app—it’s the configuration, permissions, flows, connectors, API endpoints.
• When you build a portal/low-code app, ask: who can access the data, how is the API exposed, are we protected by default, what happens if someone links the OData endpoint externally?

Source: Power Platform Worst Case – Day 1: Data Leakage - The Phantom of the Environment