[allan_s]

forbidding inline script protect you from

``` <h3> hello $user </h3> ```

with $user being equal to `<script>/* sending your session cookie out, or the value of the tag #credit-card etc. */</script>`

you will be surprised how many template library that supposedly escape things for you are actually vulnerable to this , so the "React escape for me" is not something you should 100% rely on. In a company I was working for the common vulnerably found was

`<h3> {{ 'hello dear <strong>$user</strong>' | translate | unsafe }}` with unsafe deactivating the auto-escape because people wanted the feature to be released, and thinking of a way to translate the string intermixed with html was too time-consuming

for inline style, it may hide elements that may let you input sensitive value in the wrong field , load background image (that will 'ping' a recipient host)

with CSP activated, the vulnerability may exists, but the javascript/style will not be executed/applied so it's a safety net to cover the 0.01 case of "somebody has found an exploit in

[diggan]

> forbidding inline script protect you from

What you use as an example has nothing to do with inline/"external" scripts at all, but everything to do with setting DOM contents vs text content. Most popular frameworks/libraries handle that as securely by default as one could (including React) and only when you use specific ways (like React's dangerouslySetInnerHTML or whatever it is called today) are you actually opening yourself up to a hole like that.

If you cannot rely on the escaping of whatever templating engine/library you're using, you're using someone's toy templating library and probably should switch to a proper one that you can trust, ideally after actually reviewing it lives up to whatever expectation you have.

> `<h3> {{ 'hello dear <strong>$user</strong>' | translate | unsafe }}`

This would have been the exact same hole regardless if it was put there/read by external/inline JavaScript.

I do agree with your last part that CSP does help slightly with "defense in depth", for when you do end up with vulnerabilities.

[allan_s]

my point is that all your templates are at thend coded by human that make mistakes https://nvd.nist.gov/vuln/detail/CVE-2024-6578 , you may be not using "dangerouslySetInnerHTML" directly but your dependencies may

> What you use as an example has nothing to do with inline/"external" scripts at all, but everything to do with setting DOM contents vs text content.

I fail to understand your point (it's certainly an understanding problem on my side)

What I wanted to express is that: 1. you can with some CSP forbid loading of cross origin script (i.e forbid hacker.ru/toto.js ) to be loaded 2. but even if you do this, you also want to block inline script (or use inline+nonce) because evil script can be executed from within your origin by using a vulnerability somehwere between the code and the final dom

> This would have been the exact same hole regardless if it was put there/read by external/inline JavaScript.

yes we both agree that it's the same vulnerability at the end, i'm just saying that you can arrive there from different path, and these different path are protected by different CSP mechanism

[raxxorraxor]

What is the security difference of someone injecting something into your page vs injecting something into external ressource?

[allan_s]

first, at the end the effect is the same (XSS which can be used to extract information), the difference is "how someone can get to it" and "how you protect yourself from it"

1.to be honest you should refrain yourself from loading resource outside of domain you control 2. even if you do, you can protect yourself from somebody replacing jquery.js by something totally different by using <script integrity='the_hash'> 3. if it's a CDN your control it's usually quite hard to inject something into the resource because a potential hacker has no obvious input on it (and you still can protect it by using the above script integrity= 4. so then most people feel safe and forget that inline script can still be dynamically created if you have a hole in your libraries generating DOM code, so this path of attack need to be blocked completly (forbidding inline script at all) or protected (using nonce)