CSP denies pretty much everything by default, and restrictions like
'no inline scripts' would prevent a majority of today's websites
working without big changes being made. What CSP declaration would re-
enable everything that is denied by default but prevent a site from
being framed in the same manner as X-Frame-Options?
In CSP, you specify the frame-ancestors to control who may embed your
document: http://people.mozilla.org/~bsterne/content-security-policy/details.html#frame-ancestors
As for the policy of turning everything else back on, I'm not exactly
sure how that's done, but I'm sure it's in that same document.
X-Content-Security-Policy: allow *; options inline-script eval-script;
frame-ancestors 'self';
The only thing I'm not 100% sure about is whether this allows data:
URIs, though I'm pretty sure that the 'allow *' part takes care of
that. Maybe someone more familiar with the spec could confirm this.
When CSP does finally go into Firefox, I think the X-Frame-Options
header should be supported as well, since many sites are already using
it, and it's a lot simpler than the equivalent CSP directive above.
If this was the case, then I guess the CSP spec should be updated to
define the behaviour if both headers are specified at the same time
(I'm guessing they would be intersected in the same way as multiple
CSP headers).
On Feb 2, 2:41 pm, EricLaw <bay...@gmail.com> wrote:
> On Feb 2, 4:13 am, Paul Stone <stoned...@gmail.com> wrote:
>
> > What CSP header would be the exact equivalent of X-Frame-Options: Deny
> > or X-Frame-Options: SameOrigin?
>
> > CSP denies pretty much everything by default, and restrictions like
> > 'no inline scripts' would prevent a majority of today's websites
> > working without big changes being made. What CSP declaration would re-
> > enable everything that is denied by default but prevent a site from
> > being framed in the same manner as X-Frame-Options?
>
> In CSP, you specify the frame-ancestors to control who may embed your
> document:http://people.mozilla.org/~bsterne/content-security-policy/details.ht...
That is correct.
> The only thing I'm not 100% sure about is whether this allows data:
> URIs, though I'm pretty sure that the 'allow *' part takes care of
> that. Maybe someone more familiar with the spec could confirm this.
That is also correct. "allow *" permits data: URLs to be used as valid
sources for all content types.
> When CSP does finally go into Firefox, I think the X-Frame-Options
> header should be supported as well, since many sites are already using
> it, and it's a lot simpler than the equivalent CSP directive above.
I agree that Firefox should support X-Frame-Options. It should be
trivial to support now with the plumbing we added for CSP.
> If this was the case, then I guess the CSP spec should be updated to
> define the behaviour if both headers are specified at the same time
> (I'm guessing they would be intersected in the same way as multiple
> CSP headers).
I'm not sure this is necessary. Couldn't the two specs be considered
orthogonal? X-F-O will either block the frame or not, and same for
X-CSP. So if one or both say block, then we block, otherwise we allow.
Cheers,
Brandon
There is a slight difference between X-F-O: SameOrigin and the CSP
equivalent above. X-F-O only checks the origin of the out-most page,
whereas CSP checks every frame along the way.
> I'm not sure this is necessary. Couldn't the two specs be considered
> orthogonal? X-F-O will either block the frame or not, and same for
> X-CSP. So if one or both say block, then we block, otherwise we allow.
Good point. I'm looking forward to trying out CSP when it lands on the
trunk. I see various patches are being reviewed so hopefully it won't
be long now.