The New SharePoint Online Content Security Policy Breaks Customizations

Previously, SharePoint Online did not strictly enforce CSP restrictions that would affect customizations using inline scripts or external script references. Microsoft is now aligning SharePoint with modern web security practices and is gradually rolling out a stricter Content Security Policy across SharePoint Online environments. This is a good thing. With a properly configured CSP, the browser refuses to execute injected scripts originating from untrusted sources.

Initially, SharePoint’s new CSP operated only in reporting mode, logging violations without enforcing them. However, on March 1, 2026, Microsoft began switching SharePoint Online tenants from reporting-only mode to full enforcement, which in practice blocks the execution of all scripts that violate the new CSP.

While Microsoft’s goal is purely to improve the security of SharePoint Online environments, the change has come as an unpleasant surprise to many. Organizations that built their customizations on external script references and inline scripts—often added via the open-source Script Editor web part—have been caught off guard. The policy prevents such scripts from running and therefore breaks these customizations entirely.

If you work in an organization that has just realized that the new Content Security Policy has broken its SharePoint Online customizations, this blog post is for you. We’ll walk through solution options that can be implemented quickly in the short term and properly in the long term.

As a temporary workaround that gives you extra time to implement a long-term solution, you can postpone the activation of the new CSP using the script below. This immediately restores functionality to customizations broken by the security policy. However, activation can only be postponed until June 1, 2026. After that date (or preferably well before it), you must have a long-term solution in place.

See the script in the PDF file.

The second-fastest way to restore original functionality requires two relatively small changes. Both, however, involve potential security risks that you must understand and formally accept if you choose this path.

Adding external script domains to the Trusted Script Sources list

If a SharePoint customization depends on a script hosted on an external domain, you can make that script work again by adding the domain to the Trusted Script Sources list. Adding a third-party domain to this list introduces the following security risk:

The referenced JavaScript file hosted on a third-party domain may change in the future and begin to contain a vulnerability or even malicious code. This can happen, for example, if the third party is compromised. When the referenced JavaScript file is modified to include a vulnerability or an attack, the malicious code is loaded and executed in your SharePoint environment as soon as a user opens a page that references the file.

By adding a third-party domain to the Trusted Script Sources list, you are effectively placing full trust in that domain owner’s security practices and release processes. If their systems are breached, your SharePoint environment is next in line. For this reason, you should only add script sources to the Trusted Script Sources list when you fully control the content of those scripts and their update process.

If your customization currently relies on a script hosted on a third-party domain, it is recommended that you at least take a copy of the script (and verify that it contains no security vulnerabilities), host it either on the Microsoft 365 CDN or on your own externally managed CDN (for example, in Azure), and update the script reference to point to the version stored on that CDN. This way, only users in your organization who have access to the CDN can update the script.

If you choose to store a security-reviewed version of the script on an external CDN, you can add your CDN domain to the Trusted Script Sources list as follows:

1. Go to the SharePoint Online Admin Center

2. Open Advanced and select Script sources

3. Add your external CDN domain as a new trusted script source

Using the latest version of the React Script Editor web part

If you have used the open-source Script Editor web part to add customizations to SharePoint Online pages, you may have noticed that those customizations are now broken as well. At least for the time being, inline scripts can be made to work again by installing the latest version of the React Script Editor web part.

The latest version includes a change that bypasses SharePoint’s CSP restrictions by using the Function constructor. This works because SharePoint’s current CSP configuration includes the unsafe-eval directive, which allows the use of eval() and the Function() constructor.

However, this is not something you should build a long-term customization strategy on. If Microsoft decides in the future to remove the unsafe-eval directive from SharePoint’s CSP headers (which would be a perfectly reasonable security-hardening measure), this workaround will stop working immediately. You can read more about CSP headers and directives in MDN’s official documentation.

In addition to the business continuity risk mentioned above, using the Script Editor web part also involves the following security risk:

Anyone with permissions to edit a SharePoint page can attach arbitrary JavaScript code to it. This does not require a compromised account. A well-meaning content author might embed a seemingly useful snippet of code found online without understanding its security implications, inadvertently exposing users to a vulnerability.

And not all threat actors are external. While we generally want to trust our colleagues completely, organizations are made up of people who face complex situations and emotions. Organizational changes or layoffs, for example, can lead to frustration and questionable decisions. A malicious insider with page editing rights and access to the Script Editor web part can cause significant damage. You can read more about insider threats in the blog post Insider Risks and Threats – the Blind Spot of Cybersecurity?

A secure, modern, and Microsoft-recommended approach is to implement customizations as SharePoint Framework (SPFx) solutions.

Instead of injecting scripts into modern SharePoint pages, you create a properly packaged SPFx web part or extension. The code is reviewed, versioned, packaged, and then deployed to the tenant via the SharePoint App Catalog. This aligns with modern software development best practices and works naturally within the boundaries defined by SharePoint’s new Content Security Policy.

If the previous implementation relied on external JavaScript libraries, it is still possible to reference those scripts in SPFx solutions after first moving them to the Microsoft 365 CDN or the organization’s own CDN. However, it is recommended to reassess whether those dependencies are still necessary or whether the functionality can be implemented directly within the SPFx solution using modern libraries.

Moving from external script references and content-author–added inline scripts to proper SPFx solutions brings several benefits:

• Clearly organized source code that is easy to read

• Proper version control and code review processes, which are typically missing from ad hoc code snippets injected into pages

• A clear deployment and versioning model

• A more reliable way to manage applications and their associated permissions

• Alignment with Microsoft’s long-term roadmap

Yes, this requires more effort than simply adding a script to a page. But it also dramatically reduces security risks and the likelihood that your solution will break the next time Microsoft improves SharePoint’s security.

As I’ve reviewed these now-broken, decade-old implementations and considered the best way to fix them, I’ve encountered cases where a browser-based solution communicates directly with an external API using an API key. Because the API communication happens in browser-executed code, the API key (which is effectively a password) is visible to all SharePoint users who know where to look.

Secrets like these often have far broader permissions than a typical user—frequently full read and write access to all data in a system. For this reason, API keys and application secrets should always be stored securely and never included in browser-executed code.

To keep API keys and other secrets safely outside browser-executed code, you must implement a separate server-side solution. This typically means an Azure Function App or an Azure App Service secured with Entra ID authentication. The SharePoint Framework solution then communicates with the Azure application, which in turn communicates with the external API. The API key can be stored in Azure Key Vault and retrieved by the server-side code using the Azure application’s managed identity.

I could go on about this topic indefinitely, so it’s probably best to stop here and cover it in more depth in a separate post. Let this section serve as a small reminder that shortcuts should not be taken here either when it comes to application security.

In short, your path from a broken customization to a best-practice solution will likely include the following steps:

If your customizations are already broken and you are still able to postpone CSP enforcement (before June), you can “fix” the broken functionality quickly with a PowerShell script. This is a temporary fix that gives you time to implement a long-term solution.

If postponing CSP enforcement is no longer possible (from June onward), the second-fastest way to restore functionality is to add external script references to the Trusted Script Sources list and/or install the latest version of the React Script Editor web part, which includes a workaround for running inline scripts. Due to the associated security risks, these approaches should only be used as temporary workarounds.

To follow best practices and ensure the highest possible level of security, you should build a SharePoint Framework solution that implements the previous customization logic in a modern and secure way.

If you need help with SharePoint Online solutions, don’t hesitate to get in touch with us!