By disabling custom script on their sites, organizations using Office 365 can increase the security of their data and improve the governance of their portal. But how reliable is it actually?

Extending SharePoint in JavaScript

Over the last few years we’ve seen a significant increase of ready-to-use JavaScript widgets: pieces of script that do everything from showing the weather forecast for the location of your choosing, to forms, surveys and package tracking widgets.

The reason why these widgets are so popular, is that they are extremely easy to implement and use. All you need to do, is to grab a piece of code from the internet and add it to your page. And it just works. No longer organizations need to start costly projects, involve their IT department for approval, organize functional requirements workshops with key-users. Instead, they spend a couple of minutes on the internet, find what they need, add it to the page on your intranet and they’re done.

What a piece of JavaScript embedded in SharePoint can do

SharePoint comes with a very powerful API that can do everything from retrieving an item from a list to starting a workflow or even changing user permissions. If you, the user visiting a page on your intranet, have sufficient permissions, each script on that page can:

• search for confidential documents on your behalf
• allow everyone in your organization to view your confidential information
• send documents to an email
• change permissions on sites and documents
• track the confidential project you’re working on and share it with your competitors
• change pages and documents
• delete sites
• leak annual results to press before the official announcement

This is just a short list of things that a script on your intranet could do on your behalf, without you even knowing about it. And it’s all not even that complicated. All it takes are a few lines of code to connect to SharePoint APIs.

Any script that you take from the internet and put on your page could potentially do this and more. The only way to be sure if it’s safe, is either by reviewing each and every script, which power users who often put scripts on pages don’t have the knowledge for, or not including external scripts in the first place.

No-script sites to the rescue

Organizations have been struggling for a long time with the lack of oversight of what external scripts are being used on their corporate portals and where. After all, the risk that any of these scripts is posing is real, and it’s totally understandable that organizations feel uncomfortable not knowing if they are exposed to any danger. There is even a support page dedicated to security considerations for using custom scripts.

To help organizations regain the control of their portals, Microsoft introduced a while ago already the concept of no-script sites: for every site in the Office 365 tenant, administrators can choose if it should allow including arbitrary scripts or not. This capability is described in detail in a special knowledgebase page on the Microsoft Support site.

Using the no-script configuration setting, administrators can control where in the organizational portal custom scripts can be used. Well, almost.

Inconvenient SharePoint Framework and no-script sites

To better support extending SharePoint using client-side techniques, Microsoft released last year the SharePoint Framework - a new SharePoint extensibility model focused on building client-side customizations. Before they can be used, solutions built on the SharePoint Framework have to be deployed through the app catalog, either centrally or delegated on the site collection level. This gives the organization the opportunity to review the solutions before deploying them in the production.

Because SharePoint Framework are deployed by an administrator, even though they might contain third party JavaScript code, they are allowed to run on no-script sites, assuming they have been marked as safe.

When building SharePoint Framework solutions, for each web part and extension, developers can say if it’s safe to use it on sites that disallow using custom script or not. This is indicated by a property in the manifest of each SharePoint Framework component. And there are two problems with this property.

When false !== false

Originally, to indicate that the web part or extension was loading arbitrary scripts (scripts that users could configure), developers would set the safeWithCustomScriptDisabled property in the manifest to false. In the recent version of the SharePoint Framework, when the property has been renamed to requiresCustomScript, the false value indicated that the component doesn’t load any arbitrary scripts. So if the developers upgrading their solution don’t closely read the comments included in the generated code, they can unwillingly expose a governance or even a security hole in their portal!

But there is also even a bigger problem.

Developers, developers, developers

When building SharePoint Framework solutions, it’s the developers who decide whether the solution is safe to use on no-script sites or not. Partly that’s understandable, because they know whether the solution they’ve built requires loading arbitrary scripts or not. What the problem is, is that this setting is not enforced. Sure, when it’s set to true, the component won’t work on no-script sites. But when the web part allows users to embed arbitrary scripts but its manifest states that it doesn’t require custom script, it will work just fine even on sites with custom script disabled!

Ideally, the requiresCustomScript setting should be a binding contract, similarly to permissions in SharePoint add-ins. An add-in lists in its manifest permissions it needs to perform specific operations using the SharePoint API. When operating, it is only allowed to perform operations granted by the requested permissions. Similarly, if a SharePoint Framework component says it doesn’t allow executing arbitrary scripts, any attempt to do so, should fail. Unfortunately, this is hard if not impossible to enforce, because SharePoint Framework components run as a part of the page without any execution container around them.

Trust but verify

The only way to tell, if a solution that states that it doesn’t require custom scripts to work, truly doesn’t allow users to embed them, is to review its code. This is tedious and inconvenient but required, if you don’t want to expose your organizational information to risks.

The need to review any code before deploying it to SharePoint hasn’t really changed over all these years. One could even argue, that nowadays, where using third party JavaScript libraries and scripts is so common, it’s necessary more than ever.

Photo by James Sutton on Unsplash