When you create a new SharePoint Framework project, npm warns you of over 250+ vulnerabilities. Should you be worried?
SharePoint Framework is a new development model for extending SharePoint. There are a number of differences between the SharePoint Framework and other SharePoint development models available to-date, one of which is the fact that the SharePoint Framework uses Node.js-based toolchain.
Node.js has been steadily gaining popularity over the last few years. It’s being used for a wide-range of scenarios: from building web applications with server-side code to command-line utilities. Packages distributed via npm include both code that runs on the server as well as client-side frameworks such as Angular or React.
There are over 800.000 ready-to-use packages available on the Internet that developers can use in their solutions to solve common problems, and focus on the unique scenarios of their solution. They vary from simple utilities with a few lines of code to complete frameworks such as Angular or React.
But as more and more applications are built using npm packages, they’re becoming more of a target for hackers to exploit their vulnerabilities and gain access to sensitive information. New vulnerabilities in Node.js packages are reported every day, exposing your application to new security risks.
To raise awareness of security issues and help developers make an educated choice about handling them, the latest version of npm performs an audit each time you install dependencies.
For a newly created SharePoint Framework project, the npm audit will return over 250+ vulnerabilities. It seems a lot, but is it, and should you be concerned? There are a number of misconceptions in the community about what these vulnerabilities are and how they should be handled. Here are a few of them.
When you create a new project, you haven’t added a single dependency. And yet, npm reports over 250 vulnerabilities. Because at this stage all dependencies are related to the SharePoint Framework tooling, and you could assume that Microsoft reviewed all these packages and the reported vulnerabilities are harmless.
But that assumption would be wrong. Nowhere in the documentation, does Microsoft state that they did a security audit of all the dependencies they use in the SharePoint Framework tooling. In its toolchain, SharePoint Framework uses many open-source packages that are not owned or even managed by Microsoft. What’s more, new vulnerabilities are discovered every day, so unless Microsoft was continuously auditing their dependency tree, the audit would have limited value.
That is correct, but unfortunately, it doesn’t mean that the vulnerability is irrelevant. Recently, one of the babel packages was hacked and would exfiltrate the contents of .npmrc files stored on your computer. .npmrc files contain access tokens to private npm registries which could be used to steal your intellectual property or hack your packages. So even if you wouldn’t include babel in the generated bundle, it still poses a big risk that you should mitigate immediately.
When it comes to dealing with reported vulnerabilities, you need to consider what the vulnerability allows attackers to do and whether that attack vector is relevant to how you use the package (tooling vs. production). For example, a regex DDoS vulnerability in SPFx toolchain is unlikely to be exploited and is a risk that you could decide to accept given its low probability.
Just because the npm audit reports a vulnerability, it doesn’t mean you have to fix it. Like with any risk, it’s perfectly fine to accept it, if it doesn’t apply to you or if you’re willing to live with it. Every day, we go out on the street and commute. It’s not entirely risk-free, but we choose to accept the risks. The same applies to vulnerabilities reported for SharePoint Framework projects. If the vulnerability doesn’t apply to how you use the particular package or if the risk has low impact and fixing it exceeds the potential loss, you could decide to accept it. The key point is that you need to understand the risks and their impact first before you can make an educated choice.
What if there is a vulnerability in one of the underlying dependencies that pose a risk that you want to mitigate? You could try following the instructions provided by `npm audit`. It could work, but it could also break the project. It depends on the package and the vulnerability. Unfortunately, there is no easy answer for it. If it doesn’t work, you might want to resort to other means, like reaching out to Microsoft (if the package is a part of their toolchain), the owner of the package or you could try to use a previous version of the SharePoint Framework which might not have that vulnerability.
Yes, so is minifying your code. Do you do it manually? No, you have tools for that. Similarly, there are tools available that help you review and manage vulnerabilities efficiently so that you can focus on building your solution without compromising on its security.
Ignoring the warnings and blindly trusting that everything will be fine is not a wise decision. What will you say when one of them gets exploited? (ignoring the warnings because there were too many of them?) – how would that make you sound?
Unfortunately not. Just because you haven’t changed your dependencies or you’re using a lockfile, doesn’t mean your code is safe forever. New vulnerabilities are discovered every day, and you should regularly audit your solution and its dependencies to determine if there are any new vulnerabilities.
You hear more about Node.js packages vulnerabilities because of their wide adoption. But the same problems apply to all third-party code you use in your solutions. Even a small widget showing the weather, or a JavaScript library you load from a CDN, could exfiltrate confidential information from your SharePoint tenant.
We highly recommend that you run our free SharePoint Applications Health Check App which discovers all applications running in your SharePoint environment.
It doesn’t matter if you’re using a third-party npm package, NuGet package or a piece of script. If it’s something you don’t know, you should review it, before using it in your solution that will be deployed to SharePoint where your sensitive data and personal information is stored.
You can be “pragmatic” and choose to ignore the vulnerabilities. You can assume that someone else will review the packages. You can assume that nothing bad will happen because nothing bad happened so far. You can assume that if 500.000 other developers use the package, it’s safe because someone else reviewed the code.
There is nothing pragmatic about ignorance. Avoiding security risks takes effort. You can dismiss the warnings and hope for the best. If you’re willing to accept the risks without even knowing what they are, that’s your decision. No matter if you decide to make the effort or not, decide consciously and be aware of the consequences.
You don’t need to panic and you shouldn’t get paralyzed by the sheer number of vulnerabilities reported on SharePoint Framework projects. Create a plan to address them, and follow it.
It all starts with understanding what vulnerabilities are reported. Only then will you be able to make an educated choice about what is relevant and what is not. For the relevant vulnerabilities, the next step is to determine the impact. If it exceeds the possible loss, it’s perfectly fine to accept the risk. Just because npm reports 250+ vulnerabilities, it doesn’t mean you have to fix all of them. Address what needs to be addressed, nothing more. Focus on building your solution and solving your business problems. And keep in mind, that just because you audited your solution once, it isn’t safe forever. New vulnerabilities are discovered every day. Stay safe.
Authored by Microsoft MVPs Waldek Mastykarz and Erwin van Hunen, this free whitepaper provides a comprehensive guide on how administrators can deal with SharePoint Framework to maximize the security of SharePoint and Office 365 environments.