How to Improve Your Web Application's Security Using Mozilla Observatory

Hello, everyone. Welcome to React Day Berlin. My name is Karan. I'm a front-end developer at Fabric, which is a US-based e-commerce startup.

Today I'll be talking about how to improve your web application security using Mozilla Observatory. Mozilla Observatory is a tool where you can use to evaluate your web application security headers and evaluate the security ranking of your websites. So here you can see all the security headers that Mozilla Observatory measures for your application and gives the score.

So let's go to the Mozilla Observatory and see how it looks like. So this is the site here, there are three options here. You can see, you can choose to skip publishing your results in the public records of Mozilla. Mozilla actually caches your scanned results. So if you want to force a rescan, you can click this checkbox. And if you don't want to run any third-party scanners, you can select this one. Let's enter my domain and see what the result gives us. So here you can see it will run the HTTP Observatory and it gives me the Dplus score. And here are all the security headers that it has assessed. And you can see the pass and failure status and score of each of the security header. And the reason behind a particular score is also displayed here as well. It also maintains the grade history. So whenever you make any improvements to your website and rescan the score, then you will be able to see the improved score of your website.

Let's dive into each of the security header and learn more about each of the security header. Content security policy is a very vast topic. So we'll just talk about it briefly. Basically, content security policy allows fine grained control over what resources on your site can be loaded from. It's the best way to prevent any cross site scripting vulnerabilities, commonly known as access attacks. The primary benefit of CSP is that you can disable the use of unsafe inline JavaScript, but it comes with its cons as well. You need to be very careful when implementing it in the existing websites as it may break existing functionalities. The best way to implement CSP is to start with the content security policy report only, which is a header where it will just report your violations, but it will not block any JavaScript execution. That way you can gather the information of all the violations, fix that first, and actually implement the content security policy. Cookies, you must have heard of them.

It should be secured using secure flag, so it should be sent over HTTPS only. It needs to be HTTP only cookies. That doesn't require any access from JavaScript, so it can be blocked from access by any third-party JavaScript as well.

You need to define the expiration period as well. It should be as minimum as possible. In particular, session identifier that we store in cookies should expire very quickly whenever they are no longer needed.

We can use the same set of cookies as well to block the cookies from being sent to any close origin requests. If you're a front-end developer, you must have come across course errors, so it's very important to configure your server very properly for any close origin request. It shouldn't be allowing any other domains that doesn't need that particular resources, so it should be configured properly. It shouldn't be allowing any wildcard patterns access as well.

HSTCS commonly known as HTTP strict transport security tells the browser to load the resources via HTTPS only, and redirection is also very important. You need to enable the HTTP to HTTPS redirection in your web application.

Another important point is referred policy, so whenever you visit any resource from your application, browser will send the referrer to the web server from where the request got originated. So that may be useful for some cases, but it can lead to privacy risk as well. So to control that, you can use the referrer headers in your application.

There are a few directives that you can use. The first one is no-referrer directive, which will remove the referrer from all your requests being sent to any resource. Same origin will send entire URL, but only for the same origin request. And strict origin, what it will do is it will send the origin header, but it will just send the host part. It will strip off the actual part of the page from where you requested the resource. And the recommended one is the strict origin when cross origin. So it will send the full referrer on the same origin, but a stripped version of the origin when you're making cross origin request.

So another important concept is sub-resource integrity. So it prevents attacker from altering CDN hosted JavaScript libraries that you may be using in your application. You may be using jQuery from CDN or any libraries from the unpackage.com. So in any case, the CDN gets compromised and the content of that particular file gets changed. It can maliciously run on your application and steal your data and do all kinds of attacks on your applications. So to mitigate that, you need to define the integrity of your resource. So whenever you are using any script tag, you need to generate the SHA hash for that particular resource. So whenever the content of that particular file, let's say in case of this code.jQuery.com slash this jQuery min.js file gets modified, then this integrity will not match with that modified content and the browser will skip loading this particular file on the browser.