Learn about web application security needed by software engineers every day.

Web App Security

The applications that we create for the web today have to face up to more security risks than ever before. It is extremely important that software developers enforce security best practices, such as how to add protection through HTTP headers, to protect against the myriad vulnerabilities that web applications are subject to. 
In this module, we’ll start by learning how to prevent fraudulent SSL certificates from being served to clients. Then, we’ll move on to learning how to defend against XSS attacks and clickjacking. 
In the latter half of the module, we’ll learn security practices related to HTTP cookies. We’ll also learn some tips related to security tradeoffs that we frequently make in our day-to-day work. Towards the end of the module, we’ll learn how to ward off DDoS attacks, which is crucial when our application scales. 
This module will demystify web security and help us stay on top of important security-related concerns in our web applications.

Web Application Security for the Everyday Software Engineer

In July 2018, security researcher [Scott Helme](https://scotthelme.co.uk/) published a very interesting [blog post](https://scotthelme.co.uk/a-new-security-header-feature-policy/) detailing a new security header in the making, `Feature-Policy`.

Currently supported by very few browsers, only Chrome and Safari at the time of writing, this header lets us define whether a specific browser feature is enabled within the current page. With a syntax very similar to CSP, we should have no issue understanding what a feature policy such as the following one means.

```text
Feature-Policy: vibrate 'self'; push *; camera 'none'
```

If we still have doubts about how this policy impacts the browser APIs available to the page, we can simply dissect it:

* `vibrate 'self'`: this will allow the current page to use the vibration API and any nested browsing contexts (iframes) on the same origin.
* `push *`: the current page and any iframe can use the push notification API.
* `camera 'none'`: access to the camera API is denied to the current page and any nested context (iframes).

The feature policy might have a short history, but it doesn't hurt to get a head start. If your website allows users to take a selfie or record audio, it would be quite beneficial to use a policy that restricts other contexts from accessing the API through your page.

---
In the next lesson, we'll discuss the header `X-Content-Type-Options`.

In this lesson, we'll discuss the Feature-Policy header.

Introduction

Understanding The Browser

HTTP

Protection through HTTP Headers

HTTP Cookies

Situationals

DDoS Attacks

Bug Bounty Programs

Conclusion

Feature-Policy