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

## Same origin requests
On the browser HTTP requests can only be triggered across the same origin through JavaScript. Simply put, an AJAX request from `example.com` can only connect to `example.com`.

This is because your browser contains useful information for an attacker, cookies, which are generally used to keep track of the user's session. Imagine if an attacker would set up a malicious page at `win-a-hummer.com` that immediately triggers an AJAX request to `your-bank.com`. If you're logged in on the bank's website, the attacker would then be able to execute HTTP requests with your credentials, potentially stealing your information or, worse, wiping your bank account out.

## Cross origin resource sharing directives
There might be some cases, though, that require you to execute cross-origin AJAX requests, and that is why browsers implement Cross Origin Resource Sharing (CORS), a set of directives that allow you to execute cross-domain requests.

The mechanics behind CORS are quite complex, and it wouldn't be practical for us to go over the whole specification, so I am going to focus on a stripped down version of CORS. All you need to know for now is that by using the `Access-Control-Allow-Origin` header, your application tells the browser that it's ok to receive requests from other origins.

The most relaxed form of this header is `Access-Control-Allow-Origin: *`, which allows any origin to access our application, but we can restrict it by simply adding the URL we want to whitelist with `Access-Control-Allow-Origin: https://example.com`.

## Example

If we take a look at the example at [github.com/odino/wasec/tree/master/cors](https://github.com/odino/wasec/tree/master/cors) we can clearly see how the browser prevents access to a resource on a separate origin. I have set up the example to make an AJAX request from `wasec.local` to `sub.wasec.local`, and print the result of the operation to the browser. When the server behind `sub.wasec.local` is instructed to use CORS, the page works as you would expect. Try navigating to `http://wasec.local:7888/?cors=on`.




# Same origin requests
On the browser HTTP requests can only be triggered across the same origin through JavaScript. Simply put, an AJAX request from `example.com` can only connect to `example.com`.

This is because your browser contains useful information for an attacker, cookies, which are generally used to keep track of the user's session. Imagine if an attacker would set up a malicious page at `win-a-hummer.com` that immediately triggers an AJAX request to `your-bank.com`. If you're logged in on the bank's website, the attacker would then be able to execute HTTP requests with your credentials, potentially stealing your information or, worse, wiping your bank account out.

# Cross origin resource sharing directives
There might be some cases, though, that require you to execute cross-origin AJAX requests, and that is why browsers implement Cross Origin Resource Sharing (CORS), a set of directives that allow you to execute cross-domain requests.

The mechanics behind CORS are quite complex, and it wouldn't be practical for us to go over the whole specification, so I am going to focus on a stripped down version of CORS. All you need to know for now is that by using the `Access-Control-Allow-Origin` header, your application tells the browser that it's ok to receive requests from other origins.

The most relaxed form of this header is `Access-Control-Allow-Origin: *`, which allows any origin to access our application, but we can restrict it by simply adding the URL we want to whitelist with `Access-Control-Allow-Origin: https://example.com`.

# Example

If we take a look at the example at [github.com/odino/wasec/tree/master/cors](https://github.com/odino/wasec/tree/master/cors) we can clearly see how the browser prevents access to a resource on a separate origin. I have set up the example to make an AJAX request from `wasec.local` to `sub.wasec.local`, and print the result of the operation to the browser. When the server behind `sub.wasec.local` is instructed to use CORS, the page works as you would expect. Try navigating to `http://wasec.local:7888/?cors=on`.




In this lesson, we'll look at cross origin resource sharing.

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

Cross Origin Resource Sharing

Same origin requests

Cross origin resource sharing directives