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
Cookies contain very sensitive information. If attackers can get a hold of a session ID, they can impersonate users by [hijacking their sessions](https://en.wikipedia.org/wiki/Session_hijacking).

Most *session hijacking* attacks usually happen through a *man-in-the-middle* who can listen to the unencrypted traffic between the client and server and steal any information that's been exchanged. If a cookie is exchanged via HTTP, then it's vulnerable to MITM attacks and session hijacking.

To overcome the issue, we can use HTTPS when issuing the cookie and add the `Secure` flag to it. This instructs browsers to never send this cookie in plain HTTP requests.

## Example

Going back to our practical example at https://github.com/odino/wasec/tree/master/cookies, we can test this out by navigating to [https://wasec.local:7889/?secure=on](https://wasec.local:7889/?secure=on). The server sets two additional cookies, one with the `Secure` flag and one without

# Introduction
Cookies contain very sensitive information. If attackers can get a hold of a session ID, they can impersonate users by [hijacking their sessions](https://en.wikipedia.org/wiki/Session_hijacking).

Most *session hijacking* attacks usually happen through a *man-in-the-middle* who can listen to the unencrypted traffic between the client and server and steal any information that's been exchanged. If a cookie is exchanged via HTTP, then it's vulnerable to MITM attacks and session hijacking.

To overcome the issue, we can use HTTPS when issuing the cookie and add the `Secure` flag to it. This instructs browsers to never send this cookie in plain HTTP requests.

# Example

Going back to our practical example at https://github.com/odino/wasec/tree/master/cookies, we can test this out by navigating to [https://wasec.local:7889/?secure=on](https://wasec.local:7889/?secure=on). The server sets two additional cookies, one with the `Secure` flag and one without

In this lesson, we'll look at the secure directive.

Introduction

Understanding The Browser

HTTP

Protection through HTTP Headers

HTTP Cookies

Situationals

DDoS Attacks

Bug Bounty Programs

Conclusion

Encrypt it Or Forget it

Introduction

Example