Is there an appropriate forum to discuss this?
We've been discussing CSP in lots of places, mainly in the mozilla.dev.security newsgroup. This is a great spot to discuss details of the CSP Spec, though. I've split this page into topics and am marking each issue as either open or closed depending on whether we have made decisions to resolve it or not. -Sid
Version Beacon (OPEN)
Is more misuse of the user-agent header the best way to go, or does handling a certain file type, a policy file, fall squarely in the realm of the Accept header?
I think using the UA field is appropriate. RFC 2616 shows that the UA header should specify "subproducts that form a significant part of the user agent". While CSP is not bulky, it is a major piece of how the user-agent can behave. Additionally, this approach will add five bytes to HTTP requests and will not require an additional header such as Accept-CSP. If there were an Accept-Policies or Accept-Security-Features header standardized, we would probably want to use that, but as of yet there are none appropriate at our disposal. -Sid
RFCs say a lot of things browsers don't actually do. It's hard to argue that CSP is a "subproduct" or counts as "significant" when entire content formats (SVG, MathML, XUL, XBL, video, ActiveX, plugins (they're products, significant, and not always there)) go unreported.
The alternative to the request announcing the support level is to version the reponse, and for the client to ignore policies with an unknown (newer) version. Combine that with server UA version sniffing if the server needs to decide which version of a policy to send. Or if we allow multiple CSP headers and intersect them (discussed elsewhere) then a server could simply send multiple versions which either get intersected into something sane in newer browsers or fall back to the older CSP header in older browsers. -dveditz
Script Languages (CLOSED)
"No inline JavaScript will execute" should probably be generalized to "No inline script will execute" as there are a number of different script-protocol handlers in different browsers, and most browsers have the ability to host script other than JavaScript. -EricLaw
Good idea, updated accordingly. -Sid
X-Content-Security-Policy HTTP header (CLOSED)
Allowing the X-Content-Security-Policy header "anywhere" in the response clearly isn't correct-- it must be somewhere in the response *headers*. More importantly, it might be worth explicitly specifying that the header should/must appear in the initial headers and specifically not in TRAILER headers, because otherwise the entire page must be buffered to ensure that the policy is retrieved before the user interacts with the page. -EricLaw
Good idea, updated accordingly. We should probably remove the X- from the header name too, eventually. -Sid
Sid: that would require us to write and get published an RFC. :-) - Gerv
Gerv: One can dream. :) X-Content-Security-Policy it will remain for now. -Sid
Policy intersections (CLOSED)
I'd like to drop support for an HTML meta tag and instead support multiple headers. This brings up a question: how do we handle the multiple headers? There are two options:
- granular intersection -- Allow the HTTP subsystem to merge the two headers, separating each with a comma. Change CSP syntax to replace semicolons with commas. The result is a policy that can have multiple occurrences of each directive (including 'allow'), causing the CSP parser to intersect all multiply defined directives. For example, "allow *, script-src none, allow self" would be enforced as "allow self, script-src none".
- policy intersection -- Keep policies semicolon-separated and intersect multiple headers as the spec used to define intersecting the META policy with the HTTP header policy.
RFC 2616 says:
Multiple message-header fields with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It MUST be possible to combine the multiple header fields into one "field-name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma.
We probably want to do the "commas, no semicolon" option to prevent violating the RFC.
Please post thoughts on (1) dropping meta and (2) which of these two techniques to pursue. -Sid
I think we've agreed to drop meta, so I retitled this section. Technique 2 seems like the obvious one. -- Gerv
I've updated the spec to support intersection strategy 2 (comma-separated policies; semicolon-separated directives) and NO meta tag. I'm going to close this topic since I haven't heard any objections. -Sid
javascript: URIs (CLOSED)
Currently "JavaScript Uris" are restricted by both the "inline" and "eval" rules. This makes it unclear as to which I must allow to permit JavaScript URIs. -EricLaw
This is an unfortunate artifact of the late addition of the two opt-back-in keywords. It seems to me that javascript: URIs are probably "inline" code, but it's not completely clear. They could be considered "eval" code too (since it's code from string). I think maybe we should take the javascript: URIs out of the eval section. Thoughts? -Sid
Resolution: javascript: URIs are classified as 'inline'.
Reopening: Why not treat javascript: URIs as a hostless-scheme like data: disallowed unless specifically enumerated in one of the policies. -dveditz
Resolution (2): host-less schemes are supported in directives' source lists by stating the scheme name followed by a colon: javascript: and data: are examples. In fact, all schemes are supported this way, and any additional parameters on the source (host and port for example) are assumed to be "any" or *. -Sid
origin/host/source terminology (OPEN)
Rather than using the term "host" and "source" would it be more accurate to replace all instances with "HTML5 Origin"? This term has a defined meaning and would remove ambiguity in cases (like report-uri) which are currently defined as both "same host" and "same source". -EricLaw
Alternatively, we could use Public Suffix + 1, like the domain indicator in the URL bar - a good compromise between the rigid "exactly the same host", which might be operationally inconvenient, or something so loose that you can leak info anywhere. -- Gerv
PublicSuffix+1 is a bad compromise. If we assume the author means exactly and only the host they specify then the policy is clear (no hidden meanings) and can be restrictive if necessary. If the author wants your behavior they can add a wildcard, which also has an explicitly clear meaning. -dveditz
Gerv and I were talking about different things. He was not talking about treating all origin/host/source directives as applying to an entire subdomain but rather specifically about allowing the reportURI (and policyURI?) be anywhere on the "same domain" rather than strictly "same origin". I'm ok with publicSuffix+1 for the reportURI but uncomfortable with going beyond same-origin for the policyURI. But having the two directives have different restrictions is confusing. I'm open to arguments that looser restrictions on the policyURI is OK (or that we don't need the policyURI at all -- it complicates a lot of things) -dveditz
What does 'self' represent? (CLOSED)
"self" is defined as the scheme/host/port (origin) in the prose, but the flowchart defines it as document.domain. Which is it? -EricLaw
document.domain is evil, we should ignore it completely everywhere we can. -dveditz
"self" is scheme/host/port (origin). The flow chart is wrong and has been repaired. -Sid
On the same topic, do we want "self" to represent different things in different contexts or not? Should "http://self:80" be valid? Should "self:443" be valid? Should we only accept "self" alone with no scheme or port? -Sid
I really hate using self as a pseudo-host; either it's a keyword or it's not. "self" is same-origin with the page, otherwise it's easy to specify myhost.com:333 or ftp://myhost.com -dveditz
Would it be difficult to implement an intelligent "self" that was the same as the current URL for all unspecified bits? So it just Did The Right Thing? -- Gerv
Not difficult, but ambiguous, and it's not much more difficult to actually type the host name (it is available in the HTTP request).
Resolved: self will always represent (scheme, host, port) of the protected document.
--Sid
Scheme wildcards (CLOSED)
Do we want to support scheme wildcards, i.e., *://foo.com:80? My impression is no, but I want to be sure. -Sid
No-one's presented a use case. Let's call this one closed until someone does. Gerv
DNS wildcards (CLOSED)
The Host Expression List should describe exactly what types of wildcarding are permitted. For instance, can a * represent more than one DNS label? Can * appear in the middle or end of a string? -EricLaw
I'll clear this up in the spec, but the formal syntax should make the syntax explicit, but I will add discussion of the semantics of wildcard matching.
- One wildcard (*) per hostname is allowed
- Wildcard must be the leftmost hostname label (* and *.com are valid, www.*.com and mydomain.* are not)
- Wildcard represents any number of hostname labels (c.b.a and d.c.b.a both match *.b.a)
-Sid
Report XML mime type (CLOSED)
What MIME-type is used when sending the Report XML? -EricLaw
Any objections to application/xml? -- Gerv
Sounds good. -Sid
"Final" Directive to ignore META tags (CLOSED)
Should the HTTP header syntax allow a "Final" directive to force ignoring META tag declarations? -EricLaw
Closed as long as META is dead. -- Gerv
restrict TYPES for "object-src" (OPEN)
Shouldn't "object-src" allow restrictions on what TYPES of objects are allowed, rather than just which hosts are allowed? -EricLaw
This sounds to me like over-complication. What's the use case? -- Gerv
"font-src" and "xhr-src" directives (CLOSED)
Should there be a "font-src" restriction? -EricLaw
Good question. Right now fonts are subject to the "allow" catch-all directive, and loading third-party fonts requires loosening that restriction. Perhaps we should discuss adding such a directive as well as an xhr-source directive (for when cross-site xhr explodes). -Sid
I think we should do this, since fonts are a whole new beast. Marking this as closed; reopen if there's an objection. I'm also adding an XHR-src. -Sid
User Script interaction (OPEN)
It seems like the spec should indicate how CSP interacts with user scripts (e.g. greasemonkey). --Sacolcor
Well, it should not affect them at all. Question is, is that technically possible? -- Gerv
Distinguishing Keywords (CLOSED)
Should we distinguish keywords such as "inline", "self" etc. when they are in a hostname slot? I discussed possibilities with Sid, and we thought that single quotes might work well; script-src: 'self'. Other options are CAPS, or a $prefix %character. What do people think? -- Gerv
Using single quotes for 'none', 'inline', etc. -Sid