RE: Using CSP

> Again, the context here is that HTTP content is framing HTTPS content at the same host
> and the latter wants to use 'self' in allow-frames to allow the framing.  _That_ is what I 
> would like to understand use cases for.

That's not how I understood it.  I think the request was that "self", in the context of CSP for an HTTP resource, also implicitly include HTTPS of the same origin.   

In the context of IFRAMEs this is about loading the framed content from HTTPS; it is not about the HTTPS resource's declarations of who might have permission to frame it.  (The emerging consensus also seems to be that mechanisms for secure framing should be moved out of CSP and into X-Frame-Options and possibly a successor to XFO.)

I'm in favor of having directives be upwards compatible on the HTTP->HTTPS axis everywhere.  Not doing so introduces yet another obstacle for sites that want to move incrementally towards delivering all content securely.

-Brad

-----Original Message-----
From: Boris Zbarsky [mailto:bzbarsky@MIT.EDU] 
Sent: Tuesday, July 26, 2011 10:07 AM
To: Hill, Brad
Cc: public-web-security@w3.org
Subject: Re: Using CSP

On 7/26/11 12:58 PM, Hill, Brad wrote:
> The threat is that the secure content will be spoofed, but there are plenty of common use cases for this, where the content of the HTTPS iframe has a very low risk of spoofing.  For example, a personalized "Like", "+1", or "Pay" button.

OK, I'm with you so far.

> These buttons likely originate at an HTTPS only site, but are commonly embedded in HTTP content.

In this situation, using the 'self' CSP directive in the button would make it not embeddable even if the content were HTTPS, since presumably the content is on a different server.

Again, the context here is that HTTP content is framing HTTPS content at the same host and the latter wants to use 'self' in allow-frames to allow the framing.  _That_ is what I would like to understand use cases for.

-Boris

Received on Tuesday, 26 July 2011 17:21:57 UTC