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 :


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.


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

3 thoughts on “Be Careful with SharePoint Framework”

  1. While this post replays the historical fears of open source software it’s very misleading. Modern SharePoint sites where the framework is used are no script sites by default. This means users CAN NOT upload html or aspx pages that are browsable and there is not script editor webpart where users can add JavaScript to the page, and SharePoint designer is not supported.

    Only an admin can add JavaScript by installing packages into the app catalog making this the most secure SharePoint ever.

    Unlike previous development models there isn’t the ability to elevate permissions to run as the system. Code executed by a user is always running as that user and results are security trimmed to what that user can see.

    In the previous farm solution framework, customer code ran in the same process as the web server and SharePoint. This means your farm solutions could take on the servers identify and cause issues or even take out the server as many badly coded SharePoint solutions did in the old days.

    Any customization should be well considered based upon the positive business impact vs the long term cost to design, build, and support the code but SharePoint framework and the modern no script sites requiring admin approval of JavaScript greatly reduce the risk to organizations vs all other alternative customization paths.

    • Thanks for the detailed comments Dave and i’ll try to elaborate more and hopefully you will be able agree with what is being said.

      First of all most SharePoint Online tenants are in a transition period between classic and modern sites. That is, they have built their SharePoint Online environment based on the “classic way” of building stuff, most often requiring script enabled sites.

      Now a question regarding transition to Modern Sites without these scripting capabilities.

      Should they just add the new modern Script Editor Web Part or should they turn of scripting for all sites?

      If they turn this off I can almost guarantee that a lot of these sites will be useless. In case they are using any vendor based Intranet on SharePoint then it will be much more troublesome. Practical approach tells us that its not going to be smooth transition for most companies because a lot cannot be done in Modern Sites when compared to Classic Site and sadly addressing this has been ignored.

      – Custom page layouts or master pages are not supported in modern team sites, neither you can use classic seattle.master or oslo.master master pages in modern team sites.
      – As you mentioned in your comment, we cannot embed custom JavaScript or custom actions in modern team sites.
      – Sandboxed solutions are not supported.
      – You can not open SharePoint online modern team site using SharePoint designer 2013.
      – Some of the popular web parts are not available in modern team sites for end users.

      Nearly everyone I have spoken to on the forums or in real life has told me that they have done customizations on Classic team Sites and its not possible to convert to Modern Sites at the moment. It increases the risk and it would be a good idea to revisit the scripts running on your sites and that was my point in the blog post.

      Secondly regarding SP Framework i agree with you to a certain level but i disagree with the approach of “Its all safe now”. I think a lot needs to be addressed. The Script Editor Web Part does not exist in modern SharePoint, i agree and the whole idea with modern SharePoint and SPFx is that we (admins/editors) should have a controlled and managed way to add customizations to a site – and of course SEWP is on a collision course with that. Having that option would violate the whole idea.

      The whole issue is that there is now a “MODERN” version of the Script Editor Web Part available as a part of the SharePoint Patterns and Practices samples repository. This solution is bypassing the whole idea of SharePoint Framework – controlled and governed JavaScript in SharePoint Online. And of course this is being used by a lot of users/tenants – since it’s simple and it works.

      – Script editor web part for modern pages built in React

      I would suggest you to play with and see for yourself how it bypasses everything which they are trying to implement through Modern Sites. I will soon write my findings in a blog post and i am getting more and more concerned about the security.


Leave a Reply