Web Security, v2

Content Security Policy Overview

Steve Kinney

Steve Kinney

Temporal
Web Security, v2

Check out a free preview of the full Web Security, v2 course

The "Content Security Policy Overview" Lesson is part of the full, Web Security, v2 course featured in this preview video. Here's what you'd learn in this lesson:

Steve discusses utilizing a content security policy (CSP) as a second layer of defense against malicious code. He explains that CSP allows you to specify which domains are allowed to load resources, such as scripts and CSS, on your web page.

Preview
Close
Get $100 Off
Get $100 Off!

Transcript from the "Content Security Policy Overview" Lesson

[00:00:00]
>> Steve Kinney: So yeah, these are, we talk a lot about those, first layer and second layer defenses. Always sanitize your inputs. A content security policy is another layer that if someone does get one in, right? Then still you have a way of also not executing that code, right? The way that the web works, as we saw before again, second layer defense.

[00:00:26]
Don't rely on it first and foremost, but it's your second friend in case the sanitization doesn't work, is that, the way the web works is great. You put a cat meme in there, you're gonna see a cat meme. It could be hosted on somebody else's site. You can put in jQuery from a CDN and have jQuery available.

[00:00:44]
You can grab the bootstrap these are like blasts in the past, right? Grab the Bootstrap CSS and drop it in there. Yeah, do all that stuff. That's kind of what makes the web great, until it's not, right? And a CSP is basically a way to say, okay, you know what?

[00:01:01]
Changed my mind. Only, very much the way that CORS does it for requests, Content Security probably does it for loading resources. You're like, I only want you to load resources from known good domains. If someone jams in their third-party external script, right? Then,don't run it. And the idea of having a Content Security Policy at all, just having one will disable inline scripts just like that script tag is like that.

[00:01:35]
Script alert one script will be disabled unless you actually go, say, unsafe inline, right? Should you say unsafe inline, then you opted into this, and you deserve whatever happens to you. And you're like, what if I need it? I think you need to pull that out into a script that you load on an origin that you can trust.

[00:01:55]
I question whether or not you need it, and I will show you ways around it if you truly need an inline script. I will show them to you. I'm just not gonna be happy about it. And they work and they're good. So it's basically saying only for these things and you can say like, I'll allow CSS from this domain and scripts from this other one, right?

[00:02:11]
So you can get very granular, you can say where you'll allow frames from and everything along those lines as well, and kind of have all that in place. And it is effectively either a header in the HTTP response or if you somehow don't have access to the actual server, you can literally just put in the HTML, right?

[00:02:29]
These will work the same way headers do. And the way that the browser loads the page, it starts at the top and works its way down. So ideally, Javascript does not load until after it's read these tags. If you use any kind of ESM, it always waits until the DOM is loaded, do I actually know what happens if you really hate yourself and you put your CSS, but that will still be before the DOM loaded.

[00:02:54]
Who knows? Or your JavaScript file before your meta tags. I'm not entirely sure how that works in browsers these days but you wouldn't have access to the DOM anyway so you're probably fine but don't do it.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now