In the past, developers would build code, and most code that went through a package would be self-written. Maybe, at some point, there would be an exception, and you would reuse something like UI controls from Telerik, DevExpress, etc. But much of the code would be self-written.
Nowadays, it is no longer the case. There is so much out there, and SPFx uses the same web development approach as any other kind of modern web app. SPFx is based on a Node.js base stack with NPM, and you can easily tap into more than one million packages on NPM, adding them to applications and speeding up development.
Other blogs in this series:
- Farm solutions vs. SharePoint Framework (SPFx)
- SharePoint Framework challenges – part 1 (this blog)
- SharePoint Framework challenges – part 2
- Manual vs Automatic SPFx package analysis
Why reinvent the wheel – vulnerable dependencies
At first glance, this “new” development approach seems convenient. Just pull in packages from building charts to exploring 3D objects, which are readily available for you to use, and you can start building things that are specific to your company or a customer. You could focus on the specific things that you need. There would be no reason to reinvent the wheel.
However, this approach comes with a trade-off. Different people all over the world build libraries, and the more they are used, the higher chance someone can find a weakness within the library – an issue that could be exploited, which can expose you to risk.
In other words, code that speeds up development comes with a price that leaves your organization exposed. When building solutions, you shouldn’t blindly trust code pulled in from the internet when you cannot validate its creation. That code will run as a part of your corporate intranet where you store confidential data, where you might store HR records, as an example.
In fact, the code will be able to access any kind of information stored in your tenant on behalf of the person who is currently visiting the page. So, if that person is C-level or a HR manager, they have highly privileged access across the whole intranet. Here’s an easy example how this can happen.
SharePoint web part examples
If you build a SharePoint web part showing the weather, you probably wouldn’t build it yourself because you don’t have forecast services. Consequently, you would pull in a library that calls the weather service and integrate it into your web part, then apply some styles to align it with everything else on your page.
However, you would have a third-party piece of code that runs as an integral part of your page, and then that code could do anything. If you don’t pay attention, and somebody puts something malicious in the code, you wouldn’t know unless you validate that the code is solid, safe, and there is no way to exploit it.
How often do you analyze dependencies
In my recent webinar, I ran a poll on how often the participants checked their code. The answers were interesting. The point was to understand how often we investigate code – is it on the top of our mind – is it something we do as an afterthought? Maybe, we don’t do it at all. We might just trust J query because it’s used by such a big audience.
The majority of participants did not look into dependencies, and that’s a shame as I deem dependencies as the biggest threat. Let’s dig even deeper.
Global Permissions
Whenever you build with SPFx, the scripts by default become an integral part of the page. If you did things in the past with add-ins, you were able to build an add-in part, and that add-in part was an Iframe pointing to your page located on a different domain or URL. In essence, you have a sandbox environment. If you had malicious code in your script, it couldn’t escape the Iframe.
This is no longer the case in SPFx.
SPFx doesn’t run inside an Iframe – it runs as part of the page; it can access any rest call to any rest API or even see some API that isn’t part of your intranet. Let that sink in for a second. It has access to search across the whole tenant. It has access to all your files, documents, permissions, taxonomy, user profiles, to name a few. Anything the person on the page is allowed to do, that script can do too.
SharePoint web part example permissions
In SPFx, we can request permissions to other APIs. Companies often have personal information like upcoming appointments on the intranet landing page. This would come from my calendar on exchange. So, the SharePoint web part I would build in SPFx, by default, cannot do that. However, I can configure the web part to request permissions to Microsoft Graph, and then specifically to my calendar, or calendar of any user in the company.
If I grant that permission, it is not specific to my web part, but any piece of JavaScript running in my tenant because my web part runs as part of the page. All these scripts could read your email, your calendar, and more because you globally granted permissions to APIs. There is a way to isolate it, but it’s an explicit choice that comes with some limitations, for example, it only works with web parts and not with extensions.
Therefore, you must think about how you can properly grant permissions, but also what the dependencies are within and outside your tenant.
The solution
It is possible to manually assess code, but in practice, it falls short because it doesn’t scale, is very time-consuming, and it very much depends on the experience of the individual.
I personally advocate Rencore’s SPCAF software. It is the only solution on the market that analyzes and assures your SharePoint code quality and visualizes the dependencies of code artifacts within applications between SharePoint, Office 365, and external components.
If you would like to see a short 1-minute walk-through video of SPCAF, please head to the SPCAF product page by clicking the button below.
Can you think of any other challenges regarding SPFx? Please leave a comment below.
