Localhost debugging with CSP Update

Hi Tim Hölsken

Thank you for reaching out to Microsoft Q&A forum

Based on your description, I have conducted some research and from my perspective view, your concerns are completely valid from a security perspective, and you are not overthinking it.

Technically, trusting localhost tenant-wide conceptually opens a small window where, if an attacker could somehow inject a reference to https://localhost:4321/malicious.js into your SharePoint environment, any user who happens to be running a compromised local server on that exact port could be vulnerable.

However, to answer your technical questions directly:

1. Is there a mechanism to enable this only in an SPFx context or for a specific site collection?

Unfortunately, NO, currently, the Content Security Policy (CSP) enforcement in SharePoint Online relies on the "Trusted Script Sources" list in the SharePoint Admin Center, which is strictly a tenant-wide setting. There is no granular control to scope trusted domains down to a specific site collection, hub site, or exclusively for the SPFx execution context.

2. Is there another approach to isolate the trustworthiness of localhost?

As far as I know, since SharePoint doesn't offer a built-in scoping mechanism for CSP, you have a few ways to approach this based on best practices:

• Use a Dedicated Developer Tenant: Microsoft's strong recommendation for SPFx development is to use a dedicated M365 Developer Tenant (which you can get for free via the Microsoft 365 Developer Program) rather than testing directly in your Production tenant. In a Dev tenant, adding https://localhost:4321 to the tenant-wide Trusted Script Sources is completely safe and is the intended workflow. You should ideally never need to test gulp serve directly against your live Production tenant.
• Remove it when not developing: If you are forced to do local development against a Production or shared Staging tenant, the only way to minimize the attack surface is operational: add https://localhost:4321 to the Trusted Script Sources when you begin a development session and actively remove it from the Admin Center when you are finished.
• Use ngrok/Dev Tunnels: Instead of trusting localhost, you can use a tunneling service like ngrok or Microsoft Dev Tunnels to expose your local 4321 port to a secure, randomly generated public HTTPS URL. You can then add that specific URL to the Trusted Script Sources. When your development session ends, the tunnel is destroyed, and the URL becomes permanently useless, naturally isolating the trustworthiness. (Note: This does require slightly adjusting your SPFx write-manifests.json CDN path to point to the tunnel).

In the nutshell, while the theoretical risk of trusting localhost:4321 is relatively low, you are right to be cautious about tenant-wide security settings. The ultimate solution is restricting gulp serve workflows to dedicated Developer Tenants where tenant-wide settings do not impact production security.

You can read here for more information:

Support for Content Security Policy (CSP) in SharePoint Online

How SharePoint and OneDrive safeguard your data in the cloud

Hope my answer will help you.

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.  

CSP enforcement in SharePoint Online affects only scripts that are loaded as part of normal page rendering. The SPFx localhost debugging story remains supported and is handled separately from tenant-wide trusted script sources.

Key points from the current CSP behavior in SharePoint Online:

1. CSP is in report-only mode today CSP is currently rolled out in SharePoint Online in reporting mode and does not yet block solutions. Enforcement starts March 1, 2026.
2. Localhost debugging is an explicit, opt‑in debug path For SPFx development, localhost resources are loaded only when explicitly requested via the debug query string parameters such as:

      ?loadSPFX=true&debugManifestsFile=https://localhost:4321/temp/build/manifests.js&customActions=...
   

   or

      ?loadSpfx=true&debugManifestsFile=https://localhost:4321/temp/build/manifests.js&customActions=...
   

   In this mode, SharePoint prompts with an "Allow debug scripts?" dialog and requires explicit consent to load code from https://localhost:4321.
3. Localhost debugging is not tied to tenant trusted script sources The CSP article and the trusted script sources mechanism focus on production SPFx solutions and external script locations. Localhost debugging uses the SPFx debug pipeline with query string flags and the consent dialog, not the tenant trusted script sources list.
4. Security boundary for localhost debugging The official guidance explicitly warns that debugging SPFx solutions on modern pages in a production tenant allows execution of unverified code and should be used carefully. This is the primary security control: only developers who deliberately add the debug query string and accept the prompt can run localhost code.
5. No per–site collection CSP override is documented The CSP documentation describes tenant-level behavior and a tenant-level delay switch:

      Set-SPOTenant -DelayContentSecurityPolicyEnforcement $true
      (Get-SPOTenant).DelayContentSecurityPolicyEnforcement
   

   There is no documented mechanism in the provided material to scope CSP trusted script sources or CSP enforcement to a specific site collection.

Practical implications for the scenario:

• For normal SPFx development and debugging with heft start --nobrowser and the debug query string, localhost is already isolated by the explicit debug flags and the "Allow debug scripts" consent prompt.
• The documentation does not require adding localhost to tenant-wide trusted script sources for this debug scenario, nor does it provide a per–site collection CSP override.
• The main recommended mitigation is to avoid using the localhost debug mechanism on production sites except when strictly necessary, and only by trusted developers.

From the available documentation, the concerns about having to globally trust localhost for the whole tenant are not reflected in the official SPFx debug guidance; localhost debugging is treated as a separate, opt‑in development path rather than a tenant-level trusted script source.

References:

• Support for Content Security Policy (CSP) in SharePoint Online
• Debug SharePoint Framework solutions on modern SharePoint pages
• Migrating from UserCustomAction to SharePoint Framework extensions
• Migrate Edit Control Block (ECB) menu items to SharePoint Framework extensions