Description
Course info
Rating
(36)
Level
Beginner
Updated
May 2, 2018
Duration
1h 13m
Description

Play by Play is a series in which top technologists work through a problem in real time, unrehearsed, and unscripted. In this course, Play by Play: JavaScript Security, Troy Hunt and Aaron Powell demonstrate building an application in the browser, particularly a Single-page Application (SPA), and show how the application works, and its visibility to the user. By the end of this course, you’ll have a better understanding of how to minimize some common security risks when working with Single-page Applications.

About the author
About the author

Troy Hunt is a Microsoft Regional Director and MVP for Developer Security. He's a regular conference speaker, frequent blogger at troyhunt.com and is the creator of the data breach notification service known as “Have I Been Pwned”.

More from the author
Modern Browser Security Reports
Beginner
57m
Aug 3, 2018
More courses by Troy Hunt
About the author

Aaron is a Senior Developer and Technical Web Specialist with Readify and Microsoft MVP for Internet Explorer Development. Aaron focuses mainly on front-end web development, with a passion for JavaScript.

More from the author
Play by Play: Azure Beyond Websites
Beginner
1h 16m
Apr 14, 2017
Using ASP.NET MVC with Umbraco
Intermediate
1h 34m
Sep 30, 2015
More courses by Aaron Powell
Section Introduction Transcripts
Section Introduction Transcripts

Course Overview
Hi everyone, I'm Troy Hunt, and I'm Aaron Powell, and welcome to our Play by Play on JavaScript security. I'm an independent security researcher and trainer, and I'm particularly interested in the impact of security on our web applications. And, of course, these days our web applications are increasingly dependent on JavaScript, so naturally I'm very interested in the impact of security on the way we manage our JavaScript-based applications. While Troy comes from that security researcher background, I'm very much a web developer, building single-page applications or server-side applications that have rich UIs that are building JavaScript using, insert JavaScript framework that's the flavor of the month at the moment, React, Angular, etc. and looking at how best we can build those sorts of applications so that we are taking security best practices into consideration. The last thing we want to do is end up on someone's Twitter feed being named in shame for having some poor security practices in our application. In this course, we're going to look at many different aspects of security as it relates to JavaScript, so, for example, how we manage tokens, which are an essential part of authentication in modern applications. We'll move onto session storage persistence, and how we actually remember identities between sessions, particularly when the browser unloads. We'll look at service workers, cross-origin resource sharing, and the Access-Control-Allow-Origin header. Moving on, we're going to spend a bunch of time looking at the challenges with third-party tool integrations, and we've got a great real-world example that happened recently, which really illustrates the challenge we have when we create dependencies on other parties. This is something that I think is very important, how we're depending on these external libraries. Now we're seeing more and more reliance on things that are coming from npm or other model providers, and we want to make sure that we have a good level of trust about those dependencies that we're taking, how we're making sure that if they do have vulnerabilities we're able to track those, view those reports with inside of our build or deploy process, get that feedback back to our team so that we can make decisions on whether or not they're the right thing to use. And we'll also move onto looking at the OAuth's top ten, incorporating client and server-side validation, plus a little bit of anti-forgery token and cross-site request forgery just for good measure. If you are doing anything with JavaScript these days, and frankly, if you're doing anything with the web you are probably doing something with JavaScript, this is going to be a really useful course for you to get a good understanding of some of the security implications of JavaScript in web applications. I hope you enjoy watching it.

Managing Auth Tokens
Hi, I'm Troy Hunt, and I'm Aaron Powell, and today we're going to be doing a Play by Play on JavaScript security. Yeah, as you know, we're building more and more modern web applications, single-page applications, stuff like that, so we're probably writing a lot more JavaScript than we used to, and well we should be doing that in a secure manner, otherwise, we're going to end up on someone's Twitter stream. Yes, we don't want that to happen. Now we did a Play by Play not so long ago about going beyond just the basics of Azure websites, that was great, we're obviously going to focus very much on the client-side this time. When you and I were preparing this we found there were just so many different angles to this, so where should we start? What's a good starting point? Well, I think that probably the best starting point is, if we're talking about doing something securely, is how you actually log someone into a website, and how we manage the information that we get back about that person and their identity. So obviously OAuth2 and OpenID Connect are probably the most common way if you're building a single-page application and you're going to be doing security. That gives you nice tokens that you can pass back and forth to your API, or that you send to the browser in different mechanisms, and that's stuff that you want to probably keep secure, beyond just sending it over HTTPS.

Caching Strings and Service Workers
Okay, so that was a good start. We have covered off auth tokens, we started with cookies, we've looked at sessionStorage, localStorage, let's move on and talk a bit about caching things in the browser and server workers. So where do you want to start there? Yeah, so service workers are obviously starting to get a lot more popular. They're appearing across all of the browsers these days, you know, Edge, Chrome, Firefox, iOS, and Android, they're all getting service workers so that we can do these sexy, new progressive web applications that everyone is talking about. But they do introduce a really interesting thing around how we manage data, because a bunch of what we're doing is we're storing data so that we can have these offline experiences. So to take one step back, do you want to define service workers? So put this in a context. What are we talking about here? Yeah, so a service worker is essentially something that's going to run in the background of a web application, and it will continue to run even when you don't have a browser open, so it's just continual background processing. It's also used so that you can do things like intercept network requests, and maybe proxy them, so if you're offline we can send back some data that you've previously cached, and that's where we can start finding some interesting challenges when we're looking at it from a security standpoint.