Classic versus SharePoint Framework Customization
Over the past few years, a topic that comes up more and more is whether these customization and development approaches within SharePoint are safe. I, myself have built Managed Code and Sandbox solutions, as well as client-side solutions both as scripts, or as part of a controlled and managed deployment such as the SharePoint Framework. Being out in the field as a consultant for best part of 15 years, over multiple versions of SharePoint, clients will create the customization they need in whatever way is easiest and fastest. Honestly, there are not many that go through a full-lifecycle of testing and controlled security review at all.
For instance, years ago I wrote the “Helloitsliam Claims Viewer Web Part” which is a managed code solution (WSP), that you deploy to the SharePoint Farm, and allows you to see the claims attributes, etc. during an Authentication process. This web part was needed, and I used it a lot. What I didn’t realize though was how many Administrators installed it into their Production SharePoint Farms. I would ask the question of whether they checked it and of course, the answer was no most of the time.
Surely “Liam” would not write bad, suspicious or malicious code? I will leave you to decide that
So, let’s go back to the issue at hand. Over the past year, Microsoft has done its best to try and discourage using the “Classic” SharePoint User Interface along with the “Classic” way of customization. Modern is a new way, limited access to modify the pages, etc. and a more controlled approach to customization. Surely this is what you should be using right now?
Why are you still using “Classic” customization approaches?
Three words: Quick, Simple and Easy. That does not make it right though.
While working with different organizations, there are those that adopt the new and those that don’t. I have worked with organizations that have tried to move to the new “Modern” way and have just not been successful, simply down to it not all working that way yet. The biggest complaint has been that not everything is in the modern design and does not support the modern design principles, or further it just doesn’t support what is needed by the organization. Whether this works or not, is out of our hands. Microsoft is actively working on. With the release of the Patterns and Practices components such as the starter kit, we are slowly moving closer to the true “Modern” experience.
Why should I use SharePoint Framework?
The real answer is “Microsoft” wants and needs you too, and it is not a bad thing either. Microsoft’s goal has always been to provide a platform or service that has the best Service Level Agreement (SLA), one that means if you customize the system it does not just break. Running Office 365 has taught Microsoft lots of things about what “we” as the normal users do to SharePoint and why it breaks. This information has pushed them to make decisions about what should and should not be allowed. Microsoft isn’t just deprecating something because they want to stop customization or annoy us, it is about creating a more stable and capable platform.
Will SharePoint Framework fix all the Security problems?
The short answer is “No” the long answer is “Yes” and “Maybe”
Running this within the Firefox web console and then watching Task Manager you can see what I mean. The function keeps reloading the page as long as “1 = 1” which it does, which causes the browser to lock, memory to grow and CPU to keep spiking. Imagine this code hidden within a SharePoint Framework Component or even a script editor web part for that. That would be a fun support ticket to try and figure out, with the browser crashing everytime you got there.
Using SharePoint Framework, with the centralized deployment and management, would hopefully find this code, as it would get reviewed before deployment. If not, then let me know, and I am sure we can work something out…..just kidding
SharePoint Framework by itself using rules to validate the functional code structure, ensuring that checks get ran. However, the “tslint” rules which control the structure do not highlight these types of issues. A manual review is needed or use of a tool such as the tools created by the Rencore Team (shameless I know).
What is nice though within the SharePoint Framework, is the ability to load other modules into the projects that can check for security issues. As a side note, when you run an “npm install” command, it will output the vulnerabilities for the various installed packages as it also runs “npm audit“. If you then use the “npm audit fix” it will probably break the SharePoint Framework project due to dependencies breaking.
You can, however, run “npm audit” manually to see the results, as well as outputting a “JSON” file for review later using this “npm audit –json > security.json.”
The tooling allows you to manually make fixes needed for any of the dependencies, or even add in other “npm” packages that can perform security checks on the code. Basic Security checks run within a SharePoint Framework solution as well. An example of this could be the use of “Eval().”
Upon finding an instance of “Eval()” the “jshint” plugin provides further details of the code block.
This simple check goes much further than anything you can do with end-user scripts added to a script editor web part. Even just this, being notified when looking at the code, of what is good and bad is 100% better than arbitrary script added to a page, with an end-user being expected to know what the code completely does.
How do I tell my end-users they can’t add scripts anymore?
From my experience end-users only make these changes because they need to perform some action that doesn’t exist or don’t know another way. I have also seen end-users make these changes because there are no developer resources available. Changing the approach may cause an issue, removing their ability to create what they need when they need, to now a dependency on a developer plus a process of checks and deployment. Honestly, there is no magical answer, but more to explain and then manage.
For me, the SharePoint Framework is the next evolutionary step in building customizations. It offers a much better approach to management and control, as well as flexibility in developing solutions. Combine this with moving from “Classic” to “Modern” user experience then you have reduced the surface area of customization drastically, reducing not only that, but the support calls you may get.
Call to action
I highly recommend the following tasks:
Check your existing SharePoint or SharePoint Online solution for customizations.
Review any existing customizations.
Perform migration planning to move them from classic to modern customizations.
Migrate the user interface to “Modern” versus “Classic.“
I am not advocating you do all of these in one go, but prioritize each one, and plan the updates and move in conjunction with working with your business users.
Shameless Suggestion: To help you, take a look at the “Analysis Cloud” service provided by Rencore, it can make lite work of finding those end-user customizations.