Share

0

SharePoint is often used as a data source for Power Apps canvas apps, there’s no getting away from that any time soon. However, this presents additional challenges regarding security, as we need to ensure that our lists and libraries are properly secured.

Unlike sharing a Dataverse-ready application, where we can apply a security role to the tables at the same time, the process is different for SharePoint. As Power Apps specialists, developers, architects and even administrators, it’s important to understand how this works.

In this article, I’ll share my top tips for securing SharePoint lists and libraries that support your canvas app projects.

Table of Contents

• The risk
• Contribute, not Edit
• Custom permission level
• Turn off Edit in Grid View
• Enable item-level permissions
• Break and reset permissions
• Customise the list form
• Hide the list completely
• Be wary of Equals [Me]

The risk

A common requirement is to send a link to a document or list item, usually via an email or Teams message. This is quite easy to do in either Power Apps or Power Automate. Unfortunately, this can also expose the URL of the underlying SharePoint site(s).

An inquisitive user might navigate to the site and interact directly with any lists or libraries. This would bypass any conditional access or other logic you may have in your canvas app. For example, you might have a gallery filtering records to show only those created by the logged-on user – but your root SharePoint list might be showing everything.

This, and other scenarios are easy to go undetected. Here’s my rundown of ways to mitigate such risks.

Contribute, not Edit

When a site is first created, three permission groups are automatically applied – Owners, Members and Visitors. A simple way to give users access to create, edit and delete list or library items is to add them to the Members group (either individually or via an AD Group):

However, the Edit permission level is potentially quite risky. It allows users in that group to create items & documents, but also create or delete actual lists and libraries. If you just need members to perform actions against lists/libraries supporting an app, the Contribute permission level works just fine. It allows members of the group to perform the usual CRUD operations, without creating, deleting or changing any infrastructure.

Custom permission level

In Dataverse we can create security roles to control granular access to tables. SharePoint offers the same in terms of custom permission levels. These are basic by comparison but allow for bespoke permissions to be leveraged. For example, the Contribute permission allows users to create, read, edit and delete items, so what if we only want them to create and read?

Site owners can create custom permission levels to be used against lists and libraries:

1- From the site’s homepage, click the cog (top right), then select Site Permissions.
2- From the slide-out pane, select Advanced Site Permissions.

3- Select Permission levels

4- From here, you can either select Add a Permission Level and build one from scratch, or select an existing one and click on Copy Permission Level:

Personally, I prefer the latter; it will have boxes ticked that are standard so you only have to worry about the main permissions you want to grant. Configure to your needs, save it, then apply it to your relevant Permission Groups  for your site, lists and/or libraries. 

Contribute or custom permissions should be handled during the first phases of Power Apps solution development. Try to action these ASAP where you can – security shouldn’t be retrospective.

Turn off Edit in Grid View

If you have full create/edit/delete access to a SharePoint list or library, you’ll see the Edit in grid view option in the ribbon menu:

This option turns the list or library into something akin to an online spreadsheet. Changes can be made instantly without a save button, they could be accidental changes too. Someone could use this feature to bulk-update lots of entries and cause throttling issues. These changes are really hard to reverse if list versioning isn’t enabled (it is by default for libraries, but not for lists).

To disable this option for SharePoint lists:
1- Navigate to the list, click on the cog (top right) and select List Settings.
2- Select Advanced Settings.

3- Scroll down and toggle the following setting to No.

4- Click OK at the bottom of the Advanced Setting screen.

Navigate back to your list and you’ll see the option is now hidden.

It’s an almost-identical process for SharePoint libraries. Navigate to the library, click on the cog, Library Settings, More Library Settings, Advanced Settings, configure and save.

Enable item-level permissions

In our Power Apps, we might configure some logic where users can only see records relating to themselves. We need to remember this isn’t the case by design in our SharePoint lists. Any user finding their way into the lists may therefore see records associated with other people. A quick remedy to this is enabling item-level permissions.

To enable this:
1- Navigate to the list, click on the cog (top right) and select List Settings.
2- Select Advanced Settings.

3- Item level permissions should be the option at the top of the resulting page. Configure both options as per below:

Break and reset permissions

You can extend the option above even further, by using Power Automate to break & reset permissions to the specific list or library item. This will provide an extra level of granularity for access, both for your apps and if anyone stumbles across the backend site structure.

1- Navigate to the Power Automate homepage and select the environment you need to use to build the flow.
2- Create a new automated cloud flow. The trigger will be when an item is created in SharePoint.

3- Configure the trigger to point to the relevant SharePoint site and list:

4- Next, add an action and find the Stop sharing an item or a file SharePoint action. Configure the site and list, then use dynamic content to get the item ID from the trigger:

5- Next, add and configure the Grant access to an item or a folder SharePoint action. The recipients will be who you want to grant access to. This can be users or groups from Active Directory, or dynamic content (ie the Created By from the trigger is usually a good idea). Here you can also specify what role these users will have to the item – Edit or Read: 

If you need to grant edit & read to different sets of users, you’ll need 2 dedicated actions – 1 for each. Also, don’t forget these actions are compatible with environment variables too, should you have multiple SharePoint sites or lists to support Application Lifecycle Management.

Customise the list form

Even with some or a combination of the above, users may still be able to add or edit items using the native SharePoint controls. Adding or editing an item directly in a list may also bypass logic or settings we’ve configured in our standalone canvas apps. We can customise the default form experience in our SharePoint lists to prevent this. You’ve put all that hard work into building a canvas app, make sure they use it 😊.

1- Navigate to the list, click on the cog (top right) and select List Settings.
2- Select Form Settings.

3- Click on Customize with PowerApps:

From here, you can build the experience you need. Maybe admins can use the default experience but users can’t. Or maybe NO-ONE should be edited through the SharePoint list. 

I typically opt for the latter, so to customise the list form by removing all default forms/controls and adding my own experience. I’ll usually include a button to launch the canvas app too. Don’t forget to publish the app, else the changes won’t be visible in the SharePoint list.

With this in place, when users try to add or edit an item, they’ll see your revised list form experience:

CAVEAT:
Sometimes this can be a bit temperamental. If you’re customising the list form for the first time, it might not show the changes right away. You may have to return to List Settings > Form Settings, modify and republish the revised list form, before the experience will show in the list.

Hide the list completely

If all maker and admin activity is performed in Power Apps, you can opt to hide the SharePoint list(s) completely. You can do this via PowerShell or Power Automate, I’ll focus on the latter method here.

1- Navigate to the Power Automate homepage and select the environment you need to use to build the flow.
2- Create a new instant cloud flow. The trigger will be manual.

3- Add the Send an HTTP request to SharePoint action. Configure the action has shown below, ensuring you type the display name of your relevant list in the Uri field. In the body, we simply use a boolean to show or hide the specified list:

Configuration if you want to copy & paste:

Uri:
_api/web/Lists/getbytitle(‘Display name of your list’) – don’t forget the single quotes either side!

Headers:
X-HTTP-Method / Merge
If-Match / *

Body:
{
‘Hidden’: true
}

To unhide, run the same flow but change the boolean in the Body to false.

Be wary of Equals [Me]

Something I see a lot is the ‘Equals Me’ method for SharePoint security. This is done by adding a Person or Group column, and then configuring view filters like so:

If this is the only method you’re using for locking down your lists or libraries, please note this is purely a cosmetic thing. Another user could send me a link to one of their items and I’d still be able to edit or delete it!

This method is otherwise known as security by obscurity, so if you want to ensure robust access to SharePoint lists, especially ones supporting your Power Apps, please opt for using other methods detailed in this article.

In a perfect world, Dataverse would be everyone’s primary data source to support Power Apps. Until then, SharePoint lists are, and will remain a widely used tool on which to build Power Platform solutions.

If you’re using SharePoint lists to support your apps, how are you securing them to ensure compliance & integrity? If you’re using any methods not listed above, please let me know in the comments below!

About the Author

Craig White

2x Microsoft MVP, Low Code & AI Readiness Lead

Reference:

White, C (2025). How To Secure SharePoint Lists Used For Power Apps – Platforms of Power [Accessed: 11th October 2025].