The internet lit up a bit yesterday as UpGuard posted an article on how Microsoft Power Apps default permissions “exposed millions”.
The article can be found by clicking here.
Is this something you should panic about?
If you follow best practices and have been diligent in setting up Table Permissions, then you really should have nothing to worry about.
The issue was not a hack or defect with Power Apps portals, but rather a default security setting that was overlooked.
The issue reported is very similar to buying a new internet router and using the out of the box settings. You are going to want to spend some time to lock that down.
Even “out of the box”, Power Apps portals will not automatically expose any of your Microsoft Dataverse information.
The issue surfaces if you have setup any kind of List, Basic or Advanced Forms (formerly known as Entity Lists, Entity Forms and Web Forms) using the Portal Management App. If you were not using the most up to date version and haven’t bothered to tick the “Entity Permissions” (now called “Table Permissions”) box, you might want to review your portal configuration to ensure your data is protected.
Going forward, the option is checked by default if you create a new list or form using the Portal Management app.
Note that you do need to manually update your Portal managed solutions to ensure you have the latest updates.
If you create a list or a form using the Portal Studio; table permissions are also enabled by default.
If you surface any data using Liquid, you will need to configure table permissions to view the data on via custom liquid code, as the security is enable by default (always has been).
The big issue as noted in the article is OData feeds. You can configure a list component to surface Microsoft Dataverse information as a OData feed on your portal. That being said, if you forgot to enable table permissions, you could end up exposing that particular Microsoft Dataverse table to the entire world.
In some cases, you may actually want a public data feed (upcoming courses for integration into a partner’s learning management system, for example). However, you still should configure table permissions linked to an anonymous user web role.
Steps to Peace of Mind
Microsoft has now begun to surface all kinds of warnings and messages, along with sending customers emails if they have detected configurations that could leak data. Heed these warnings!
If you have used the OData feature for the list component, simply add a “/_odata” to your portal URL to view the lists configured for OData, and ensure that you have configured Table Permissions for these feeds.
Running the Portal Checker is a good practice regardless, this tool will also highlight potential data leak issues using lists or forms;
Finally, sometimes some old school tools are the easiest and best way to find issues. Simply use Advanced Find to locate any List or Form where Table permissions have not been enabled;
Even if you have table permissions enabled, you should double-check that they are linked to the appropriate web roles, which are linked to the appropriate contacts (portal users) and that these folks are allowed to see what they are allowed to see, create or update.
Following best practices when configuring a Power Apps portal is not only important for a project to go smoothly, but to also protect one of your most valuable assets… your data. If you are new to portals then this might have been something easily overlooked (you don’t know what you don’t know). However, this particular situation can be used as a learning opportunity, and thankfully, moving forward, the default settings are in place in to ensure that portals are secure.
Nick Doelman is a Microsoft MVP, MCT and resets the default passwords and security settings on all his Internet-enabled devices, including the air-fryer and the refrigerator. Nick usually remembers to lock the door on his truck… except that one time and lost $2.35 in change and a non-working iPhone (haha suckers…)