New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Content Security Policy error in XML parsing in Chrome #13268
Comments
@kimsey0 Thank you for the report! We will looking into this shortly. |
note: I was able to repro by adding the following to my html <meta http-equiv="Content-Security-Policy" content="style-src 'self'"> |
When our module is loaded, we try to parse an invalid xml document then save the namespace of the element in the parsed result to After every time we parse an xml document, we check whether it contains errors by using the saved error namespace I agree with @kimsey0 that we could remove the browser check since in IE, an error would have been thrown from parsing in the error cases, we wouldn't even get to check whether we probably still to search using the same namespace, because there's a possibility that element is part of a valid xml document. |
Unfortunately, Chrome and Firefox return different error documents. Firefox has the I think every solution is going to be a workaround. One possibility could be to do a non-namespace-aware ( |
Basically, something like this: let errorNS = "";
function throwIfError(dom: Document): void {
const parserErrors = dom.getElementsByTagName("parsererror");
if (parserErrors.length) {
if (!errorNS) {
try {
errorNS = parser.parseFromString("INVALID", "text/xml").getElementsByTagName("parsererror")[0]
.namespaceURI!;
} catch (ignored) {
// Most browsers will return a document containing <parsererror>, but IE will throw.
}
}
for (let i = 0; i < parserErrors.length; i++) {
if (parserErrors[i].namespaceURI === errorNS) {
throw new Error(parserErrors[i].innerHTML);
}
}
}
} |
Yes, this is exactly the same as I planned to do. Also thanks for the code snippets @kimsey0! |
We eagerly save the namespace of "parsererror" element on module load. It's unnecessary because in most scenarios we would not encounter a parse error. Furthermore, it caused Content Security Policy error in Chrome version 86.0 or newer because the returned DOM object for parser errors contains some CSS styles. This change fixes the issue by lazily loading the error namespace when the parsed DOM document contains "parsererror" elements. Fixes Azure#13268
We eagerly save the namespace of "parsererror" element on module load. It's unnecessary because in most scenarios we would not encounter a parse error. Furthermore, it caused Content Security Policy error in Chrome version 86.0 or newer because the returned DOM object for parser errors contains some CSS styles. This change fixes the issue by lazily loading the error namespace when the parsed DOM document contains "parsererror" elements. Fixes Azure#13268
We eagerly save the namespace of "parsererror" element on module load. It's unnecessary because in most scenarios we would not encounter a parse error. Furthermore, it caused Content Security Policy error in Chrome version 86.0 or newer because the returned DOM object for parser errors contains some CSS styles. This change fixes the issue by lazily loading the error namespace when the parsed DOM document contains "parsererror" elements. Fixes Azure#13268
We eagerly save the namespace of "parsererror" element on module load. It's unnecessary because in most scenarios we would not encounter a parse error. Furthermore, it caused Content Security Policy error in Chrome version 86.0 or newer because the returned DOM object for parser errors contains some CSS styles. This change fixes the issue by lazily loading the error namespace when the parsed DOM document contains "parsererror" elements. Fixes #13268
This has been published in @azure/core-http v1.2.3 |
Thank you! We upgraded earlier today (but have some unrelated CORS errors, #13658). |
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
azure-sdk-for-js/sdk/core/core-http/src/util/xml.browser.ts
Line 35 in 0f1c73f
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 astyle-src
directive not includingunsafe-inline
, Azure SDK for JavaScript causes a CSP error to be reported and shown in the console.To Reproduce
Steps to reproduce the behavior:
style-src
directive not containingunsafe-inline
, for examplestyle-src: 'self'
.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:
parsererror
element, even in Internet Explorer.The text was updated successfully, but these errors were encountered: