    Gain insights into HTTP security headers, learn their risks, explore solutions, and discover how to implement them using Helmet for enhanced web application security.

HSTS_brew_final.tar.gz

Chrome

run_mal

Chrome_hsts

Chrome_hsts-mkcert

debug

Chrome_hsts-mal

Chrome_hsts-inn

This course teaches you 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 your web application security, you'll learn what is the overall risk of not implementing it, and what does a proposed solution help with. Finally, you'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

HTTP Strict Transport Security, also known as HSTS, is a protocol standard which enforces secure connections to the server via HTTP over SSL/TLS. HSTS is configured and transmitted from the server to any HTTP web client using the HTTP header **Strict-Transport-Security**. This specifies a time interval during which the browser should only communicate over an HTTP secured connection (HTTPS).

> Tip
>
> When a Strict-Transport-Security header is sent over an insecure HTTP connection, the web browser ignores it because the connection is insecure.

After the header has been set, the browser consults a **preload service**, like [Google's](https://hstspreload.org/), to determine whether the website has opted in for HSTS.

# The risk

The risk that may arise when communicating over a secure HTTPS connection is that a malicious user can perform a **Man-In-The-Middle** (MITM) attack. This type of attack downgrades future requests to the webserver to use an HTTP connection. Once an HTTP connection is established, the attacker is able to see and read all the data that flows through.

> **Interesting Fact:**
> The [original HSTS draft](https://tools.ietf.org/html/rfc6797) was published in 2011 by Jeff Hodges from PayPal,
> Collin Jackson from Carnegie Mellon University, and Adam Barth from Google.

A website that uses HTTPS can still create insecure HTTP requests, however. End users would not suspect anything to be amiss, but they may still be exposed to MITM attacks.

In the following flow diagram (Figure 1-1), we can see an example scenario where the server returns an HTML file for a login page to the browser. This includes some resources that are accessible over HTTP (`http://cdn.server.com/images/submit.png`), like the submit button's image.

If an attacker is able to perform a Man-In-The-Middle attack and “sit on the wire”, they will be able to read any un-encrypted traffic that flows through, including HTTP requests that  include sensitive data. An even worse scenario would involve the attacker watching where actual data is being sent and accessing HTTP resources set for POST or PUT endpoints.

In this lesson, we'll learn how to force secure communications with the use of the HTTP Strict Transport Security header to improve end-to-end communication for users and websites.

Introduction

HTTP Security Headers

Testing for Security Headers

What's Next?

HTTP Strict Transport Security

The risk