Isn’t that only the case when the inline code uses untrusted user data somehow?
Inline: alert(“Hello “+userInput) is problematic.
Inline: alert(“Hello there”) isn’t, right?
Isn’t that only the case when the inline code uses untrusted user data somehow?
Inline: alert(“Hello “+userInput) is problematic.
Inline: alert(“Hello there”) isn’t, right?
CSP is a defense in depth mechanism which can be (among other capabilities) used to preempt the capability of inline scripts. This mitigates rendering bypasses, in the event that unsafe rendering occurs. For example, imagine you have an insecure markdown renderer, where a user can manage to escape some HTML and inject it into the DOM in a comment thread of some sort. If they can do so, then they can embed JS inside that HTML and get XSS on other users. Adding a rule to disallow all inline scripts mitigates this, assuming the first layer of defense fails.
Under a properly configured CSP, allowing scripts that aren't from the same origin to inject things into the DOM is the problem.
Both of your examples are problematic.