[nickknw]

> How would you like to be largely invulnerable to XSS? No matter if someone managed to trick your server into writing <script>alert(1);</script>, have the browser straight up refuse it?

I don't quite get how this header makes you invulnerable to XSS, would someone mind explaining?

It seems like it only prevents XSS attacks from loading remote javascript files. What's to stop the attacker from just injecting the entire script inline? If you can get a small piece of javascript to execute you should be able to get a larger piece to execute just fine.

I can see how it makes XSS more inconvenient, but I don't understand how it makes you largely invulnerable to it.

[UnoriginalGuy]

Inline Javascript is outright banned by default. Read the HTML5Rocks article they linked, it is much more comprehensive and answers most of the questions like that that I had.

[nickknw]

Ahh, now that makes sense, thanks! The HTML5Rocks article cleared up my concerns.

For anyone reading this later, it was the section starting with this paragraph:

Inline Code Considered Harmful

It should be clear that CSP is based on whitelisting origins, as that’s an unambiguous way of instructing the browser to treat specific sets of resources as acceptable and to reject the rest. Origin-based whitelisting doesn’t, however, solve the biggest threat posed by XSS attacks: inline script injection. If an attacker can inject a script tag that directly contains some malicious payload (<script>sendMyDataToEvilDotCom();</script>), the browser has no mechanism by which to distinguish it from a legitimate inline script tag. CSP solves this problem by banning inline script entirely: it’s the only way to be sure.

[porges]

'inline' is also treated as a separate source. If your policy is 'self' that only means same-origin code is allowed to run, and inline JS is disabled.