[CSP] specify handling of malformed content-security-policy HTTP header

[shekyan]

Section 3.1 should be explicit how user-agent should behave in the context of malformed content-security-policy header.
For example, unknown directive, non-ASCII characters, multiple 'none' keywords in source-expression do not match the 'policy-token' grammar.

We suggest treating these headers as either default-src 'none' or default-src 'self'

[joelweinberger]

There are more nuanced alternatives. For example, if a source expression in a source list has a malformed character, we can just ignore the single source expression. This, in fact, is how I read the current spec (since it simply doesn't add it to the list of sources if it can't be parsed), but it would be nice if it was explicit.

[michaelficarra]

@metromoxie Being permissive like that can lead to unintentional vulnerabilities at worst and strange inconsistencies at best, unless the specification is very explicit about the details of error recovery. As-is, the specification does not make much sense, parsing source lists in one way in the source-list grammar and another way in section 4.2.1. For example, (and this is mostly targeted at @shekyan), 4.2.1 separates source expressions on U+0020 (space), U+0009 (tab), U+000A (line feed), U+000C (form feed), and U+000D (carriage return), and the source-list grammar separates source expression on WSP, which is only U+0020 (space) and U+0009 (tab).

The easiest way to safely handle this is to fall back to some restrictive default for malformed policies. Care should be taken, though, to allow for future directives and possibly even extensions to the grammar.

[joelweinberger]

@michaelficarra Sure, but we should explore all the options, especially when one of them is how it appears to be currently defined. And if we change it to be more closed, we risk breaking sites that are currently compatible with the spec, which might be a nasty surprise.

[mikewest]

This issue was moved to w3c/webappsec-csp#6