Content Security Policy error in XML parsing in Chrome

• Package Name: azure/core
• Package Version: Unknown, but code introduced in https://github.com/Azure/azure-sdk-for-js/commit/d1bc00b00199f0bebcb52d064b7a12df90436c8e#diff-9e0e581981750681d3bfa10a039c1cae8e0aaba5193c40352eec62a20d3b6660R20
• Operating system: All
• nodejs
  • version:
• browser
  • name/version: Google Chrome 86.0 (released October 6th) and later
• typescript
  • version:
• Is the bug related to documentation in
  • README.md
  • source code documentation
  • SDK API docs on https://docs.microsoft.com

Describe the bug The Azure SDK for JavaScript includes a utility module for XML parsing. As part of initializing the module, it attempts to parse an invalid XML string at https://github.com/Azure/azure-sdk-for-js/blob/0f1c73f76331d23efb61c9f636ee2d2338b8e113/sdk/core/core-http/src/util/xml.browser.ts#L35 In most browsers, this returns a document containing a <parseerror> element describing the error. The error document contains inline styles which the browser interprets. In version 86.0 and newer of Chrome (https://bugs.chromium.org/p/chromium/issues/detail?id=1148221), the error document inherits the Content Security Policy from the owner document. Therefore, on pages with a Content Security Policy with a style-src directive not including unsafe-inline, Azure SDK for JavaScript causes a CSP error to be reported and shown in the console.

To Reproduce Steps to reproduce the behavior:

1. Set up a page with a Content Security Policy with a style-src directive not containing unsafe-inline, for example style-src: 'self'.
2. Load the Azure SDK for JavaScript.
3. Open page in Google Chrome version 86.0 or newer.
4. Look for Content Security Policy error in console.

Expected behavior No Content Security Policy error should be shown in the console.

Screenshots

Additional context I’m unsure if and when the issue in Chrome will be fixed. Until it is fixed, the XML parser module will necessarily cause a Content Security Policy error when parsing an invalid XML string on sites with the relevant policy. However, since XML parsing errors are likely not expected during normal usage of the library, it would still be beneficial to prevent the CSP error on load to save developer effort in debugging it.

Potential fixes could be to:

1. Lazily testing for browser behavior when first parsing error is encountered, instead of at module load.
2. Removing the check for browser behavior completely and always querying for the parsererror element, even in Internet Explorer.

[jeremymeng]

This has been published in @azure/core-http v1.2.3

[jeremymeng]

One possibility could be to do a non-namespace-aware (getElementsByTagName) search for parserelement when parsing and then, if any are found, check each of their namespaces against a lazily computed (and potentially cached) error namespace.

Yes, this is exactly the same as I planned to do. Also thanks for the code snippets @kimsey0!