Hello and welcome to Secure JavaScript Programming with Vladimir de Turckheim. In this video, you won't see me on the webcam because I have to show you stuff at the bottom of the screen and my face would be hiding the important bits. We have a simple web page that actually loads an image from somewhere on the Internet and that loads a script locally. The script actually just logs, I am index.js. If we start the sever serving that and we reload, we see that the image is not rendered so we give an HTML, maybe there's an error here. If we check the "Console", the script is not loaded. It should have been loading, Hello, I am index.js. Here, Google Chrome tell us that there are issues, so lets check what these issues are. Content security policy on your website blocks some resources because their origin is not included in the content security policy header. We've got two directives that actually prevented the loading of index.js and/or image. Let's check that. If we go to the "Network" tab, close the issue, reload the page, we see that the image and the script have tried to be loaded, the browser will try it but it's written, blocked CSP. In this server, I'm adding to each request this CSP policy. CSP stands for content security policy and it's one of the most powerful way in JavaScript, in modern web, to actually prevent all kinds of unfaithful resource loading. Here, I've written it on multiple lines but actually when I render it in the header, they're all on one line under the content security policy header, script source, none, image source, self. What does that mean? That means that this page is not allowed to load any script by default. It can't. It can't execute JavaScript. It can't load JavaScript and that it can only load images from its host. You cannot remotely load images, but you could save images through the same web sever. If the image was local, it would work. To fix the script part, based on what they just said, maybe if we put script, self, it will work. Actually, yes, the script has loaded, I am index.js, and the image is still not loaded. You can have multiple targets for CSP. So let's say I want to integrate jQuery into my app. I know nobody has said that in a long time. I mean, jQuery's super cool. Let's reload this page and then here we see that it refused to load jQuery because it violates the CSP policy. Let me update the CSP, not the CSP polices, CSP and reload and now it actually accepted to load it. But now it's the jQuery part that is not load. Yes, of course. Because you have to allow a domain. Let's try again. Still not? I'm not sure why this one is not loading. Let's audit the CSP. You even have the right to load. Oh, that's because it should not be with quotes. Here we are. Now, jQuery has been loaded into my app. If I check the network, jQuery has been faithfully loaded. Because for URLs, you can't put quotes. There are directives for a lot of other things. You've got child-src, which is to create new JavaScript environment, whether it's a frame, an iframe or worker, connect-src. You decide which URLs can be loading script. Default for fetch font tuning it into as font come from, image we seen, media for other media, objects for specific media too, script src that we have seen, style src to prevent cross loading styles, worker src and a lot of them that are still experimental. That's actually very powerful because it means that even if your front-end application is compromised and someone can run arbitrary stuff in it, that will fail. I don't know if you remember, but there is a very common way of doing XSS to exfiltrate a cookie. That is document.getElementById, you get any element, and then you innerHTML equals, and then you insert an image then you do httpsmalicious.com/, and here you put document.cookie, and of course you close the statement. When this image is actually trying to be loaded by the remote server, the cookie will be leaked to a meshes remote server. Well, thanks to content security policy, even that attack is not possible anymore. Whether CSP are really hard to maintain in a world where you add more and more dependencies from diverse sources in your project. That's why it first makes sense to bend earlier app so you don't depend on external code dependencies such as cheek jQuery. You have it loaded from your server directly. That's why you should not trust remote loading stuff. Also, this means that if you want to load third-party assets, you need to know their origin for all of them. That's actually complicated. There's also what's called report directives. There are two of them went at his name, report URI that is duplicated but still maintained and report 2 that is experimental and not implemented everywhere. Let me show you just for the sake of this, what report URI writers. Here I will still have have my unfaithful policy because we will try to load a remote image. I will put report URI to report. I could put a fully qualified URI, but let's just put a slash report. Now if I refresh the page and I go to network, I see that there is a call to slash report. look at it. That's a past requests that actually sends a JSON object Content-Type CSP report. This CSP report is an object containing details about the violation. Here, we've got to URL that has been blocked. We are in the enforce mode so directives that has been compromised with MGSSC, we have the line and we've got the original policies so we know what failed. We could actually go back to our own first policy or let's just remove jQuery from the policy. Now, we have two reports. One from the image and one for jQuery that have been evaluation for jQuery loading. Based on that you can build a server to handle CSP violations or have a third party service monitor that for you. It's actually very important when you go with CSP that you monitor violations. Not because that will tell you about hackers which is a good thing, you would be able to know when there're XSS's including DOM Based XSS's in your app, but also because it's really hard to make a mistake and to add a new asset that would not be in the CSP. In that case, well, you want to know it quickly. Actually, there is also a report-only mode that tells that you don't want it to be enforced. Let's change the name of our header in the server. Let's restart it. Now, if we restart the page, it says that the image failed because of another mistake, but that's not because of the CSP. That jQuery loaded, however we still got the report. If you have been closely following, I had to change the name of the header containing the CSP, meaning that you could have a reportedly an end block CSP policy at the same time. Meaning that for instance, when you are not sure that something is fully mature enough, you can put it in report-only. They're although very end full directives, block all mixed content, prevent to load asset over HTTP when the load of page is in HTTPS. We also have trusted types but I don't want to spoil the next video that will go in depth about what trusted types is. As you noticed in this video, I've been cheating and going through the MDM documentation. Well, there are a lot of things to know about CSP and the main goal here was to explain to you how they work. The detail of all of that is so complex that it actually had to build a CSP policy, a policy by hand, a CSP or CSP policy. There is a module in node named helmet CSP that actually enable you to put multiple CSP in a friendlier way. Also, there is something I forgot to mention, is that thanks to a content security policy, you can also block inline script. Well, in order to allow them, you can use hash to tell exactly which script is allowed. If we click on this documentation, there must be something that hash. You can actually provide as a value in the CSP hash with announce to say, "This script that follows this hash is actually valid and executable." That's even more constraining and I would recommend to have a pipeline in prediction for deploying that to not have inline script. Now we have learned how CSP, our content security policy, can be used to prevent loading external resources. In the next video about trusted types, we will see how a CSP, a content security policy can actually be used to dynamically update malicious code. I hope you enjoyed this video, see you soon and have a great evening.
