---
title: "Neil Matatall — Content Security Policy"
url: https://appsecpodcast.com/neil-matatall-content-security-policy/
date: 2020-08-04
duration_seconds: 2582
guests: ["Neil Matatall"]
topics: ["Secure Development"]
audio: https://www.buzzsprout.com/1730684/episodes/8122595-neil-matatall-content-security-policy.mp3
video: https://www.youtube.com/watch?v=8f0ZeW_SgIA
transcript: true
---

# Neil Matatall — Content Security Policy

*August 4, 2020 · 43 min*

with [Neil Matatall](https://appsecpodcast.com/guests/neil-matatall/)

on [Secure Development](https://appsecpodcast.com/topics/secure-development/)

[Audio](https://www.buzzsprout.com/1730684/episodes/8122595-neil-matatall-content-security-policy.mp3) · [Video](https://www.youtube.com/watch?v=8f0ZeW_SgIA)

## Show notes

Neil Matatall is a product security engineer at GitHub. He focuses on designing and engineering user experiences solutions related to authentication and account recovery. Working remotely from Hawaii, Neil is a strong believer in the future of remote work. Neil joins us for a deep-dive into Content Security Policy. We explore what it is, the purpose, and why it's so difficult to implement. Neil Madhatal is a product security engineer at GitHub. Neil joins us for a deep dive into content security policy. We hope you enjoy this conversation with— Neil Madhatal. Are you trying to build a security champions program? Everyone is these days.

The Application Security Podcast is brought to you by [Security Journey](https://www.securityjourney.com/).

About Security Journey  
Neil Madhatal is a product security engineer at GitHub.  
→ [Learn more about Security Journey](https://www.securityjourney.com/)

Connect with Neil Matatall:  
→ [github/secure\_headers](https://github.com/github/secure_headers)  
→ [Content-Security-Policy (MDN)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy)

Mentioned in this episode:  
→ [github/secure\_headers](https://github.com/github/secure_headers)  
→ [Content-Security-Policy (MDN)](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy)  
→ [Scott Helme](https://scotthelme.co.uk/)  
→ [Troy Hunt](https://www.troyhunt.com/)  
→ [Twilio](https://www.twilio.com/en-us)  
→ [Sqreen (now Datadog AAP)](https://docs.datadoghq.com/security/application_security/)

Chapters:  
00:00 Meet Neil Matatall: Neil Matatall — Content Security Policy  
01:56 So, you know, probably like me, enough to be dangerous, which  
05:19 Yeah, that's very cool to hear that you, you know, were  
09:50 So just to kind of summarize a little bit, when we're  
11:58 So like, do you remember, it was about maybe a year  
14:36 So I interrupted when we were in the middle of talking  
20:25 Kind of going back to, you talked about the unsafe inline  
22:18 Neil, when you're building a policy then, is that the steps  
28:46 It just, this is not very easy to do  
30:14 In the example you had where you're adding a button and  
32:39 Yeah. Now, we talked about SRI earlier. One of the challenges  
34:44 We mentioned secure headers as one potential resource. Are there any  
36:07 Scott Helm had a, I think it's still out there, secureheaders.io  
40:02 Great, thanks for sharing that with us and for sharing it

## Transcript

*7,194 words · assemblyai*

**0:00 Chris Romeo:** Neil Madhatal is a product security engineer at GitHub. He focuses on designing and engineering user experience solutions related to authentication and account recovery. Working remotely from Hawaii, Neil is a strong believer in the future of remote work. Neil joins us for a deep dive into content security policy. We explore what it is, the purpose, and why it's so difficult to implement. We hope you enjoy this conversation with—

**0:26 Neil Matatall:** Neil Madhatal.

**0:27 Robert Hurlbut:** Neil Matatall.

**0:28 Chris Romeo:** Are you trying to build a security champions program? Everyone is these days. One challenge of rolling out security champions is, how do we educate all these new folks? Security Journey has your answer. We provide a security dojo environment with level-based security education that gives your newfound champions a path to follow. And the best part? It requires almost zero administration by you. Visit www.securityjourney.com to set up a demo and learn how you can use the Security Dojo to connect with your security champions. Hey folks, welcome to this episode of the Application Security Podcast. This is Chris Romeo. I am the CEO of Security Journey and co-host of said podcast. I'm also joined by Robert Hurlbut. Hey, Robert.

**1:28 Robert Hurlbut:** Hey, Chris. Yeah, good to be here with you. Threat modeling architect.

**1:32 Chris Romeo:** And we're going to talk about content security policy, which, Robert, you were advertising that you were a semi-expert, which I'm not really sure what that would mean, but—

**1:41 Robert Hurlbut:** Yeah, well, not quite advertising, but I've dabbled in it a bit, enough to know how it works and set it up and test it, at least for my own site, maybe a couple others, but I'm very interested in learning more about it.

**1:55 Chris Romeo:** And so, you know, probably like me, enough to be dangerous, which is a lot of things in my career. And so we're joined by Neil Matatall today, and Neil, we're gonna jump right in with our first question for you. Our audience always loves to hear how people got into security. So what is your security origin story, Neil?

**2:15 Neil Matatall:** So my security origin story stems from my developer origin story, but if I was going to look back at the first sign I thought I knew I'd be in security was that I like to take things apart. Anytime some electronic equipment would break or become obsolete or whatever, my parents would give it to me and I would disassemble it to see how it worked. Surely I didn't deduce all functionality, but especially with the mechanical things, I thought it was really cool to see how these machines would work. Fast forward to when computers were more prevalent, I discovered eBay, and the first time I created a bulleted list so that I could sell some junk in my closet, or in my parents' closet, for some reason it was mind-blowing because it first of all took me 10 tries to get it right. And then when it finally rendered, I thought it was a beautiful thing. So that was my first time I actually enjoyed a computer where I wasn't doing data entry, which I did not enjoy. My school started offering a C++ course the year before my senior year. And a couple of my friends were interested and I just enrolled because my friends were into it. And then I think about 3 weeks into it, I kind of realized like I really enjoy this. I had just sent in my college application. to be a math major, but shortly after I knew I was switching majors immediately. Halfway through my college career, I accidentally realized I was on the path to get a specialization in networks and distributed systems just because of the classes I had chosen to take, if I just sort of modified my future plan a little bit. And 2 of those classes included a class on cryptography, which I had no interest in before, and another one that was sort of a general network class with a light focus on network security. Another, you know, moment where something clicked was the first time I worked out an RSA encryption operation by hand. I encrypted the number 3, and it came back the number 3. And I just thought that was beautiful and amazing, especially understanding how public key cryptography sort of works. By the time I graduated, my internship gave me the option to switch to another team or to stay on the same team, but He devoted 50% to security. At the time, I have heard of XSS, but I didn't even know what the defense was. So that security position sounded interesting and was completely accidental and situational and non-intentional in every way. But the opportunity did sound at least interesting. And one of my first tasks was to come up with a training course based on the OWASP Top 10 because our director had seen it mentioned in the PCI spec, and she definitely was also very security conscious. So an early mentor really helped me along this path. And by the time I created a training course on the top 10, my understanding of the web went from barely anything to, I want to learn all the things for the web. So just a series of accidents and moments that clicked in my head that really just made it very obvious what my career path was going to be.

**5:18 Chris Romeo:** Yeah, that's very cool to hear that you, you know, were kind of taking things apart and putting them back together. I think the, the term hacker is misused so many times, you know, like in the media and kind of portrayals and things. But if you look at that original definition, it's what you were doing. It's taking things apart and figuring out how they work, and then sometimes putting them back together and making them continue to work. That's always the rub. It's the making them work again. Well, that's very cool though, to hear your kind of path as you have made your way into the world of security. And so the topic that we want to specifically focus in on here is content security policy. Now, some people are probably shaking right now. They're a little bit afraid because they may have dabbled in content security policy and then quickly, you know, they dipped their toe in the pool and then turned around and ran away from the pool because it was something that it seems like it's it's misunderstood, but I think the value of it is so worth understanding because it can make such a big difference. And so when we're talking about content security policy from your perspective, I mean, what is content security policy?

**6:27 Neil Matatall:** Just to skip the question for a second, I just want to be very clear in everything I say that while I have successfully done CSP in many environments, it is Mostly because of what other people did. So if I talk about it and it seems like I'm making it seem easy, maybe it was a little easier for me than many others. But to get back to Content Security Policy, it is an HTTP response header, or it can be used as a meta tag in limited form. Its primary purpose is to govern what resources can load on a given page or what sort of content can execute in the context of a given page load inside of a browser. It was developed over at Mozilla in 2008, I think. It was sort of a successor to the NoScript browser extension, which would allow an end user to specify what JavaScript can run. You know, we would disable trackers. If there was this particularly sketchy, you know, bulletin board site, maybe you just don't want any JavaScript. But it was up to the end user to apply that. And so CSP kind of brought it to the Application Administrator. It was announced at AppSec USA in 2010. I was at that event. I had a chance to talk to the people who built it. And my first question was, how difficult is it to retroactively apply? Their answer was maybe discounting how hard it is. So time passed and WebKit, which was what Chrome was running on before Blink, implemented CSP, but they did it differently. The implementations kind of shared some core concepts, but the headers themselves were absolutely not compatible between the 2 implementations. They also had different header names for this reason. You would actually have to write a library to translate between the 2 modes if you wanted to effectively apply it in all scenarios where it's understood. It became a W3C standard and it dropped the X prefix and the standard kind of chose mostly what was in the WebKit implementation, but I think one of the most important things they took from both implementations was the concept of prefixing unsafe things with the word unsafe. If your policy has to do something because your application determines it, having to declare that you're doing something unsafe, I do think makes a mental impact, or at least something obvious that if you're just looking at this thing and something looks wrong, it should change. It's gonna be removing the word unsafe. We're currently on the 3rd version of CSP. CSP 1.0 was not really adopted by many. CSP 2.0, tried to make it easier to apply, but again, it's just still not taking off. CSP3, again, introducing more features to make it easier. It's too early to say whether this will be successful. It's not widely implemented. But the point is that CSP is trying to become easier and more concise and not trying to solve every problem, but really focus on whether or not JavaScript should execute, because that's really the biggest concern. Each CSP version's new features do, in a sense, weaken the policy. You know, if you have a policy that is all CSP 1.0, you cannot make it any better. The policies that you can apply in 3 and 2 can be great and practically just as good, but technically not as good. I'll explain where I get that from later on.

**9:50 Chris Romeo:** And so just to kind of summarize a little bit, when we're thinking about Content Security Policy and trying to get kind of a mental model for what's happening here. Content Security Policy is set on the server side and it is communicated to the browser and it is basically pushing the policy down into the browser that is saying— it's defining what the browser can do. Specifically, from a security perspective, we're most interested in the JavaScript, I believe is what you said. just because it can execute? I'm guessing because it can execute, right?

**10:27 Neil Matatall:** Yeah, there are other concerns like whether or not Flash can load, but those are becoming less and less important over time.

**10:34 Chris Romeo:** Given Flash is about to be— Flash is about to die, right? We're all in the security world, we're about to, you know, January 1st, I think it's this January 1st coming up, we have a collective cheer across the industry as Flash goes to end of life, end of sale, end of everything.

**10:50 Neil Matatall:** I will certainly be celebrating, that's for sure. But you can do so much more with CSP, and I'm beginning to be of the mind that trying to focus on all of CSP detracts away from the main goal of CSP. And so I've kind of been downplaying its other capabilities and really trying to focus on the script execution. And if you have a policy that literally only defines what JavaScript can run, that is just so much better than most of the policies on the internet.

**11:18 Chris Romeo:** So from your perspective then, most of the sites that are out there that you're aware of aren't using CSP, like big, big sites we use every day?

**11:26 Neil Matatall:** It's both a matter of adoption and proper use of policies. So I think we're still under like less than 1% of the top 500 or total page loads on the internet. So adoption is very poor and of those policies, Google did some research recently that showed that like 90% of them provided little to no benefit. So it's very, very, very, very niche, but I do still believe it's very, very, very powerful.

**11:58 Chris Romeo:** And so like, do you remember, it was about maybe a year or two ago, there was a British Airways attack where they had JavaScript that was being loaded into users' browsers? I can't remember all the details, but when I think of something like that, I think CSP seems like it was invented to prevent that from happening, because I think the attackers polluted the JavaScript somehow and then got that JavaScript to execute in the users' browsers. I think they were crypto mining, if I remember correctly. But I think that's— I mean, when I think of CSP, that's the use case for CSP though, right, is to prevent things like that from even being possible?

**12:37 Neil Matatall:** Exactly. That is one of the many threats that it attempts to address. I don't remember that one specifically. I absolutely believe it was about Bitcoin, but there's a few things that could have happened, whether or not there was another asset stored on the same server. So to get into— to jump ahead into how CSP operates, you can— one part of it is that you can define the hosts from which you can load resources. Instead of the entire internet, maybe it's just limited to your CDN. That's an ideal situation. But even if you're just limited to one CDN, something like subresource integrity would actually protect you further in case your CDN were compromised. So going back to that case, I don't know if—

**13:25 Chris Romeo:** Subresource integrity is— sorry to interrupt. Just a— what is subresource integrity?

**13:31 Neil Matatall:** So Subresource Integrity allows the server to return HTML that will essentially provide a hash value of the expected contents of the loaded resource. So when you go and you deploy your app and you build your bundle, you compute all the hash values for the content that you are going to be then pushing up to your server. And so you're saying, give me this JavaScript file and it better match this checksum or else I'm not going to load it. Even though you specified just my server, even if your server was compromised and they changed the JavaScript underneath you, you're still probably safe.

**14:08 Chris Romeo:** The browser's smart enough to check that, to check those features out?

**14:13 Neil Matatall:** Actually, this came up recently, the Twilio instance where someone had swapped the JavaScript underneath to add probably a Bitcoin miner thing. I don't think CSP would have stopped that attack. I might have been misspeaking on that one. I don't think they were loading host JavaScript from an external source, but they had instead modified the JavaScript they expected to serve, so resource integrity would have helped.

**14:36 Chris Romeo:** Okay, so I interrupted when we were in the middle of talking about kind of how this actually works. And so you mentioned resources. When you say resource, you mean like a JavaScript file, for example, is a resource?

**14:50 Neil Matatall:** JavaScript file, image, CSS file, XHR requests.

**14:58 Robert Hurlbut:** All kinds of—

**14:59 Neil Matatall:** List goes on and on.

**14:59 Chris Romeo:** You've talked about some of the kind of categories and things, but let's get into the nitty-gritty of how it actually works.

**15:05 Neil Matatall:** So again, CSP is a response header or meta tag. It's a semicolon-delimited string of directives, are what they're called. Each directive will govern, like we said, where an image can load, where CSS can be loaded, where JavaScript can be loaded. Those are what are called the fetch directives as they integrate directly with the fetch spec, which is more or less how browsers are agreeing on, for example, whether or not a CORS request is necessary. It's heavily integrated with that spec, and so anything that is loaded via fetch will be covered by these directives. There is one special directive called the default source directive. that will apply to any undefined directive. Confusingly, it is not additive. So if you have a default source and you have an image source, the image source contents are not added onto the default. They overwrite the default source. Now, each directive is a list of sources. And a list of sources— oh, sorry. It's a source list, which is a list of sources. The source is where it kind of gets important where you understand the differences. It can be a URL-like thing, so http:// would allow any HTTP resource, HTTPS, any SSL resource. You can specify a specific host, so that's why I mentioned just my CDN, not the public CDN, not every internet, not every server on the internet. You can even get as specific with a path, so only load resources from this host at this path. It's pretty darn powerful that way. I don't see too many people using paths, but that has been supported since CSP 1.0. Then you get into a set of reserved strings. I think they're called keywords. There's one that's called self, and this means the same origin as the page that is loaded, which is really helpful, especially if you're just doing an application where the resources come from the same place as the dynamic application. Really simple. Maybe it's hosted on 10 different domains. You won't have to keep updating that value. Whatever this host is, allow something from it. There's a value of none, which says don't load anything. That's hopefully self-explanatory. There's also, for JavaScript and also CSS, there's the concept of unsafe inline and unsafe eval. Unsafe inline for JavaScript refers to a script tag in a page that has literal JavaScript and is not sourcing it from an external file. Unsafe eval is whether or not the eval function is able to be used at all. Eval is not uncommon in frontend frameworks. It is not uncommon to be used. It is not inherently dangerous, but it has the possibility to be very bad. It is async for direct XSS, execute whatever I say. It is a— that is kind of a problem. I'll explain more of that later. And then lately they've added these sort of helpful values to make applying CSP more easy. There is a concept of noncing individual script tags such that if the value of a nonce attribute of a script tag matches what is in the header itself, that inline content can then execute. There's also the concept of hashes so you don't have to manage setting a random value in a header and script tags, but rather you know the value of the content of the script tags ahead of time So you can declare that in your header and you don't have to modify your page at all. Obviously that doesn't work if you're using dynamic JavaScript, but I would strongly argue you should not be using dynamic JavaScript. The hash is nice because it doesn't allow you to do that. The nonce still allows you to— the nonce approach allows you to do whatever you want. So I don't encourage it, but it can be a useful tool. And there's also a new concept of what's called strict dynamic. And that is the CSP 3.0 feature I will talk about that is That could change the game for a lot of people. But that is the anatomy of a CSP header itself. There are non-fetch directives. For example, form-action governs where a given form on a page can, for example, post to. So I only expect my website to post to my website. I don't want to allow some JavaScript to potentially change that form to post to an external website. There's also special directives like block all mixed content where if you're on an SSL page and you just try to load any non-SSL content, it just refuses to load it no matter whether it's an image, whether it's an XHR request, et cetera. And this list kind of grows on and on and there's some debate whether CSP is just becoming like a bloated place to throw every security feature ever. But I don't know that that's still a concern. Going back to the subresource integrity thing, we have proposed a directive that says require SRI for, so I don't ever want to load a script tag without an SRI tag. If a script tag is missing one, I don't care, just don't load it no matter what. I don't think that's been implemented, but I hope it does one day.

**20:25 Chris Romeo:** So kind of going back to, you talked about the unsafe inline and then unsafe use of eval. How do I control that with the policy? Like if I specify the unsafe inline, does that just, does the browser then just ignore inline scripts? Is that what's happening?

**20:51 Neil Matatall:** It's more the other way around. The presence of the unsafe inline value tells the browser to execute any script whatsoever. The lack of an unsafe inline would prevent it. Okay, got it. So a really common strategy is to start with your default source of none. So by default, nothing is being allowed. And then you can sort of like add it on to like your script source. And then hopefully that doesn't include the unsafe inline.

**21:17 Chris Romeo:** Okay, and then so you're kind of starting, when you're building that first policy, you're starting with kind of a bare bones policy. You load your app, nothing works. And then you're slowly adding things to kind of help you to— because there are resources that your app needs to use to operate, right? Like you can't, you know, as much as we as security people would love to have a deny-all, you know, CSP, deny-all policy means there's a white background screen or whatever your background is in the browser, and there's nothing, nothing's gonna load because it's all being blocked.

**21:52 Neil Matatall:** Right, super secure.

**21:54 Chris Romeo:** That's always the key.

**21:56 Robert Hurlbut:** I remember that when I was first learning about it and I did that, I said, okay, I'm not going to start with the best scenario. I want the worst scenario. Give me no access to anything. And I remember the white page, I go, uh-oh, and building up from that. And it was interesting, but yeah, I remember those days.

**22:17 Chris Romeo:** So Neil, when you're building a policy then, is that the steps you're going through? Are you starting by, you mentioned that kind of default code or tag that you were putting in that policy. Is that kind of what you recommend to people, is to start with a policy that blocks everything and then just start adding the things that you need? Is that how you implement CSP?

**22:38 Neil Matatall:** Personally, yes. I think you can— there's also a baseline policy that is reasonably secure and applies to most websites on the internet that you could start with, but you know, that's not going to save you that much time. You're going to have to modify your policy a lot, and it's going to be an iterative process too. I guess I could get into the recommendations for starting to use CSP now.

**23:06 Chris Romeo:** Yeah, yeah, let's talk about that.

**23:09 Neil Matatall:** So CSP comes with a report-only mode so you can simulate using your policy, and in combination with that, it has a a reporting mechanism such that you can supply a URL and it'll post some JSON to you each time there's a violation containing information about, you know, what page it was on, what violation occurred, what tried to happen, you know, why it didn't happen. Lately, if it's an inline script violation, we'll actually even include the snippets of JavaScript so you can help maybe identify where that came from, be it malicious or not. So yeah, I would start with a default source none policy in report-only mode. Look at your console, start picking it, because it'll literally tell you what to add to your policy. The console will tell you, so just do whatever it says with some reasonable expectation that your browser isn't compromised or riddled with browser extensions or your website is not currently hacked, because all of those situations will lead to erroneous reports and you don't want to just start adding everything to your policy that you see. That is exactly why, I don't know if, do you remember the Superfish privacy issue? I think it was one of the laptop manufacturers were installing spyware.

**24:31 Robert Hurlbut:** Yep.

**24:31 Neil Matatall:** Well, the way that manifested was it did something in your browser. And so a lot of people who are managing CSP saw these violations and they go, oh, Superfish, I don't know what that is, but sure. And so myself included. ended up enabling this attack when we actually could have maybe put a dent in it. So I think just crawl your site, try to hit the deepest, darkest corners of your website, modify your policy as you go along. I think it's okay to be a little generous for your first time. Some policy is better than no policy. You're going to build up a baseline policy that works on your machine. There are browser extensions that allow you to modify and iteratively build your policy. One of them is called Casper for Chrome. I believe Observatory from Firefox will also allow you to do this. And once you have some sort of reasonable assurance that your policy is good, then start testing it. At GitHub, we're lucky because we can test our employees. Our employees always get the CSP changes first. Because one, like, again, we have reasonable expectations that their browser isn't owned, that they're not installing malicious plugins. There's no guarantees here, but it's, it's not the general internet. That their browser is generally up to date. An out-of-date browser will also be more noisy than one that's currently up to date. So if you have this sort of test group you can run it on, get this report, modify your policy, again, it's going to take so many iterations before you get it to where it's good, and then you make the decision to turn it on for your employees. And if that all works out great, you do the same thing to the rest of the general population. And now if you don't have a group of employees you can test it on, or if maybe your employees just don't use your app for one reason or another, that can be more difficult because again, you don't want to open it to the general internet because the reports will be garbage. Malware, extensions, all these things generate CSP reports. I would say that 10% of the CSP reports on the internet are because of LastPass specifically. So just the reporting is helpful, but don't treat it as absolute truth. Always question it. Always make sure that you're supposed to be loading that asset resource and maybe create a note to follow up and be like, maybe we don't need to do this later on. It's an iterative process and I think every engineer who hears that is going to think, well, I'm going to hook up a crawler to it and just generate my policies. More power to you, but I think you're just wasting your time. Install the plugin, crawl your site for 30 minutes, get your version 1, move on and be done with it. There are products that will help you manage CSP reports. I believe Sentry has a dedicated UI for this. There are also a couple products out there. The Chrome— the Casper author, I believe, is coming up with a product to sort of read these reports, manage the policy itself. I think Screen also has a product around this. I would love to see these products be successful. I really think it's a hard, hard problem to solve because for you to make CSP like point-and-clickable for the general internet, that's gotta have like Apple-level experience engineering going on there.

**27:54 Chris Romeo:** Yeah, so I've got some experience with the screen one, and it's actually quite well done because they just, they let you put it into monitor-only mode, and it just sits there and runs. Literally, you can let it run for as long as you want, for a week or longer, and then it goes through and builds the policy for you based on everything that's happened. And you see some crazy things that pop into that as well. that you can obviously not click on and add in. But yeah, it's actually, it's a pretty, I was impressed with it as far as the ease of use. Now, I had to have a little bit of knowledge about what was happening. It wasn't Apple-level point-and-click and it just does what it's supposed to do. But I think it's going in the right direction for making CSP easier for folks to do. 'Cause I think that's one of the keys here.

**28:44 Neil Matatall:** Yeah.

**28:45 Chris Romeo:** Is it just, this is not very easy to do?

**28:47 Neil Matatall:** It's so hard to do. That was all about getting, I think, your version 1 of your policy, and I think it's very much like a mentality of the policy is more or less static across your application. But if you really want the best possible policy, you're gonna have to have some sort of way to dynamically apply it in certain situations. And I think this is where those products might not do so well because they might not know enough about the application. We might have an integration that puts a button on a page, and that's a third-party frame, and it's only available on Tuesdays if your account starts with the letter A, and there's been a blue moon in the past 3 months. This sort of flexibility is what you need in an application, and I'm not sure that something living outside the application would know all that information, but I would love to see it work out. I'd said you're supposed to crawl your site, go to the deepest, darkest corners, see what you should allow. If this is— and this is a true story— one of the first ones I did had one page that had a WYSIWYG editor that needed unsafe-inline and unsafe-eval, but enabling that for the entire application was wrong because it didn't need that anywhere else. So don't think of it as something that you set in your Nginx application unless you are truly building a static site. You need facilities to have dynamic CSP if you want it to be as concise as possible.

**30:13 Chris Romeo:** In the example you had where you're adding a button and in an enterprise-grade application you need the ability to do dynamic CSP, is that something that has to be hardcoded by the developer to make the modifications to make CSP work correctly for that button when it's loaded, or are there automated solutions in the developer flow? that make that dynamic CSP a reality?

**30:42 Neil Matatall:** There absolutely has to be well-understood, easy-to-copy facilities for managing the policy. GitHub uses a library called Secure Headers, and that one has a way to just— you just have a function call that says, hey, add this to the CSP. It's used in hundreds of places. It's used by 99% of the time, not anyone on the security team. So it really enables the developers to control the policy however they see fit. And, you know, it's not Wild West. Every time they add an override, it triggers a review internally, and it absolutely has caught people trying to, for example, add unsafe inline to the default policy. So if you have a well-documented and understood API that can be found with a regular expression, You've both enabled the developers to do whatever they need, and you've enabled the security team to keep an eye on things as it goes.

**31:40 Chris Romeo:** Yeah, I was just taking a quick peek at Secure Headers. I hadn't heard of that before. So that's a GitHub project that GitHub puts out there based on what you're using internally, so that's really cool.

**31:51 Neil Matatall:** It's a product from Twitter, actually. We took ownership of it. It not only applies makes adding a one-line opt-out easier. It does add some functionality, like when I mentioned the nonce JavaScript tags. The concept of putting a random number in an attribute and having a matching number in the header is not rocket science. But if you're still treating this as a static string, that can be hard. So there's just a helper function that you can put inside of whatever is generating HTML that says nonce JavaScript tag, and then you add your raw JavaScript in between it, and it'll automatically create the script tag. It'll populate the header. and you've never even seen or dealt with the nonce attribute itself. It's just all handled automatically for you. Another thing we alert on.

**32:39 Chris Romeo:** Yeah. Now, we talked about SRI earlier. One of the challenges that I've seen with using SRI is when a third party— when you're getting JavaScript from a third party and they're obviously building and deploying 50 versions of that library per day, it's tough to keep up with the hash that they have, given that it's a piece coming from a third party. Do you have any insight on that? Is that truly, from your perspective, a problem, and there's just not a good— there's no dynamic answer to how you can deal with that?

**33:16 Neil Matatall:** Well, I mean, if it's dynamic, then there's nothing to stop the malicious code from being dynamically accepted as well. It is a problem. Certain vendors will, like you said, change it 50 times a day. Some will maybe agree to support a static version for some period of time. Some will give you their unminified source and some won't. Some want to play ball and others don't, and then that's who we do business with. Third-party marketing tools are particularly tough. You do want the ability to be able to change the code on the fly. Marketing teams don't want to manage a custom JavaScript solution that they have to glue 2 incompatible systems together. So it really does limit the types of technologies you can use. Other vendors will bend over backwards to play ball with you, and in those cases you have secure solutions. One example was we started adding CAPTCHAs to our signup form, and, you know, putting third-party content on a page where someone's password exists is a big no-no. We would never do that. It's against the rules, period. But if the vendor is willing to build a postMessage API so that you could then create framed content on your domain that hosted their framed content that you could communicate to with postMessage, then you've effectively sandboxed the third-party code. That third-party code even required the use of eval and we said, that's fine. It's in a frame. No problem. We're not worried.

**34:44 Chris Romeo:** So we mentioned secure headers as one potential resource. Are there any other— I know you mentioned Mozilla. Are there any other resources that you would direct people to that are listening to this and they're thinking, now I feel like I know a little bit about CSP, maybe as much— and I know enough to be dangerous, like Chris said earlier. But what other places would you send people to that are thinking, I want to know more about CSP?

**35:12 Neil Matatall:** So the Secure Headers Library lists out other libraries that have similar functionality that cover practically every framework or language. So if you want a tool, I would suggest checking one of those out. I feel that Twitter is a great place to get CSP information. Mike West is a great follow. remember their whole handles, or Lucas Weichelbaum, a bunch of Google employees are really tweeting about the forefront of CSP and where it's going. So that's a good way to sort of keep up with the current news, but there's certainly no shortage of content going deep into CSP. I think Scott Helm had a pretty good explanation of it. I think Troy Hunt also did an article on it. Great way to get your feet wet with these sort of things.

**36:06 Robert Hurlbut:** And Scott Helm had a, I think it's still out there, secureheaders.io, I think. Is that still there, that test site?

**36:15 Neil Matatall:** I think so. Yeah, that's the one that'll analyze your policy and tell you about maybe things you should focus on not doing. It'll call out unsafe inline and dock you heavily for that.

**36:30 Robert Hurlbut:** Right, I remember using that a lot when I was building mine.

**36:34 Neil Matatall:** Yeah, I think it's a cool tool. I think there's been at least 5 or 6 of them that have been built. I think Mozilla also built one. I think it's really, it's really useful. If we can take the word unsafe and make it a red unsafe, that matters.

**36:49 Chris Romeo:** Definitely. So Neil, one other thing we wanted to ask you about. You had been telling us about an initiative to bring remote workers back to Hawaii. And so, as I understand, that's, you know, where you call home. And so I'd love to hear more about this program you're working on.

**37:08 Neil Matatall:** So I'm not originally from Hawaii. I'm originally from Southern California, but I moved here about 5 years ago and kind of got involved in the tech scene around here, which is kind of fragmented, a little bit limited, not too huge, but I did get the opportunity to meet some good people. including someone who works with the state, about business development. And as you can imagine, Hawaiʻi is struggling in the face of COVID An economy that is wholly dependent on tourism has now tried to— now has to scramble to figure something else out. Unemployment is expected to hit 33% by the end of the year, and without any tourism income, it's not going to improve unless we do something else. One of the initiatives was an idea to bring people who maybe previously couldn't work remotely, but now have either the new ability or new desire to work remotely, who at the same time maybe have enough mobility to choose where they want to live. And if that's the case, maybe they should consider Hawaii. And it would be a shame if we imported 1,000 Silicon Valley engineers I don't think that's anyone's goal. We would love to have people who are originally from Hawaiʻi return. That's definitely the first group of people we'd go after, but, you know, tech workers coming to Hawaiʻi will benefit Hawaiʻi no matter who they are. You know, obviously, the tax revenue and the business to local businesses will help tremendously, but there's actually a hidden element that may not be too obvious to anyone who doesn't work in HR, is that hiring your first employee in Hawaii is one of the most difficult tasks you can do in HR-related businesses, so much so that even companies that support remote work will put a big red X over Hawaii. Not that it's the most difficult state to do business in, but it's difficult and it's not very common. So they're going to incentivize companies to stream— to hire their first remote employee in Hawaii such that maybe we can build a pipeline so in the future they can hire their second and their third and their fourth employee in Hawaii. which will be trivial compared to the first one. So companies like GitHub and Microsoft that already have employees here, that's easy. They can move. But for other companies, it's not trivial, and we want to make that easier. We want to encourage it. We want to encourage these people to give back as well when they get here. Start a tech community, train up your neighbors, get involved with the schools, Throw a coding class together, just really help grow a tech scene that's gonna help diversify Hawaii's economy.

**40:01 Chris Romeo:** Great, thanks for sharing that with us and for sharing it with our audience as well. As we think about kind of the end of the conversation here, any particular key takeaways or perhaps a call to action you might have for our audience so they can get out and do something as a result of this conversation?

**40:27 Neil Matatall:** Yeah, I mean, I understand there is a lot of— I will just say hate directed at CSP. It's stupid, useless, or hard depending on who you talk to. I just think it's stupid.

**40:38 Robert Hurlbut:** Excuse me.

**40:39 Neil Matatall:** I just think it's stupid hard. GitHub is at a place with our CSP where we don't even think about it anymore. I haven't made a change to the policy in probably 4 years now. It is an afterthought. We do not worry about it. We're confident that our policy is good, won't be modified underneath our feet without it triggering alerts, and it provides us so much protection that we've even been— we've even said publicly that XSS isn't really a big concern for us anymore. We're actually more concerned that you can inject an official-looking link where it's not supposed to be than whether you can generate a console violation. And having that sort of certainty along with a certainty that technologies like SRI bring, it's like I don't worry about the things that a lot of people worry about, or I don't worry about them as much. If someone were to find an XSS vulnerability, it would be like, well, we'll get to it. CSPs got our back. We're not too worried about it. And that's just a feeling that I don't think a lot of people get to have. And that's, I think, why I appreciate it so much is I don't worry about these things anymore. I have guarantees about my application. I have assurances. I know how my application behaves. And that is powerful.

**41:59 Chris Romeo:** Yeah, definitely. So thanks, Neil, for joining us today and sharing your knowledge and experience both in Content Security Policy and also for sharing your thoughts on this remote worker initiative for Hawaii. So it's great to have you here as part of the show, and we definitely want to bring you back in the future to talk about security at scale because I think you've got some unique experiences there that I would love to hear, some of the stories of security at scale. So, Neal, thanks for being here with us. Thanks for listening to the Application Security Podcast. You'll find the show on Twitter @AppSecPodcast or on the web at www.securityjourney.com/appsecpodcast. application-security-podcast. You can also find Chris on Twitter @edgeroute and Robert @roberthurlbut. Remember, security is a journey, not a destination.

---

Source: https://appsecpodcast.com/neil-matatall-content-security-policy/