[athanagor2]

Honest question: I don't understand how forbidding inline scripts and style improves security. Also it would be a serious inconvenience to the way we distribute some of our software right now lol

[theandrewbailey]

CSP tells the browser where scripts and styles can come from (not just inline, but origins/domains, too). Let's pretend that an attacker can inject something into a page directly (like a SQL injection, but HTML). That script can do just about anything, like steal data from any form on the page, like login, address, or payments, or substitute your elements for theirs. If inline resources are forbidden, the damage can be limited or stopped.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/CSP

[magicalhippo]

Still recall the classic forum exploits of including Javascript in your signature or similar, before such software started escaping input.

[flir]

Cross-Site Scripting. If a user injects a malicious script into the page, it doesn't get run.

[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.

[raxxorraxor]

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

[bryanrasmussen]

sounds weird to me too, although I guess there could be a script that was not allowed to do CORS that then instead created an inline script and did its CORS stuff in that script - about the only way I can think of it being bad.

[diggan]

> although I guess there could be a script that was not allowed to do CORS that then instead created an inline script and did its CORS stuff in that script

Wouldn't even matter, as it's the origin of wherever it ends up being executed that matters, not where the code was loaded from. So JS code loaded from cdn.jquery.com on mywebsite.com would have the origin mywebsite.com, even if loaded with a typical <script> tag.

In short, CORS applies to network requests made by scripts, not to the scripts themselves