Far too often we place the blame for lousy low-code solution architecture on citizen developers building their first apps. In practice, the more experienced IT professionals and pro developers are equally capable of making bad choices that lead to compromised data security. Sometimes their gut reactions just create confusion around what is/isn’t a secure way to handle business data in applications, automations and reports built on Power Platform.

Today I want to show you three examples of real-life challenges that you can expect to encounter when addressing access control / security topics in the low-code world of Microsoft Power Platform. What they all have in common is the fallacy of "what you see is what the user can access". Of course, that’s not how any of these tools work. UI is just one layer on top of the underlying data, which may have much broader access rights assigned to the users. You should always assume that users can have a peek behind that layer - accidentally or intentionally.

For a business user that’s just getting familiar with making apps, such an assumption would be a perfectly understandable error. If you work in IT or software, not so much. Yet the common factor here is that these theoretical personas are all really just humans. We tend to trust our eyes more than our knowledge.

Exhibit 1: SharePoint

What’s the most popular data source for Power Apps? Yes, of course it’s SharePoint lists, “because they are FREE!!1!” Thanks to the enterprise content management legacy of SharePoint, it’s been sufficiently cumbersome for a user to find a list they have full access to, so this has made them seem like a valid data storage for sensitive information.

Until someone invented a new product on top of that data store, called Microsoft Lists. And it all went to 💩 from there:

In short, some app developers on the Power Users forum are furious about the fact that MS Lists, a product aimed at making it easy for any user to work with list data they have access to, is doing precisely that. They had assumed that no one else except them would ever be building application UIs that reference SP list data. Which, given the popularity of SharePoint, is an obvious mistake.

Relying on a crappy, confusing UI is hardly a security model. Because one day someone will invent a better UI than what the legacy SharePoint experience has been like. That’s exactly how the evergreen products in the Microsoft cloud work.

Exhibit 2: XrmToolBox

Okay, so now we know SharePoint isn’t the optimal back-end for your business app data. Microsoft Dataverse is a much better choice, even if it requires a premium license. Let’s put our data there and then we don’t have to worry about any of these front-end/back-end security layers. Right?

Oh, if only it was so easy. Unfortunately, you can’t just throw licensing dollars at a concept like solution architecture and hope for the software products to solve all the issues.

XrmToolBox should by now be familiar to anyone who is building any kind of solutions on top of Microsoft Dataverse. With its broad usage across Dynamics 365 and Power Platform projects, also people who don’t have hands-on experience with the platform may run into it. This can create confusion around what the relationship is between Microsoft’s products and these many community-built tools. Because at first glance, it may appear that XrmToolBox allows your users to peek behind the UI and see things you didn’t expect them to see.

The whole reason why any of such tools exist is that MS has skipped building the necessary UIs into their products. Either some of the platform actions are only available via API calls, or the standard UI is so cumbersome that frustrated developers have created a more useful UI to get their work done. Thanks to XrmToolBox providing the common foundation for development and distribution, both you and me can take advantage of these alternative interfaces to work with supported platform operations.

What’s the problem then? Well, since something is not possible in the native Microsoft application UIs, some folks assume that users are technically blocked from performing the actions. Like modifying data that is only restricted on the client side, yet fully allowed for CRUD operations on the server side. When such “security holes” are then exposed, it’s a natural reaction to direct the blame to someone else. Like the authors of those community tools.

Mr. FetchXMLBuilder, Mr. PluginTraceViewer and Mr. “14 other XrmToolBox tools” Jonas Rapp recently published an excellent post on the Scary, dangerous, creepy tools he and other community members have built:

We shouldn’t have to explain to technology professionals that API access is an equally valid way to work with data as a graphical UI. Especially when any malicious actor certainly won’t care about the difference while trying to break into a restricted business system. But we do, because again: humans.

Relying on the power users of a system like MS Power Platform to not discover any alternative client applications to get to the APIs they have access to is hardly a valid security model. Because they don’t even have to install a scary 3rd party application like XrmToolBox. All they need is access to Power Platform itself to achieve the same results:

It’s a platform for Makers to build new analytics, UI and automation experiences on top of data that they have already access to. As MS says, Power Platform is for every developer. Everyone can be a developer. The classic division between those who build vs. those who use no longer apply within your Microsoft 365 tenant. Learn to deal with it - or expect to be surprised by the power of low-code application development platforms again & again.

Exhibit 3: Fabric + Copilot

With all this talk about Copilots revolutionizing how information workers get their jobs done, should we even spend time thinking about the traditional graphical UIs of business applications anymore? In a way, it doesn’t matter at all whether the user interface is graphical or conversational, as is the case with generative AI powered chat tools like Copilot in Microsoft “product X”. Rather this shift towards personalized interactions between the user and the Copilot just makes it harder to observe what data is & isn’t accessible to the end users.

Let’s jump over from the operational MS Dataverse to the analytical MS data platform products under the Fabric brand umbrella. In this case, the Power BI reports. Natural language queries have been available in Microsoft’s reporting products for a much longer time than they have actually worked in a satisfactory way (meaning, before LLMs like GPT-3+ became a mainstream tech). This “security through obscurity” approach has guarded them from most of the potential controversy around security implications of such alternative UIs.

The way the graphical representation of data in reports is defined by the report developers has remained pretty much the same, even if there are AI based helpers to speed up the development work. This may lead to the false assumption that what the developer chooses to include in the visual report is what the report end users can see. That’s not the reality, though.

Recently, security researchers from Zenity reported a “by design” feature that they had discovered with the Q&A feature of MS Fabric. In short, via the Q&A visual of a Power BI report, a user that has been given rights to access the report will be able to query any data that’s included in the underlying semantic model (previously “dataset”). In the example, the detailed monetary value of deals used to rank top customers will get exposed via Q&A, even if it’s not included in any visuals that the report developer has published:

Is it really “an inherent flaw in the product” as described by the security researchers? Personally, I do think that the scope of the software product should cover the implicit impressions that the tool gives to its users. Thus, when the act of sharing a report doesn’t make it obvious that you are actually sharing access to the server-side data source in addition to the client-side report visualizations - yes, it’s a flaw of the user experience that the product delivers. No matter if you’re a citizen or a professional developer, it’s too easy to fall victim to thinking that "what you see is what the user can access".

With the rise of Copilot as the entry point to internal data sources, there will hopefully be broader exposure to and awareness of the role of managing data access beyond the UI layer.