I have a bit of a dilemma and I'm hoping someone someone may be able to help me solve it.
I've built a PowerApp to facilitate the hiring and termination process at my company. The PowerApp utilizes SharePoint list on a site that my department has access to as a backend because it is our only available option as of right now.
The PowerApp does not directly write to the site in question's lists, it writes to an entirely different site with lists containing very little information which bridge data to the main site's lists. This is to avoid giving any contribute access to the main site's lists, which have data we do not want to provide to the PowerApps users. However, though the app does not write data, it has to be able to read some data from the site in question to garner information about the new or terminating employee to display to the PowerApp users.
For further information about the main site, I have two lists facilitating this process, one for new hiring requests and an active employees list to facilitate terminations. I have one custom permissions group called PowerApps Users. Since the users do not need contribute access to these two lists, I haven't worried about that. At the top level, PowerApps Users has a custom permission called PA Users Read, which only contains Open permissions for the site and no list permissions. On the two lists, I have broken inheritance and given PowerApps Users a custom permission for each called PA Users VO (view only), which contains the following permissions: Site View/Open, List View.
These permissions are working flawlessly as intended regarding the new hire list, at least as far as I can tell. The PowerApps Users can see the new hire requests in the PowerApp, but when accessing the SharePoint site or the direct link to the SharePoint list, they get Access Denied.
However, when given the exact same permissions on the active employees list, PowerApps users who access the list do not get the Access Denied message and can see all items in the list. They cannot edit, add, or delete any of these items, but they can see all of the data. We don't want this, as not all the data in this list is info we want to be accessible by the users (private extension numbers, supervisor information, resources employees have been provided, etc). None of it is especially sensitive, but it isn't something we want accessible either. While the URL for the site has not been leaked or anything like that, the fact that it is accessible at all is concerning.
When comparing the permissions on the new hire list and the active employees list, we noticed that PowerApps Users were being granted Limited Access permission on the active employees list, while they were not on the new hire list. The only real difference between these lists is that some items in the active employees list have text documents attached to their attachments column which contain some information about specific tables the employee has access to in a database.
Would the attachments cause this? If so, what recommendations do you have to prevent access to this database. We would prefer to not remove the attachments column if at all possible because the document is provided to our DBA upon account termination.
Solved! Go to Solution.
Wait! I found a solution. I don't know why this works... but it does. I went into the list permissions for the active employees list. I then restored inheritance, broke inheritance AGAIN using the permissions from the new hire list, deleted the PowerApps Users group, then re-added it with the view only permission level. Suddenly... miraculously... It works. Now to go back and do that for any lists that my end users have to access, haha. For anyone who stumbles across this post, here are my steps to secure the SharePoint backend as VIEW ONLY (not contribute). For those who need to allow your users to contribute to a list which has sensitive data, it may be better for you to create a bridge list or two, and update that instead, allowing Power Automate to process changes to the main list(s). This can be done by adding a column to the bridge lists called UniqueID and having the PowerApp update that field with the list item ID of the item in the main list.
This seemed to work for me. I didn't have to remove any attachments or modify the list at all. The URLs are now properly hidden behind Access Denied messages!
@cwebb365 This doesn't work, as the user is unable to see the items in the PowerApp. The user must be able to READ the items, but NOT be able to access the link if it were to ever be leaked.
The individual items do not have any permissions added directly to them, I already confirmed that. None of the items are being shared, either, as sharing permissions are turned off for the whole site.
However, as stated in my original post, the items in the active employees list contain items in their Attachments columns. I'm under the impression that the Attachments column is like a miniature document library. Forgive me if I'm incorrect. What I need to know is if this is what is causing the issues with limited access. If so, I can use Power Automate to break the attachments, which are simple text documents, up into their own individual columns. However, I don't want to put in that effort if it is going to be meaningless in eliminating the limited access issue.
Update: I think that attachments might truly be what is causing the limited access issue. I'm looking at the advanced settings right now, and I'm showing that permissions are enabled for users to upload their own attachments:
While this is also enabled on the new hire list, no items in that list actually include attachments.
However, marking this disabled says that it will delete all currently attached items. I don't want this. I suspect that this is going to involve more trial and error. My next test will be to add attachments to the new hire list items and see if that causes broken inheritance issues.
Wait! I found a solution. I don't know why this works... but it does. I went into the list permissions for the active employees list. I then restored inheritance, broke inheritance AGAIN using the permissions from the new hire list, deleted the PowerApps Users group, then re-added it with the view only permission level. Suddenly... miraculously... It works. Now to go back and do that for any lists that my end users have to access, haha. For anyone who stumbles across this post, here are my steps to secure the SharePoint backend as VIEW ONLY (not contribute). For those who need to allow your users to contribute to a list which has sensitive data, it may be better for you to create a bridge list or two, and update that instead, allowing Power Automate to process changes to the main list(s). This can be done by adding a column to the bridge lists called UniqueID and having the PowerApp update that field with the list item ID of the item in the main list.
This seemed to work for me. I didn't have to remove any attachments or modify the list at all. The URLs are now properly hidden behind Access Denied messages!
Hi @CameronWilliams and @cwebb365
I tested the options above, but there is a security point that is not functional.
Users who have access to the list are able to consume the list through a Power Automate Flow and a Power Apps App through their account using the Site link.
Any solution for this security point?
Thanks,