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

A server can send a cookie using the `Set-Cookie` header.

```text
HTTP/1.1 200 Ok
Set-Cookie: access_token=1234
...
```

A client will then store this data and
send it in subsequent requests through the `Cookie` header.

```text
GET / HTTP/1.1
Host: example.com
Cookie: access_token=1234
...
```

Note that servers can send multiple cookies at once,

```text
HTTP/1.1 200 Ok
Set-Cookie: access_token=1234
Set-Cookie: user_id=10
...
```

and clients can do the same in their request.

```text
GET / HTTP/1.1
Host: example.com
Cookie: access_token=1234; user_id=10
...
```

In addition to the plain *key* and *value*, cookies can carry additional directives that limit their time-to-live and scope.

## `Expires`

Specifies when a cookie should expire, so that browsers do not store and transmit it indefinitely. A clear example is a session ID, which usually expires after some time. This directive is expressed as a date in the form of `Date: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT`, like `Date: Fri, 24 Aug 2018 04:33:00 GMT`. Here's a full example of a cookie that expires on the first of January, 2018: `access_token=1234;Expires=Fri, 24 Aug 2018 04:33:00 GMT`

## `Max-Age`

Similar to the `Expires` directive, `Max-Age` specifies the number of seconds until the cookie should expire. A cookie that should last one hour would look like the following: `access_token=1234;Max-Age=3600`

## `Domain`

This directive defines which hosts the cookie should be sent to. Remember, cookies generally contain sensitive data, so it's important for browsers not to leak them to untrusted hosts. A cookie with the directive `Domain=trusted.example.com` will not be sent along with requests to any domain other than `trusted.example.com`, not even the root domain, `example.com`. Here's a valid example of a cookie limited to a particular subdomain: `access_token=1234;Domain=trusted.example.com`

## `Path`

Path is similar to the `Domain` directive but applies to the URL path (`/some/path`). This directive prevents a cookie from being shared with untrusted paths, such as in the following example: `access_token=1234;Path=/trusted/path`.

---
In the next lesson, we'll study session and persistent cookies.


A server can send a cookie using the `Set-Cookie` header.

```text
HTTP/1.1 200 Ok
Set-Cookie: access_token=1234
...
```

A client will then store this data and
send it in subsequent requests through the `Cookie` header.

```text
GET / HTTP/1.1
Host: example.com
Cookie: access_token=1234
...
```

Note that servers can send multiple cookies at once,

```text
HTTP/1.1 200 Ok
Set-Cookie: access_token=1234
Set-Cookie: user_id=10
...
```

and clients can do the same in their request.

```text
GET / HTTP/1.1
Host: example.com
Cookie: access_token=1234; user_id=10
...
```

In addition to the plain *key* and *value*, cookies can carry additional directives that limit their time-to-live and scope.

# `Expires`

Specifies when a cookie should expire, so that browsers do not store and transmit it indefinitely. A clear example is a session ID, which usually expires after some time. This directive is expressed as a date in the form of `Date: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT`, like `Date: Fri, 24 Aug 2018 04:33:00 GMT`. Here's a full example of a cookie that expires on the first of January, 2018: `access_token=1234;Expires=Fri, 24 Aug 2018 04:33:00 GMT`

# `Max-Age`

Similar to the `Expires` directive, `Max-Age` specifies the number of seconds until the cookie should expire. A cookie that should last one hour would look like the following: `access_token=1234;Max-Age=3600`

# `Domain`

This directive defines which hosts the cookie should be sent to. Remember, cookies generally contain sensitive data, so it's important for browsers not to leak them to untrusted hosts. A cookie with the directive `Domain=trusted.example.com` will not be sent along with requests to any domain other than `trusted.example.com`, not even the root domain, `example.com`. Here's a valid example of a cookie limited to a particular subdomain: `access_token=1234;Domain=trusted.example.com`

# `Path`

Path is similar to the `Domain` directive but applies to the URL path (`/some/path`). This directive prevents a cookie from being shared with untrusted paths, such as in the following example: `access_token=1234;Path=/trusted/path`.

---
In the next lesson, we'll study session and persistent cookies.


In this lesson, we'll study how cookies are set, requested, and what directives they can have.

Introduction

Understanding The Browser

HTTP

Protection through HTTP Headers

HTTP Cookies

Situationals

DDoS Attacks

Bug Bounty Programs

Conclusion

Deploy an API to Production Using Nginx

What's Behind a Cookie?