Gain insights into enforcing web app security best practices, such as HTTPS, defending against XSS and clickjacking, managing HTTP cookies, and warding off DDoS attacks.

new.tar.gz

node

cookies

hsts

hsts-https

cookies-https

clickjacking

cors

There are more vulnerabilities than ever when creating applications for the web, so it is extremely important that software developers enforce security best practices such as, how to add protection through HTTP headers.

In this course, you will start off by learning how to prevent fraudulent SSL certificates from being served to clients, before moving on to how to defend against XSS attacks and clickjacking. 

In the latter half of the course, you’ll learn security practices related to HTTP cookies, and tips around security tradeoffs that you’ll make in your day-to-day work. Towards the end, you’ll learn how to ward off DDoS attacks, which is crucial when your application scales.

This course will demystify web security, and help you stay on top of important security-related concerns in your web apps.

Web Application Security for the Everyday Software Engineer

# Introduction 
As we've seen, servers can send HTTP headers to provide the client with additional metadata around the response. Besides sending the content that the client requested, servers are then allowed to specify how a particular resource should be read, cached or secured.

There's a large spectrum of security-related headers that we should understand, as they have been implemented by browsers in order to make it harder for attackers to take advantage of vulnerabilities. The next paragraphs try to summarize each of them by explaining how they're used, what kind of attacks they prevent, and a bit of history behind each header.

# HSTS

Since late 2012, HTTPS-everywhere believers have found it easier to force a client to always use the secure version of the HTTP protocol, thanks to the *HTTP Strict Transport Security*. A simple `Strict-Transport-Security: max-age=3600` will tell the browser that for the next hour (3600 seconds) it should not interact with the applications with insecure protocols.

When a user tries to access an application secured by HSTS through HTTP, the browser will simply refuse to go ahead, automatically converting `http://` URLs to `https://`.

You can test this locally with the code at [github.com/odino/wasec/tree/master/hsts](https://github.com/odino/wasec/tree/master/hsts). You will need to follow the instructions in the README (that involves installing a trusted SSL certificate for `localhost` on your machine, through the [mkcert](https://github.com/FiloSottile/mkcert) tool, and then try opening `https://localhost:7889`.

## HTTPS
There are two servers in this example, an HTTPS one listening on `7889`, and an HTTP one on port `7888`. When you access the HTTPS server, it will always redirect you to the HTTP version, which will work since there is no HSTS policy on the HTTPS server. 

If you instead add the `hsts=on` parameter in your URL, the browser will forcefully convert the link in the redirect to its `https://` version. Since the server at `7888` is http-only, you will see a page that looks more or less like this:



In this lesson, we'll study the HTTP strict transport security.


Introduction

Understanding The Browser

HTTP

Protection through HTTP Headers

HTTP Cookies

Situationals

DDoS Attacks

Bug Bounty Programs

Conclusion

HTTP Strict Transport Security

Introduction