do we want a directive to control postMessage explicit channels outbound?

[hillbrad]

has come up in context of COWL, elsewhere, e.g.:

https://lists.w3.org/Archives/Public/public-webappsec/2014Jul/0044.html

[mikewest]

@devd wants this too, though it sounded like his use-case was in the other direction (e.g. incoming messages as opposed to outgoing).

If we restrict outgoing messages, connect-src seems like the right way to do so. I'll add a metric to Chrome, I suppose.

[mikewest]

(Also, how would y'all expect this to work with MessagePorts? Assume I had a port to valid.site, which then sneakily turns around and transfers ownership to bad.site. Would we need to block that as well?)

[mikewest]

Adding metrics for postMessage's interaction with connect-src in https://codereview.chromium.org/2873223003.

[devd]

Why not have a new directive instead of reusing connect-src? CSP is complicated enough; I am against adding more confusion around meaning of connect-src.

[mikewest]

"CSP is complicated enough, so let's add more directives." is a strange thing to say. :) If it turns out that in-the-wild usage shows that connect-src doesn't generally block existing postMessage() usage, it seems like the conceptually correct place to restrict the origins to which (from which?) a document can "connect", doesn't it?

If we decide that we really do need a new directive to limit some kinds of messaging without limiting others, it seems reasonable to consider it a scoped subset of "connections". That is, cascading as postmessage-src -> connect-src -> default-src.

[devd]

Sure; but you can't measure the loss in security. For example, most websites I have seen have connect-src of https://. For them, postMessage could be empty or 1 origin. Your measurement will show you that connect-src works but doesn't show you the loss in security because now we can't limit postMessage.

On the other hand, there could be an app that wants to be purely client side and wants to set connect-src to empty set and postmessage to local already loaded pages. This will break that.

Having a separate directive is more flexible and allows potential applications we can't think of. I strongly feel the spec should give primitives that each target a specific case and then let applications mix and match them per their needs.

[annevk]

I don't like adding something here without it also being a solution for MessageChannel and BroadcastChannel (and maybe localStorage synchronization events). We try to make the postMessage() experience quite seamless and even though in implementations there's all kinds of differences, I would not want those to end up getting exposed.

[arturjanc]

As a developer, I'd agree with @devd that it seems simpler to have a separate directive to control outgoing messages, rather than merging it into connect-src. Yes, it means adding two different directives to your policy, but those directives control different things: which domains I can send CORS to, and which frames I can interact with via postMessage. While both of them are instances of "connecting" somewhere, the APIs have quite different semantics, and it is likely that developers would need different whitelists for them (e.g. maybe I need to allow my JS widget to send a message to its parent origin, but I don't have to let my document send out arbitrary data via CORS to that domain).

I wonder if our experience with child-src vs. frame-src / worker-src can be a guide here ;)

FWIW I'm also worried about new restrictions on messages suddenly coming into play once user agents adopt this; I'd like to not break / annoy people if we can avoid this.