SharePoint CSP Enforcement: Audit & Fix Your SPFx Solutions Before March 2026

What Changed in March 2026: Microsoft's CSP Enforcement

On March 1, 2026, Microsoft activated strict Content Security Policy headers across all SharePoint Online tenants with no opt-out. This was not a new announcement — Microsoft had communicated the enforcement date through the Microsoft 365 Message Center (MC710234) throughout late 2025 — but the scale of production breakage it caused across enterprise tenants worldwide was significant. SPFx solutions that had loaded third-party scripts, fonts, or CSS from arbitrary external origins simply stopped working overnight.

The CSP header that SharePoint now emits includes a default-src 'self' directive, a tightly scoped script-src allowlist, and a style-src that blocks inline styles and unauthorised external stylesheets. The policy is applied at the SharePoint Online infrastructure level, meaning it cannot be overridden by tenant administrators or SPFx solution manifests. The only compliant path forward is to ensure every asset your SPFx solution loads originates from an approved source.

The approved sources Microsoft permits by default include *.sharepoint.com, *.scdn.microsoft.com (the SharePoint CDN endpoint), and Azure CDN endpoints registered through the SPFx CDN configuration. Any solution loading assets from npmjs.com, cdnjs.cloudflare.com, unpkg.com, Google Fonts, or any arbitrary third-party host will now throw a CSP violation and the corresponding functionality will be silently blocked in the browser.

Auditing CSP Violations with Browser DevTools

Before you can fix violations, you need a complete inventory of what your SPFx solutions are loading from external origins. The fastest way to do this at scale is to use the browser's built-in CSP violation reporting, combined with a structured DevTools audit process.

Open Chrome DevTools (F12) and navigate to the Console tab. Filter by "Content Security Policy" to see all CSP violation messages. Each message follows the pattern: Refused to load the script/style/image '[URL]' because it violates the following Content Security Policy directive: '[directive]'. Note every blocked URL — the origin and resource type are the two data points you need for your remediation plan.

For a more systematic approach across multiple web parts, use the Network tab with the "Blocked Requests" filter enabled. Reload the page and sort by status — blocked resources appear with a red strike-through. Export the HAR file for offline analysis. In large tenants with dozens of custom SPFx solutions, we recommend running this audit on each major site collection type rather than every individual site, then correlating blocked origins back to specific SPFx packages using the solution's bundle manifest.

// Paste in browser console to capture all CSP violations on a page
document.addEventListener('securitypolicyviolation', (e) => {
  console.table({
    blockedURI: e.blockedURI,
    violatedDirective: e.violatedDirective,
    documentURI: e.documentURI,
    sourceFile: e.sourceFile,
    lineNumber: e.lineNumber,
  });
});

Once you have the list of blocked URIs, group them by origin domain. Common offenders we see in SPFx solutions include: Google Fonts (fonts.googleapis.com, fonts.gstatic.com), chart libraries loaded from CDNjs or jsDelivr, third-party icon fonts like Font Awesome from its CDN, and analytics or tracking scripts. Each group requires a different remediation strategy.

Understanding the Approved CDN List

Microsoft's enforced CSP allows assets from a specific set of origins that are considered trusted within the Microsoft 365 ecosystem. Understanding this list is essential for planning your remediation correctly so you do not end up fixing one violation only to introduce another.

The always-permitted origins include: all *.sharepoint.com subdomains (your tenant, plus publiccdn.sharepointonline.com and privatecdn.sharepointonline.com), Microsoft's own CDN infrastructure at res.cdn.office.net and static2.sharepointonline.com, Azure CDN endpoints under *.azureedge.net that are explicitly registered in your SPFx config.json, and the Microsoft Graph API endpoint for data calls.

What is explicitly not permitted includes all third-party CDNs not registered through SPFx configuration, any custom domain you own unless it is fronted by Azure CDN and registered, and data: URIs for scripts (they remain blocked for security reasons even if inline styles are permitted in certain configurations). The distinction between Azure CDN and arbitrary CDNs is important: Azure CDN is approved because Microsoft controls the infrastructure trust chain, not because it is inherently safe.

Setting Up the SharePoint CDN for SPFx Assets

The SharePoint CDN (also called the Office 365 CDN) is the simplest approved delivery mechanism for SPFx assets. It works by designating a SharePoint document library as a CDN origin — Microsoft then replicates files from that library to its global CDN edge network and serves them from publiccdn.sharepointonline.com or privatecdn.sharepointonline.com, both of which are within the approved CSP allowlist.

Enable the Office 365 CDN and configure your origins using the SharePoint Online Management Shell. The public CDN is appropriate for static assets like images, CSS, and JavaScript bundles that do not contain sensitive data. For assets that should only be accessible to authenticated users, use the private CDN origin — assets are served through an authenticated SharePoint URL that respects site permissions.

# Connect to your SharePoint tenant
Connect-SPOService -Url https://contoso-admin.sharepoint.com

# Enable the public CDN
Set-SPOTenantCdnEnabled -CdnType Public -Enable $true

# Add the default SPFx asset library as a CDN origin
Add-SPOTenantCdnOrigin -CdnType Public `
  -OriginUrl sites/appcatalog/ClientSideAssets

# Verify origins (propagation takes up to 15 minutes)
Get-SPOTenantCdnOrigins -CdnType Public

After enabling the CDN and adding your origin, you need to update your SPFx solution's deployment configuration. In config/deploy-azure-storage.json or by setting cdnBasePath in config/write-manifests.json, point the asset base path to your SharePoint CDN URL. Rebuild with gulp bundle --ship and repackage — the bundled assets will now reference the CDN path instead of relative SharePoint page URLs. Upload the assets to the designated library and deploy the updated .sppkg.

Using Azure CDN as an Alternative

For organisations that already use Azure infrastructure, deploying SPFx assets to Azure Blob Storage fronted by Azure CDN is a robust alternative to the SharePoint CDN. Azure CDN provides more configuration flexibility — custom cache rules, origin authentication, geo-filtering, and custom domain support — and integrates naturally with CI/CD pipelines that deploy to Azure.

The critical step that makes Azure CDN CSP-compliant is registering the Azure CDN endpoint hostname in your SPFx package manifest. Microsoft's CSP policy dynamically allowlists CDN origins that are declared in deployed SPFx packages — this is how the SharePoint runtime knows to trust your specific Azure CDN endpoint without opening the policy to all of *.azureedge.net.

{
  "$schema": "https://developer.microsoft.com/json-schemas/spfx-build/package-solution.schema.json",
  "solution": {
    "name": "my-spfx-solution",
    "id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",
    "version": "1.0.0.0",
    "skipFeatureDeployment": true,
    "isDomainIsolated": false,
    "metadata": {
      "shortDescription": { "default": "My SPFx Solution" }
    },
    "webApiPermissionRequests": []
  },
  "paths": {
    "zippedPackage": "solution/my-spfx-solution.sppkg"
  }
}

In your config/write-manifests.json, set cdnBasePath to your Azure CDN endpoint: https://contoso-spfx.azureedge.net/releases/1.0.0. Your CI/CD pipeline should upload the contents of the dist/ folder to Azure Blob Storage at the corresponding path before deploying the .sppkg to the App Catalog. Use versioned CDN paths (include the solution version in the path) so you can roll back by redeploying a previous .sppkg version that points to the old CDN path.

Fixing CSP Violations in SPFx Solutions

With your CDN infrastructure in place, the remediation work for each SPFx solution follows a consistent pattern. The goal is to eliminate every external origin reference and replace it with either a bundled dependency or an approved CDN reference. Here are the most common violation types and their fixes.

Google Fonts: Remove the Google Fonts link tag from your web part's domElement injection or any HTML templates. Instead, download the font files (.woff2) and host them in your SharePoint CDN origin library. Reference them via an @font-face declaration in a CSS file that is bundled into your SPFx solution. This is a one-time task per font family and dramatically improves load performance since the font is co-located with your other assets.

Third-party JavaScript libraries: Move all library dependencies into your package.json as npm dependencies and bundle them with webpack (SPFx does this by default). Delete any dynamic <script> tag injection that loads from external CDN URLs. If a library is very large and you were using a CDN for performance reasons, consider whether it can be lazy-loaded from the SharePoint CDN instead.

External API calls that return rendered HTML or scripts: These need architectural refactoring. Move the data-fetching to a server-side function (Azure Function or Power Automate HTTP action) that calls the external service and returns only JSON data to your SPFx solution. Your solution then renders the data itself — this removes the external origin dependency entirely.

// BEFORE: CSP violation — loads from external CDN
const script = document.createElement('script');
script.src = 'https://cdnjs.cloudflare.com/ajax/libs/Chart.js/4.4.0/chart.umd.min.js';
document.head.appendChild(script);

// AFTER: CSP-compliant — bundled via npm
// 1. Run: npm install chart.js --save
// 2. Import directly in your component:
import { Chart, registerables } from 'chart.js';
Chart.register(...registerables);

// Now use Chart directly — it is bundled into your SPFx package
const ctx = canvasElement.getContext('2d');
new Chart(ctx, { type: 'bar', data: chartData });

Testing with CSP-Strict Preview Mode

Microsoft introduced a CSP-strict preview mode in the SharePoint workbench and in tenant settings that lets you validate your solutions against the enforced policy before rolling out to production. This testing mode was available from late 2025 alongside the enforcement announcement, meaning organisations that tested proactively had months to remediate before the March 2026 enforcement date.

To enable CSP-strict mode in your development environment, append ?cspStrict=true to the SharePoint workbench URL. This forces the browser to apply the production CSP policy in your dev environment. Any violations that appear in the console under this mode will also appear in production after enforcement. This parameter works in both the hosted workbench (https://tenant.sharepoint.com/_layouts/15/workbench.aspx?cspStrict=true) and on live SharePoint pages using the page query string.

For automated regression testing, integrate CSP violation detection into your Playwright or Cypress test suite. Listen for the page.on('console') event and flag any message containing "Content Security Policy" as a test failure. This gives you continuous CSP compliance checking as part of your CI/CD pipeline — so a newly added npm package that injects an external load cannot slip through to production undetected.

Ongoing Compliance: Building CSP Awareness into Development

A one-time remediation is not enough. Without process changes, CSP violations will re-appear as developers add new dependencies, update existing packages that change their loading behaviour, or introduce new features that pull in third-party content. Building CSP compliance into your development and deployment workflow is the only sustainable solution.

Add a CSP lint step to your SPFx project's build chain. Tools like csp-evaluator (available as an npm package) can scan your bundle output for known CSP-unsafe patterns including unsafe-inline style injections, dynamic script creation, and base64 data: URI usage. Run this as a pre-deploy check in your Azure DevOps or GitHub Actions pipeline and fail the build if violations are detected.

Review your SharePoint CDN origin configuration quarterly. As your organisation deploys new SPFx solutions, ensure that any new asset locations are added as CDN origins before the solution goes live. Create a runbook in your SharePoint development documentation that outlines the approved CDN options, the steps to add a new origin, and the testing procedure — so new team members understand the constraints before they begin writing code.