Sp-dev-docs: Errors reported from new content-security-policy-report-only

[nero120]

Category

• [ ] Question
• [ ] Typo
• [x] Bug
• [ ] Additional article idea

In one of our tenants we've just started seeing browser errors in the console when running SPFX web parts such as the below:

[Report Only] Refused to load the script 'https://spoprod-a.akamaihd.net/files/sp-client-prod_2018-04-13.002/sp-pages-assembly_en-us_ea66f8f8711fabe4ca8c47ac09c3d6d3.js' because it violates the following Content Security Policy directive: "script-src 'strict-dynamic' 'unsafe-eval' 'nonce-579d1bac-3fdb-4d81-b5bd-092846b8edb5' ". 'strict-dynamic' is present, so host-based whitelisting is disabled.

The errors stem from a new content-security-policy-report-only header which looks like it's been added on or after version 16.0.0.7612, as it's not present on our tenant running 16.0.0.7611 but is present on our tenant running 16.0.0.7618. The new header is:

content-security-policy-report-only: script-src 'strict-dynamic' 'unsafe-eval' 'nonce-579d1bac-3fdb-4d81-b5bd-092846b8edb5' ; report-uri https://[siteurl]/_layouts/15/CSPReporting.aspx

I realise that this is a report only and is not being enforced (though who knows if you'll suddenly change it to be enforced without warning), but it's causing errors to appear in the browser and what's even more concerning is that it's strict enough to cause the browser to refuse to load spfx scripts from Microsoft's own CDN as well as all of the library scripts we are loading from public CDNs that our SPFX web parts rely on. I'm also very concerned that these issues are being rolled out to production tenants without being caught in testing.

Also could you tell me why our non-first release tenant has a later version of SharePoint (16.0.0.7618) than our first release tenant (16.0.0.7611)?

[VesaJuvonen]

On the tenant version question - first release setting is not really controlling what is the tenant version. First release setting controls which capabilities will be enabled where first and this is not dependent on the version of the tenant. We'll also investigate the actual issue related to the security policy.

[patmill]

Hi @nero120 , we'll be releasing guidance around this shortly. As you mention, this is reporting only, so we can see what the impact would be and refine the policy (as well as make sure we are handling it correctly ourselves).

Can you tell me how you got your page to have the sp-pages js code to not be loaded correctly? Does this appear if you navigate directly to a modern page (sites/yoursite/sitepages/home.aspx) or did you navigate from the _layouts/15/SharePoint.aspx page, or a document library first?

Thanks,
Pat.

[nero120]

@VesaJuvonen oh I see. I always thought that a first/targeted release tenant would get patches/updates first, and thus we could use this feature to test our custom web parts/applications before those updates hit our production tenants. Are you saying that this is not the case? If that is so, how can we test that our production tenant web parts/applications are not broken by new updates/patches before they are rolled out?

[nero120]

@patmill I've checked today and even though the content-security-policy-report-only header is still present, we're no longer getting the errors reported in the console. Has there been another update? Looks like the nonce value has changed.

Just to clarify, the javascript files were loading, but the errors were appearing in the console as "[Report Only]".

[patmill]

@nero120 - right. They should only appear as warnings, the code should correctly execute. There shouldn't have been an update, although it is possible as we roll out changes gradually. It's also possible that you are hitting an edge case where the partial navigate (browser only, not a full server request) is winding up with a script tag without a nonce. The nonce, by definition, is a value that changes on every page request. This ensures that a malicious individual couldn't guess the nonce and inject script.

[nero120]

Ok thanks @patmill, well in any case the warnings have gone away so feel free to close this issue.

However my question to @VesaJuvonen still stands. Does Microsoft have any recommendations or best practice regarding implementing an ALM process on SharePoint Online/O365/Azure if updates/patches could be rolled out to production tenants/subscriptions at any time with no way to test them beforehand?

[luismanez]

@nero120 I'm pretty sure the "First release" just enables something like "Feature flags" (like VSTS team explains here: https://www.visualstudio.com/learn/progressive-experimentation-feature-flags/) and is not related with the updates/patches. So yeah, the problem with possible MS updates breaking our customisations is still there...

[nero120]

Absolutely @luismanez! Btw it's been a while since I last spoke to you dude, hope you're doing well! 😃

[luismanez]

All good here @nero120, hope you too. Great to see you´re also working with spfx :)

[BeccaAtAcumen]

I realize this is an old stream but we have SharePoint Server 2019 and I want to remove the CSP-ReportOnly header as it's throwing dozens of exceptions in the console due to the anonymous users not having access to _layouts/15/CSPReporting.aspx

[msft-github-bot]

Issues that have been closed & had no follow-up activity for at least 7 days are automatically locked. Please refer to our wiki for more details, including how to remediate this action if you feel this was done prematurely or in error: Issue List: Our approach to locked issues