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

Rate this content

In today's digital landscape, web application security is of paramount importance to protect sensitive user data and maintain user trust. The Mozilla Observatory is a powerful tool that can help developers assess the security posture of their web applications. In this talk we'll learn how to improve the security of web applications using the Mozilla Observatory. 

9 min
12 Dec, 2023

AI Generated Video Summary

The Talk discusses how to improve web application security using Mozilla Observatory. It covers topics such as evaluating security headers, maintaining grade history, and implementing content security policies. The importance of securing cookies and enabling HTTP to HTTPS redirection is emphasized. The use of referrer headers to control browser behavior and sub-resource integrity to prevent compromising files are also highlighted.

1. Introduction to Mozilla Observatory

Short description:

Welcome to React Day Berlin. Today I'll be talking about how to improve web application security using Mozilla Observatory. It evaluates security headers and ranking. Let's go to the Mozilla Observatory and see how it looks. You can skip publishing results and force a rescan. It gives the Dplus score and assesses security headers. It maintains grade history. Content security policy allows fine-grained control over loaded resources. It prevents cross-site scripting vulnerabilities. Be careful when implementing it in existing websites. Start with the content security policy report only. Cookies are also important.

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.

2. Securing Cookies and Redirection

Short description:

It should be secured using secure flag and sent over HTTPS only. Define minimum expiration period for session identifier cookies. Configure server properly for close origin requests. Enable HTTP to HTTPS redirection.

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.

3. Referrer Headers and Sub-resource Integrity

Short description:

Whenever you visit a resource from your application, the browser sends the referrer to the web server. To control this, use the referrer headers. There are different directives available, such as no-referrer, same origin, and strict origin. Sub-resource integrity prevents attackers from altering CDN hosted JavaScript libraries. By defining the integrity of your resource using the SHA hash, the browser can detect modifications and prevent loading compromised files.

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 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 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.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Node Congress 2022Node Congress 2022
26 min
It's a Jungle Out There: What's Really Going on Inside Your Node_Modules Folder
Do you know what’s really going on in your node_modules folder? Software supply chain attacks have exploded over the past 12 months and they’re only accelerating in 2022 and beyond. We’ll dive into examples of recent supply chain attacks and what concrete steps you can take to protect your team from this emerging threat.
You can check the slides for Feross' talk here.
JSNation 2023JSNation 2023
30 min
The State of Passwordless Auth on the Web
Can we get rid of passwords yet? They make for a poor user experience and users are notoriously bad with them. The advent of WebAuthn has brought a passwordless world closer, but where do we really stand?
In this talk we'll explore the current user experience of WebAuthn and the requirements a user has to fulfill for them to authenticate without a password. We'll also explore the fallbacks and safeguards we can use to make the password experience better and more secure. By the end of the session you'll have a vision for how authentication could look in the future and a blueprint for how to build the best auth experience today.
React Advanced Conference 2021React Advanced Conference 2021
22 min
Let Me Show You How React Applications Get Hacked in the Real-World
Modern frontend frameworks like React are well thought-of in their application security design and that’s great. However, there is still plenty of room for developers to make mistakes and use insecure APIs, vulnerable components, or generally do the wrong thing that turns user input into a Cross-site Scripting vulnerability (XSS). Let me show you how React applications get hacked in the real-world.
JSNation 2023JSNation 2023
22 min
5 Ways You Could Have Hacked Node.js
All languages are or were vulnerable to some kind of threat. I’m part of the Node.js Security team and during the year 2022, we've performed many Security Releases and some of them were really hard to think about.
Did you know you can make money by finding critical vulnerabilities in Node.js? In this talk, I’ll show you 5 ways you can have hacked Node.js and how the Node.js team deals with vulnerabilities.
JSNation Live 2021JSNation Live 2021
9 min
Securing Node.js APIs with Decentralised Identity Tokens
Authentication and Authorization are serious problems. We often dedicate a lot of time to craft powerful APIs but overlook proper security measures. Let's solve it with Magic using a key-based identity solution built on top of DID standard, where users’ identities are self-sovereign leveraging blockchain public-private key pairs. In this talk, we’ll look at proper ways to secure our Node.js APIs with Decentralised Identity Tokens. We’ll go from learning what Decentralised Identity standards are, how the users’ identities are self-sovereign leveraging blockchain public-private key pairs, why they’re the future of API security, and to put theory into practice we will build a real-world implementation using Node.js where I’ll show common best practices.

Workshops on related topic

React Summit 2023React Summit 2023
56 min
0 to Auth in an hour with ReactJS
Passwordless authentication may seem complex, but it is simple to add it to any app using the right tool. There are multiple alternatives that are much better than passwords to identify and authenticate your users - including SSO, SAML, OAuth, Magic Links, One-Time Passwords, and Authenticator Apps.
While addressing security aspects and avoiding common pitfalls, we will enhance a full-stack JS application (Node.js backend + React frontend) to authenticate users with OAuth (social login) and One Time Passwords (email), including:- User authentication - Managing user interactions, returning session / refresh JWTs- Session management and validation - Storing the session securely for subsequent client requests, validating / refreshing sessions- Basic Authorization - extracting and validating claims from the session token JWT and handling authorization in backend flows
At the end of the workshop, we will also touch other approaches of authentication implementation with Descope - using frontend or backend SDKs.
JSNation 2022JSNation 2022
99 min
Finding, Hacking and fixing your NodeJS Vulnerabilities with Snyk
npm and security, how much do you know about your dependencies?Hack-along, live hacking of a vulnerable Node app, Vulnerabilities from both Open source and written code. Encouraged to download the application and hack along with us.Fixing the issues and an introduction to Snyk with a demo.Open questions.
DevOps.js Conf 2022DevOps.js Conf 2022
76 min
Bring Code Quality and Security to your CI/CD pipeline
In this workshop we will go through all the aspects and stages when integrating your project into Code Quality and Security Ecosystem. We will take a simple web-application as a starting point and create a CI pipeline triggering code quality monitoring for it. We will do a full development cycle starting from coding in the IDE and opening a Pull Request and I will show you how you can control the quality at those stages. At the end of the workshop you will be ready to enable such integration for your own projects.
TestJS Summit 2021TestJS Summit 2021
111 min
JS Security Testing Automation for Developers on Every Build
As a developer, you need to deliver fast, and you simply don't have the time to constantly think about security. Still, if something goes wrong it's your job to fix it, but security testing blocks your automation, creates bottlenecks and just delays releases...but it doesn't have to...

NeuraLegion's developer-first Dynamic Application Security Testing (DAST) scanner enables developers to detect, prioritise and remediate security issues EARLY, on every commit, with NO false positives/alerts, without slowing you down.

Join this workshop to learn different ways developers can access Nexploit & start scanning without leaving the terminal!

We will be going through the set up end-to-end, whilst setting up a pipeline, running security tests and looking at the results.

Table of contents:
- What developer-first DAST (Dynamic Application Security Testing) actually is and how it works
- See where and how a modern, accurate dev-first DAST fits in the CI/CD
- Integrate NeuraLegion's Nexploit scanner with GitHub Actions
- Understand how modern applications, APIs and authentication mechanisms can be tested
- Fork a repo, set up a pipeline, run security tests and look at the results
DevOps.js Conf 2022DevOps.js Conf 2022
32 min
Passwordless Auth to Servers: hands on with ASA
These days, you don't need a separate password for every website you log into. Yet thanks to tech debt and tradition, many DevOps professionals are still wrangling a host of SSH keys to access the servers where we sometimes need to be. With modern OAuth, a single login and second factor to prove your identity are enough to securely get you into every service that you're authorized to access. What if SSHing into servers was that easy? In this workshop, we'll use Okta's Advanced Server Access tool (formerly ScaleFT) to experience one way that the dream of sending SSH keys the way of the password has been realized.
- we'll discuss how ASA works and when it's the right tool for the job- we'll walk through setting up a free trial Okta account to use ASA from, and configuring the ASA gateway and server on Linux servers- we'll then SSH into our hosts with the ASA clients without needing to supply an SSH key from our laptops- we'll review the audit logs of our SSH sessions to examine what commands were run