I was chatting to some folks at a bank just the other day about a bunch of modern web security standards. Whilst this blog post is about a Pluralsight course I created with Lars Klint, it only really hit me during that bank conversation just how much there is to take onboard when it comes to securing things in the browser today. Let me paraphrase:
Bank: We're thinking of using SRI to protect malicious modification of scripts we load in from a partner.
Me: Ok, but be conscious that means they can never change those scripts without you first modifying the integrity attribute on your script tags and you need time to push that out so as not to break the site.
Bank: We're also thinking about using HPKP to pin the TLS cert to the browser and protect against misissuance of a rogue cert from a CA.
Me: Well, given HPKP is being deprecated from Chrome (and frankly caused more problems than it solved), there's no longer much value in that approach. Have you considered CAA?
Bank: First we've heard of it!
Me: It's pretty neat, it's just a DNS record but it stops a CA you haven't expressly given permission from issuing a cert for your domain. Another really neat modern pattern you can use is the upgrade-insecure-requests directive in CSP. It'll take your HTTP requests and automatically turn them into HTTPS ones.
Bank: We were planning on using HSTS to do that.
Me: HSTS is awesome, but it's different. That'll redirect any requests to the host name HSTS is been set for, but it won't cascade that logic down to child resources served from other host names. If one of those partners you're embedding content from accidentally inserts an insecure request, you're going to need upgrade-insecure-requests to fix that for you.
Bank: But upgrade-insecure-requests isn't fully supported by all browsers, right?
Me: No, IE won't recognise it and neither will the current version of Edge (the next one is all good), but there's a mitigating pattern for that; you add a CSP "report only" that blocks all insecure requests and reports the violation to a report URI of your choosing.
As I had that discussion, the nuances such as the ones I described above just kept coming up over and over again. There were so many edge cases and angles not just to the security controls the folks at the bank had heard of before, but of course all those others that were entirely new to them. These were smart people I was talking to and it made me realise just how complex things are getting these days.
Getting back to the point of the blog post, a couple of months ago Lars and I caught up down in Sydney to record a course on Modern Web Security Patterns which set out to highlight precisely these sorts of security constructs. It's another "Play by Play" in that the course involves Lars and I discussing the content on camera. I decided not to give Lars a heads up on any of the content, but rather let the whole discussion play out as organically as it possibly could because that's really what this style of course is about - a candid discussion between a couple of people. It's also a fairly high-level course intended primarily to introduce the concepts and it only runs for an hour an 24 mins which makes it great for consuming on the daily commute or over a lunch (or two). If you want to get down into the details, Google [security thing] and my name (or Scott Helme's) and you'll find a heap of in depth material.
Modern Web Security Patterns is now live - enjoy!