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?
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.
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