Q15: Content Security Policy CSP Header

[00:00:00]
>> All right, which resources will be allowed with following content Content Security Policy header? Is it A, a script like a local script, B, fetching from api.website.com, a font face with fonts, or like just loading local fonts? I'll just say it like that. A data URI image, an inline style, an iframe that embeds from embed.example.com, a stylesheet from fonts.googleapis.com, or a video from videos.example.com?

[00:00:32]
All right, so let's look at the answer. The answer is we can only load our local scripts and the stylesheet from fonts.googleapis.com. So with a Content Security Policy header, we can control where our website can load resources from. So we can do this for scripts, images, fonts, stylesheets, video, audio embedded content, iframes, web and service workers, fetch and web sockets, and form submissions.

[00:00:59]
Now by default here, we say default-src none. So this basically sets everything to none. We can not load any resources, not even local resources, nothing, we cannot do anything. But we can override this with, in this case, a script-src, sorry about that, which I set it to self, very subtle.

[00:01:18]
So in this case, we're saying scripts can only be loaded from the same origin, from our website, not from any other location. Then we set img-src to self, so we can load images from the same origin, but also from the example.com domain. We set the style-src only to fonts.googleapis.com.

[00:01:38]
So it can only fetch from fonts.googleapis.com, not from your own fonts, no, only from that domain. And then the style sheet, sorry, it says CSS from there, and then the fonts from gstatic or fonts.gstatic.com. So also not from self, just from fonts.gstatic. So if we now compare that, first we have, well, our local scripts.

[00:02:01]
And this is allowed because we have the script-src self. So we just said that it's okay to load resources from the same origin or yeah, from your own website. That's totally fine. But then we make a fetch request to api.website.com, but we have the connect src still to none because we didn't specify any overrides.

[00:02:18]
So it defaulted back to that default-src. So that'll be blocked by the Content Security Policy. Same for font-face, we only set okay, you can load fonts from fonts.gstatic.com but not from your own fonts, not from your own domain. So this one gets blocked. For images, this is a bit deceiving cuz you think, okay, it's a data image, is this self, it's not.

[00:02:39]
So with img-src, you need to then define the data. You need to add the data attribute to img-src to allow these base 64 images as well. So this one is blocked because we don't have that data in the CSB policy. Then we have inline styles also not allowed because we only specify that styles we come from fonts.googleapis.com, and this includes inline styles.

[00:03:04]
Then we have iframes, frame-src is none, so we cannot embed anything. Finally, we have stylesheet. This is allowed because we're fetching it from fonts.googleapis.com so that domain is allowed. And then lastly, we have video, which is the media-src, we also set that to none. So this one will be blocked.

[00:03:22]
Yeah, I'll just keep it on this one. So yeah, the Content Security Policy is just a great way to really fully control where a website can load resources from to prevent any attacks like cross-site scripting, all that kind of stuff. Especially important when you're working at the bank or anything that uses very sensitive data.

[00:03:43]
Making sure that if you know exactly where your resources are coming from, setting up a Content Security Policy, either in like a metatag or as a response header is a great way to ensure that your website is a bit more secure, yes.