Script is disabled Understanding Permissions in SharePoint-Hosted Add-ins - Portal Integrators
Select Page

Understanding Permissions in SharePoint-Hosted Add-ins


SharePoint-hosted add-ins are focused around components in SharePoint including, but not limited to, pages, lists, libraries, and workflows and does not include server-side code. The code logic uses JavaScript which is directly on a custom SharePoint page or on a JavaScript file referenced in the custom page.

SharePoint add-in as we also briefly discussed in this blog post is a self-contained piece of functionality that extends the capabilities of SharePoint websites to solve a well-defined business problem. – Microsoft

SharePoint add-ins are usually run from a tile on the Site Contents page of the site to which the add-in is installed, and most often than not, you may have the requirement to want to restrict access to its contents. For example, you may want to provide access to a content in the add-in to a specific group of users and restrict access to other users.




Add-in runs in the context of the current user and does not give user more permissions than what they already have. It supports 4 permission scopes.


-Image grabbed from here.

The file responsible for managing add-in permissions is the App.Manifest.xml file.

Also listed below are the rights for each of the permission scope:

  • Read – Allows viewing of pages, list items, and downloading of documents
  • Write – Allows viewing, adding, updating, and deleting items in lists and libraries
  • Manage – Allows viewing, adding, updating, deleting, approving, as well as, customizing pages within a site
  • Full Control – Grants full control within the specified scope


By default, the permissions in the host web, where the add-in is installed, is inherited in the app web, the current scope of the add-in. But there are cases that you have to incorporate data from different sources as well. For example, you need to get list items from the host web and use it in your add-in. There are security reasons that block communication with more than one domain at a time that might prevent you from doing that. The host web and add-in web domains are 2 different domains that you will usually see an Access Denied error when you try and do just above, make calls, or issue requests for resources on the host domain from the add-in.

To access host data in the host web, the permission scopes and rights we have mentioned above must be setup and the cross-domain library needs to be used. Cross-domain library is a JavaScript file (SP.RequestExecutor.js) lets add-in pages access data in the SharePoint domain. We will have a separate post dedicated to this that we will publish in the coming weeks.

Since permissions in SharePoint add-ins are granted when installed, there are times when add-in will have issues with the permissions. Regranting permissions is done by selecting the … button on the add-in tile. Select PERMISSIONS and click here link on the page.

We just touched a bit of what there is when it comes to permissions in SharePoint add-ins, but you may want to have these thing considered early on as you are building your add-ins so you will at least have the security part covered.

Send us your questions on SharePoint

11 + 6 =

Related Blog Post