Most of us probably know, but every now and then, I still run into cases where hiding pages in a Power BI report is used for security purposes. Although hiding pages might seem like a security feature, it is not intended to be used as one since it can be easily bypassed. Users can find hidden pages by simple URL tweaking or right-clicking on the tabs. The article provides an example of how users can use the Reports-Get Pages API to get all report pages and report sections without having to write a single line of code. The default page when publishing a report is the one that is open, even if it is hidden.

Hiding pages

In Power BI reports, it’s pretty easy to hide a page for your end users. A simple right-click on the page let you hide the page. There could be various reasons to consider hiding pages, like the tooltip page you created, or the drill through page. From a user experience perspective, you do not want to show these pages by default, as that might only lead to confusion as normally these pages are filtered when a user navigates to them. For tooltip pages, the context of the item you hover over is applied, and with drill through you can pass-on filters to the drill through page as well.

Another thing to keep in mind, is the page which is open when you publish a report will be the default page on which a report opens, for you and all your end users. So, keep in mind that in case you publish while you navigated to the hidden page, the users will open the report on this page by default.

Every now and then, I run into conversations with clients or people at community events, where hiding pages is used as a security feature. Often this is done by using dynamic page navigation like I described earlier in this blog post. Don’t get me wrong, dynamic page navigation is awesome and is definitely the way to go to serve your users in the most optimal way and provide them with easy click paths to the pages relevant for their persona. However, let me get one thing very clear: Hiding a page is NOT security! This feature is never intended to be a security feature and for end users it is pretty easy to still navigate to a hidden page. So basically, hiding a page is security by obscurity.

But my users can’t see nor find these hidden pages right?

Wrong! Users can definitely find and navigate to hidden pages. Of course, you can debate how likely it is that your users will take these steps to get to the potential hidden pages. But let me explain a few ways how users can find hidden pages.

A simple right click for report server reports

The classic page navigation is the navigation in tabs at the bottom of a report – which we all still use in Power BI Desktop. For the Power BI Service, you have to enable this in the Power BI report settings by toggling on this setting. For Power BI Report Server, this is still the default page navigation.

In Power BI Report server, viewing hidden pages is as simple as doing a right click on the little arrows < > next to the tabs page navigation at the bottom of the report. In this way, you can simply see the hidden pages and navigate to them.

Some simple URL tweaking

When we look at the URL of a Power BI Report, it is typically setup like this:
https://app.powerbi.com/groups/ {workspaceId} / reports / {reportId} / ReportSection{Guid}
In this example, the workspaceId could also just be “me” when it is a direct share, lives in a personal workspace or when it is shared as an app. The ReportSection elements typically relate to a report page or bookmark and that is where the trick comes in.

You might think, hey… but that ReportSection thingy, that’s a GUID. The likelihood that my users guess the right GUID is very minimal. Well, that is where the trick with the API comes in. You might think, my users don’t even know what an API is, let there that they will start using this to discover hidden pages in the Power BI report. Well, they don’t have to write a single line of code to use this API. No matter if you shared the report via a Power BI App or direct share, as a user you can execute a simple API call based on the reportId to get more details.

Using the Reports – Get Pages API, will allow users to specify just the ReportId which they can fetch from the URL when opening the report, to get all report pages as a result. As I mentioned, they don’t have to write a single line of code, given they can just use the Try It button. The API Call looks as follows:

GET https://api.powerbi.com/v1.0/myorg/reports/{reportId}/pages

As a result set, you will get a JSON including all report pages and ReportSections for example like shown below.

{
  "@odata.context": "http://wabi-west-europe-e-primary-redirect.analysis.windows.net/v1.0/myorg/$metadata#pages",
  "value": [
    {
      "name": "ReportSection",
      "displayName": "Hidden page",
      "order": 0
    },
    {
      "name": "ReportSectionb055c3241710dd6b372b",
      "displayName": "Overview",
      "order": 1
    },
    {
      "name": "ReportSectionbcc5c5887b01d10c12d0",
      "displayName": "Daily summary list",
      "order": 2
    },
    {
      "name": "ReportSection1ea7dbb00c397a0957dd",
      "displayName": "Individual Trip list",
      "order": 3
    }
  ]
}

From this JSON object we can read the page names, order but more interestingly, the ReportSections including the GUIDs. When we simply copy this, and paste it in the URL, you can directly navigate to a hidden page of a report. As you might have noticed in above example, the first page does not have a GUID behind the ReportSection. As far as I’ve tried, this is the default for the first page of a report. This makes it even easier for users to just try to navigate to this ReportSection without specifying a GUID at the end.

What alternatives do I have?

Who knows, one day we might get something like page level security. But at the time of writing this blog (March 2023), something like page level security is not possible withing the capabilities of Power BI. The alternative you could work with, should be building multiple reports on top of the same dataset, and taking benefit from multiple app audiences to only serve the relevant content to the right user. Features like cross-report drill through will also come in handy, to jump from one level of granularity in a report, to a more detailed report for example, which you do not want to make available to each and every user.

Obviously, the argument of maintenance comes up when you start suggesting an approach like this. In all honesty, I personally think this is a nonsense argument. Whether you maintain two individual reports which each one report page, or you maintain one Power BI file with two pages, this all remains the same. Other than that, I believe that most of your maintenance work will be on the dataset level, which can still be a shared dataset across both reports.

At any times, the security features you should be using, are row-level-security and object-level-security. From a data perspective, these are the only real security features to actively secure your data and make certain aspects unavailable to some users.

Wrap up

In short, always setup proper security by using RLS and OLS. Hiding a page, is not security as there are ways for your users to figure out the specific ReportSection GUIDS which allow them to directly navigate to these pages. While that is the most complex way to do it, for Power BI Report server, it is even a simple right click that allows you to find these hidden pages.

If you’re actively hiding pages for your users to avoid questions, given this page only contains secured visuals as you’re using it in combination with RLS/OLS, then for sure go ahead. That’s the point where you started using it for a user experience perspective with personalized page navigation. But keep one thing in mind. Just hiding a page, is not enough!