2 ms·

In general I do agree that it would be nicer if script (and style) tags weren't in-band; the Link header solves this for style, and I think could do similar if

In general I do agree that it would be nicer if script (and style) tags weren't in-band; the Link header solves this for style, and I think could do similar if it were specified for scripts, it's just a pity Chrome never wanted to implement it. However, this just moves the problem around. While it could be argued specifying JS out-of-band would make it less likely for XSS to occur, anywhere that JS is specified is still likely to be programmed dynamically, with external inputs (db values, etc.), so the risk remains. For example, a lot of modern XSS leverages innerHTML rather than server-side markup insertion. e.g.: element.innerHTML = fetchData(endpoint); This code is XSS-able (especially in the case of things like jsonp payloads), and it's completely agnostic of where the JS is specified (in-band or out-of-band). The proper solution, as a sibling commenter mentions, has already been specified: it's CSP and it works well if used.

KMag 6y ago
> element.innerHTML = fetchData(endpoint); Presumably element here is <head> or later, so scripts wouldn't execute. Also, you'd presumably define things such that new <script> tags would be ignored if they were parsed temporally after the first non-<stript>, non-<html> tag, regardless of their position in the DOM, so that you'd need to explicitly eval any dynamically loaded scripts. Thanks for the pointers to CSP. I'll have a look. In any case, the default should have been to ovoid in-band signalling, and perhaps have a CSP-like mechanism to relax security constraints. Sure, hindsight is 20/20, but precedents in phreaking are obvious.