Learn Eslint, Http and Particle

In this course, we will learn the fundamentals of the Hypertext Transport Protocol (HTTP) by exploring several popular HTTP APIs such as the GitHub API. Starting with the basic structure of an HTTP request and response, we will then delve into the specifics of each element of the request/response messages. Using concrete examples from these APIs, we will cover request methods, response status codes, messages headers, and message bodies. Along the way, you'll learn about specific message headers, such as `Cache-Control`, and `Cookie`  and how they control the behavior of clients/browsers and HTTP API services.

This course uses HTTPie, if you would like to follow along with the instructor you can download the client [here](https://httpie.org/).

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers.

http

Understand the Basics of HTTP

As developers, we're often working closely with APIs to make requests in the browser or on the backend with a server, but we might not always know exactly how those requests work or how they should look.

Postman is a tool that lets us create, manage, and test API endpoints all within a UI so we can wrangle our APIs and understand how they work.

Create, Manage, and Test API Requests with Postman

React is one of the web’s most popular frameworks for building JavaScript applications. 

If you know what you’re doing, React can drastically simplify how you build, use, and maintain code.

Whether you’re a React newbie or you’re ready for advanced techniques, you can level-up with egghead. Explore our in-depth courses, lessons, and community resources to build more powerful applications and crack open your career.

react

Our first layer of defense when building accessible React applications is to add some auditing tools to our development workflow. This should include adding static analysis checking for common accessibility standards and best practices. We can get this with the latest eslint plugin: "eslint-plugin-jsx-a11y". If you are already linting your projects adding this plugin should fit very smoothly into your workflow.

## Resources
1. [List of all the rules supported by eslint-plugin-jsx-a11y](https://github.com/evcohen/eslint-plugin-jsx-a11y#supported-rules)
2. [Comparison of the difference in rules between recommended and strict mode](https://github.com/evcohen/eslint-plugin-jsx-a11y#difference-between-recommended-and-strict-mode)
3. [Background on how the Accessibility API implemented by browsers interfaces with Assistive Technologies](https://github.com/evcohen/eslint-plugin-jsx-a11y#some-background-on-wai-aria-the-ax-tree-and-browsers)

Set up ESLint to Audit Accessibility Issues in React

The pluggable linting utility for JavaScript and JSX.

eslint

We have a number of options to use when testing for accessibility issues concerning alternative text for images.  The react-axe library and axe browser extension will both report when an image is missing alternative text.  The tota11y browser extension will annotate any images that are missing alternative text.  Running eslint with the eslint-plugin-jsx-a11y plugin installed will report on any `<img>` elements missing an `alt` attribute.  Finally, we can use a screen reader to actually hear what is read when an image has focus.

Test for Image Alternative Text Accessibility Issues

Images must have text alternatives that describe the information or function 
represented by them so they can be read and understood by those using screen readers.

## Alternative text for images
* All `<img>` elements should have an `alt` attribute provided
    * When not provided many screen readers will fallback to reading the file name instead
* The `alt` value should not include words like _“image”_, _“picture”_ or _“icon”_
    * Screen readers are already announcing that the element is an image
* Images that are decorative only and provide no information or function to the page should be hidden from Assistive Technologies by providing an empty `alt` attribute (`alt=””`)

## References
* https://www.w3.org/WAI/tutorials/images/
* https://www.w3.org/WAI/tutorials/images/decision-tree/
* https://www.w3.org/WAI/tutorials/images/tips/
* https://www.w3.org/WAI/tutorials/images/informative/
* https://www.w3.org/WAI/tutorials/images/functional/
* https://www.w3.org/WAI/tutorials/images/textual/

Define Images with Appropriate Text Alternatives

Our accessibility auditing toolkit makes it very easy for us to test for any form controls that are missing labels or are not correctly associated with their labels.  Running Eslint with the eslint-plugin-jsx-a11y installed will show us any form controls with missing or unassociated labels.  Running react-axe or using axe to audit a web page will similarly list any of these findings.  Finally using tota11y we can annotate any form controls on a page that are missing labels.  This is definitely some of the lower hanging fruit that we can easily find and fix when making our applications accessible!

Test for Form Control Label Accessibility Issues

Labeling inputs, elements, and widgets add context and clarity for assistive technology such as screen readers.  Elements of a `<form>` such as `<input>` or `<textarea>` or `<select>` should be labelled by using a `<label>` element.  Placeholder text can be used in addition to a label but should not be used in place of a label as not all assistive technologies respect placeholder text.

Ensure Form Controls have Accessible Labels

Express is a minimal and flexible Node.js web application framework that provides a robust set of features for web and mobile applications.

express

In this lesson, we'll learn how to add https (and remove http) support to the localhost version of our express application. By adding https support, we'll be able to prevent a MITM (in this case Charles Proxy) from reading our session id, mitigating the attack known as "session hijacking".

Add https to a Localhost Express App to Prevent MITM Attacks

In this course, we'll learn how to exploit and then mitigate several common Web Security Vulnerabilities: Man in the Middle (MITM), Cross Site Request Forgery (CSRF), and Cross Site Scripting (XSS).

The goal of this course is to introduce you to these attacks from the point of view of an attacker, and then as the defender of a sample application, and to gain first hand experience with how these attacks works. You'll also learn several security "rules of thumb" along the way and discover modern defenses against these attacks that drastically reduce their likelihood of succeeding!

By the end of this course, you’ll know how to recognize these vulnerabilities in your own application and have strategies to mitigate and defend against all of them. You'll feel more confident in your ability to write secure code, and my hope is that you'll be inspired to continue your security journey and help make the internet a safer place for all of us.

Course Overview: Web Security Essentials

In this lesson, we'll learn how to use Charles Proxy to “sniff” the web traffic flowing an example website using an attack known as a Man in the Middle attack, or MITM. Because our example website is using http and not https, you'll “discover” a vulnerable piece of user data called a session id being transmitted in cleartext across every request. This info will become the central piece of data that we'll learn how to protect throughout this course.

Simulate Man in the Middle Attacks and Inspect Network Traffic with Charles Proxy

In the previous lesson, we disabled http in favor of https. In this lesson, we'll learn that the default protocol for web browser is http, and we therefore need to provide an http endpoint that redirects the browser to https. We'll do that by setting up a small express application whose sole responsibility is to redirect http urls to https. In doing so, we'll accidentally reintroduce the transmission of our session id over http, which we'll need to fix in our next lesson.

Redirect All HTTP Traffic to HTTPS in Express to Ensure All Responses are Secure

In this lesson, we'll will learn how to set the `secure` flag on our session id cookie to ensure it is only transmitted over https connections. This will effectively mitigate the Session Hijacking vulnerability we introduced in the previous lesson.

Set the Secure Cookie Flag to Ensure Cookies are Only Sent Over Secure Connections

In this lesson, we'll learn how to add HSTS headers to an express application so that all requests after the first request made to the application are https. We'll also learn about the HSTS preload list which will ensure that even the first request is secure. Even though we secured our session id cookie in the previous lesson, ensuring all requests go over https ensure that even if we add another cookie and forget to set it to Secure, we'll still not be transmitting it in cleartext over an http connection.

Add HSTS Headers to Express Apps to Ensure All Requests are https Requests

In this lesson, we'll learn what a Cross Site Request Forgery (CRSF) vulnerability is by learning how to exploit a CSRF vulnerable site by making malicious requests on behalf of a logged in user. We'll construct a malicious payload that automatically gets POSTed to the vulnerable site simply by visiting the attacker website while being logged into the target website.

Create a Proof of Concept Exploit of a CSRF Vulnerable Website

In this lesson, we'll learn what the SameSite cookie flag is, what it’s various settings are, and how it can be used to prevent most forms of CSRF vulnerabilities. We'll then demonstrate how it protects against the exploit we crafted in the previous lesson.

Mitigate CSRF Attacks by Setting the SameSite Cookie Flag in Express

In this lesson, we'll learn what CSRF tokens are, and how they are used to defeat Cross Site Request Forgery vulnerabilities. Even though we've defeated CSRF through the use of SameSite cookies, adding CSRF tokens are an important "defense in depth" strategy to ensure that browsers that don't support SameSite cookies can still be protected against CSRF.

Add CSRF Token Middleware to an Express Server to Mitigate CSRF

In this lesson, we'll learn how to set the httpOnly flag on our session id cookie to ensure it is inaccessible from javascript, thereby defeating theft of the session id from the XSS attack we crafted in the previous lesson. However, we'll still leave ourselves open to other dangers from XSS, which we'll exploit in our next lesson!

Set the httpOnly Cookie Flag in Express to Ensure Cookies are Inaccessible from JavaScript

In this lesson, we'll learn what CSP is and how it can be used to prevent inline scripts from being executed on our vulnerable website. First, we'll deploy CSP in "report only" mode, which will send violations to the endpoint you specify without blocking execution. Then, we'll run CSP in regular mode, which we'll use to completely block inline scripts from executing.

Prevent Inline Script Execution by Implementing Script-Src CSP Headers in Express

In this lesson, we'll learn how to set the script-src CSP to use nonces. Using nonces will disallow both inline scripts and remote scripts from executing unless the script tag has a nonce attribute that matches the nonce provided by the CSP header. This will mitigate the vulnerability we discovered in the previous lesson and will effectively block all javascript from running except the scripts you explicitly added, and is an effective defense against javascript powered XSS!

Add a Nonce Based script-src Header in Express to Only Allow Scripts that Match the Nonce

In this lesson, we'll learn how to disable all external content srcs other than the specific types of external resources we need. For the types of external resources we need, we'll limit those resources to only nonce-matching resources. This will effectively mitigate all forms of XSS, using the principle of least power to only enable needed capabilities, and drastically reducing the surface area of possible attacks on our website.

Add a default-src CSP Header in Express to Enforce an Allowlist and Mitigate XSS

To make our opengraph image generation function, we'll have to work out a way to pass the querystring variables from the original URL through to the React script running inside the headless browser. We choose to set them on the window using another injected script, and we also cover handling URL decoding of querystring components.

Topics

Instructors

Content Type