SPFx: Be prepared for the Content Security Policy (CSP) in SharePoint Online
Very soon in March 2026, the new Content Security Policy will be switched from report-only mode to active blocking (enforcement) mode. If you are not prepared, maybe some custom web parts or extensions will stop working. If the term "SharePoint Online Content Security Policy (CSP)" is new for you, you should continue reading. If you are already prepared, keep relaxed😎.
SharePoint Online Content Security Policy (CSP) - explained
Regarding the Microsoft SharePoint Blog post CSP means:
Content Security Policy (CSP) is a critical browser security feature designed to protect web applications from threats like cross-site scripting (XSS), clickjacking, and other code injection attacks. CSP allows site owners to specify which resources (scripts, styles, images, etc.) a page can load, reducing the risk of malicious code execution.
More about CSP: Content Security Policy (CSP)
The basic facts about CSP are:
- strengthen SharePoint Online security by only allowing to load approved scripts — defense against cross-site scripting (XSS) attacks
- Implemented via a Content-Security-Policy response header
-
Applies only to SPFx solutions when hosted on site pages
- Does not apply to SharePoint Add-Ins
- Does not apply to classic page types as they can’t contain SPFx solutions
This new policy is until end of February in report-only mode. In report-only mode, every script use violation is only logged in Purview. Beginning march 2026 the policy is going to switched to active blocking. If your web part or extension loads, for example, scripts from external sources or uses inline scripts, these scripts will be blocked. The official time plan for this new policy:
- Now–Feb 29, 2026: CSP in report-only mode (no blocking, only logging)
- March 1, 2026: CSP enforcement begins (blocking non-compliant scripts)
- Optional: Delay enforcement by 90 days (until June 1, 2026) using PowerShell
As long a SPFx-based solution uses the "normal" script loading mechanismus, means everything is combined in the *.sppkg file, nothing should be blocked by the new policy. In this case, all scripts are deployed to the site’s ClientSideAssets library, which is trusted by the default SharePoint Online CSP configuration. Any other script loading approaches could be blocked by the policy and need maybe manual configuration. For example if you load script libraries dynamically with SPComponentLoader you must ensure that the domain is registered as trusted source.
INLINE SCRIPTS
In case your solution uses any inline scripts, everything is blocked by CSP!. Inline scripts will be blocked. In case your solution uses any inline scripts, everything is blocked by CSP! Inline scripts will be blocked.
Overview: how impact CSP your solution
| Script usuage case | CSP behavior |
|---|---|
| Using default SPFx configuration to load from SharePoint. | No impact 😎 |
| Deploy script to external CDN, location is configured via the cdnBasePath property in the ./config/write-manifests.json file | No impact: On "solution add" the cdnBasePath URL is added as trusted source 😎 |
| Deploy script to external CDN, location is configured via the externals map in config.json. | No impact: On "solution add" the cdnBasePath URL is added as trusted source 😎 |
| Dynamically load a script with SPComponent loader | BLOCKED! 😒 Fix: Add script URL as trusted source. Easy 😎 |
| Load script using DOM updates | BLOCKED! 😒 Fix: Use previous instruction or use altrenate load script mechanism. Easy, too 😎 |
| Load inline script | BLOCKED! 😒 Clean your code! More work but it's worth. Move inline script to separate script file and load from trusted source or via package (*.sppkg). |
| Inline script: EXCEPTIONS |
It is possible to use eval and timeout. Event handler function using innerHTML still allowed. |
How to prepare?
Be sure that all your custom extensions loads scripts regarding the recommendation approach or ensure that all script sources registered as trusted source. In case you have your CDN path configured via the external property in config.json, the CDN domain is added to Trusted Script Sources automatically. To ensure everything is in place and prepared, you should test all your custom solutions. This is very easy, just go to a page with the extension and check the browser console output. In case of CSP violation, you see some messages in the console, like in the image below.
Besides these checks, you should also evaluate the Microsoft Purview audit logs and filter on "Violated Content Security Policy" activity.
Check your Modern Script Editor WebPart version
In case you use the Modern Script Editor WebPart ensure that you use a version equals to or greater than Release 1.0.27. This new version is compatible with the CSP checks. In case you have an older version in use, you must update soon.
How to prepare?
If the enforcement on March 1, 2026, is too soon because you need more time to review and update your existing SPFx solutions, you can delay the enforcement by 90 days, until June 1, 2026, using SPO Management Shell:
Set-SPOTenant -DelayContentSecurityPolicyEnforcement $true
To find all your affected SPFx solutions, you can either open all pages that have embedded custom solutions and check the console log output, or you can use Microsoft Purview and create an audit report for "Violated Content Security Policy" entries. The report contains all the important information that you need to find any affected solution. The screenshot below shows an example of the details.
 |
| Microsoft Purview CSP report |
Demo time
For more details on how it works, see my short video where I prepared a simple webpart to demonstrate how to deal with CSP.
Helpful links
Kommentare