Table of Contents

⚠️ Security Advisory: SharePoint Online CSP Enforcement
Status Announced
Enforcement Date March 1, 2026 (or June 1, 2026, if postponed)
Impact High (Potential breaking change for SPFx components)
Microsoft Reference CSP Trusted Script Sources

Summary

Microsoft is improving SharePoint Online security by enforcing Content Security Policy (CSP). Currently, CSP is applied in "reporting mode", but starting March 1, 2026, this policy will be strictly enforced.

What does this mean?

  1. External Scripts: JavaScript files loaded from servers not explicitly marked as "Trusted" in SharePoint will be blocked.
  2. Inline Scripts: Code directly embedded in HTML (e.g., <script>...</script> or onclick="...") will be blocked.

How this affects your solution

1. Ometa Core Dependencies (Configuration Required):

The ADM and other Ometa Web Parts load external scripts hosted on the Ometa Core Service / IIS Server. To ensure continued operation, the Core Service URL must be explicitly added to the SharePoint "Allow List." This requires manual configuration (see Action Plan).

2. Custom Renderers & Conversion Scripts (Update Required):

Many solutions use Custom Renderers or Conversion Scripts containing inline scripts. Under strict CSP, patterns like the ones below would normally break:

Problematic Example of Custom Renderer

const templateFunction = function(rowData, formattedData, csl) {
    let productName = rowData.productName;

    return `
    <!-- The onclick is an inline event which will be blocked. -->
    <div class="card" onclick="window.myNamespace.processAction()">
        ${productName}
    </div>
    `;
}

Problematic Conversion Scripts

  • Inline event handlers:

    Value = "<div onclick='javascript:someFunction()'>Click Me</div>"

  • Javascript protocols in links:

    Value = "<a href='javascript:someFunction()'>Click Me</a>"

Other Problematic Patterns

  • Any <script> block which goes directly to HTML:

    <script>console.log('Hello');</script>

  • Inline Event Handlers (JavaScript embedded in HTML attributes):

    <button onclick="alert('Hi')">Click</button>
<body onload="init()">...</body>

    const testDiv = document.createElement('div');
testDiv.setAttribute('onclick', "alert('Hi')");
testDiv.click();

  • JavaScript embedded in href or src attributes:

    <a href="javascript:alert('Hi')">Click</a>

  • Dynamically Created Inline Scripts:

    const s = document.createElement('script');
s.textContent = "alert('Hi')";
document.head.appendChild(s);

  • InnerHTML or insertAdjacentHTML with <script>:

    element.innerHTML = "<script>alert('Hi')</script>";

Our Solution: Backward Compatibility Hotfix

You likely do not need to rewrite your code.

Ometa is currently working on a hotfix aimed at resolving these inline script issues automatically. This update is designed to make existing Custom Renderers and Conversion Scripts compatible with the new CSP rules without requiring you to manually refactor your code.

Important

Living Document
We are currently investigating the full technical modalities to ensure the best possible coverage. We are committed to transparency and will update this guide with more specific technical details and release timelines as soon as our investigation is complete.

Note

Strategic Advice: Use Cards
While our hotfix aims to keep Custom Renderers working, we strongly advise using the Cards module for all new configurations. The Cards module is the preferred, future-proof alternative to Custom Renderers.

Action Plan

Step 1: Add Trusted Sources (MANDATORY)

Regardless of the hotfix, you must explicitly trust your Ometa Core Service URL. The software cannot do this for you.

  1. Go to the SharePoint Online Admin Center.
  2. Navigate to Advanced > Script sources.
  3. Add the URL of your Ometa Core Service (e.g., https://ometa.coreservice.com).

Trusted script sources

We aim to release the hotfix before the March 1st deadline. However, to ensure business continuity and allow sufficient time for testing and deployment, we strongly advise all customers to apply for the postponement.

This extends the deadline to June 1, 2026, creating a safe buffer for your upgrade.

Important

Only run this command after February 9, 2026. If you do this before, the setting is not persisted.

Run the following PowerShell command after February 9, 2026. (available in SPO Management Shell version 16.0.26712.12000 or higher):

Set-SPOTenant -DelayContentSecurityPolicyEnforcement $true

Even though we are providing a fix, we recommend auditing your environment to ensure you haven't missed any other external script sources apart from Ometa (e.g., Google Analytics, external widgets) that also need to be added to the Trusted Sources list in Step 1.

  • Via Browser: Open your SharePoint site, press F12 (DevTools), and check the Console. Look for "Violates Content Security Policy" errors (refer to the next two screenshots).

    Network trace

    Second network trace

  • Via Microsoft Purview: Navigate to the Audit log and search for ViolatedContentSecurityPolicy.

    Purview audit

Step 4: Plan your Upgrade

  • Wait for the Hotfix: Plan to install the upcoming Ometa framework update or the hotfix for version 6.2.x before March 2026. This will patch the inline script vulnerabilities in Custom Renderers and Conversion Scripts.
  • Migrate to Cards (Optional but Recommended): If you are planning major maintenance on a solution, consider replacing Custom Renderers with Cards to reduce technical debt.

Timeline & Postponement

  • Now: Reporting mode is active.
    • Action: Add Trusted Sources & Identify external dependencies.
    • Action: Run the Set-SPOTenant postponement script to secure the June deadline.
  • Q1 2026: Release of the Ometa CSP Hotfix.
    • Action: Update Ometa Framework or apply the hotfix.
  • March 1, 2026: Official Microsoft enforcement begins (Safe if postponed).
  • June 1, 2026: Final enforcement for delayed tenants. You must have upgraded to the Ometa hotfix or migrated your customizations by this date.