RE: ISSUE-25: Do frame-options directives (or other UISafety directives) make sense in a meta tag context?

Some use cases:

1. The document wants the UA to apply restrictions as a defense.

2. The parent may be applying restrictions anyway, but the document wants to communicate compatibility with such restrictions.


Some issues:

1. Would the restrictions be parsed in a first pass of the head element thus applying to all elements of the head, or would the restrictions take effect as they are parsed.

2. Should the directives be loaded only while loading and parsing the meta tag within the head element, or should changes be allowed later.

3. If there is overlap should the effective restrictions be the intersection.

4. meta element versus HTTP header.

This old discussion on CSP HTTP headers versus meta element has some interesting points that may be relevant: http://blog.sidstamm.com/2009/06/csp-with-or-without-meta.html

The reason for using a HTTP header for CSP seems to be largely that it would be harder to attack.  A similar argument could be made for other directives.

However some restrictions on when the meta element is parsed and takes effect should close any threats from injected content, and it would seem to be a much lower burden on all the content creation software to use a meta element rather than require a HTTP header, so unless there are some vulnerabilities I suggest the use of a static meta element in the head section.

cheer
Fred

> Date: Thu, 1 Nov 2012 15:56:02 +0000
> To: public-webappsec@w3.org
> From: sysbot+tracker@w3.org
> Subject: ISSUE-25: Do frame-options directives (or other UISafety directives) make sense in a meta tag context?
> 
> ISSUE-25: Do frame-options directives (or other UISafety directives) make sense in a meta tag context?
> 
> http://www.w3.org/2011/webappsec/track/issues/25
> 
> Raised by: 
> On product: 
> 
> 
> 
> 
>