Learn about the Helmet library of Node.js for HTTP headers and test the security.

Web App Security

This module teaches us hands-on practical use of HTTP security headers as browser security controls to help secure web applications. 
For each HTTP security header that can enhance our web application security, we'll look at the potential risk of not implementing it as well as the benefits of employing a solution that we propose. Finally, we'll learn how to implement and configure the security header with Helmet, a popular and well-maintained Node.js package on npm.

Web Application Security: Understanding HTTP Security Headers

As we discussed in the X-Frame-Options section, there are many attacks related to content injection in the user’s browser. These include Clickjacking attacks as well as another form of attacks known as Cross-Site-Scripting (XSS).

#concept=XSS#XSS#concept#

Another improvement to the previous set of headers we reviewed so far is a header that can tell the browser which content to trust. This allows the browser to prevent attempts at content injection that is not trusted in the policy defined by the application owner.

With a [Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/Security/CSP/Introducing_Content_Security_Policy) (CSP) it is possible to prevent a wide range of attacks, including Cross-site scripting and other content injections. The implementation of a CSP renders the use of the X-Frame-Options header obsolete.

## The Risk

Using a Content Security Policy header will prevent and mitigate XSS and other injection attacks. Examples of some of the issues that  can be prevented by setting a CSP policy include:

- Inline JavaScript code specified with `<script>` tags, and any DOM events which trigger JavaScript execution such as `onClick()` etc.
- Inline CSS code specified via a `<style>` tag or attribute elements.


## The Solution

With CSP allowlists, we can allow many configurations for trusted content. As such, the initial setup can grow to a set of complex directives.

Let's review one directive called **connect-src**. It is used to control which remote servers the browser is allowed to connect to via XMLHttpRequest (XHR), or `<a>` elements. Other script interfaces that are covered by this directive are: `Fetch`, `WebSocket`,`EventSource`, and `Navigator.sendBeacon()`.

Acceptable values that we can set for this directive:

- `'none'` - not allowing remote calls such as XHR at all.
- `'self'` - only allow remote calls to our own domain (an exact domain/hostname - sub-domains aren't allowed).

The following is an example of a content security policy being set. It allows the browser to make XHR requests to the website's own domain and to Google's API domain:

```
Content-Security-Policy: connect-src 'self' https://apis.google.com;
```

Another directive to control the allowlist for JavaScript sources is called **script-src**.
This directive helps mitigate Cross-Site-Scripting (XSS) attacks by informing the browser which sources of content to trust when evaluating and executing JavaScript source code.

The script-src control supports the `'none'` and `'self'` keywords as values and includes the following options:

- `'unsafe-inline'`: allow any inline JavaScript source code such as `<script>`, and DOM events triggering `onClick()` or `javascript:` URIs. It also affects CSS for inline tags.
- `'unsafe-eval'`: allow execution of code using `eval()`.

For example, the following is a policy for allowing JavaScript to be executed only from our own domain and from Google's while allowing inline JavaScript code as well:

```
Content-Security-Policy: script-src 'self' https://apis.google.com 'unsafe-inline'
```

Note, the `'unsafe-inline'` directive refers to a website's own JavaScript sources.

A full list of supported directives can be found on the [CSP policy directives page on MDN](https://developer.mozilla.org/en-US/docs/Web/Security/CSP/CSP_policy_directives), but let's cover some other common options and their values.

- **default-src**: where a directive doesn't have a value, it defaults to an open, non-restricting configuration. It is safer to set a default for all of the un-configured options, which is where the default-src directive comes in.
- **script-src**: a directive to set which script sources we allow to load or execute JavaScript from. If it's set to a value of `'self'` then it will only allow sources from our own domain. Also, it will not allow inline JavaScript tags, such as `<script>`. To enable those, add `'unsafe-inline'` too.


> It should also be noted that when implementing CSP, the CSP configuration needs to meet the implementation of your web application architecture. If you
> deny inline `<script>` blocks, then your R&D team should be aware and well prepared for this. Otherwise, it may break features and functionality across code that depends on inline JavaScript code blocks.

# The Risk

Using a Content Security Policy header will prevent and mitigate XSS and other injection attacks. Examples of some of the issues that  can be prevented by setting a CSP policy include:

- Inline JavaScript code specified with `<script>` tags, and any DOM events which trigger JavaScript execution such as `onClick()` etc.
- Inline CSS code specified via a `<style>` tag or attribute elements.


# The Solution

With CSP allowlists, we can allow many configurations for trusted content. As such, the initial setup can grow to a set of complex directives.

Let's review one directive called **connect-src**. It is used to control which remote servers the browser is allowed to connect to via XMLHttpRequest (XHR), or `<a>` elements. Other script interfaces that are covered by this directive are: `Fetch`, `WebSocket`,`EventSource`, and `Navigator.sendBeacon()`.

Acceptable values that we can set for this directive:

- `'none'` - not allowing remote calls such as XHR at all.
- `'self'` - only allow remote calls to our own domain (an exact domain/hostname - sub-domains aren't allowed).

The following is an example of a content security policy being set. It allows the browser to make XHR requests to the website's own domain and to Google's API domain:

```
Content-Security-Policy: connect-src 'self' https://apis.google.com;
```

Another directive to control the allowlist for JavaScript sources is called **script-src**.
This directive helps mitigate Cross-Site-Scripting (XSS) attacks by informing the browser which sources of content to trust when evaluating and executing JavaScript source code.

The script-src control supports the `'none'` and `'self'` keywords as values and includes the following options:

- `'unsafe-inline'`: allow any inline JavaScript source code such as `<script>`, and DOM events triggering `onClick()` or `javascript:` URIs. It also affects CSS for inline tags.
- `'unsafe-eval'`: allow execution of code using `eval()`.

For example, the following is a policy for allowing JavaScript to be executed only from our own domain and from Google's while allowing inline JavaScript code as well:

```
Content-Security-Policy: script-src 'self' https://apis.google.com 'unsafe-inline'
```

Note, the `'unsafe-inline'` directive refers to a website's own JavaScript sources.

A full list of supported directives can be found on the [CSP policy directives page on MDN](https://developer.mozilla.org/en-US/docs/Web/Security/CSP/CSP_policy_directives), but let's cover some other common options and their values.

- **default-src**: where a directive doesn't have a value, it defaults to an open, non-restricting configuration. It is safer to set a default for all of the un-configured options, which is where the default-src directive comes in.
- **script-src**: a directive to set which script sources we allow to load or execute JavaScript from. If it's set to a value of `'self'` then it will only allow sources from our own domain. Also, it will not allow inline JavaScript tags, such as `<script>`. To enable those, add `'unsafe-inline'` too.


> It should also be noted that when implementing CSP, the CSP configuration needs to meet the implementation of your web application architecture. If you
> deny inline `<script>` blocks, then your R&D team should be aware and well prepared for this. Otherwise, it may break features and functionality across code that depends on inline JavaScript code blocks.

In this lesson, we'll learn about one of the most powerful security features that browsers have introduced in recent years in mitigating Cross-site Scripting vulnerabilities and how it helps create a content trust policy.

Introduction

HTTP Security Headers

Testing for Security Headers

What's Next

Conclusion

Content Security Policy

The Risk

The Solution