You’re about to deploy a SharePoint Framework solution package to your tenant. Before you do, have you considered what’s inside?

SharePoint Framework primer

SharePoint Framework is the recommended model for extending SharePoint. While SharePoint Framework extensions work currently only in modern sites, client-side web parts built using the SharePoint Framework can be used in both classic and modern sites.

SharePoint Framework solutions contain only JavaScript code which runs in the web browser. Similarly to SharePoint add-ins, they’re deployed through the app catalog, but, and this is the crucial part for you to understand, unlike add-ins, they run unrestricted. Whatever the user visiting the page with the SharePoint Framework solution can access, the solution can access to.

What you should know before deploying a SharePoint Framework solution in your tenant

Because SharePoint Framework solutions have unrestricted access to the information and APIs in your tenant on behalf of the current user, there are some important questions that you should answer, before deploying the solution in your tenant.

What does the solution truly do

Along with the solution package you might have received documentation describing the solution. But have you verified if the documentation is complete and up-to-date and if there have been no last-minute changes to the solution that aren’t included in the documentation?

Depending on what the solution does, your organization might have a different way of handling it. Maybe even it doesn’t allow certain solutions to be used in specific sites. Just because the documentation says, that the solution does or doesn’t do something, it doesn’t mean it’s true.

Where is the solution hosted

SharePoint Framework solutions consist of two main parts: a manifest with the solution’s metadata and JavaScript files containing the solution’s code.

Developers building SharePoint Framework solutions can choose whether they want to include scripts inside the solution package or not. If they do, when you deploy the package to your app catalog, these scripts will be copied to a document library in your tenant. But if they don’t, then it means that the scripts are hosted elsewhere and that leads to a number of additional questions.

Who owns the hosting location

Is the server, where the script files are hosted, owned by your organization or is it owned by developers? Is the continuity of this hosting location guaranteed or will you wake up one day to an email saying that one or more web parts are broken?

Under which circumstances could the source code change

SharePoint Framework scripts have unrestricted access to your tenant. This is why you need to be able to ensure their integrity. Under what circumstances could the source code of the deployed files change? Who has access to the files and could the files be changed without an official process? Is this in agreement with your organizational policies?

What is the SLA of the hosting location

If SharePoint Framework solutions are hosted outside of SharePoint, then it’s possible that the hosting location doesn’t meet the same SLA as SharePoint. This could lead to planned outage of some components on your intranet during the working hours.

Can the solution be deployed globally

Based on the contents of the solution, developers can decide to support tenant-wide deployment or not. When a SharePoint Framework solution supports tenant-wide deployment, it can be deployed to all sites at once. This alleviates you from having to manually deploy the solution to all sites and keeping track of where the solution is deployed. If the solution needs to provision some resources that it needs to function properly, like lists or content types, you might have to deploy it on each site separately.

Does it require access to APIs

When building SharePoint Framework solutions, developers can specify that the solution requires access to resources secured with Azure Active Directory. These resources can be Microsoft APIs, like the Microsoft Graph, or enterprise applications owned by your organization. When deploying a package that requests access to APIs, you will be prompted to visit the SharePoint administration page and either approve or reject these requests. There are two caveats that you should consider.

First of all, just because a solution doesn’t request permissions to access any APIs, it doesn’t mean it’s not using them. Solution’s code and the permissions it requests are two separate things not related to each other.

Once you approve a permission requested by a solution, that permission is granted to all scripts in your tenant: both scripts deployed through SharePoint Framework packages as well as all arbitrary scripts that your users might embed on their pages. This is why you should be very careful what APIs you allowed to be used in your tenant.

What JavaScript libraries does it use

There are literally thousands of JavaScripts libraries available on the internet, that developers can use in their solutions. While using an existing library enhances developer productivity, it comes with caveats and risks for the organization using the solution.

Is there anyone in the organization who knows this library

When developers use a specific JavaScript library to build their solution on, it introduces a huge dependency for your organization. What if that developer moves on? Is there someone else in the organization capable of fixing bugs or applying changes without having to rebuild the whole solution? How likely is the library to exist in 6 months time or a year? How active is the community supporting it and how well they respond to any issues? If your organization doesn’t standardize on which libraries developers should use, you could face costly problems.

Where does the solution load its JavaScript libraries from

Similarly to the scripts that make up a SharePoint Framework solution, all JavaScript libraries used by that solution are loaded and executed as a part of the page. These libraries also have unrestricted access to all information in your tenant and all APIs exposed through Office 365. Can you trust the location hosting these scripts to ensure their integrity? What is the possibility of someone modifying these scripts and adding malicious code that could access the data in your tenant? Also, if an issue is discovered, is there someone you can contact? How likely are they to fix the issue?

What is the SLA of this hosting location

If any of the JavaScript libraries used by the SharePoint Framework solution fails to load, that whole solution will likely fail to load as well. If developers chose to load JavaScript from a location not owned by your organization, you should verify that the SLA at least meets the SLA of SharePoint.

What is the license of this library

JavaScript libraries are often distributed under a license. Some, don’t specify a license explicitly. Do you know what the licenses are of the JavaScript libraries used in the solution and is the software distributed under these licenses approved to be used by your legal department?

Are there any known vulnerabilities

Despite the best intentions, regularly, vulnerabilities are being found in JavaScript libraries. The severity and impact of these vulnerabilities varies and often each reported vulnerability contains a recommendation whether you should update to a different version or take some other corrective action. There are number of services on the internet tracking vulnerabilities in JavaScript libraries. Have you checked that the libraries used in the solution are up to date and don’t contain any known vulnerabilities?

Summary

Using the SharePoint Framework organizations can extend SharePoint to their specific needs. But due to the proliferation of JavaScript libraries and the flexibility the SharePoint Framework offers developers, deploying a customization in your tenant introduces a number of risks. Because these solutions have unrestricted access to content and APIs in your tenant, you should review them carefully before deploying them in your tenant.

Photo by Bench Accounting on Unsplash