SVG fails to render as CSP blocks inline content
Categories
(Core :: DOM: Security, defect)
Tracking
()
People
(Reporter: manday, Unassigned)
References
()
Details
Uploading an Inkscape created SVG to Github as part of a comment. The SVG renders fine, [inline in the comment]](https://github.com/osmandapp/OsmAnd/issues/16968#issuecomment-1644032252), but will fail to render correctly if opened in a separate tab, CSP interference is mentioned on the console.
W.r.t. bug 923392 I point out that the CSP headers are (of course) the same in both responses.
|
||
Comment 1•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Security' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
|
||
Updated•2 years ago
|
|
|
||
Comment 2•2 years ago
|
||
When an SVG is loaded as an "image" it's not allowed to run scripts or load external resources so it effectively gets a pass from CSP. When it's loaded as an XML "document" (in a window, frame, or inline in an HTML document) then it is treated as an XML document and the usual things get blocked. In this case several elements have an style= attribute, so the CSP would need to have style-src-attr 'unsafe-inline';. On this site there's no such directive nor style-src so it falls back to default-src 'none';
Firefox does have some SVG/CSP brokenness (e.g. bug 1459872) but in this case appears to have the same behavior as Chrome. They both give 4 errors, one each for each element with a style= attribute. Firefox appears to give a bonus 4 errors missing a "Source:" and that appears to be a reporting bug but isn't the cause of the mis-rendering.
|
|
||
Comment 3•2 years ago
|
||
Not very satisfactory, I know. Sorry. There's nothing all that dangerous about fills and strokes in this particular case, but the style attribute supports the whole CSS spec. CSP shuts it down at the attribute parsing level rather than trying to inject itself deep into the SVG spec picking and choosing "dangerous" attributes. Fundamentally CSP was created as a defense against attacks on the parser(s) via text-injection.
This issue will have to be hashed out in the spec first: https://github.com/w3c/webappsec-csp/issues
We can re-open it if that changes.
Thank you for the explanation. It seems slightly inconsistent that the SVG passes CSP as an inline image with a-priori limitations, but gets curtailed beyond those a-priori limitations where they don't exist. I would expect that CSP simply imposed the same a-priori limitations which are considered "safe" in the inline context, when the context's (XML document) own limitations are considered a-priori "unsafe".
Description
•