
Hi, my name is Jason Gillum with Secure Ideas and I'm going to be presenting building a better grid. So, this is a framework that I'm proposing for measuring the content security policy effectiveness. Uh, and this uh presentation is being done for Besides Charlotte 2026. Um, and I I'll get on to the next page here. Uh, who am I? Uh for those who have never met me uh in the Charlotte area, my name is Jason Gillum and I am the CIO of Secure Ideas. Uh Secure Ideas is a pen testing firm. That is primarily what we do, but we also do a lot of other cool things because we're really just a big bunch of nerds. Um and
uh I'm I'm in addition to that, I'm an Ians faculty member. Ions is an organization that pairs up uh their their clients uh who are in seeking expertise in various areas with experts to answer their various different questions that come up. Uh I am also an OAS project committee member which is part of my interest I guess in coming in with this specific um type of of uh talk right where I'm talking about an application security uh control and uh other than that I've been hacking things for a long time programming for even longer and uh and I have a variety of different interests uh all of which are in various There's different ways somewhat nerdy. Um, I
know the the I have my business strategy uh on there. It probably doesn't seem like that's that is there, but I I guarantee for those of you who are in the tech world who have not looked at business before, it can get pretty nerdy once you get in there. Okay, so let's start with what is CSP or content security policy. Um so what this is this is a control a security control that is actually built into all modern browsers and it it uh takes the form of a response header. So when you look at the raw request and response traffic that you get in uh a browser um for the various different um requests that are
being made by an application. um some of those uh some of the some parts of that response may contain a header that's called the content security policy and it will have a list of directives on it. Um this is a very simple example on this slide where you see script source is self frame ancestors none form action self. Okay. Um there are a lot more directives than this and that's one of the things that I I want to talk about a little bit and why why this project makes a lot of sense. Um but uh but those are some of the basics. Um so some of the key capabilities of the content security policy um one one of the the most
well-known ones in the application security world is script sources. Right? So what this does is it controls which JavaScript is permitted to run within the browser for that website. Um so that can be a very powerful tool especially if you start thinking about cross-sight scripting attacks where uh it's the attacker is in attempting to inject their own scripts into an application. Um a properly formed content security policy would prevent those scripts from running. Okay, they they still might be injected but they won't actually run because the the browser will actually stop it. um other types of of uh controls that are there. Uh there's a whole set of controls around form actions. So you know when you go to a
website and it says fill out this form and then you press a button and it submits that form. Um the form action is where you're submitting that form to. Okay. So that is uh that is something that can actually be controlled again through the content security policy thus preventing an attacker from injecting their own um target for forms to be submitted to. That is a kind of a a twist on on the cross- sight scripting attack because um if if they're able to control the form destination, they don't even need uh an attacker doesn't even need to have a um uh the ability to run scripts at that point in in your application in order to
do something such as capture the username and password that's logged in through a form. Um then there is frame controls. So a lot of websites will use frames to bring up either other parts other information or parts of the same um application or sometimes they are used to embed um information from other applications. Uh and then they're also used for a variety of different uh web application tricks as well on the development side. Um so one of the things that we can do the for frames are by the way they are used for a a series of of uh attacks category of attacks um that are in the the field of um uh clickjacking, right? where you you
basically stack various different elements in front of each other and when a user goes to click on uh let's say a button that looks innocuous on your website, they're actually clicking through into a frame to something else. Um so it's that things of that nature um are are the uh the types of attacks that are used there. And with uh again a content security policy and the right directives on there, you can prevent um this type of attack altogether, right? It it controls where frames are allowed to open from the website. Um and then finally uh we have uh a variety of different directives for where to load um various resources from such as your images and
your fonts and your styles and uh and even media on there as well. Okay. So um what I would like to propose and the reason why I think this is important is because the way that we treat the content security policy in um in our uh you know when we when we're analyzing or testing the security of an application uh the way we treat it is um not not very good. Okay. It's it's definitely not on par with something that we're more familiar with testing, which is let's say a firewall or a set of firewall rules. So, if we're doing a test inside of a network and we know that there's supposed to be a firewall
there, what we do is we there's a lot of questions that we might ask ourselves like and and just think bear with me for a second, but just think for example, um you have uh a sensitive network inside of your system like a card holder data environment, a CDE for for those of you who are in PCI or a similar um set aside network for sensitive data. Maybe it's for healthcare or whatever. Okay. And then you have a security control that's dividing that subnet from the rest of your network. What are some of the things that you're going to be asking yourself? Well, first of all, is the firewall there? Yes. Okay, it is. But
you don't just stop there. What you want to know is, is it actually doing its job? What traffic is it blocking? Are the rules set up correctly, or is it allowing certain types of potentially malicious traffic through? Um is it um is it uh doing proper um blocking of of uh ingress and egress of traffic? Right? So so does it allow sensitive information out through potentially the wrong um channels. Okay. So there's a lot of things that can be tested in firewalls and quite often during an audit or an assessment or a pentest of a network where there is supposed to be a firewall, we spend some time scrutinizing that. But when we look at a
content security policy, this is treated as oh it's just another control but nobody really uses it. And in very very often what we see is in any sort of audit and part of this may may just be because people don't really understand the content security policy, but they just say, "Hey, do you have one?" And oh, yep, you do. Okay, you're done. May maybe we'll ask, does it have unsafe inline or or some sort of directive in there that's known to be bad? Uh, but that's that's pretty much as far as it goes, right? We don't really scrutinize the the content security policy very closely. And so the result is we have a control um that is there that is not used well.
And um last year I did a talk that where I had actually scraped a bunch of data off the internet. Um I looked at a whole bunch of content security policies. I took something called the tranquil list and it has a million domains in it. Now, I wasn't able to get um pull back web content from all million domains because a lot of those domains are used for other things, but I was able to pull data back for a very large number of them. Let's just say around 3/4 of them. And of those, I found that um and I I recently redid this uh just a couple weeks ago um and the numbers really haven't changed much. So about 80% of
what's out there doesn't have any content security policy and then about um almost 20% has a content security policy and then there's a couple of other modes on there too report only mode which is maybe somebody who's looking into doing one or assessing one or something like that. So um but uh but the point is is that really only 20% of of the internet even uses the control at all. Now of that 20% um if if you if you look at the the breakdown of that um you have a a very large percentage of that. So that that 20% that's kind of the the orange yellow and green on the end here. Um and what what you see and and also actually
sorry part of the red on here as well. So this this is this graph is a little bit um um maybe maybe seem a little bit odd uh because it doesn't really fit with the previous slide perfectly. that um when I say no meaningful protection, what I mean by that is it either doesn't have a content security policy or it has a content security policy that doesn't do anything. Okay? Whereas on the previous slide, I was talking about no policy even stated. Um so in this one here of the policy of of all of those same websites that I looked at, um 82.2% have a content security policy on there that um that is completely ineffective.
Um, so it's either it's either doing it doesn't have one at all or the it has one but it doesn't do anything. Um, and then uh around 17 um% of all again of all of the websites out there have a content security policy, but it's very very minimal. It's only it only has it's only using a fraction of the available directives and so it's not actually fully blocking stuff um including a lot of things that it probably could turn on but um but it's not um and then we have the remainder. So as you can see on here of all the websites out there that I tested we're looking at less than half a percent
um that are in the the sort of moderate. So they actually provide some protection. So, they're doing relatively well compared to everybody else. And then a very small percentage um actually have strong protection built into their content security policy. Um and that's that's really the state of what we're looking at right now, right? I'd like to see these numbers change. And um so if I if I look at you know where are the directives actually being used what we see is um so I have I have these six different main categories of directives that I look at and um frame embedding is the one that's used the most. Okay, which is a little bit weird because I
would have thought that script execution would be the one we look at most because in information security that's what we do. But apparently what's happened is clickjacking is is a uh apparently a a more um a a more focused control uh and and maybe because it's taken the place of an existing control that people used to use very often called um uh x-frame options. Um, so using a content security policy is the new way of doing that and for some reason that has taken off as the the one thing that people actually do. Um, so then you have um a style injection on there and object and plug-in injection at 15% of of what's in
there. So if you think if you think of the content security policy as similar to a firewall control and what I mean by this is this is an extra control you already have you know you have other things like when when you have a device sitting on a network it should have um services that you don't need are turned off the services that are there still have O controls on them right but that doesn't mean you don't need the firewall you still need the firewall because this plays plays into the principle of defense and depth. Right now, for websites, we have a control, the content security policy, but we're only configuring some of its rules, right? We're we're skipping over
a whole bunch of things that it's capable of doing, and we don't turn them all on. So, um it it's basically become a checkbox, right? we we're looking for um you know a few things about it but we're not taking into effect a whole bunch of other things. So um in the green box on this slide you can see I have um this is this is what typically happens in if somebody is running some sort of scanner that does a content security policy check. Okay. Now this said I know that there uh Google has a a content security policy tool um for for verifying them um but its focus is entirely on the script access uh aspects rather uh it doesn't
it doesn't still doesn't look at these other aspects of the content security policy right so it's not looking at form actions or frame ancestors or the base UI uh a lot of those other things are just not really covered in there and they should So um what I am proposing is an index okay a way of measuring the quality of a content security policy um and to to basically give some determination as to you know how much residual risk is it leaving there um by by not covering every all of the things that it should be covering or not covering them as well as it should. Um, and what I wanted to do was come up with a scale and a way of
measuring a content security policy that could be uh fully autonomous, right? So, um, you basically could could build a rule engine around this to do automatic scanning. Um, I know that's going to um it that that will make some aspects a little bit more difficult because there are subjective um or or maybe aspects that might require more analysis to get a you know a very accurate feel for how quote unquote secure it is. But um but I don't think that's the point. What I what I really want to do is I want to put something together here that's an an easy measurement and gives a relative score uh in a way that uh promotes actually using content security policies
to reduce risk in web applications. Okay. So let's go beyond just checking a box and get into some form of a measurement. That's what I'm proposing. And so the way that I would like to do that is a weighted U sixdimensional. I'm starting with sixdimensional. We I may expand it later on in a version two, but let's start with um script execution being the most weighted. Those percentages are are the weights that I'm uh planning on giving. Um but having uh script injection weighted probably at about a third and and uh objects frames and forms at around 15% the base URI because it's um it's it's a harder one to attack in the in the first place. Um
and it's really just does one thing. So we'll um put that one a little bit lower at a 10. And then style injection um also at 10. And um and all of these things we we can do some level of of measurement on them um in order to get a a numerical score out of it, right? And so what what I was thinking we would do is have uh a scoring between let's say let's just call for now on the scale zero as perfect. you're doing you're doing the best you possibly can for that directive for the content security policy and one being you you don't have it right you've skipped it and so with a
simple uh bit of math we can get ourselves to a point where you can you can calculate across those six different categories I showed previously um and uh and then this sort of uh scoring range here to come up with with some actual scores and here's uh one example Um, so this would be a checkbox content security policy. So in this case here, we said default sources self. That's actually not bad to have that. Um, uh, that's, you know, it's better than not having anything at all or having a default source of of, um, of that's, you know, a star wide open or something like that. Um, but it does have unsafe inline, unsafe eval, and and
uh um it looks like I got cut off here on the end, but um but anyway, uh if you looked at how something like this might be scored, uh you're missing the um so for the script execution, it's not very good. So that's going to score pretty high, but it's not a one, right? It's below a one. So that's better than a one. Um and then we have the object plugin, frame embedding, form, actions, base UI. All of those are missing, right? So those are going to be all ones and based on their waiting that's going to add 1.5 points for each. And then the style injection um that's probably what the part that got cut off there um is uh
is present but not not done that well either. So that's going to add another8 points. So then you end up with a with a score overall of quality on this one of just under nine. Okay. Um, and then here's an example of we'll call this a gold standard where things are done a lot better. Um, and we have script execution at um, uh, that's it's using nonses on here that that with the random on there. You would you would fill that in in strict dynamic. And I won't get into specifically what all of these do right now. Um but that that is a uh recommended approach for handling scripts. Um and then the object source
is none which means uh you can't put object tags into the website. They just won't work. Um frame ancestor same thing. Um form actions can only submit forms to itself. And um and there's there's no changing of the base URI. And um so putting all of this together, we've now put directives in in several of these places. In most cases, the directives are set to the the uh you know, some of the better settings out there. And so we end up with a with a score of 1.8, which is nice and low that shows a much lower level of risk than the previous one. Um, and so through through this lens, what this would tell us is that if we
were to look at the same data that I had out previously, um, we're at 34% of websites would actually fall in that, you know, somewhere between 1 and 2.5 of of that low risk. and the the vast majority fall into, you know, a number that's over 8.5, right? So that's 8 82.2% is over um over 8.5. And then also, you know, actually you could look at everything above 6.5 and say that that's almost everybody. Um so the it's it's uh you know, somewhere around 3% actually fall below a five point on this scale. And my hope would be is by putting this out out there, having a way to measure um we could get the
um we could get folks to actually use a a uh a measurement in order to push developers to to make better use of the content security policy. Okay. um for those that do have uh or are enforcing content security policy um this just gives another uh another um a view of that data as well. So I just wanted to throw that out there for some more specific numbers on on things that are defined there. Um so uh with that said uh I am looking for feedback on this um index idea. it is in its infancy in terms of like defining how we're going to do the measuring on it. Um so I would really like uh some
some folks to read through and and give me some feedback on it and and you know let me know are there aspects that you're like hey maybe we should actually add this other directive into the measurement or the waiting doesn't seem right or um or maybe just asking questions about different parts of it. So if you could, if this is something that you're interested in, if application security is something that you've studied, um then please uh give me your feedback on the proposal. It's in my GitHub. Um so github.com/jgillum gam csp-index. Um so if you could take a look at that, uh please let me know. And uh thank you very much for listening to my talk. I
much appreciate it.