How often do you scan your SharePoint applications for vulnerabilities?

You should be scanning your SharePoint applications for vulnerabilities even when their code hasn’t changed. Here is why.

Other blogs in this series:

• Assess what’s in your SharePoint environment
• The dark side of SharePoint applications
• The business impact of your SharePoint applications
• 3 tips for efficiently handling alerts about your SharePoint applications
• How often do you scan your SharePoint applications for vulnerabilities? (this blog)

Modern vulnerabilities

Back in the days, when we were building SharePoint applications, we used primarily .NET with little to no third-party libraries. All the code that was running in production was our own. Sure, it probably wasn’t 100% secure but there was little risk of it getting exploited in the context of a SharePoint intranet available only inside your organization.

SharePoint applications we build today are nothing like the applications we built in the past. SharePoint Framework, the development model recommended to extend SharePoint, uses Node.js-based toolchain and produces solutions that consist of 100% client-side code. And when building these solutions, developers can choose out of over 1 million libraries to speed up their work and focus on solving business problems. But this convenience comes at a price. New vulnerabilities in these libraries are being discovered every day. So what are the chances that one of your applications uses a library with a known vulnerability exposing your organization to risks?

Exploiting SharePoint

Imagine that one of your applications was loading a third-party library with an exploit targeting SharePoint specifically. What could it do?

First of all, all of the JavaScript loaded by SharePoint applications runs in the context of the page. As such, it has unrestricted access to SharePoint. Whatever the user currently visiting the page is able to do, the script can do as well. If it’s a regular person, the script can probably do little harm. But what if the user is an admin or a CEO? The script could do anything from searching for and leaking confidential documents to changing permissions. And there is nothing you can do to stop it.

If you’re building solutions using the SharePoint Framework, an exploited package could also have access to your computer and could steal data from it.

It sounds severe, doesn’t it? So what should you do?

Scanning for vulnerabilities with a pinch of SharePoint

New vulnerabilities are being discovered every day. The good news is, that the information about them is available publicly and you can use them to verify if your SharePoint applications are affected or not. The bad news? While there are many solutions available on the market that scan applications for vulnerabilities, they typically don’t have the notion of a SharePoint application. They don’t know all the different ways how a piece of script can be referenced or embedded in a SharePoint application. As such, they might find no issues, giving you a false sense of security.

What you need instead is something that understands SharePoint and all the different types of applications that can be built for it. This solution must have an up-to-date database of vulnerabilities refreshed at least daily. Finally, you have to set it up in such a way, that your applications are scanned every day. Because even if your code hasn’t changed, one of the referenced dependencies could now contain a vulnerability.

One more thing

There is one more thing you should consider when thinking about protecting your organization from vulnerabilities in SharePoint and Office 365. Developers are not the only audience that can build applications that reference scripts. For years power-users could embed scripts on pages using the Script- and Content Editor Web Parts. These scripts are also capable of loading third-party libraries that could contain vulnerabilities. So when looking for a solution that would scan for vulnerabilities, it should not only be able to scan application packages that you know of, but also your whole SharePoint environment for applications that have been built by end-users and could expose you to risks nonetheless.

We’d love to help you find a solution suitable for your organization.