Share via

Not able run JS on the SharePoint pages due to CSP (Content security Policy)

KarthikeyanBalasubramani-1991 5 Reputation points
2026-05-15T09:19:01.9433333+00:00

Hi Team,

We have a custom webpart called "HTML " which is added in our Sharepoint pages. Basically it will run the Javascript code along with the HTML. We have some requirement to show the charts and when we click it will show the steps along with it.

For that, we had a html file includes, Javascript and css. We have to put that file in our assets folder. We can refer the link to the file in the webpart properties.

But when we run that, it gives error that "Executing inline script violates the following Content Security Policy directive 'script-src 'unsafe-eval' "

We have tried different approach like split the single file into two like one file has html and other file has JS and CSS. The html will have the reference of the other file. For some time it worked but now it stops and again gives the same error.

Do you have any suggestions how to solve this! Because we can do when we disable that CSP policy for our tenant using script but coming June 1 2026 microsoft has announced it will be completely disabled.

Thanks in advance!

Best regards,

[Moderator note: personal info removed]

Microsoft 365 and Office | SharePoint | Development
0 comments

2 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Jayden-P 22,305 Reputation points Microsoft External Staff Moderator
    2026-05-15T10:12:46.1466667+00:00

    Please note that our forum is a public platform, and we will modify your question to hide your personal information in the description. Kindly ensure that you hide any personal or organizational information the next time you post an error or other details to protect personal data.

    Hi KarthikeyanBalasubramani-1991

    The error you are encountering is expected due to the recent tightening of Content Security Policy (CSP) controls in SharePoint Online. Inline scripts and patterns such as unsafe-eval are no longer permitted, and Microsoft is enforcing stricter security measures across all tenants. This is aligned with updated CSP requirements, where overly permissive directives like unsafe-inline and unsafe-eval are not supported.

    Ref: Support for Content Security Policy (CSP) in SharePoint Online | Microsoft Learn

    While splitting the HTML, JavaScript, and CSS into separate files may have worked temporarily, this approach is not fully compliant with CSP. Even when scripts are referenced externally, execution patterns such as inline handlers or dynamic evaluation can still trigger violations.

    Additionally, using custom script injection is no longer recommended due to security considerations. As CSP enforcement moves towards full blocking mode starting from June 1st, 2026, these approaches will continue to fail. Security considerations of allowing custom script - SharePoint in Microsoft 365 | Microsoft Learn

    For the official and long-term supported approach, Microsoft recommend migrating to SharePoint Framework (SPFx) and using Trusted Script Sources (if applicable).

    User's image

    I hope this information helps.

    If the answer is helpful, please click "Accept Answer" and kindly upvote it. If you have extra questions about this answer, please click "Comment". 

    Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

    Was this answer helpful?

  2. AI answer

    2026-05-15T09:19:35.1666667+00:00

    Inline script is being blocked by design and will be fully enforced by SharePoint Online CSP by June 1, 2026, so the current HTML web part approach must be changed rather than trying to bypass CSP.

    Key points from the CSP behavior in SharePoint Online:

    1. Inline JavaScript is blocked
      • Any <script> block directly in HTML, inline event handlers (onclick, onload), javascript: URLs, document.write with <script>, dynamically created inline <script> tags, or scripts injected via innerHTML/insertAdjacentHTML are treated as inline script and will be blocked by CSP on modern pages.
      • This matches the error seen: Executing inline script violates the following Content Security Policy directive 'script-src 'unsafe-eval'.
    2. Recommended pattern: move all JS into external files
      • The guidance is to move inline script into external .js files, and load those files as normal script resources instead of embedding code directly in the page.
      • For SPFx-based solutions, this means:
        • Put JavaScript into bundles that are part of the SPFx package, or
        • Host JavaScript on a trusted CDN and reference it as an external script.
    3. Use SPFx instead of custom “HTML” script web parts
      • Allowing arbitrary custom script on pages is not recommended because it cannot be governed or audited and runs with the full permissions of the visiting user.
      • The recommended alternative is to implement functionality (such as charts and step views) using SharePoint Framework (SPFx) web parts or extensions, which are fully compatible with CSP.
    4. Supported ways to load scripts in SPFx under CSP If the chart solution is migrated to SPFx, there are CSP-compliant options:
      • Option 1: Deploy SPFx scripts to an external CDN
        • Configure cdnBasePath in ./config/write-manifests.json so bundles are hosted on a CDN instead of in the package.
        • When the app is installed, SharePoint Online automatically adds this CDN URL to Trusted script sources in the SharePoint Admin Center.
      • Option 2: Pull script dependencies from a CDN
        • Exclude third‑party libraries (for example, chart libraries) from the bundle and configure them under externals in ./config/config.json.
        • SharePoint Online automatically adds these external URLs to Trusted script sources when the app is installed.
      • Option 3: Dynamically load scripts with SPComponentLoader
        • For conditional loading, use SPComponentLoader.loadScript('https://some-external-site/script.js'); to load external JS from a trusted source.
      In all these options, scripts are loaded as external files, not inline code, so they comply with CSP.
    5. Inline script and HTML/script editor web parts
      • Script Editor/HTML web parts and similar custom “HTML” web parts rely on inline script and will not execute JavaScript on modern pages once CSP is enforced.
      • HTML content without script will still render, but any inline JavaScript will be blocked.
    6. Trusted script sources and external hosting
      • If chart scripts are hosted externally (for example, on a CDN), ensure the domain is added as a trusted script source.
      • SharePoint Online automatically adds cdnBasePath and externals domains for SPFx solutions to **Trusted script sources`. For any other loading mechanism, the domain must be added manually in the SharePoint Admin Center.
      • When using domain or folder-level entries, follow the documented patterns (for example, https://cdn.example.com/ with a trailing slash for a folder, or the exact file URL for a single script).
    7. Testing now with CSP enforcement
      • To validate that a new SPFx-based chart solution works under future enforcement, test pages with csp=enforce or csp=report in the URL.

    Practical migration path for the current scenario:

    1. Stop relying on the custom HTML/script web part for JavaScript.
    2. Implement the chart and step UI as an SPFx web part:
      • Move all JavaScript into the SPFx project (React or plain TypeScript/JavaScript).
      • Include CSS either in the bundle or as external stylesheets.
    3. If using third‑party chart libraries:
      • Either bundle them directly, or
      • Configure them as externals and host them on a CDN, letting SharePoint add the CDN to Trusted script sources.
    4. Remove all inline script patterns from the HTML (no <script> blocks, no onclick attributes, no javascript: URLs, no script via innerHTML).
    5. Use the CSP testing flags (csp=enforce / csp=report) to confirm the solution will continue to work after June 1, 2026.

    This approach aligns with the CSP model and avoids relying on disabling CSP, which will no longer be possible.

    References:

    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.