 And this talk is on, you know, CSP which I, you know, I look at it as a browser site firewall, right? Before, before I begin, I would, you know, quickly like to understand if any of you are, you know, currently or ever in the past, or, you know, in the future, looking to be interested with any security related responsibilities, like the show of hands. Wow, okay, that's good. That's a good number, 30% and I presume the ones who have not been interested with now, probably in the future, you know, down the line, you would eventually be pushed into it, or at least some responsibility you will have to take up. Or let me ask another question. Have, have any of you faced any attacks on your servers or anything of that kind, not you personally, but your company servers have been attacked, you know, you've seen some raise of hands. Okay, good. Only the people at the back are raising, so because their faces are not visible. The ones here are being very discreet. You know, it's like, yeah, I got attacked, but I'm not telling anybody about it. Okay. So let me, you know, I'll not waste a lot of time. I'll get started directly. A little bit about myself. I'm the founder of Iron Wars Security. We build a product called as S-Boxer. So this is a continuous security monitoring system. And one of the techniques it uses for security monitoring is using CSP, content security policy, right? So some of the techniques we developed for this system, I'll be explaining that here on the talk. And, you know, I've been doing security products, developing security products for about 10 years now. And my expertise is web application security. Okay. So this is the outline of the, of the talk. We will first talk about data exfiltration attacks, what they are. And then we'll look at how they can be detected using content security policy. And then we'll see how, so once I explain, you know, how the system will work, then we'll talk about how that system can be implemented, right? So some of the implementation details. And then finally we'll talk about some of the limitations in that approach. And what you could potentially do to overcome those limitations, right? So that's roughly how the talk is going to be structured. You have any questions in any part you can, you know, raise your hand and we can get it addressed, you know, then and there. Okay. So let's talk about data exfiltration first. So here we have three companies, you know, all big names, the Ticketmaster, British Airways, New Egg, you know, these are big companies with millions of customers. And all three companies were attacked in 2018. And these are the number of credit card details which were stolen, you know. These are big numbers and in fact with New Egg.com, the attackers were able to steal about 45 million credit card information, right? Now, the impact of the attack is serious. But what is even more serious is the duration for which the attack actually took place, you know. So it's one thing to get attacked, which is you can have a single, you know, like she was saying, you can have one weak link in any of your systems and that can be used, you know, by an attacker to attack you, right? So that is very difficult to, you know, actually protect against, you know, not be attacked at all. But once an attack actually takes place, you should at least know that your systems are being attacked, right? And you should be able to, once you know you're being attacked, then you can actually do something to stop the attack from happening, right? But the scary thing here is the attacks, they were high impact attacks obviously because a lot of credit card information was stolen. But they went on for a very long time, you know, before they were actually picked up. In case of Ticketmaster, it went on for more than eight months. And I usually say that if someone got to know they were pregnant when the attack started, then, you know, they would have actually had the baby, you know, before they found the attack was going on and they actually stopped it. So that's how long the attack went undetected. Now, this is a very, very serious thing. You cannot have your systems being attacked and you're not even knowing about it, right? So I'll try and, you know, so that's why the stock was made because this is a kind of attack which is not having a lot of understanding with people. So I'll explain how this can be used, this can be detected using CSP. Okay, now, why did it not get detected for so long? Now, data exfiltration is usually monitored on the server side. Now, data exfiltration, let me explain it for the ones who do not understand. It is, you know, data being extracted out of your environment, right? So you own an asset and if somebody else is able to extract data out of it, that's called as a data exfiltration attack. The monitored data being stolen from the server side, but any data theft on the client side is never monitored, you know? So let's say there's a very overly simplistic representation of your environment. You have your server here and it's being monitored. Now, I've said monitored by IDS, which is an intrusion detection system, but you can have different, you know, systems which are actually monitoring this. And if your server starts sending data to somebody, you know, to some external party, then some server-level monitoring system will pick it up. Even if it is not necessarily a security-based monitoring system, even your APM might pick it up, you know? And you might know that, hey, my system is sending data to this external party. But let's say your client side, which is your browser, you load a whole bunch of JavaScript on the client side and if you're, you know, you go to hasgeek.com and let's say JavaScript and hasgeek.com starts sending data to an external domain, then you don't really have any mechanism to detect that, right? So this is how all of this data was actually stolen. I'll go into details of how exactly the attack took place a little later. So here you can see egress traffic is not being monitored, so the attack can go on and detect it for extensive periods of time. Now, how does this happen? An attacker will look for any weakness in your application, right? So there are different ways in which different kinds of weaknesses you can have, but once he finds some way by which he can inject his own malicious code into your site, he will do that. And once he has done that, he will just wait for your users to visit your site. And as your users visit your site and they feed in their details, then the attacker's JavaScript can actually still, you know, collect this information and send it to their servers, right? So technically, it's a very straightforward, you know, attack to perform. Now, there are different ways in which an attacker can inject malicious code into your website. I don't have to go into details here. You have something called cross-site scripting. It's a form of, you know, it's a vulnerability you have on your application, which can be exploited. If you're using external CDNs, which most people do, if the CDNs get compromised and the JavaScript there can be modified, if you're using advertising or analytics, you know, code loaded from external parties, and if they get, they don't necessarily have to get compromised in the sense they don't have to get hacked by the attacker, but even if they are gamed by an attacker, then, you know, your site can get affected. And finally, if your web server itself is compromised by an attacker, then even then, you know, he can inject, you can modify the contents of your JavaScript. Now, this is an example of British Airways. I don't know how clearly you can see the, you know, the text on the slide, but this is the, you know, the JavaScript, which was actually attacked. So, this is modernizer-2.6.2.min.js. Okay, so this is a specific version of modernizer JavaScript file, which was being loaded by British Airways. So, what the attackers did was they modified the, you know, content of the JavaScript file because they were able to get a, you know, get enough access to modify the, you know, JavaScript files on the server. So, they took an existing JavaScript file, which was being loaded by British Airways website. They just added a bunch of JavaScript to the end of this file. You know, they didn't change the functionality. They just included their JavaScript at the end. And any British Airways page which was loading this, which was most pages, had the attacker's JavaScript file, JavaScript running. So, when the attacker from the user enters their credit card information, this JavaScript will take it and it will send it to the server. Okay, so once an attacker is able to inject the JavaScript file, how can they take, you know, data and send it to their external sources? So, they can use different ways. The reason I cover this is only if you know how the data is taken out, we can talk about how they can be, you know, stopped using content security policy. So, the first approach is they can try to load resources from an external site, like for example, I can say, you know, image src slash attacker.com slash and then the, you know, credit card information. So, there will be a request made to my server and my web server log will have the credit card information. Or I can force the user to navigate to an external site. I can put a link. He clicks on the link now that a request is made to my website. Or they can use DOM APIs like Ajax, Fitch and so on to actually send data to my server. That is the attacker server. So, this is the, you know, additional piece of JavaScript which was injected into British average website. So, this is the actual code. It was not like this, you know, beautifully formatted. They had, of course, minified it and everything. But once you expand it, this is roughly how it looks and it's surprisingly elegant code, you know, they have not done much. So, what they are doing is they are like listening for, you know, submit button, they're attached, you know, a bunch of event handlers to it. And whenever someone is feeding data into it, they take the payment form and then serialize it. And then they put it into an Ajax call and they send it to this domain called bavas.com. Now, bavas.com, you would think actually is, you know, it belongs to British average. But this was a domain registered by the attackers. Right? So, ba.com is actually British average domain. So, they went and they registered bavas.com. And, you know, so that if someone looks at it, they think it's, you know, legitimate traffic. So, this little piece of code is what led to 40,000 credit card information, you know, of British average customers being stolen. And British average, I think, is looking at a fine of about 100 million plus dollars under GDPR, you know, because of this particular attack. So, this is serious stuff. Now, this is how you can steal data, you know, using external URLs and so on. I just talked about it briefly. You know, you put the attack, stolen data here and you load a new script. Or you can, you know, send it using the, you know, communication APIs. Okay. So, now I think that gives you a rough idea about what a data exploitation attack is when it takes place on the client side, how an attacker could perform it, you know, how they could actually steal data. So, I think that much is established. Now, that we are not sure because British average has not given away that information, you know, how an attacker, how the attackers were able to actually change the contents of the file that we do not know, right? But irrespective of how it was done, what we are interested is in the end result, right? Like once the file gets changed, it did not get detected, right? So, that's what we're going to focus on. So, I doubt British average would give that information away because it should be very confidential for them, right? Okay. So, in terms of detection, there are two ways in which you can do this detection. One is you can detect it at the JavaScript level. I'll talk about it briefly. So, you have your application code, which is written by your developers, which is here. And then your native APIs. The native APIs are all the DOM APIs exposed by your browser. The application code will communicate with the DOM APIs on a regular basis to, you know, like read data from the local storage or to send information on the network and so on. So, what you can do is you can actually put an abstraction layer in between. And you do this by hooking into the native APIs. So, let's say, for example, you hook into the fetch API, you know, fetch API. I don't know how many of you are familiar with client-side APIs, but, you know, it's an API to perform network communication. So, once you hook into it, so what happens is whenever the application developer is writing code to call this API, then the call will not go to the, go to that API directly, but it'll insert into your code, right, which is your hooked piece of code. And now here you can actually look at to which URL data is being sent and so on. So, you can do some level of monitoring on it and then you can call the native API, right. So, this way you sit in between or you can, in some ways you can monitor the functioning of your JavaScript code, right. This is one approach, but it has a few disadvantages. One is it's complicated because you will have to do this hooking of native APIs and if you, and it's not a trivial thing to do and if you make any mistakes, then it will break your application's functionality, you know, and if it's breaking application functionality consistently, then the, you know, the managers would essentially say, you know what, let's do away with it because it's essentially affecting your productivity, right. You're paying a price for that additional security. So, it's going to take loading and maintenance effort. So, that's money and it'll also have performance impact, right. Because it's changing the speed at which your JavaScript code is running because every time there's a native call, there's another piece of code which runs and it performs some actions and all that and if you get some intern to write that code it's, you know, because like you don't want to spare your star programmer who's working on an important feature. So, that's a good point. The thing is it depends on when you load it. You can load this hooking code as the very first thing which loads into your application, right. So, and if you're, say, using something like CloudFare, you can just configure it at CloudFare and it'll load it at the very beginning, right. So, this will run even before the attacker's code comes in, right. Oh yeah, oh yeah, I mean. Yes, so for example, so that's the worst case scenario where an attacker is able to come into your server has unrestricted access to modify any JavaScript. If they could do that, then of course they can change this code as well. That's, maybe I should add that as another disadvantage, that's a good point. But assuming the person doesn't have unrestricted access, they can only modify some sections. So, this will still hold good, right. But that's another weakness you have with the system as well. Okay, so those are some downsides with the JavaScript approach. Now, we'll talk about the primary approach we're going to discuss here, which is the content security policy approach. How many of you have heard about content security policy or know what it is? Not that many, okay. Content security policy has a few advantages. One is it can be done either by the developers or it can be done by the network or infrastructure team, right. So, it is not strictly a coding effort and it's a much simpler approach because you're not modifying any existing behavior. You're using a built-in functionality in the browser. And if you configure it in the monitoring mode, then it will not break your website's functionality at all. So, you can do it with a piece of mind and it has no performance impact also. So, these are the advantages with this approach. And content security policy itself, it's a functionality supported by a browser. It's available in all, you know, supported in all modern browsers. And you can think of it like a firewall for your browser, right. Now, I'm sure all of you know what a firewall is and you would never put a website on the internet or any service on the internet without it being predicted by a firewall, right. So, when you have an equivalent for your browser you should also, you know, make sure that you always turn it on so that you control what your browser can do. Now, what a content security policy does is, it essentially tells your browser what it should and should not do, right. So, one is typically a browser whatever the server sends as a content, it will follow the content, it will first run the HTML parser and JavaScript parser and so on. And whatever code is there it will essentially evaluate all of that, right. But content security policy is like it's an instruction you give to the browser saying, hey, this is how I expect my site to behave. So, irrespective of what code is downloaded from the site, the browser will always refer to this policy. And if the code is, you know, trying to do something which the policy has not allowed then the browser will not perform that particular action. So, that's in essence what content security policy is. And it has two modes. One is you can put it in a blocking mode. So, which means if there is a, you know, behavior the code wants to do which the policy is not allowing then the browser will stop that from happening. That's a blocking mode. And then you have a monitoring mode where if the code wants to do something which the policy does not allow then it will let the thing to happen but it will give you an alert saying hey, the policy said this should not happen but the code is actually doing this thing, right. So, that's the mode in which we are going to, you know, like deploy our policy to look for these kind of attacks. Now, this is an example of what a CSP policy would look. It has, you know, two components. You have these directives. Directives are individual, okay, I will get into the details a little later. So, you have content security policy and content security policy report only. So, report only is the monitoring mode system and if you just say content security policy then it goes into blocking mode, right. And what follows that is the actual policy definition itself, okay. Now, the policy definition is made up of a bunch of directives. So, here these are the directives and each directive is separated by a semi-colon, okay. So, you can think of a directive as a specific command which defines one specific behavior of your application, okay. So, these directives cover different kinds of behavior as in, like for example, there's a directive which says what kind of CSP behavior should be there on your site. There's another directive which says what kind of image loading behavior should be present. There's another directive which says what kind of communication based behavior is allowed, right. So, each directive is meant for a different behavior. Now, for the purpose of this specific, you know, attack detection, the directives which are of interest. Now, there are a lot of directives which are supported by CSP, you know. But for this specific attack, the directives of interest are these, script SRC, style SRC, image SRC, you know, like I put a whole bunch of them. I've researched the entire list of CSP directives and these are the only ones which are applicable to the job at hand, right. So, you can just stick to these. And each directive has a value associated with that, right. So, the directive says, you know, each directive controls a certain behavior. The value will, you know, say or it will specify, you know, how the behavior should be. So, for example, the possible values are, you can have none. You can have self or you can specify either a single domain or multiple domains, right. And the domain can be just the domain name or it can be the origin or it can be the origin and even a path included, right. So, it can be very vague or it can be very specific. And what the value does is it says, you know, how this particular behavior should be. For example, here you have connector SRC. Connector SRC defines your browser's communication behavior, okay. So, if you say connector SRC none, then your browser will not make any kind of, you know, DOM communication calls, which is any Ajax communication which is made will be blocked by your browser. If I say connector SRC none, when I say none, I mean, do not connect to anybody. If I say connector SRC self, now here I have script SRC and the value is self. When I say self, then it means load JavaScript files but only loaded from the same domain. So, if you are visiting hasgeek.com, then it can the browser will only load JavaScript files from hasgeek.com, not from any other external domain. Or you can specify a specific origin. So, here it says style SRC and then this. So, this means that CSS files can only be loaded from this particular origin, right. And you can mix and match. So, for example, you can say script SRC self comma abc.com comma, you know, 123.com. So, which means it will load it from the same domain as well as abc.com as well as 123.com, right. So, I think you get an idea of how this thing is, it is very simple, it is very straightforward, nothing complicated here. Okay, so we will quickly go through the different directives and the related browser behavior. So, script SRC, if you have a script SRC like this, you say you know you say script SRC and then you give the name of the site from where you want to load the code. So, then if you have a script tag like this where the SRC is pointing to that domain, then the browser will load it. But if it is pointing to another domain, then this will be blocked by the browser, which means this JavaScript will not be loaded and it will not be evaluated, right. So, similarly for the other origins as well. This is part of my slide so you can, you know, refer to it, right. So, for each of them I have defined which is allowed and which is not allowed. Okay, so now that we know what a CSV policy is, what are its different components, now you will have to write a policy, right. Now, how do you get started with writing a policy, what directives should you use and what values should you set for these directives. So, what you can actually do is, you start with finding out what all content your site is legitimately supposed to load, right. But finding out this information is difficult because your application is typically very complicated, you know, there's lot of JavaScript being loaded from different places, lot of dynamic content and this is all controlled by your developers, right. So, you might not have all the information. So, what you can do is you can actually use CSV itself to collect this information which is you can write a very simple policy which is you set everything, you can start with a baseline policy, right. And then you can turn it on and as your users are using your website you start getting a violation reports, right. So, in your policy you can specify report URI and you can give a domain. So, this URL is essentially a HTTP endpoint, you know, it's a web service endpoint. So, whenever there's a policy violation, your browser will send an alert to this particular domain, that is this particular endpoint. So, you can collect and you can know, you know, what all violations are taking place. So, if you set a baseline policy and this is how a violation report would, this is what it would look like, it will say in which URL the violation is taking place and it will say which content is being blocked. So, in this case example.com slash css slash style.css is not being loaded by the browser and the reason why it is not being loaded is because of this particular directive. So, you have set the directive which says style src cdn.example.com. So, you're saying CSS files should only be loaded from this domain but your site is trying to load it from example.com which is not matching. So, there was a violation. So, you get a report of this kind, right. So, the report has all the details that you require. So, what you can do is you can start with a simple baseline policy. You can set it up on your server and as your users are using it, you'll have a new violation report. You can look at the violation report and from the violation report you can identify what all resources I'm loading and you can start adding those things to your policy, right. So, once you do that then you will have a policy which contains all the whitelisted information and every time you have a new violation you know you analyze it and then you update the policy again. So, this is a continuous cycle. If you would see first thing you do is from the browser to the browser, then your users are browsing the site. As they browse the site you will get CSP violations which will be collected by your endpoint. Now, you analyze these violations and then you update your CSP policy again, right. So, this keeps going on a continuous basis. At the beginning there would be a bit of work. The first time you set up a policy because you have a baseline policy which is not customized to your site. So, you can say in the first week you would have a policy but once you have tuned up the policy like from week to onwards you should not get any violations, right. If you get a violation it most likely is you know pointing to something bad happening on your website. So, now what will happen is once you have this policy stabilized. So, now you have clearly defined who your website can communicate with, from where it can load resources, so where it can navigate and all of that information. So, now let's say the website is someone goes and modifies your JavaScript file and they write the same kind of you know inject the same piece of code which is going to collect your data and it's going to you know post it to some attackers bavas.com, right. So, now what will happen is you will get a policy violation from multiple users saying that hey now there is a new connectors RC violation to bavas.com and then you can be like hey what is this bavas.com. You can do a quick you know who is lookup and then you will see that bavas.com is not really registered to you guys and then you can check with your developers and find out hey guys bavas.com does not belong to us. Do you are you like you know is it by design that you are communicating this with this website and if they say no then you have a problem on your hands, right and it will get picked up in the first one hour or depending on how much traffic your website gets it will get picked up in the first few hours. So, you know the attacker injecting this code and your developer and your users actually getting affected because you will start getting these violation reports, right. So, in the CSP mode any egress traffic you will get a report and you know it will get picked up by your team. Okay. So, to get started you will need an initial policy and this can be a fairly decent initial policy which is for all of these directives of interest of this attack. We are setting it to self which means we are saying you can load these content from the same domain but not from a different domain, right. So, this would mean that only the content being loaded from external domains you will only get violations for those and you can go and update those in your policy, right. But this is a very good starting point you can just copy this policy of the slide and you can put it and you can get started, right. So, there is not a whole lot of customization you will have to do. So, we can use CSP to look for your site's behavioral anomalies and you can detect those kind of data filtration attacks, right. So, now I have discussed the advantages at the very beginning itself of using the CSP approach but there are some limitations to using CSP for this purpose. Now the first thing is CSP is not designed for detecting data filtration attack. CSP's primary goal is to prevent cross-site scripting, right. So, that is what it was designed for. So, what we are doing is we are using it for a purpose it was not originally designed for and all of you know how that works like when you take one system and you hack it to do something else. Yeah, I mean it does do its work but then it comes with its little problems as well. So, the problems here are that it is possible to bypass this monitoring system and I have listed down a bunch of different bypasses. I will just cover them briefly. So, you can have a DNS preface based data leakage which is the attacker can say you know stolen data attacker.site and he can instead of putting it in a script tag or you know style tag or whatever he can put it in a you know preface type of attack. Now what will happen is the browser will make a DNS lookup to stolendata.attacker.site now if I am the owner of attacker.site then this DNS lookup will actually come to my DNS server and if I just monitor all the incoming DNS lookups then I know the sub domain part is the attack is the you know like customers website customers data for example if I am stealing credit card information or credit card information is like what 20 digits. So, I can say credit card information dot attacker.site right. So, when I since I own the DNS server I can just look for all the sub domains which you know came to me and they are all the credit card information right. So, this will not get picked up by CSP you can you know navigate the user to your website by doing something like this you can say location dot href and you can set a new URL the user will be redirected there and this will not get picked up by CSP and or you can just put a href tag a link and you can maybe convince the user to click on it or you know even if by accident the user clicks on it you will get a you know hit to your server that will not get picked up by CSP I can do a window dot open which is I will open a new popup and that will not get picked up by CSP So, those are ways by which an attacker can actually perform an attack and your system monitoring system will not pick that up right but why should we still look at CSP as a valid approach for this attack So, the first thing is yes it is not a perfect solution but it is better than having no solution right because it makes the attackers work harder they will have to make you know you know they will have to put a little bit more effort in trying to bypass your system So, usually you have this thing called you know like a blind brute force type of attack where what the attackers will do is they will scan all the let us say they find one specific you know exploit they will scan all the servers on the internet to see which ones will you know fit this particular exploit wherever this exploit works they will have another script which will go and inject their JavaScript everywhere right so in this case it is not a targeted attack they are just seeing whoever they have one technique they are just seeing where this technique will work and they just you know go and exploit that system usually not customized with you know all these bypasses so your system will pick up things like this right most of the common kind of attacks so that is one the second thing is CSP is not a you know static standard it is a constantly evolving system right so they are adding new capabilities to CSP which will fix some of the bypasses that we just discussed about for example CSP version 3 is adding two new directives prefetch src and navigate to src which will block like a bunch of bypasses that we just spoke about so if you invest in CSP right if you have a policy in place you have the process defined you have your team which is trained on it and you have this you know started this you know discipline of looking at the alerts and so on so whenever CSP is upgraded to the new system then automatically the bypasses also get fixed right so this is prefetch src so the the dns resolution will get taken care of here navigate to a directive will take care of your you know window.location.hrap window.open as well as you know clicking the link kind of a issue right so there is something else also you can do with CSP which is you can use it to identify all the JavaScript code which is loaded on your server so the way you will do that is you will set your script src to none okay you can pick a time when your you know sites traffic is low preferably you know later in the night or whenever you can set just script src alone to none and you can leave it on for like half an hour one hour whatever time and as your users are browsing the site you will start getting CSP violation reports now the CSP violation report will have the list of the JavaScript file your site is trying to load right so from that you can create a list of all js files when I say js files these are not domain this is the exact this is the you know entire URL of the js file which your site is loading so you can collect this list of js files which your site is loading you can keep it with you and you can run it again say after a week and then you can compare the list of JavaScript files and if you see some new js files being loaded then you can go and manually duplicate those js files and you can see if you know it looks okay or if it looks malicious usually if the code is heavily obfuscated then that's clearly a sign of you know something bad happening right so this is another thing you can do using CSP which will also help you you know like address some of the loopholes we discussed earlier okay so with that we have covered the you know entire approach there are a bunch of free tools available for you you have you can use them to generate your CSP policies and you have open source software available which you can use as the CSP reporting you are right so you can set it up on your server and it will process all your incoming CSP violations and it will store it I think in Elasticsearch so that's the talk I would you know be happy to answer any questions you have on whatever we discussed yes CSP policy is essentially a header so why it's a HTTP header all the modern browsers support CSP header right but the kind of directives that are supported some browsers might support all the directives some older ones might not support all the directives but that does not really concern us the reason is we are we are interested in detecting an attack so let's say chrome chrome has like excellent support for CSP right now chrome let's say chrome makes up even worst case scenario if even if it makes up 5% of your user base now if your site is compromised and if it is leaking data externally and if your browser like 100 people use your site so 5 of them are using chrome which means you are eventually going to get those CSP alerts to your server right as a monitoring person will get to know that hey my site is talking to somebody it should not be talking to right so you don't have to get it from all of your users even if you get it from a small portion of your users your objective is met so the browser support is not that big of a deal but chrome has really good browser support and chrome has like excellent market share anyway so I think we are good that way so you had a question yeah so I just wanted to ask like do we configure CSP at the web server level or at what like at what point we configure the CSP these values and all see that's entirely up to you the the idea is to set the header so you can decide as a person who owns infrastructure where it's easier for you to do it you can add a middleware or you can do it at the code level you can do it at the web server level or if you have someone like cloudfire for example you can do it at that level that's that's internal operational decision for you to make right wherever it's easier for you to manage I had another question just like small one so previously you said we can tap into the native 80 APIs of the JavaScript right can those be used as a monitoring tool like every request it makes it just simply like creates a dump on some reporting server or something like that can it be used as a monitoring tool or all the request in your website something like that or you're saying the JavaScript approach if you go down that of course you can do that if you hook into the native API of course you can collect all of that information in fact if you look at things like New Relic APM for the client side that's what they do right but would you want to do that as a big question because you would end up collecting a lot of data and you would be essentially you know like leading to bandwidth consumption for your end user right would you want to do all that if that information is useful for you of course you can collect all the outbound network calls which is being made by your JavaScript you can get a copy of all of that sent to your server that's entirely technically it's possible does this also collect the browser extensions or requests that's a very good question it will collect you know information from the browser extensions as well but you can filter them out from the policy details because you know when there is a violation which comes it will tell you you know it will tell you which is the page on which it is happening and which is the violating you know URL right so there you will know the extensions will have a separate URL and you can filter those things away but it will get information from extensions also however you cannot so the things from extension is essentially noise but if you try to you know use that as a security thing which is to say hey I can use csp to see if the user is to protect the user from the extensions that wouldn't work because the extension developer can just write one line of code which will just remove the csp header itself right so he can bypass the csp so that approach will not work any other questions sure I think there is one so if an attacker has the flexibility to inject some JavaScript code or something like that so wouldn't he be aware of modifying the content security policy also yeah that's that depends that's all I can say because it depends on where you are you know configuring the csp policy and how much control an attacker has like for example if your server web server is compromised but if you are adding the csp header at the you know cloudfire level still the attacker cannot do much but there could be situations where an attacker has enough access to also overwrite the csp policy itself at that point you are just in bad luck right