Content-Security-Policy: img-src 'self' https: data:;
I would read that out loud as "images can be loaded from the current domain, or any https://
url, or are data://
url".
So having https:
basically means that images can be loaded by reference from any 3rd party website. In this day and age, that's basically all websites. So that sorta defeats the purpose of having this directive in the first place.
data:
is a bit more subtle; this is intended if you want to embed an image directly into an HTML document; ie you don't want the page to make an external GET to fetch the image. W3Docs give this example which is the data for a 5x5 pixel red dot.
<img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4
//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot" />
Embedding an image of any reasonable size will be much larger, for example here is my StackExchange avatar (some random site, not sure if this link will go dead at some point).
So again, allowing data:
kinda defeats the whole point of this CSP directive.
What's the point of CSP: img-src anyway?
Content-Security-Policy is generally viewed as a second line of defense against XSS; say an attacker has found a bug in your UI that lets them inject arbitrary javascript into the page that users load; having a tight CSP on your page can sandbox what that malicious javascript can do.
I think the point of the img-src
directive is to prevent:
- Website defacement: embedding images into your page that are unprofessional, lead to phishing, or otherwise damage your website.
- Exploit vulnerabilities in a client's image parser. Historically there have been, for example, buffer overflows in the Android media parser, and an attacker may be embedding a crafted jpeg on your webpage with the goal of taking over devices of your users.
You'll have to decide for yourself whether the legitimate functionality of your website needs the UI client to be able to load images from arbitrary https URLs, or to directly embed data: encoded images, but if you don't, then you should probably take out those CSP directives in order to maximize the protection you're getting from your CSP.