Repository navigation
filebrowser.aspx (Teams SharePoint list tab) ignores the tenant CSP allow-list, blocking SPFx extensions #10999
Description
Target SharePoint environment
SharePoint Online
What SharePoint development model, framework, SDK or API is this about?
💥 SharePoint Framework
Developer environment
None
What browser(s) / client(s) have you tested
- 💥 Internet Explorer
- 💥 Microsoft Edge
- 💥 Google Chrome
- 💥 FireFox
- 💥 Safari
- mobile (iOS/iPadOS)
- mobile (Android)
- not applicable
- other (enter in the "Additional environment details" area below)
Additional environment details
- SharePoint Framework: 1.22.1 (also reproduced on 1.21.1)
- Node.js: 22.14.x
- Browser: Google Chrome 151.0.7922.169 (Official Build) (64-bit)
- Microsoft Teams: web client, x-ms-client-version 1415/26041617215 at capture time
- Extension type: Application Customizer (top placeholder), deployed tenant-wide
- Solution packaging: includeClientSideAssets = false. Assets are served from an
Azure Front Door CDN endpoint (https://cdn.contoso.com/assets//), wired up
through cdnBasePath / internalModuleBaseUrls in the component manifests - Tenant configuration: that CDN origin is registered under SharePoint admin center >
Settings > Content security policy > "Trusted script sources" - Tenants affected: multiple customer tenants (this is a commercial ISV solution);
captures below are from one customer test tenant
Describe the bug / error
Two Microsoft Teams tabs are added to the same team, both pointing at the same SharePoint
site, using the built-in SharePoint tab app:
| Tab | Target | SharePoint host document | SPFx host | Application Customizer |
|---|---|---|---|---|
| A | a site page | /SitePages/Home.aspx |
sp-pages-assembly |
renders |
| B | a document library on that same site | /_layouts/15/filebrowser.aspx?app=teamsfile&scenario=teamsPage… |
ListViewHostApplication |
blocked by CSP |
Same tenant, same site, same deployed solution, same allow-listed CDN. The only difference is which
host document Teams loads, and the two documents ship different Content-Security-Policy headers.
The tenant has the CDN registered through the supported mechanism — SharePoint admin center >
Settings > Content security policy > Trusted script sources (manually added *.contoso.com, plus specific build
paths imported from the app catalog, ala. https://cdn.contoso.com/assets/24437/). Tab A honours that list; tab B ignores it.
Tab A — /sites/<site>/SitePages/Home.aspx?useTeamsAuth=true (enforced script-src, abridged):
script-src 'unsafe-eval' https://cdn.contoso.com/assets/24199/ https://cdn.contoso.com/assets/24437/
… https://cdn.contoso.com/assets/26136/ … 'nonce-<redacted>'; worker-src blob: 'self'
Tab B — /sites/<site>/_layouts/15/filebrowser.aspx?app=teamsfile&scenario=teamsPage&… (verbatim):
worker-src 'self' blob:;
script-src https://contentstorage.osi.office.net https://swx.cdn.skype.com
https://res.delve.office.com https://lpcres.delve.office.com https://widget.uservoice.com
https://by2.uservoice.com https://www.bing.com/api/maps/ https://www.bing.com/rms/
https://fabriciss.azureedge.net https://public-cdn.sharepointonline.com https://ajax.aspnetcdn.com
https://res-1.public.onecdn.static.microsoft https://res-1.public.onecdn.static.microsoft
https://res-2.public.onecdn.static.microsoft https://webshell.suite.office.com
https://amcdn.msftauth.net *.cdn.office.net *.fluidpreview.office.net *.onecdn.static.microsoft
https://res-1.cdn.office.net https://teams.microsoft.com https://js.monitor.azure.com
https://r4.res.office365.com https://res.public.onecdn.static.microsoft
https://c1-word-view-15.cdn.office.net https://loki.delve.office.com
https://res.cdn.office.net/midgard/ https://substrate.office.com
'wasm-unsafe-eval' 'nonce-<redacted>';
Console and SPFx loader output in tab B:
Loading the script 'https://cdn.contoso.com/assets/<build>/<Strings>_en-us_<hash>.js' violates the
following Content Security Policy directive: "script-src https://contentstorage.osi.office.net …
'wasm-unsafe-eval' 'nonce-<redacted>'". Note that 'script-src-elem' was not explicitly set, so
'script-src' is used as a fallback. The action has been blocked.
ListViewHostApplication SPFx loading for ListViewHostApplication
ListViewHostApplication SPFx loaded for ListViewHostApplication
NavigationOrchestrator Loading application customizers
ApplicationCustomizerLoader Loading new extensions
ListViewHostApplication [error] Script error for "<component-id>_<solution-version>/<Strings>"
SharePoint is not declining to run extensions in this host. It registers them, loads the SPFx
runtime, starts the Application Customizer, requests its assets from the tenant-approved origin, and
then blocks its own request.
Key points
- SPFx supports hosting client-side assets on a custom CDN (
cdnBasePath/
internalModuleBaseUrls), and the origin here is an Azure Front Door endpoint — a first-party
Azure CDN service, not an exotic host. - Trusted script sources is the supported, tenant-administered way to allow such an origin.
SharePoint honours it in tab A and ignores it in tab B. Same tenant, same site, same solution. - Running the same scenarios directly in SharePoint, both the A and B scenarios render on the site with their respective extensions correctly with no flagging of CSP violations.
- SharePoint's own loader issues the request that the host's CSP blocks. If extensions were not
meant to run there, the loader should not start them. - This is also a regression: the identical Teams tab setup worked on another tenant about a year ago.
Steps to reproduce
- Build an SPFx solution containing an Application Customizer that renders visible UI in the
Top
placeholder. Package it withincludeClientSideAssets: falseand setcdnBasePathto a
non-Microsoft origin — in our case an Azure Front Door endpoint
(https://cdn.contoso.com/assets/<build>/). - Upload the package to the tenant app catalog and deploy it tenant-wide.
- In SharePoint admin center > Settings > Content security policy, add that origin under
Trusted script sources. - Verify in a browser that the customizer renders on the site — open
https://<tenant>.sharepoint.com/sites/<site>; the top placeholder is shown. - In Microsoft Teams, open a team connected to that site and add two tabs with the built-in
SharePoint app:- Tab A → a site page (e.g. the site home page)
- Tab B → a document library or list on the same site
- Open each tab with DevTools attached to the embedded frame.
Observed: tab A renders the customizer; its script-src contains the Trusted script sources
entries. Tab B does not; its script-src contains only Microsoft origins plus a nonce, the CDN
requests show status 0, and the console logs the CSP violation and the SPFx Script error.
Expected behavior
Expected: the Application Customizer renders in tab B exactly as it does in tab A.
/_layouts/15/filebrowser.aspx should build its script-src the same way SharePoint site pages do, honouring the tenant's Trusted script sources so
that SPFx extensions deployed tenant-wide load there regardless of where their assets are hosted.
Activity
Ashlesha-MSFT commentedon Aug 21, 2026
Thank you for the detailed report. We reviewed this against the previously confirmed behavior in #10140.
SharePoint list and library tabs in Teams use the filebrowser.aspx experience, which currently does not support SPFx extensibility. Therefore, tenant Trusted Script Sources are not applied to enable SPFx extensions in that host. The SPFx loader attempting to initialize extensions does not make this a supported extension surface.
As a supported workaround, add the list or library to a modern SharePoint page using the List or Document Library web part, and add that page as the Teams tab. Alternatively, users can open the list/library directly in SharePoint.
Changing to includeClientSideAssets: true might avoid this specific external-CDN CSP block, but it would not make extensibility in filebrowser.aspx supported or reliable, so it is not a recommended resolution.
A change would be a feature request. Customers with Premium Support can submit a Design Change Request, or the request can be posted to the SharePoint Community Feedback Portal.
MortenGuldbaek commentedon Aug 24, 2026
Ashlesha-MSFT Thanks for the response and for linking #10140.
One correction based on that issue. The scripts blocked in #10140 are app catalog assets (/sites/AppCatalog/ClientSideAssets/...), i.e. includeClientSideAssets: true, blocked by the same filebrowser.aspx policy. Repackaging does not avoid the block.
On the workaround: adding each list or library to a site page via the List or Document Library web part, synching it out to all sites and then changing the Teams tab to show the site page instead is a major task. We ship a commercial solution across many tenants, so it becomes a manual step per list, per library, per team, and it changes the customer's information architecture to work around a host limitation.
Separately, I would like to keep one part of this as a defect rather than folding it into a feature request. If filebrowser.aspx is not an extensibility surface, SharePoint's own loader should not enumerate and initialise extensions there.
As shown in the issue, it does:
SPFx loaded for ListViewHostApplication -> Loading application customizers -> Loading new extensions -> Script error.Extensions are deployed tenant-wide by design, so this happens unprompted in every tenant with any SPFx extension installed, and it produces permanent console errors that neither the administrator nor we can suppress. It also makes the host indistinguishable from a genuine load failure when we diagnose customer reports. Not initialising extensions in a host that cannot load them looks like a contained fix that does not depend on the design change.
Lastly: where is this documented? I cannot find the limitation in the SPFx extension documentation, and the Trusted script sources admin UI gives no indication that entries are ignored in this host.