CODEWITHSUNDEEP
svghttp-headerscontent-security-policyinkscape
fabianegli
fabianegli

Reputation: 2246

Allow SVGs in Content Security Policy without 'unsafe-eval'

SVGs are an important part of the web. Is there a way to have SVGs created in Inkscape work with secure settings of the Content Security Policy header?

There are multiple "http://..." links in my SVGs, that are apparently required and the SVG is not displayed correctly any more when they are changed "https".

These are some of the links in my SVGs:

xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns="http://www.w3.org/2000/svg"
xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
rdf:resource="http://purl.org/dc/dcmitype/StillImage"

I thought about replacing the links with links that I serve myself and return a copy of the original linked resources but I believe that this is not the point of these links. Is it?

Is there a way to modify such SVGs to completely drop the links?

Upvotes: 1

Views: 914

Answers (2)

ccprog
ccprog

Reputation: 21836

The "links" you list are only links in a very peculiar sense of the word. They are namespace declarations that identify which XML dialect a certain element or attribute belongs to.

Yes, the addresses in these links exist. But they will never be called. Only "validating XML interpreters" will do that, and browsers are not among them. Browsers take these "links" only as unique strings. If they know the strings, they will render content according to the dialect they represent. If not, the element/attribute will be entered into the DOM, but ignored for the actual rendering - just like a custom element the browser does not know.

There are two namespaces in SVG files provided by Inkscape that browsers will understand:

  • xmlns="http://www.w3.org/2000/svg"
  • xmlns:xlink="http://www.w3.org/1999/xlink"

They tell the browser a standalone file is SVG. They must be included (yes, that is a bit simplified for xlink), but have no bearing at all on CSP.

Upvotes: 2

fabianegli
fabianegli

Reputation: 2246

I found that my problem was actually of a different nature and I asked the wrong question. My problem is related to style="fill:..." in SVGs which resulted in completely black renderings of the SVG in the Browser. This is apparently a known bug in Firefox and there is a seemingly good workaround (that also addresses additional security threats) by setting separate CSP headers for SVG resources.

Upvotes: 0

Related Questions