Please help me with some advice about the following data security concern:
How do you avoid that the Power-apps users modify the data directly on the SharePoint list if it is your back end data source?
The above taking into account the following:
I have to use SharePoint as data source due to several restrictions, so there is no other option so far.
As you know, when you shares a Power App you must grant access to the users to the back end SharePoint list.
If a "curious" user achieves to know where the Power App data is, they can go there and edit it, which is dangerous whether your solution is an approval app or you app contains confidential information.
Power Automate offers some options to help with this. I've used flows to create backups of SP lists and to interact directly with data sources. The flow is shared, but not the underlying data to which the flow connects.
_________________________________________________________________________________________ Help the community help more users by choosing to "Accept as Solution" if this post met your needs. If you liked the post and want to show some appreciation, please give it a Thumbs Up.
That's one of the issues with Power Apps, is the implicit data source sharing. You could try doing as much obfuscation as possible on the SharePoint end (e.g. not linking the site/subsite anywhere, hiding Site Contents maybe, etc.) which would be a good start. They'd have a hard time guessing a URL for a site (and lists, libraries, etc.) that they don't know exists. Ensure you have list-level permissions set up appropriately. Ensure your Power App itself has its field-level security set up how you want it.
We have apps that contain confidential information (not social security numbers or anything like that) and knock-on-wood nobody has gotten THAT curious to go digging through SharePoint. If you have someone that malicious, you'd probably want to start with that person, rather than Power Apps. That being said, maybe you can set up your data sources differently to divorce sensitive data in different ways. Maybe set up different security groups. If the security is so impossibly detailed, that should probably be reviewed as well.