Hello SharePoint guys,

In this post, I want to focus on concerns all SharePoint developers and administrators should be aware of.

JavaScript code is running in the users'browsers, in other words, with and only with the permissions of the current user.

It actually means two things:

1. A JS code, on its own, will never be able to do more than what the current user is allowed to do.
2. A JS code will be able to do more than what you, as a user, expect it to if you are a privileged user with enough permissions.

While it is a consideration for developers to take into account, it is also a security concern to take care of for governance and people responsible of security and content privacy. Let's figure it out!

No more privileges than the current user

A developer who plan to implement a JS customization (either SPFx or simply embedded piece of JS) will always have to make sure the current user has the required privileges on the required assets for the application to run properly. Typically, the end user should, ideally, see an error message mentioning he is not allowed to perform the current operation.

My SPFx application must be able to do more than what the current user is allowed to (e.g. Write to a list the user has read-only access on), how can I address that ?

There is no way that JS code running in a browser can achieve that because it would mean there is a security breach. However, a trusted third party (SharePoint Provider Hosted Add-ins, or fully external apps or web API with app-only permissions) could totally have the required "elevated" privileges. It is then possible to address the requirements via this third-party. The JS code will communicate with this third-party and kindly request it to do the job.

Warning: With a full external app/API with app-only, you have to take care of the authentication (and maybe authorization) by your own mechanism.

Info

The available technologies and techniques are numerous. The third party API could be written in any language (C#, VB.NET, Java, Node.js, Python, PowerShell, ...) as far as it has HTTP capabilities and it can be hosted on any kind of system. In a full OnPrem environment, it must be hosted on an app server while in a SharePoint Online or hybrid environment, the Web API can be an Azure Website or Azure Function (or any other cloud service).

An elevated privileges user can possibly execute malicious code

An administrator must realize that, in SharePoint classic pages*, any user with Design (or similar) permission level can embed a custom JavaScript on a page that will run under the permissions of the current page visitor. If a malicious user wants to get or manipulate information he has not access to, it might be pretty easy for him to let a privileged user execute a malicious code and perform bad actions on his behalf. Moreover, a well-intent "IT amateur" user who barely knows how to copy/paste a JS snippet might include scripts from unsafe sources to SharePoint site home page (Yes I personally faced this...).

*   (In SharePoint Online, only if the Custom Script setting is enabled)

Since custom scripts are embedded directly on various pages, it is very hard and practically impossible for administrators to monitor and analyze all these pieces of code especially in large organizations. It results in potential security threats because of the lack of control the administrators are reduced to. Administrators have alternatives to prevent this :

• The ideal solution would be a strict governance plan that ensures there is no way an unsafe user has enough permissions or can possibly get enough permissions to embed a malicious code in a page. Unfortunately, such strict governance is often causing the users to step back from SharePoint.
• Currently only on SharePoint Online, you can make sure the Custom Script setting is disabled (set to NoScript) everywhere. However, this solution has also its bunch of drawbacks (check this out https://support.office.com/en-us/article/Turn-scripting-capabilities-on-or-off-1f2c515f-5d7e-448a-9fd7-835da935584f). It also prevents all kind of SharePoint customization through JS embedding.

We have several JS customizations vital for our organization and we trust them. Is there a way to only allow these ones ?

YES ! Actually, it is exactly the main benefit of the SharePoint Framework (SPFx) from an administrative perspective. Modern SharePoint sites (which are the main target for SPFx solutions) are, by default, in NoScript mode (Custom Script disabled) and there is no way to embed JavaScript. On the other hand, SPFx solutions are specifically allowed by the administrators. Administrators have to upload the solution package of the SPFx solution to the AppCatalog, a Dialog box will then appear and indicate where the JavaScript sources will come from.

This message, actually asks the administrator if he does or doesn't trust the JavaScript code. That way administrators can, at least, monitor what JS code can run on the SharePoint they are responsible for.   As always, I hope this post will be useful for developers and administrators around.

Leave some comments!

Yannick