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

Chances are that the application you're working on *right now* depends on a plethora of open-source libraries: ExpressJS, a popular web framework for NodeJS, depends on 30 external libraries, and those libraries depend on external libraries, and those...we could go on forever. As a simple exercise, I tried to install a brand-new version of ExpressJS in my system, with interesting results:

```console
$ npm install express
+ express@4.17.1
added 50 packages from 37 contributors and audited 127 packages in 9.072s
found 0 vulnerabilities
```

Just by installing the latest version of ExpressJS, I've included 50 libraries in my codebase. Is that inherently bad? Not at all, but it presents a security risk; the more code we write or use, the larger the attack surface for malicious users becomes.

One of the biggest risks when using a plethora of external libraries is not following up on updates when they are released. It isn't so bad to use open-source libraries, after all, they're probably safer than most of the code we write ourselves. But forgetting to update them, especially when a security fix is released, is a genuine problem we face every day.

Luckily, programs like npm provide tools to identify outdated packages with known vulnerabilities. We can simply try to install a dependency with a known vulnerability and run `npm audit fix`, and npm will do the rest for us.

```console
$ npm install lodash@4.17.11
+ lodash@4.17.11
added 1 package from 2 contributors and audited 288 packages in 1.793s
found 1 high severity vulnerability
  run `npm audit fix` to fix them, or `npm audit` for details
$ npm audit
                                                                                
                       === npm audit security report ===                        
                                                                                
# Run  npm update lodash --depth 1  to resolve 1 vulnerability
┌───────────────┬──────────────────────────────────────────────────────────────┐
│ High          │ Prototype Pollution                                          │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Package       │ lodash                                                       │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Dependency of │ lodash                                                       │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ Path          │ lodash                                                       │
├───────────────┼──────────────────────────────────────────────────────────────┤
│ More info     │ https://npmjs.com/advisories/1065                            │
└───────────────┴──────────────────────────────────────────────────────────────┘


found 1 high severity vulnerability in 1 scanned package
  run `npm audit fix` to fix 1 of them.
$ npm audit fix
+ lodash@4.17.15
updated 1 package in 0.421s
fixed 1 of 1 vulnerability in 1 scanned package
```

If you're not using JavaScript and npm, you can always rely on external services to scan your software and point out any library with known vulnerabilities. GitHub offers this service for all their repositories, and you might find it convenient if your codebase is already hosted there.


In this lesson, we'll study a few open-source libraries that have dependencies with known vulnerabilities.

Introduction

Understanding The Browser

HTTP

Protection through HTTP Headers

HTTP Cookies

Situationals

DDoS Attacks

Bug Bounty Programs

Conclusion

Dependencies With Known Vulnerabilities