By default, modern SharePoint sites don’t allow embedding scripts, and it’s for a reason.
Where everything is a site collection
Every day your colleagues create tens if not hundreds of new site collections. When they need a place to collaborate, they get a site collection. When they need a place to keep the rest of the organization up-to-date, they get a site collection as well. When they create an Office 365 Group, they get a SharePoint site collection too. Site collections are the new default in Office 365.
When users create a modern site collection, by default it doesn’t allow them to embed scripts, and this is very important. Because the IT no longer controls the process of creating site collections, disallowing users to embed arbitrary scripts by default, allows the IT to lower the security risks for data stored in SharePoint.
The problem with arbitrary scripts
At this moment, there is no standard web part for embedding arbitrary scripts in modern SharePoint sites. In classic sites users can use the Script- and Content Editor Web Parts to embed scripts. But to embed scripts in modern sites, organizations need to defer to third party solutions or build something themselves. And this is for a reason.
From the end-user point of view, embedding scripts using the Script- and Content Editor Web Part was a great idea. It empowered end-users to put together powerful solutions without the involvement of the IT: from simple widgets showing the weather to complete applications supporting business processes.
But over the course of years, organizations experienced first-hand their share of problems related to arbitrary scripts. The IT would get support issues related to application they knew nothing about. Looking closer at these applications, they would realize that they were hosted outside the organization circumventing all security measures and having unrestricted access to the data in SharePoint on behalf of the current user. What’s even worse, is that there is no easy way for them to tell how many more of these applications are scattered over their SharePoint environment and what they do exactly.
In the past, organizations had a handful of site collections created and governed by the IT. Nowadays, this is no longer the case. So to prevent users from adding arbitrary scripts to pages, by default all modern site collections are no-script sites: sites that don’t allow embedding arbitrary scripts.
The no-script setting plays crucial role in helping organizations to protect their data from security risks. But to some, it’s an inconvenience that stands in the way of how they used to work. So they disable it, giving as a reason flexibility or a prerequisite for their solution.
Convenience but at what price
Organizations can extend capabilities of modern SharePoint sites using the SharePoint Framework. Each solution specifies if it allows users to embed arbitrary scripts and as such, if it requires the no-script setting to be disabled. No organization is the same and yours might have a valid use case for allowing users to embed scripts. But don’t let disabling the no-script setting be the default. Make it an exception and keep track where you’re applying it. Secure your organization’s data and don’t sacrifice it for a little bit of convenience.