Is including the data scheme in your Content Security Policy safe?

Question

I have a Cordova app that transforms some images to base64. This violates CSP with this message:

Refused to load the image 'data:image/svg+xml;charset=US-ASCII,%3C%3Fxml%20version%3D%221.0%22%20encod…E%3C%2Fg%...%3C%2Fsvg%3E' because it violates the following Content Security Policy directive: "default-src 'self'". Note that 'img-src' was not explicitly set, so 'default-src' is used as a fallback.

According to this answer, I can simply add data: to my Content-Security-Policy meta, but I would very much like to know, if this is safe? data: does not specify origin and therefore I fear it's unsafe.

Answer 1

This is a great question, and I commend you taking the time to think about this from a security perspective rather than knee-jerk implement the solution from the link you sent.

Yes, as you have feared, use of data: in a CSP directive is unsafe, since this allows for XSS vulnerabilities to be opened up as data: can handle any URI. This is spelled out in Mozilla's CSP Documentation. and in this W3C Working Draft

There is no way in CSP to specify "allow only SVG images to be embedded via data URIs, but no any other type of URIs". CSP just lets you specify data:.

As a best practice I would endeavor to address the root issue about the images being provided as base64 and see if that can be done another way so as not to require modification of the CSP directive.

Answer 2

1. The note on whitelisting the data protocol which is referenced says

   data: Allows data: URIs to be used as a content source. This is insecure; an attacker can also inject arbitrary data: URIs. Use this sparingly and definitely not for scripts.

This is not in a part specific to the risks of data URIs in images, and I have not seen any substantive evidence that data URIs in images can execute code in a modern browser any respect, never mind XSS a page.

In certain contexts, an SVG image can execute Javascript code, but these are either child contexts such as <iframe>, <object> or <embed> elements, or a direct part of the host DOM i.e. <svg> elements.

MDN calls out explicitly that <img> embedded SVGs cannot execute Javascript, along with some other security restrictions, saying

• JavaScript is disabled.
• External resources (e.g. images, stylesheets) cannot be loaded, though they can be used if inlined through data: URIs.
• :visited-link styles aren't rendered.
• Platform-native widget styling (based on OS theme) is disabled.

2. It doesn't appear to be possible to specify a MIME as part of the data: protocol whitelisting statement as suggested as a possible mitigation. The only content security policy directive I've seen able to restrict MIME type is plugin-types, which restricts only for <object> and <embed> (see general CSP docs).

I will agree with the accepted answer in the respect that if you don't have to use data-uris, and can do so with little pain, it's easier to just keep your CSP and not use them. However, if you're working with images at all, that is usually a huge pain.