This was noted during the Oct 20th call. We should emphasize contributions by current and previous members of the working group.

@mnot very correctly notes that it's tough for developers to understand what's changed since 1.0. We should spell that out in a non-normative section of the introduction.

These resource types map to the following Fetch request contexts: ..., image, .... These contexts are the blockable request contexts.

https://w3c.github.io/webappsec/specs/mixedcontent/#category-blockable

I assume you mean s/image/imageset/

Section 3.3:
5. Remove all occurrences of reflected-xss, report-uri, and sandbox directives from directive-set.

This list should also include frame-ancestors.

Right now, the spec mentions that SRI could be used to ID cached files.

User agents may decide to use the integrity metadata as an identifier in a local cache, for instance, meaning that common resources (for example, JavaScript libraries) could be cached and retrieved once, regardless of the URL from which they are loaded.

Personally, I feel this part is huge.

This would provide what Content-MD5 and ETag failed to, without the roundtrip to check if the resource it still good.

Without the caching, the usefulness of this spec could be diminished, potentially relegating it to download checksum for certain websites and CDN safeguard for banking websites.

With the caching, this is bound to go straight in every performance optimisation guide. Right below the title. With a 72px bold flashing font.

Would you consider making the spec about caching as much as it is about security, with caching as a MUST implement?

The descriptions and examples for "Origin Only" and "Origin when Cross-Origin" policies do not make it clear that they also imply the "None When Downgrade" policy.

Be nice to include the note about not being able to use "Content-Security-Policy-Report-Only" in a meta element in the "Content-Security-Policy-Report-Only" section. I was testing the things in the spec out as I was reading and this almost tripped me up. I spotted the note in the meta section by accident.

the spec says:

For example.... If their site violates this policy, instead of breaking the site, the user agent will send violation reports to a URI specified in the policy.

Be nice in this example to actually link to, or show, the declaration an author needs to use to include the URI that is pinged when there is a violation of some policy.

Authors are not a conformance class, hence shouldn't have RFC2119 terms associated with them... For authoring recommendations maybe just "recommend" things instead:

Authors SHOULD place the meta element as early in the document as possible to reduce the risk of content injection before a protective policy can be read and enforced.

Could be:

Authoring Requirement: It is RECOMMENDED that authors place the meta element as early in the document as possible. This is to reduce the risk of content injection before a protective policy can be read and enforced.

Current working draft for CSP has the following test vector (Example 6):

For example, the SHA-256 digest of alert('Hello, world.'); is qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=.

Calculated by the following command:

echo -n "alert('Hello, world');" | openssl dgst -sha256 -binary | openssl enc -base64

I've tried that on two different machines (Mac & Linux) and the resulting hash is different:

$ echo -n "alert('Hello, world');" | openssl dgst -sha256 -binary | openssl enc -base64
b+jOy0DlwBaNGMxhuGypbGgvtY9mVoy1LlMALqJWsoY=

Just after that, there's another example that contains yet another hash, which is way too long for SHA256:

Content-Security-Policy: script-src 'sha256-YWIzOWNiNzJjNDRlYzc4MTgwMDhmZDlkOWI0NTAyMjgyY2MyMWJlMWUyNjc1ODJlYWJhNjU5MGU4NmZmNGU3OAo='

As proposed in http://lists.w3.org/Archives/Public/public-webappsec/2014Aug/0034.html:

Many web site uses JSONP, but may set the wrong Content-Type(e.g.
text/html), sniffing will let the codes looks working. But for security, I
want to turn sniffing off using `X-Content-Type-Options: nosniff`.

Sometimes it is really difficult for me to find out all the JSONP with
wrong Content-Type assigned.

If I can use CSP like :

Content-Security-Policy-Report-Only: content-type-option noniff; report-uri
/cspreport.do

Help me finding out all the Content-Type sniffing invoke.

P.S.
1. "X-" prefix header is deprecated by RFC6648
2. In CSP Level 2 frame-ancestors replaces X-Frame-Options and
reflected-xss replaces X-XSS-Protection, but X-Content-Type-Options has no
replacement.

There are a lot of referenced specs that are quite out of date: xhr, "html5" should be HTML, etc. Be nice if instead of URI, the WHATWG URL spec was referenced, etc.

a style-src restriction that does not include unsafe-eval intends to block modifying CSS from scripts using free text. This currently restricts a set of algorithms: "insert a CSS rule, parse a CSS rule, [and] parse a CSS declaration block".

It is still possible to modify styles from scripts using the .selectorText attribute for CSS rules.
I recommend we include the "parse a group of selectors" algorithm from the CSSOM spec

Level 2:
Editor's Draft: https://w3c.github.io/webappsec/specs/content-security-policy/
Last Call Working Draft: http://w3.org/TR/CSP2

the document is https://w3c.github.io/webappsec/specs/content-security-policy/ update to Level 3, but the README document is refer to Level 2

url: https://github.com/w3c/webappsec/blob/master/admin/Overview.html

<html>
    <meta http-equiv="Content-Security-Policy"
          content="default-src none; img-src http://www.w3.org https://www.google.com; style-src 'self'; child-src https://www.google.com; frame-src https://www.google.com; form-action http://www.w3.org; connect-src https://localhost:*">
    <!--
        Chrome mobile on iOS uses internal XHR to do things like checking the phishing url database, so you
        trigger a spoof warning if you don't have this connect-src rule for a meta-tag. (header processing
        has a workaround, it seems) OK here since there is no XHR anywhere in this resource anyway
    -->
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>W3C Web Application Security Working Group</title>
    <link href="Overview.css" rel="stylesheet" type="text/css"></link>
<head>
</head>
<body>

should be:

<html>
<head>
    <meta http-equiv="Content-Security-Policy"
          content="default-src none; img-src http://www.w3.org https://www.google.com; style-src 'self'; child-src https://www.google.com; frame-src https://www.google.com; form-action http://www.w3.org; connect-src https://localhost:*">
    <!--
        Chrome mobile on iOS uses internal XHR to do things like checking the phishing url database, so you
        trigger a spoof warning if you don't have this connect-src rule for a meta-tag. (header processing
        has a workaround, it seems) OK here since there is no XHR anywhere in this resource anyway
    -->
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>W3C Web Application Security Working Group</title>
    <link href="Overview.css" rel="stylesheet" type="text/css"></link>
</head>
<body>

the meta tag should between <head> and </head>, right?

http://www.w3.org/TR/CSP11/#source-list-paths-and-redirects

To avoid leaking path information cross-origin (as discussed in Egor Homakov’s Using Content-Security-Policy for Evil, the matching algorithm ignores the path component of a source expression if the resource being loaded is the result of a redirect.

should have a paren after "for Evil".

"Issue-5" in the draft spec text states that noncanoncial-src only makes sense if we are allowing HTTP. This is not true - it also allows for fallback in the case that e.g. a client is behind a proxy that intercepts and modifies HTTPS connections. This is likely a nontrivial percentage of clients. (e.g. enterprise and government systems)

Given the potential for a manifest to affect the behavior of a web application (e.g., adding a service worker, controlling the display mode of a document), It would be nice if the CSP spec included a directive for manifests. This would restrict where manifests can be obtained from.

http://w3c.github.io/manifest/

Related to:
w3c/manifest#207

What would be a sensible default behavior for when manifest-src is missing? Should it default to self or behave like script, style sheets, or HTML imports do?

cc @PaulKinlan

Bit more background in w3c/manifest#263

We should update the first part to reflect the fact a blob/unique Worker inherits the CSP of the owner document or parent worker (if the parent worker has CSP header). I am happy to provide a pull request if you agree with these semantics.

There's a ref for Object Capability URLs, but no context provided for Section 1.4. Many readers will not be familiar with this term and the first few Google hits aren't an easy place from which to extract a concise definition. Can we find a good informative reference at a stable link to point to?

The fetch section is currently poorly cited (as evidenced by the confusion in 1).

Per @agl mail http://lists.w3.org/Archives/Public/public-webappsec/2014Mar/0019.html

We should deal with srcset in the spec. Creating an issue here instead of in the spec document because the latter will change all the issue numbers in the spec. I don't want to do that while the Call for Consensus is still out.

A simple use case that I can't figure out how to implement with the current spec is: "require integrity for all script loads"

I am beginning to think that instead of a new "integrity-policy" directive, we should just have new keywords for the existing CSP directives like script-src. OR some other way to declare integrity requirements for each type of sub-resource.

I am just creating a placeholder issue for now. I am traveling and don't have the time/connectivity required to start and participate in a thread on public-webappsec.

(HT Tanvi)

The spec needs to talk about fonts. It mentions it in the beginning but never follows up with details.

If the integrity metadata has the content type specified, it seems the browser should change the Accept header to the specified content type.

We should make it explicit, that iframe integrity includes the iframe's HTML, but not the resources the iframe would then request.

I'll take care of that pretty soon.

Forgive me if I'm mistaken, but the current hashing solution detailed in the Subresource Integrity specification seems to be silent on the the possibility of length extension with Merkle–Damgård type hash functions like the SHA family.

http://en.wikipedia.org/wiki/Length_extension_attack

One solution would to be use a HMAC construction where the 'key' material is composed from resource metadata, including the verified Content-Length, or to mandate a hash function immune to such attacks, such as SHA-3.

This refers to 3.2, Cryptographic hash functions. We say that user agents MUST support SHA-256 and SHA-512 and MAY support additional hash functions.

I am not a cryptographer, but the more I read about Merkle–Damgård constructions, the more I'm wondering whether we'd want SHA-384 as mandatory. It seems the most convenient way to prevent length extension problems.

SHA-384 is well supported within OpenSSL and NSS, so I think this should add no cost.

SRI currently uses and clarifies the terms secure channel and insecure channel in 2.1 (key concepts and terminology).

Do we instead prefer to talk about authenticated and unauthenticated origins, as we do in MIX?

The spec constantly speaks as if Server is a valid conforming class. However, all conformance requirements for servers are "MAY". This clearly indicates that the server is not a conforming class, but more of a thing that emits policies to be enforced by the client (hence, anything to do with the server can only ever be "authoring guidelines" at best!).

I would recommend dropping the server as a conforming class and changing all "server MAY" statements to statements of fact: "A server can".

Consider, these are all TRUE facts:

• A server can send more than one HTTP header field named Content-Security-Policy with a given resource representation.
• A server can send different Content-Security-Policy header field values with different representations of the same resource or with different resources.
• A server can send more than one HTTP header field named Content-Security-Policy-Report-Only with a given resource representation.
• and so on... you get the idea. Given the facts above, the user agent (client) is forced to deal with the above situations through the algorithms defined in the specification.

That sets more realistic expectations about what conforming user agents can expect from server responses - specially when they servers send "funky" things that the client needs to make sense of and enforce.

I'll take it if nobody beats me to it.

Forgive me if I'm missing something obvious!

Only the form-action and frame-ancestor directives appear to be called out as directives which do "not fall back to the default sources when the directive is not defined."

Should similar text be added for the base-uri, referrer, plugin-types, and reflected-xss directives?

the spec says:

The server delivers the policy to the user agent via an HTTP response header.

Should it not say:

The server delivers the policy to the user agent via an HTTP response header or a HTML meta element.

CSP violation reports sent when browser blocks eval() and inline script are identical in their contents, which makes it difficult to determine what really caused them.

In both cases the fields violated-directive will be set to script-scr and blocked-uri will be empty. So when I'm trying to analyse received reports I can't really say what I should allow - unsafe-eval or unsafe-inline.

The solution might be either sending some kind of generic blocked-urlvalue - such as self-eval or self-inline, or adding an additional field to the report, such as blocked-feature set to eval or inline respectively.

Along the lines of http://www.chromium.org/Home/chromium-security/prefer-secure-origins-for-powerful-new-features. There may need to be a pair of terms to cover before-load and after-load like "a priori insecure origin" vs "insecure origin".

This is related to w3c/ServiceWorker#385, but I'm filing it here so I can update https://github.com/jyasskin/web-bluetooth when it's done.

In:
https://w3c.github.io/webappsec/specs/content-security-policy/published/2014-09-03-CSP-2-CR.html#changes

There is the following sentence fragment that should be corrected:
"Redirects are blocked by default, and explicitly allowed with a new unsafe-redirect expression, as part of"

Please avoid the use of RFC2119 keywords in non-normative sections. For example, 3.4 Enforcing multiple policies:

The above sections note that when multiple policies are present, each must be enforced or reported, according to its type.

Should be:

The above sections note that when multiple policies are present, each is enforced or reported, according to its type.

Arguably most of the sandbox flags don't make sense for workers, but the empty directive (i.e., just sandbox) and sandbox allow-same-origin can have reasonable semantics. The question is if a worker inherits CSP from owner document or is accompanied by a CSP header which has the 'sandbox' directive, should the worker script's origin be set to a unique origin? Or should we just ignore sandbox for workers (and maybe have SandboxedWorkers instead)?

It struck me as weird to remove the trailing equal signs only when applying the algorithm within the user agent. I assume that we need to do this similarly in the 'Does resource match metadataList' algorithm (3.3.5) after step 8 to ensure matching?

in the proxies section, there's a slight dissonance between the requirement from proxies and the requirement from user-agents.

While proxies must avoid modification of resources which integrity is verified (which is great, and I 100% agree with), UAs may send the no-transform headers that'd enable proxies to do that. Without that header, most proxies would have a very hard time avoiding modifications of such resources, resulting in compliance issues, and worse, user visible content integrity issues.

I'd say that at the very least, the requirement should be that UAs should send these headers (even though I'd consider must better).

Section 2.1 lists the IPv4 private address space, but not IPv6. I think RFC 4193 defines this for IPv6, but my notes indicate the following address spaces should probably be investigated as they may be security relevant:

# IPv4 addressed Encoded into IPv6, where the IPv4 component is an RFC1918 address
0::  ffff:AABB:CCDD - IPv4 Mapped Address (SIIT).  Also 0::ffff:aa.bb.cc.dd
0::  0000:AABB:CCDD - IPv4 Compatible Address (SIIT). Also 0::0:aa.bb.cc.dd
0::ffff:0:AABB:CCDD - IPv4 Translated Address (SIIT).
2002:AABB.CCDD:: - 6to4 address. Send to the IPv4 Address AA.BB.CC.DD

#Private Address Space
fc??::  - Possibly, eventually, the local network 10.0.0.0/8 for IPv6.  Currently Reserved.  (Part of fc00::/7)
fd??::  - The local network, 10.0.0.0/8 for IPv6.  Not routable unless conifgured explictly. (Part of fc00::/7)
fe80::  - Space for Link Local Addresses (not all assigned \/ )
fe80:0:0:0:: - Link Local Addresses. 169.254.0.0/16.
fe80::0200:5efe:aabb:ccdd - ISATAP globally unique IPv4 translated address
fe80::0000:5efe:aabb:ccdd - ISATAP private IPv4 translated address
fec?:: - First attempt at 10.0.0.0/8 for IPv6, Deprecated. (Part of fec0::/10)
fed?:: - First attempt at 10.0.0.0/8 for IPv6, Deprecated. (Part of fec0::/10)
fef?:: - First attempt at 10.0.0.0/8 for IPv6, Deprecated. (Part of fec0::/10)

#Multicast Addresses
ffx?:: - Multicast Addresses - http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xml
ffx1:: - Interface-Local. 127.0.0.1; Packets may not exit box, stay within loopback.
ffx2:: - Link-Local. Packets may not be routed anywhere, but may be passed within a subnet.
ff02:0:0:0:0:1:ff??:: - Solicited Node Multicast Addresses
ffx3:: - IPv4 Local Scope?
ffx4:: - Admin Local Scope. Smallest scope an admin would need to configure. Kind of like two subnets.
ffx5:: - Site-Local. Restricted to local physical network.
ffx8:: - Organization-Local. Multicast within an organization. Not valid on public internet.
ffxe:: - Global Multicast addresses
ff3?:: - Unicode-Prefix-Based Multicast https://tools.ietf.org/html/rfc3306

Current spec contains a Worker constructor as follows:

[Constructor (DOMString scriptURL, DOMString integrityMetadata)]

I wonder if it would be more future proof to spec an object instead.
Assuming future patches to the Worker, tthis would cause less "first come first serve paremeters" being added in a possibly unintuitive order.

So how about this

[Constructor (DOMString scriptURL, object options)]
and then requiring an integrity field within?

Maybe @annevk has an opinion.

@mnot says it's cargo-cult design, which is pretty much a completely accurate depiction of how I defined it. :)

See also: igrigorik/http-client-hints#24

We should number the issues manually so that they don't change while fiddling with the document's structure.

If a link on http://example.com/ points to https://example.com/, what will be sent with a policy of "Origin When Cross-Origin"?

According to RFC6525, these are not same-origin, but it is common to support "upgrade" of this sort for other parts of the web platform like cookies.

I'm not particularly attached to either outcome, but it should be clear which path to take.

The spec currently refers to HTTP/1.1 per RFC 2616. This should be fixed to RFC 7230/1.

It also has some direct links to RFC2616 and the HTTP drafts. These should be updated to point to the relevant subsections of RFC 7230/1.

IIUC, default-src affects a number of *-src directives. Should manifest-src be included in that list? My feeling is probably.

The CSP specification does not mention IP addresses as all.

Unlike IPv4, IPv6 addresses does not fit in the current host-part rule. Could you either specify that the CSP is not intended for IP addresses, or include IPv6 addresses in the specification?

The IPv6 format is described in https://tools.ietf.org/html/rfc4291#section-2.2