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

Often times, web applications serve some of their content through a content delivery network (CDN), typically in the form of static assets like JavaScript or CSS files, while the main document is rendered by a webserver. This gives developers limited control over the static assets themselves, as they're usually uploaded to a third-party CDN (e.g., CloudFront, Google Cloud CDN, Akamai).

Now, suppose an attacker gained access to your login credentials on the CDN provider's portal and uploaded a modified version of your static assets, injecting malicious code. How could you prevent such a risk for your users?

## Using integrity hashes to protect users

Browser vendors have a solution for you, called [sub-resource integrity](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity) (SRI). SRI allows your main application to generate cryptographic hashes of your static files and tell the browser which file is mapped to what hash. When the browser downloads the static asset from the CDN, it will calculate the asset's hash on-the-fly and make sure that it matches the one provided in the main document. If the hashes don’t match, the browser will simply refuse to execute or render the asset.

This is how you can include an asset with an *integrity hash* in your document.

```html
...
<script 
  src="https://my.cdn.com/asset.js" 
  integrity="sha256-Y34u3VVVcO2pZtmdTnfZ+7OquEpJj/VawhuWPB4Fwq3ftcFc0gceft1HNZ14eUHT"
></script>
...
```

The *integrity hash* can be computed with a simple command.

```console
cat $ASSET_FILE_NAME | openssl dgst -sha384 -binary | openssl base64 -A
```

A working example can be found below; after you've ran the web server by clicking the run button, you can visit https://x6jr4kg.educative.run by replacing the educative.run link with the one generated in your app below to see the SRI in action.



# Introduction

Often times, web applications serve some of their content through a content delivery network (CDN), typically in the form of static assets like JavaScript or CSS files, while the main document is rendered by a webserver. This gives developers limited control over the static assets themselves, as they're usually uploaded to a third-party CDN (e.g., CloudFront, Google Cloud CDN, Akamai).

Now, suppose an attacker gained access to your login credentials on the CDN provider's portal and uploaded a modified version of your static assets, injecting malicious code. How could you prevent such a risk for your users?

# Using integrity hashes to protect users

Browser vendors have a solution for you, called [sub-resource integrity](https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity) (SRI). SRI allows your main application to generate cryptographic hashes of your static files and tell the browser which file is mapped to what hash. When the browser downloads the static asset from the CDN, it will calculate the asset's hash on-the-fly and make sure that it matches the one provided in the main document. If the hashes don’t match, the browser will simply refuse to execute or render the asset.

This is how you can include an asset with an *integrity hash* in your document.

```html
...
<script 
  src="https://my.cdn.com/asset.js" 
  integrity="sha256-Y34u3VVVcO2pZtmdTnfZ+7OquEpJj/VawhuWPB4Fwq3ftcFc0gceft1HNZ14eUHT"
></script>
...
```

The *integrity hash* can be computed with a simple command.

```console
cat $ASSET_FILE_NAME | openssl dgst -sha384 -binary | openssl base64 -A
```

A working example can be found below; after you've ran the web server by clicking the run button, you can visit https://x6jr4kg.educative.run by replacing the educative.run link with the one generated in your app below to see the SRI in action.



In this lesson, we'll look at some measures you can take to ensure your users' protection in the case of a CDN compromise.

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

My CDN Was Compromised!

Introduction

Using integrity hashes to