The risk of easily testing SharePoint Framework web parts in your tenant
SharePoint Framework allows you to easily test the web parts you’re building in your production tenant without having to deploy them first. But are you okay with the risk it exposes your data to?
Ad-hoc customizations
For years we’ve been customizing SharePoint using client-side technologies. With nothing but a few lines of JavaScript and the Content Editor Web Part, we would build compelling business solutions.
Embedding scripts on pages is extremely powerful. It empowers organizations to quickly respond to the ever-changing business need without having to burden the internal IT. But it’s not without risks.
Many organizations allow regular users to place web parts on pages. As a result, very quickly the IT loses the track of what customizations are present on the intranet and what code is running where.
What can a piece of JavaScript do in your intranet
Each piece of JavaScript you put on a page has unrestricted access to all the information in your intranet that you can access. If you have access to a single site, it couldn’t do much harm. But if you happen to be the administrator of your tenant or the company CEO, things start to look more grim. Did you also know, that each piece of script can load other scripts and they could also access all information in your intranet on your behalf?
SharePoint has a rich API layer that allows us to build powerful solutions. But the same API layer can be easily used to extract the information from your tenant and share it freely with unprivileged third parties. Also, if you have the rights to manage sites, lists or permissions, so does each piece of JavaScript that runs on pages you visit.
Client-side development with governance, almost
SharePoint Framework strikes the balance between using client-side technologies to build powerful customizations and giving the organization insights into what customizations run in their tenant. Before they can be used, all SharePoint Framework solutions must be approved by app catalog administrator: either on the tenant- or site collection-level. With one exception…
Easily testing SharePoint Framework web parts
Recently, I wrote an article about how you can use one of the standard SharePoint Framework features to easily debug SharePoint Framework web parts on modern pages. This capability is invaluable if you have to verify that your web part works as expected in the full-width column or with other elements on the page.
Fellow-MVP, Elio Struyf, extended the idea of using this feature to debug your solution in production. Because the production-version of your solution is optimized, it lacks important details that allow you to find bugs in your code. Instead, without affecting other users, you could load a debug version of your web part on the page for yourself to see what’s wrong. I fully agree with Elio, that this capability is very helpful, but it has a side-effect I believe many of us don’t realize.
The risk of using the SharePoint Framework
SharePoint Framework is meant to give organizations the control over the client-side customizations they run in their tenant. Because these solutions have unrestricted access to all the information in the tenant on behalf of the current user, it’s important that organizations have the ability to verify the code, before deploying it to production. But as Elio illustrated, you can easily load unverified solution on your production tenant without admin’s approval!
The whole scenario is quite constrained and it’s unlikely that it could be used to trick an end-user into executing a malicious piece of code. But developers, who have the best intentions to test their new code against the production data and configuration, could unknowingly load unverified code on their tenant. This code could either access some information directly or install itself to be executed by highly-privileged users later.
Ideally, the ability to load debug versions of SharePoint Framework solutions in production tenants should be constrained. Tenant administrators should be able to explicitly enable it, accepting the possible risks it introduces. It would be also helpful, if the debug code was isolated in some way, so that it cannot freely reach out to APIs and resources on the intranet. For now, there is nothing you can do about it except to educate your fellow-developers of the possible risks of using this feature on your company portal and to share your concerns with Microsoft.
Photo by James Sutton on Unsplash