Be Careful with SharePoint Framework

​Yes the heading says it all and i literally mean it. I am actually getting more and more concerned where we are blindly heading with SharePoint Framework without any strategy and common sense. Since its availability it has been released with a number of new versions and i am not sure for how long the developers can keep up with new features and new scenarios. Can we really always use the latest version of SharePoint Framework and keep on changing stuff we have developed? Well this post is all about what needs to be considered, analyzed and thoroughly digested before jumping to new releases.

Which Version – The Risks

​Both versions, SharePoint On Premise and Online can be used with SharePoint Framework but with on premise the story is very different. SharePoint On Premise currently has only one version of framework which makes it easy to control through patch updates at farm level. I am not sure if Microsoft will release more versions for On Premise also – i hope they release them with some intervals rather then frequent monthly updates. On the other side SharePoint Online continously recieves updates and though they are compatable with older versions still you do get some nasty surprises.

Since the framework uses a toolchain with dependency tree and also third party inherent using Node based development stack – if you update one package then it could trigger updates on other packages. This can be a pain if it turns out uncompatible with other packages in your solution. I haven’t come across much people who have given me a valid reason for updating the solution to latest framework and in most cases i have seen people try to fix messed projects.

Know the SharePoint Framework Solution before Deploying

​SharePoint Framework solution only contains JavaScript code which runs on the browser and they are deployed through the app catalog just like SharePoint Add-ins but we must always remember that they run unrestricted. This means, SharePoint framework solutions have unrestricted access to the information and APIs in your tenant – wherever the user has access so does the solution. Make sure all the documentation and details you have received with the solution are up to date and take the liberty of verifying it as i am sure you will find some stuff missing from it. Depending on the nature of your solution and organizational requirements you might have to adjust or change the deployment of the solution on certain sites. There are so many JavaScripts libraries available on the internet, that developers can use in their solutions. While using an existing library enhances developer productivity, it comes with issues and risks for the organization using the solution. Another aspect is to know if anyone else in your company is familiar with the specific Java Script library and if so then how long do you think this library will exists?

• Where is it hosted and where is the server?
• Are all webparts working correctly?
• Who has access to files and can they be changed?
• Whats our agreement with the vendor? etc.

Usually when you deploy the package to your app catalog, these scripts will be copied to a document library in your tenant. 

Developers can specify if the solution requires access to resources with Azure AD and they can use Microsoft APIs or any other third party application being run in the organization. If the solution does not specifically request for access to API then it does not mean its not using them. Please remember permissions granted means, allowing the 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. ​One scenario which i have come across is regarding scripts which were not included in the solution package by the developers. Meaning, its hosted somewhere else and this leads to a number of additional questions. 

Some more point which i feel we should emphasize is to know:

• Where does the solution load its JavaScript libraries? ​

• 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?

• 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?

• ​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?​

Office 365 CDN and SharePoint Framework – CLIENTSIDEASSETS

​If you have the Office 365 CDN enabled in your tenant, files deployed from SharePoint Framework packages, will be automatically served from the CDN, which simplifies the deployment steps even further. By default, the Office 365 CDN is disabled. You can easily enable it using the Office 365 CLI or the SharePoint Online Management Shell.

o365 spo cdn set –enabled true

To see the available origins using the CLI, execute:

o365 spo cdn origin list

SharePoint will create :

• */MASTERPAGE
• */STYLE LIBRARY
• */CLIENTSIDEASSETS

Now at times, for some reason the */CLIENTSIDEASSETS origin is not configured, you won’t be able to use your SharePoint Framework solutions. Amazingly you will never be prompted for any errors and left wondering why you are unable to add a client side web part.  So how to fix it?

To add it using the CLI, execute:

o365 spo cdn origin add –origin */CLIENTSIDEASSETS

SharePoint Framework relies on static assets and optimizing how they are loaded, can help you significantly improve the performance of your application.

Level of Access with JavaScript in SharePoint Framework

With a few lines of code to connect to SharePoint APIs you can do the following and much more – it should be enough to raise some eyebrows:
​

• 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

Customizations and JavaScript

While JavaScript brings in easy to customization options for SharePoint client side technologies but it also involves some factors which are very easily over looked for the sake of empowering organizations to quickly respond to changing business needs. 

​Your users can easily place web parts on different pages and each of these JavaScripts have unrestricted access to all the information on your intranet. Now  imagine how many sites you have and are you really keeping track of all the changes happening to these web parts? This is a serious nature of breach and risk which needs to be thought and addressed. 

I agree that SharePoint allows us to built some very powerful solutions but at the same time the same API layer can be easily used to extract the information from your tenant and also each piece of JavaScript that runs on pages you visit having the same rights to manage sites, lists or permissions, etc.

RISKS

• You can easily load unverified solution on your production tenant without admin’s approval.

• The ability to load debug versions of SharePoint Framework solutions in production tenants should be constrained.

• Trick an end-user into executing a malicious piece of code.

Share your concern with Microsoft to address these fundamental fill in the blanks because not everyone is following 100% processes for implementing or maintaining SharePoint Framework based solutions. Proliferation of JavaScript libraries and the flexibility the SharePoint Framework offers developers, deploying a customization in your tenant introduces a number of risks. Unrestricted access to content and APIs in your tenant, you should review them carefully before deploying them in your tenant.