The Power BI “Publish to Web” Exposure Risk: What It Actually Reveals

How do Power BI reports end up exposing sensitive data publicly?

Power BI reports end up exposing sensitive data publicly most often through the platform’s “Publish to Web” feature, which is designed to make a report freely viewable by anyone with the link, but which independent security researchers found also frequently exposes far more than the report’s visible summary. An account of how Microsoft Power BI reports have exposed sensitive data on the web describes how unauthorized users can reach the underlying semantic model behind a published report, including hidden tables, filtered records, and columns that were deliberately left out of the visible dashboard, through straightforward API calls that don’t require any special access.

That distinction matters: an organization might reasonably believe it published only an anonymized summary chart, while the data actually sitting behind that chart, unaggregated and unfiltered, remains reachable to anyone who knows where to look. The gap between what a report appears to show and what its underlying model actually contains is the core of why this has become a recurring exposure pattern rather than a one-off configuration mistake.

Researchers described the extraction process itself as simple: once a published report is located, pulling the hidden data behind it doesn’t require credentials, special tooling, or any interaction with the organization that published it. That combination, a low technical bar paired with a large and easily searchable pool of published reports, is what turned this from a theoretical design tradeoff into a practical exposure risk that researchers could demonstrate at scale rather than in a single isolated case.

How widespread is this Power BI exposure problem?

Independent security researchers reported that the issue affects tens of thousands of organizations worldwide, after finding that a simple search-engine query for publicly indexed Power BI report URLs returned more than 160,000 results, a number that narrowed to over 50,000 with more targeted search terms. Manually screening a portion of those results, researchers said they quickly identified dozens of reports from which sensitive data, including employee records, customer information, and government data, could be extracted, with some belonging to state government sites, universities, and municipalities.

The categories of exposed data researchers documented included protected health information and personally identifiable information alongside internal business records, which is a meaningfully different risk profile than the marketing dashboards and public statistics the “Publish to Web” feature was originally intended for. Because the exposure sits at the semantic-model level rather than in the visible chart, standard checks like reviewing what’s on-screen in a published report simply won’t catch it; the risk lives one layer below what anyone looking at the report would ever see.

Figures reflect the number of search-engine results returned for publicly indexed Power BI “Publish to Web” report URLs, as documented by independent security researchers and reported in technology press in June 2024. Not every result represented a report with sensitive data; researchers manually confirmed a smaller subset.

What did Microsoft say when researchers reported the issue?

Microsoft’s Security Response Center confirmed the underlying behavior but characterized it as a design choice rather than a vulnerability, after researchers reported the issue in mid-2024. That framing puts the responsibility for avoiding exposure squarely on the organization publishing the report, which is consistent with how Microsoft’s own documentation on publishing Power BI reports to the web describes the feature: it’s intended for content meant to be fully public, and Microsoft advises against using it for anything containing information that shouldn’t be visible to an anonymous internet user. In practice, that guidance is easy to miss in the moment someone clicks “publish” to quickly share a dashboard with a client or a public audience, especially when the person doing the sharing is focused on the visible chart and has no reason to think about what else might be attached to it underneath.

Does this risk stop at Power BI, or does it extend across the Power Platform?

It extends well beyond Power BI. A breakdown of the Power Platform’s broader security risk surface identifies five recurring threat categories across the platform family: Power Apps exposure and hardcoded secrets, Power Automate flows carrying injection and stale-credential risk, Power BI dashboards oversharing data, custom connectors introducing supply-chain risk from untrusted sources, and Copilot Studio agents taking unvetted actions through unsafe integrations. Power BI’s publish-to-web exposure is simply the most visible and most publicly documented instance of a pattern that shows up across the whole platform: features built for ease of sharing and automation, deployed by people who aren’t necessarily thinking about the security implications of a single click.

What should an organization actually do about exposed or overshared reports?

The first step is knowing what’s already been published, since most organizations don’t have a running inventory of every report or dashboard that’s been shared externally, let alone what data sits behind each one. A use case built around detecting overshared and publicly exposed data across connected platforms approaches this by mapping data sources, connectors, and integrations tied to each app, flow, and report, then flagging assets that are publicly exposed or that have accumulated more access than their intended audience should have. From there, remediation is usually straightforward: unpublish or reconfigure the report, and route a notification to whoever owns it so the same mistake doesn’t get repeated the next time a quick external share feels like the fastest option.

The underlying lesson generalizes past Power BI specifically. Any platform feature designed to make sharing effortless is, by definition, also a feature that makes oversharing effortless, and the organizations that catch these exposures early are the ones actively looking for them rather than waiting for a researcher, or an attacker, to find them first.

There’s also a timing argument for treating this as an ongoing check rather than a one-time cleanup. New reports get published continuously as teams share dashboards with clients, partners, or the public, so a single audit that clears the current backlog doesn’t prevent the next well-intentioned share from recreating the same exposure a month later. Building the check into a recurring process, rather than a project with a defined end date, is what keeps the fix durable instead of temporary.

Frequently Asked Questions

Can someone access hidden data in a Power BI report even if it looks anonymized?

Yes. Security researchers demonstrated that unauthorized users can reach hidden tables, filtered records, and non-displayed columns in a report’s underlying semantic model through direct API calls, even when the visible report appears to show only an aggregated summary.

Did Microsoft treat the Power BI exposure as a security vulnerability?

Microsoft’s Security Response Center confirmed the behavior after it was reported but characterized it as a design choice rather than a vulnerability, placing responsibility on the organization publishing the report to avoid including sensitive information.

Is this exposure risk limited to reports published with “Publish to Web”?

The most widely documented cases involve “Publish to Web,” but the broader Power Platform carries similar oversharing and exposure risks across Power Apps, Power Automate, custom connectors, and Copilot Studio agents.

How can an organization find out if it has exposed Power BI reports already published?

Organizations typically need an inventory of every report, dashboard, and connector that has been published or shared externally, since most do not track this automatically and can’t remediate exposure they don’t know exists.