How to fix SharePoint Online customisations broken by the new Content Security Policy
Last updated on April 22, 2026
Content Security Policy (CSP) is a mechanism that specifies which resources (scripts, styles, etc.) a page is allowed to load and execute. Its purpose is to mitigate the impact of cross-site scripting (XSS) and similar client-side code injection attacks.
Previously, SharePoint Online did not strictly enforce CSP restrictions that would have impacted customisation patterns involving inline scripts or external script references. However, Microsoft is now aligning SharePoint with modern web security best practices and is progressively introducing a stricter content security policy for SharePoint Online environments. Hurray! This is a good thing. With a properly configured CSP, the browser refuses to execute injected scripts that originate from untrusted sources.
At first, the new SharePoint CSP was running in reporting mode, only logging those policy violations. However, starting the 1st of March, 2026, Microsoft began enforcing the policy in SharePoint Online tenants, effectively blocking all script execution that violates the new CSP.
Even though Microsoft only wishes to improve the security of its customers’ SharePoint Online environments, this change has also been an unpleasant surprise for many. The new security policy has caught many organisations, whose customisations rely on external script references and inline script blocks embedded in the open-source script editor web part, off guard. The policy prevents the execution of such scripts, thereby breaking those customisations entirely.
If you are working for or with an organisation that has woken up to its SharePoint Online customisations being broken thanks to the new content security policy, this blog post is for you. Here, we will take a look at the resolution options you can implement quickly for the short term and properly for the long term.
Table of Contents
- Temporary solution: disable the policy for a limited time
- The quick and easy longer term solution comes with security risks
- The recommended long term solution: SharePoint Framework
- Bonus: Remember to keep all secrets on server-side
- Conclusion
Temporary solution: disable the policy for a limited time
As a temporary workaround to buy yourself time to implement a long-term solution, you can postpone the activation of the new SharePoint content security policy with the script below. This will immediately restore the functionality of the customisations blocked by the policy. However, the activation can only be delayed until the 1st of June 2026. After that (or preferably, by then), you need to have a long-term solution in place.
The quick and easy longer term solution comes with security risks
The second-fastest way to restore the original functionality involves two relatively minor changes. However, both of these come with potential security risks you should be aware of and officially accept if you truly wish to tread down this path. Because if a breach happens and your organisation goes bankrupt as a result, you’ve got only yourself to blame.
Adding external script domains to the Trusted Script Sources list
If the SharePoint customisation relies on a script hosted on an external domain, you can get that script reference working again by adding the domain to the Trusted Script Sources list. However, simply adding a third-party domain to the Trusted Script Sources list poses the following security risk.
The risk is that the JavaScript file on the referenced third-party domain may change in the future and begin to contain a security vulnerability or even malicious code. This may happen if the third party in question is compromised. And when the referenced JavaScript file is changed to include a security vulnerability or an attack, the malicious code is loaded and executed in your SharePoint environment the next time a user opens a page that references that file. By adding a third-party domain to the Trusted Script Sources list, you are effectively placing all of your trust in that domain owner’s entire security posture and deployment process. And if their systems are compromised, your SharePoint environment will be next.
For this reason, you should only add script sources to the Trusted Script Sources list if you fully control the contents and the update process of those scripts.
If your solution is taking advantage of a third-party script that is currently hosted in a third-party domain, it is recommended that you at the very least take a copy of that script (and review it for security vulnerabilities), host it either on the built-in Microsoft 365 Content Delivery Network or your own external CDN that you control (e.g., on Azure), and update the script reference to point to the script file now stored in this CDN. That way, only your organisation’s users with access to the CDN can update the script.
If you are opting for storing the security-reviewed version of the script in an external CDN, you can add your CDN domain to the Trusted Script Sources list by following these steps:
- Open the SharePoint Online Admin Centre
- Expand Advanced and click on Script sources
- Add your external CDN domain as a new trusted script source
Using the latest version of the React Script Editor web part
If you’ve taken advantage of the open-source script editor web part for adding client-side customisations to SharePoint Online pages, you might have noticed that those customisations have broken as well. However, at least for now, it is possible to get those inline scripts to work again by installing the latest version of the React Script Editor web part. The latest version implements a change that works around the SharePoint CSP restrictions by using the Function constructor. This works because SharePoint’s new CSP configuration currently includes the 'unsafe-eval' directive, which allows the use of eval() and Function().
However, this is not something you should build your long-term strategy around. If Microsoft decides to remove the 'unsafe-eval' directive from the SharePoint CSP header in the future (which would be a perfectly reasonable security hardening step), this workaround will stop working immediately. You can read more about CSP headers and directives in the official documentation on MDN.
In addition to the business continuity risk above, using the script editor web part also carries the following security risk. Anyone with permissions to edit a SharePoint page can insert arbitrary JavaScript into it. This does not require a compromised account. A well-meaning content editor might embed a seemingly useful snippet from the internet without understanding the security implications, accidentally exposing users to a vulnerability.
And, of course, not every threat actor is external. While we generally want to trust our colleagues, organisations are made up of humans with complex emotions and situations. For example, organisational changes or layoffs can lead to frustration and poor decisions. A malicious insider with page-edit permissions and access to a script editor web part can cause significant damage.
The recommended long term solution: SharePoint Framework
The secure, modern, Microsoft-recommended way forward is to reimplement external and inline script-based customisations as SharePoint Framework (SPFx) solutions.
Instead of injecting scripts into modern SharePoint pages, you build a properly packaged SPFx web part or extension. The code is reviewed, versioned, and packaged by you, and then deployed through the SharePoint App Catalogue. This aligns with modern development best practices and works naturally within the boundaries defined by the new SharePoint Content Security Policy.
If your legacy implementation relied on external JavaScript libraries, you can still reference those scripts in your SPFx solutions after moving them to the M365 CDN or your organisation’s own CDN. However, ideally, you should evaluate whether those dependencies are still necessary or whether the functionality can be implemented directly within your SPFx solution using modern libraries.
Moving from external script references and content editor added inline scripts to proper SPFx solutions provides several advantages:
- Structured source code
- Proper version control and code review possibilities that typically don’t happen with ad-hoc snippets that are simply stuck on a page
- Clear deployment and versioning model
- Stronger governance and permission management
- Alignment with Microsoft’s long-term roadmap
Yes, it requires more effort than pasting a script into a page. But it also dramatically reduces the likelihood that your solution will break the next time Microsoft improves the platform’s security.
Bonus: Remember to keep all secrets on server-side
As I’ve been going through some of these now-broken decade-old implementations, deciding on the best way to fix them, I’ve come across cases where the client-side solution communicates directly with an external API using an API key. Because API communication occurs in code running in the browser, the API key (equivalent to a password) is effectively visible to all SharePoint users if they know where to look. These types of secrets tend to have far greater privileges than a regular user, often allowing read and write access to all data in the system. Thus, API keys and application secrets should always be stored securely and never be exposed on the client side.
To keep API keys and other secrets securely out of the client-side code, you need to implement a separate solution on the server side. Typically, this means an Azure Function or App Service that is protected by Entra ID authentication. Your SharePoint Framework solution then communicates with the Azure app, which in turn communicates with the external API. The API key can be stored in an Azure Key Vault and retrieved by the server-side code using the Azure app’s managed identity.
I could go on and on about this topic, so I’d best stop here and talk about it in depth in a separate article. But let this section serve as a gentle reminder not to cut any corners here, either, when it comes to application security.
Conclusion
To sum it up, your path from a broken customisation to a best practice implementation is likely to contain the following steps:
- If things are broken and you are able to delay the CSP enforcement, you can quickly restore the functionality with the PowerShell script. This is a temporary fix that buys you time to implement a longer-term solution.
- If delaying the policy enforcement is no longer possible, the second fastest way to restore the functionality is to add the external script references to the Trusted Script Sources list and install the latest version of the React Script Editor that has a workaround for running inline scripts. However, in many cases this approach too should only be used as a temporary workaround because of the security risks they impose.
- To adhere to best practices and to ensure the highest level of security, implement a SharePoint Framework solution that implements the customisation logic in a modern and secure manner.
I hope you found this blog post useful. If you’d like to read more articles written by me and get notified when they get published, feel free to subscribe to my blog and/or follow me on LinkedIn. You can find controls for both in the sidebar or at the bottom on mobile.
Happy coding and until next time!
Laura