target: "self" doesn't help defend against XSS. about webappsec-permissions-policy

[jkarlin]

Was it necessary to throw "self" out? It would be very nice to have as it's much more copy&pasteable and useful for snippets:

Feature-Policy: {"enable":["geolocation"], "target":["self"]}, {"disable":["geolocation"], "target":["!self"]}

[ojanvafai]

Is target:self meant to defend against XSS? I think it's more for incremental adoption than security, i.e. I want this on my first party content by I can't force some third party I embed to do this.

I think it'd be OK to say that target:cascade is not overrideable via the attribute though and that if you want the security assurance you should be using target:cascade.

Does that work?

[igrigorik]

I think it'd be OK to say that target:cascade is not overrideable via the attribute though and that if you want the security assurance you should be using target:cascade.

This makes it impossible to whitelist a specific origin: either you block access for everyone, including yourself, or you keep it open for everyone... That said, perhaps #13 could address this?

---

Taking a step back.. If it is our goal is to address the XSS case (is it? :)), then I think we have to restrict ourselves to the header mechanism. Or, at least, if you want to protect yourself from the XSS case then: you MUST use the header mechanism; the header mechanism needs to support a whitelisting mechanism (which is what the attribute provides); header policy must take precedence over the attribute values?

Feature-Policy: {"disable":["geolocation"], "target":["cascade"]}, 
           {"enable":["geolocation"], target:["https://foo.com"]}

<iframe src="https://foo.com/widget"> <!-- Geolocation enabled -->
<iframe src="https://bar.com/thing" enable="geolocation"> <!-- noop...? -->

[igrigorik]

@jyasskin I think @mikewest's update addresses this case. Can you review and confirm?

[jyasskin]

It's a step, but to protect against XSS we need a whitelist of origins, while {disable: 'thing', target: [evilx, evily, evilz]} still allows evilw to use 'thing'. When 'enable' rules exist, that'll finish addressing this case.

[igrigorik]

I think we can add "self", but I don't think we want to get into predicates with "!self" and such. /cc @mikewest

[jkarlin]

Then I propose adding self and third-party as targets.

[igrigorik]

See discussion in #28 (comment).