When installing SharePoint Framework solutions, SharePoint shows you the URLs of external scripts used by the solution. But it doesn’t show all of them, so be careful what solutions you allow to run unrestricted in your tenant.
SharePoint Framework client-side solutions
Using SharePoint Framework, developers can extend SharePoint beyond what’s possible out of the box. Based on the market-standard toolchain, SharePoint Framework allows them to use their existing skills to add functionality to SharePoint. What separates SharePoint Framework from other SharePoint development models is the fact, that solutions built on it are fully client-side. While developers use TypeScript when building SharePoint Framework solutions, the framework toolchain compiles it to JavaScript that runs in any web browser.
The true power of the SharePoint Framework comes from the fact that developers can use literally thousands of libraries available on the internet, to build rich SharePoint customizations. These libraries vary from helpful utilities to ready-to-use solutions for connecting to line of business APIs. But there is more to it.
SharePoint Framework: benefit or risk
When you install SharePoint add-ins in your tenant, you explicitly grant them a specific set of permissions. Because add-ins are hosted on a separate domain, they cannot just call SharePoint directly. Instead, if the add-in is communicating with SharePoint client-side, it has to call a specific endpoint that will communicate with SharePoint on behalf of the add-in. If the add-in is provider-hosted, then its identity is included in the request which is verified by SharePoint against the granted permissions before performing any operation.
SharePoint Framework solutions on the other hand are a part of the page. With that, they get unrestricted access to the whole portal on behalf of the current user. Whatever the user can do, the SharePoint Framework solution can do too. If that user happens to be the administrator or the CEO, that’s pretty much everything: from changing permissions to accessing confidential documents.
New model but old problem
The risk of customizing SharePoint isn’t a new problem that’s specific to the SharePoint Framework. In the past, when we were using farm solutions, their code would run on the server and could elevate privileges beyond what the user was allowed to do. Even the SharePoint Framework can’t do that. What is new, is the increased popularity and simplified access to ready-to-use third-party JavaScript libraries.
Even before the release of the SharePoint Framework, users customizing SharePoint were embedding scripts and widgets from the internet on their company portal. Many of them were either totally unaware of the risks that introduces or were simply blindly trusting the script, because hundreds of other people use it. Think again: how can you know if the weather or stocks widgets, or even the news web part you pulled from GitHub don’t leak your confidential information and share it with a third party?
You get the power but also the responsibility
SharePoint Framework brings structure to client-side SharePoint customizations and gives the organization back the control over what code is running in their tenant. But it’s still an organizational responsibility to review the solution packages and their code before deploying them in production. Sure, it’s inconvenient and a lot of work, but without it, you’re gambling with the security and integrity of your organization’s data.
SharePoint Framework helps, a bit
When deploying SharePoint Framework solutions to the app catalog, SharePoint shows you the list of locations from which the solution loads scripts.
The information shown in this dialog is based on the manifests included in the solution package. What the dialog doesn’t show, are all other scripts that developers could load in code.
Using the SharePoint Framework API, developers could write:
SPComponentLoader.loadScript('https://random.cdn.com/random.script.min.js', (): void => {
// rest of the code
});
When the web part is loading on the page, the above line of code would download the script https://random.cdn.com/random.script.min.js and execute it as a part of the page.
Loading external scripts on runtime isn’t new and developers have been using it long before the release of the SharePoint Framework. The SharePoint dialog I showed you earlier, doesn’t report any of the scripts loaded in code on runtime. So is reviewing the code the only option to know what the solution is truly doing?
The risk is real
More and more organizations are investing in securing their data and implement measures varying from policies to enterprise-grade firewalls and intrusion detection systems. But as long as they allow random scripts to run on their intranet, they’re at risk. Using the rich SharePoint APIs these scripts can access personal and confidential information and share it with third parties without anyone knowing about it.
Reviewing the code is the only way to ensure that the third-party scripts you use in your solutions are safe. But that’s tedious and time-consuming, almost impossible you could say. Luckily, you don’t need to do it manually. Solutions such as SPCAF help you verify your SharePoint customizations and tell you in a matter if there are any risks such as any scripts running from a location you haven’t approved or a possible negative impact on the performance of your intranet.
Do trust your developers and solution providers, but verify their work. The security of your organization and its information is in your hands.
This blog post has been originally published on Waldek’s blog.
