GTconsult - Blog #CSP EnforcementGTconsult - Blog #CSP Enforcementhttps://www.gtconsult.com/blogs/tag/csp-enforcementWed, 01 Apr 2026 08:41:36 -0700http://zoho.com/sites/<![CDATA[SharePoint CSP: Lessons Learned After Enforcement]]>https://www.gtconsult.com/blogs/post/sharepoint-csp-lessons-learned-after-enforcementCSP enforcement went live 1 March 2026. Here's what actually broke, what held up fine, and what every SharePoint environment can learn from the aftermath.]]>

1 March came and went. Here's what actually broke, what held up fine, and what everyone who was "planning to deal with it later" is dealing with right now.

Microsoft's SharePoint Online Content Security Policy enforcement went live on 1 March 2026. For teams that had prepared, audited their violations, refactored inline scripts, registered trusted sources: it was a non-event. For those who hadn't, it was a rough Monday morning. This post captures what we've seen in the aftermath: what broke, what didn't, and what the experience teaches us about managing security changes in a modern SharePoint environment.

What Actually Broke


Commonly Affected

Inline Scripts in Content Editor Web Parts
​

Classic content editor web parts with embedded JavaScript were one of the most common failure points. Many organisations had years-old scripts sitting in these parts that nobody had touched, and nobody realised were inline until they stopped working.


Commonly Affected

Third-Party Integrations Using Dynamic Injection

Analytics tools, chatbots, CRM connectors, and similar third-party solutions that inject scripts dynamically at runtime without pre-registration were blocked. Some vendors had updated their SharePoint integrations ahead of enforcement; others hadn't.


Partially Affected

Custom SPFx Web Parts with Dynamic Loading

Web parts using  SPComponentLoader.loadScript() to pull in external libraries at runtime worked fine if those sources were pre-registered in Trusted Script Sources, and broke if they weren't. The split outcome here caught some teams off guard who assumed their SPFx solutions were automatically safe.


Unaffected

Standard SPFx Bundles via cdnBasePath or externals

Solutions deployed through proper SPFx packaging, bundles referenced via  cdnBasePath  or external libraries declared in  config.json , were automatically added to Trusted Script Sources on installation and were entirely unaffected by enforcement.


Unaffected

Classic SharePoint Pages
​

CSP enforcement only applies to modern SharePoint pages. Organisations still running classic team sites or publishing sites were not affected, though the long-term trajectory of classic SharePoint remains what it is.


Still running classic SharePoint? CSP is one of many reasons the clock is ticking. Our Support Manager Barend Olivier walks through exactly what's at stake and how to move forward in our on-demand webinar, Migration & Modernization: From Legacy to Modern.

The Common Thread in Failures

Looking across the common failure patterns, there's a single theme: legacy script patterns that nobody had revisited in years. The solutions that broke were rarely recently built, they were older integrations, older web parts, scripts embedded when SharePoint was configured years ago and then forgotten.

CSP enforcement didn't create new problems; it surfaced old ones. That's actually the point. The report-only window from late 2025 through 28 February was designed exactly for this: a chance to audit before enforcement hit. Teams that used that window had nothing to worry about on 1 March. Teams that didn't are doing triage now.

The Fix Is Usually Simpler Than It Sounds

One of the more reassuring findings: for most organisations, the actual remediation work is not as complex as it sounds once you know what you're dealing with. The common fixes are:

  • Inline scripts: Extract into a  .js file , host it somewhere trusted, update the reference. An afternoon of work in most cases.
  • Untrusted external sources: Add the domain to Trusted Script Sources in SharePoint Admin Center. A few minutes per source.
  • Third-party vendor tools: Contact the vendor. Most major vendors had CSP-compliant updates available before enforcement, it's usually a version upgrade.

The difficulty isn't the fix itself. It's the discovery: knowing which scripts exist, where they live, and what they load. That's why the Purview audit log is so valuable, run a search for "Violated Content Security Policy" to get the full map.

What This Tells Us About Security Governance

CSP enforcement is a useful lens on a broader question: how well do organisations actually know what JavaScript is running in their SharePoint environment? For many, the honest answer before 1 March was "not very well." Scripts accumulate over years of SharePoint growth, solutions built by people who've left, integrations set up for projects long since finished, vendor tools added during evaluations that never quite got removed.

CSP enforcement forced an audit that should have been happening on an ongoing basis. The silver lining: teams that went through the remediation process now have a much cleaner, better-documented picture of their SharePoint script landscape than they did before.


If You're Still Cleaning Up

Check your Purview audit log, work through violations methodically, and use  ?csp=enforce  on individual pages to verify fixes. If you're on the 90-day delay, enforcement hits 1 June 2026. Use the time you have.

Need our help?

Chat to us and let's help you navigate this change.

Book a Free Consultation with Our Technical Account Manager, Trevin
]]>Tue, 31 Mar 2026 14:28:53 +0000<![CDATA[Still on the 90-Day CSP Delay? Your 1 June Deadline Is Coming]]>https://www.gtconsult.com/blogs/post/still-on-the-90-day-csp-delay-your-1-june-deadline-is-comingStill on the 90-day CSP delay? Your SharePoint Online enforcement deadline is 1 June 2026. Here's your 8-week action plan to audit violations, fix scripts, and test before the window closes.]]>

If your organisation opted into Microsoft's enforcement delay back in February, the window is closing. Here's everything you need to do before 1 June, and why the time to start is now, not May

When Microsoft announced SharePoint Online's Content Security Policy enforcement in early 2026, they included a lifeline for organisations that needed more time: a Set-SPOTenant -DelayContentSecurityPolicyEnforcement $true flag that pushed enforcement from 1 March to 1 June 2026. If your IT team enabled that flag, you bought yourself 90 days.

Those 90 days are now running out.

The purpose of the delay was to give organisations time to audit their environments, fix non-compliant scripts, and test changes, not to skip preparation entirely. If you haven't started yet, this post is your starting gun.

What Happens on 1 June

On 1 June 2026, the enforcement delay expires automatically. There is no second delay option. After that date, CSP enforcement behaves exactly as it does for everyone else who went live 1 March:

  • Inline JavaScript will be blocked on all modern SharePoint Online pages.
  • Scripts loaded from external sources not registered in your Trusted Script Sources list will be blocked.
  • Users will see broken web parts, missing functionality, and JavaScript errors with no visual warning that CSP is the cause.

The failure mode is silent from a user perspective: a web part just stops working. The only indication is in the browser console, which most end users will never open. That's why preparation before 1 June matters: there's no grace period, no warning message, and no automatic recovery.

Check Whether You're on the Delay

If you're not certain whether your tenant enabled the delay, check it now via PowerShell:


Get-SPOTenant | Select-Object DelayContentSecurityPolicyEnforcement

If the value returns True, enforcement is delayed until 1 June. If it returns False, enforcement was already live on 1 March. Check whether anything broke in your environment around that date.

Your Action Plan: The Next 8 Weeks

Week 1–2: Audit

Before you can fix anything, you need to know what's broken. Two tools:

  • Microsoft Purview: Search the audit log for "Violated Content Security Policy". This returns a tenant-wide list of every page and script source that triggered a CSP violation during the report-only window. This is your master list.
  • Browser console + ?csp=enforce: Append ?csp=enforce to any modern page URL to force enforcement mode. Open Developer Tools (F12) and check the Console tab for blocked script errors. Use this to verify specific pages.


Don't Skip the Audit
The most common mistake teams make is fixing the scripts they know about and missing the ones they don't. The Purview audit log is the only way to surface violations across your entire tenant, including pages and solutions built by people who may no longer be on the team.


Week 3–5: Fix and Register

Work through violations by type:

  • Inline scripts: Extract JavaScript into external .js files, host in a trusted location, update references. Register the hosting URL as a Trusted Script Source.
  • Dynamic external loads (SPComponentLoader): Register each external URL manually in SharePoint Admin Center under Trusted Script Sources. The 300-entry limit applies across your entire tenant, audit before adding everything.
  • Third-party tools: Contact vendors. Most major vendors have CSP-compliant versions of their SharePoint integrations available. This is a version upgrade, not a rebuild.






Week 6–7: Test in Enforce Mode

Once fixes are in place, use ?csp=enforce systematically across your critical pages to verify nothing is still breaking. Involve your end users or QA team, have them walk through their normal workflows on the pages they use most.


Week 8: Sign Off and Communicate

Before 1 June, communicate the change to relevant stakeholders. If any web part behaviour has changed as a result of refactoring (however minor), users should know what to expect. Frame it as a security improvement, because it is.

The Risk of Waiting Until Late May

The pattern we've seen with 1 March enforcement is that the teams who struggled were the ones who started late. Trusted Script Source changes can take up to 24 hours to propagate across a tenant. If you're making changes on 30 May and something doesn't propagate in time, you have no margin for error.

Eight weeks sounds like plenty of time. In practice, the audit usually surfaces more than expected, vendor responses take longer than expected, and internal sign-off processes take time. Start now.


Further Reading

SharePoint CSP Enforcement Is Live — Here's What to Do If Your Scripts Are Broken
Support for CSP in SharePoint Online, Microsoft Learn
SharePoint Online CSP: Enforcement Dates and Guidance, Microsoft Tech Community


Not sure where to start with CSP?

Chat to us and let's help you navigate this change.

Book a Free Consultation with Our Technical Account Manager, Trevin
]]>Tue, 31 Mar 2026 12:11:08 +0000<![CDATA[SharePoint CSP Enforcement Is Live — Here's What to Do If Your Scripts Are Broken]]>https://www.gtconsult.com/blogs/post/sharepoint-csp-enforcement-is-live-—-here-s-what-to-do-if-your-scripts-are-brokenSharePoint CSP enforcement broke your scripts? Learn how to diagnose CSP violations, fix inline JavaScript, and register trusted sources in SharePoint Online after the 1 March 2026 deadline.]]>

Microsoft flipped the switch on March 1. If your web parts or custom solutions are suddenly misbehaving, Content Security Policy enforcement is likely the culprit. Here's how to diagnose and fix it.

On 1 March 2026, Microsoft moved SharePoint Online's Content Security Policy (CSP) from report-only mode into full enforcement. That means non-compliant scripts are no longer just being logged, they're being blocked. If something in your environment stopped working around that date, there's a good chance CSP is the reason.

This post walks you through how to confirm CSP is the issue, understand what's being blocked and why, and fix it, without breaking anything else in the process.

Step 1: Confirm CSP Is the Culprit

Before diving into fixes, verify that CSP enforcement is actually what's blocking your scripts. The fastest way is through the browser console.

  1. Open the affected SharePoint page in your browser.
  2. Press  F12  to open Developer Tools and navigate to the Console tab.
  3. Look for errors beginning with  Refused to execute script  or containing Content-Security-Policy .
  4. Alternatively, append  ?csp=enforce  to the page URL to trigger enforcement mode explicitly and surface violations immediately.

If you're seeing CSP violation errors, you're in the right place. If not, the issue may be something else. Check network errors or JavaScript exceptions separately.

Step 2: Identify What's Being Blocked

CSP violations in SharePoint Online generally fall into two categories: inline scripts and untrusted external sources.

Inline Scripts

Any JavaScript written directly into a page, web part, or solution using  innerHTML  ,  document.write()  , or script tags without a proper source reference will be blocked. Microsoft has confirmed that  unsafe-inline  is not permitted and that nonce values will not be exposed, so there is no workaround here. These scripts must be refactored.


Untrusted External Sources

Scripts loaded from external URLs (CDNs, third-party services, custom hosted libraries) that haven't been added to your SharePoint tenant's Trusted Script Sources list will also be blocked. Note that standard SPFx bundles deployed via  cdnBasePath  or declared in  externals  in your config are auto-trusted, it's dynamic loading via  SPComponentLoader.loadScript()  or ad-hoc external references that need manual registration.

TENANT-WIDE AUDIT

Go to Microsoft Purview and search for "Violated Content Security Policy" in the audit log. This gives you a full picture of which pages and scripts have triggered violations across your entire tenant, not just the one page you're looking at.


Step 3: Fix Inline Scripts

Inline scripts need to be moved into external  .js  files and hosted in a trusted location. The typical path for SPFx solutions:

  1. Extract the inline JavaScript into a standalone  .js  file.
  2. Deploy the file to a trusted location (e.g., SharePoint document library, Azure Blob Storage, your CDN).
  3. Reference it as an external module within your SPFx solution rather than injecting it inline.
  4. Register the script source as a Trusted Script Source (see Step 4).

For scripts embedded directly in classic-style page layouts or content editor web parts, the same logic applies, extract, host externally, reference externally.

Step 4: Register Trusted Script Sources

For any external URL your solutions load scripts from, you need to add that domain to SharePoint's Trusted Script Sources list. This is done in the SharePoint Admin Center.

Go to SharePoint Admin Center → Advanced → Trusted Script Sources (or use PowerShell).

Add the full domain or path of the external script source. Wildcards are limited, subdomains must be registered individually.

Note the 300 entry limit across your tenant. Audit carefully before adding everything.

Changes can take up to 24 hours to propagate across your tenant.

Via PowerShell:


Add-SPOTenantCdnOrigin -CdnType Private -OriginUrl "https://yourdomain.com/scripts"

Step 5: Coordinate With Third-Party Vendors

If your SharePoint environment includes solutions from third-party vendors, analytics tools, chatbots, form builders, or similar, those vendors may need to update their products to be CSP-compliant. Reach out to them with the specific violation URLs from your Purview audit and ask for a compliance timeline.

In the meantime, you can temporarily register their script sources as trusted, but the long-term fix needs to come from their end if their solutions use inline scripting patterns.

If You're Still on the 90-Day Delay

Some tenants enabled the 90-day enforcement delay using  Set-SPOTenant -DelayContentSecurityPolicyEnforcement $true  before 1 March. If that's you, your enforcement date is 1 June 2026, and it will arrive faster than you think. Use this guide now while you still have the buffer.

FURTHER READING

Still on the 90-Day CSP Delay? Your 1 June Deadline Is Coming

Support for CSP in SharePoint Online, Microsoft Learn

SharePoint Online CSP: Enforcement Dates and Guidance, Microsoft Tech Community


Still dealing with broken scripts after CSP enforcement?

Not sure where to start with CSP?

Chat to us and let's help you navigate this change.

Book a Free Consultation with Our Technical Account Manager, Trevin
]]>Mon, 30 Mar 2026 16:25:43 +0000