SPFxApril 3, 202610 min read

SharePoint Online CSP Enforcement: SPFx Developer Guide

Fix SPFx web parts broken by Content Security Policy enforcement: resolve inline scripts, eval calls, and style violations with practical solutions.

#SharePoint #CSP #SPFx #security #Content Security Policy

SharePoint Online CSP Enforcement: SPFx Developer Guide

Your SPFx Web Part Just Stopped Working

You deploy a SharePoint Framework solution that has been running fine for months. Suddenly, users report a blank web part or broken functionality. You open the browser console and see this:

``



Refused to execute inline script because it violates the following

Content Security Policy directive: "script-src 'nonce-...'"





This is the result of Microsoft enforcing Content Security Policy headers on SharePoint Online pages. If you have SPFx solutions in production, you need to audit them now.



What Is CSP and Why Microsoft Is Enforcing It



Content Security Policy is an HTTP response header that tells the browser which sources of content are trusted. It prevents cross-site scripting (XSS) attacks by blocking unauthorized inline scripts, eval calls, and resources loaded from untrusted origins.



SharePoint Online has historically been lenient with CSP. That changed as Microsoft moved to harden the platform against supply-chain attacks targeting custom solutions. CSP enforcement gives Microsoft a server-side control to limit what client-side code can do, even in tenant-deployed SPFx packages.



Enforcement Rollout Timeline



Date Change Impact


|------|--------|--------|

June 2025 CSP headers added in report-only mode No breakage; violations logged


October 2025 script-src enforcement begins (targeted release tenants) Inline scripts blocked


January 2026 script-src and style-src enforcement reaches GA tenants Inline scripts and styles blocked


March 2026 Full CSP enforcement including connect-src restrictions Unauthorized API calls blocked


June 2026 (planned) Strict nonce-based policy for all tenants Only nonce-tagged scripts execute




If your tenant is on targeted release, you are already under full enforcement. GA tenants have been catching up since Q1 2026.



What Breaks: Common SPFx Patterns That Violate CSP



Inline Scripts via innerHTML



Setting

innerHTML with





eval() and new Function()



Both

eval() and new Function() are blocked by script-src policies that do not include 'unsafe-eval'

. Some template libraries and older utility packages use these internally.

typescript

// BREAKS under CSP

const result = eval('2 + 2');

const dynamicFn = new Function('a', 'b', 'return a + b');





Inline Styles via element.style



Setting styles directly through JavaScript properties or

setAttribute('style', ...) violates style-src when 'unsafe-inline'

 is not allowed.

typescript

// BREAKS under CSP

element.style.backgroundColor = '#0078d4';

element.setAttribute('style', 'color: red; font-size: 14px;');





Dynamic Script Loading



Creating

;



// AFTER (CSP-compliant)

const container = document.createElement('div');

container.className = styles.container;



const heading = document.createElement('h2');

heading.textContent = title;

container.appendChild(heading);



this.domElement.appendChild(container);



// Call the init function directly instead of via inline script

initWidget();





If you use React (the recommended SPFx rendering approach), you already avoid innerHTML in most cases. Audit any places where you use

dangerouslySetInnerHTML

.



Replace eval with Safe Alternatives

typescript

// BEFORE (violates CSP)

const value = eval(userExpression);



// AFTER (CSP-compliant) — use a purpose-built parser

import { evaluate } from 'mathjs';

const value = evaluate(userExpression);





For dynamic property access, use bracket notation instead of eval:

typescript

// BEFORE

const val = eval(

obj.${propertyName}

);



// AFTER

const val = obj[propertyName];





Move Inline Styles to CSS Modules



SPFx generates CSS modules by default. Use them.

typescript

// BEFORE (violates CSP)

element.style.backgroundColor = isActive ? '#0078d4' : '#ffffff';



// AFTER (CSP-compliant) — toggle CSS classes

import styles from './MyWebPart.module.scss';



element.className = isActive ? styles.active : styles.inactive;





Define the styles in your

.module.scss

 file:

scss

.active {

  background-color: #0078d4;

}



.inactive {

  background-color: #ffffff;

}





Use SPFx-Approved Script Loading



Instead of dynamically injecting