Re: [websec] Coordinating Frame-Options and CSP UI Safety directives

David Ross <> Thu, 12 July 2012 00:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9933911E8176 for <>; Wed, 11 Jul 2012 17:21:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kMA5+T68AeYo for <>; Wed, 11 Jul 2012 17:21:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D10C611E816F for <>; Wed, 11 Jul 2012 17:21:46 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server id; Thu, 12 Jul 2012 00:19:54 +0000
Received: from mail46-ch1 (localhost []) by (Postfix) with ESMTP id CEB82160204; Thu, 12 Jul 2012 00:19:54 +0000 (UTC)
X-Forefront-Antispam-Report: CIP:; KIP:(null); UIP:(null); IPV:NLI;; RD:none; EFVD:NLI
X-SpamScore: -28
X-BigFish: VS-28(zz9371I542M1418I1447Izz1202hzz1033IL8275bh8275dhz2fh2a8h668h839h944hd25hf0ah107ah)
Received-SPF: pass (mail46-ch1: domain of designates as permitted sender) client-ip=;; ; ;
Received: from mail46-ch1 (localhost.localdomain []) by mail46-ch1 (MessageSwitch) id 1342052392646677_25351; Thu, 12 Jul 2012 00:19:52 +0000 (UTC)
Received: from ( []) by (Postfix) with ESMTP id 922303A0047; Thu, 12 Jul 2012 00:19:52 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 12 Jul 2012 00:19:52 +0000
Received: from ([]) by ([]) with mapi id 14.02.0298.005; Thu, 12 Jul 2012 00:22:13 +0000
From: David Ross <>
To: "Hill, Brad" <>, Tobias Gondrom <>, "" <>
Thread-Topic: [websec] Coordinating Frame-Options and CSP UI Safety directives
Thread-Index: Ac1eARMykz8Gk35PQYOw0F4CVEc1fgAKMP0AAAFdb4AAZMpUwA==
Date: Thu, 12 Jul 2012 00:22:12 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [websec] Coordinating Frame-Options and CSP UI Safety directives
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 Jul 2012 00:21:47 -0000

Responding to a few of the points in Brad's original mail on this thread...

My concern is mostly around the degree to which a move to CSP might complicate or stall the process.  I'd also prefer not to see additional use cases pop up (eg: click fraud prevention) that just were never in scope before.

I think that w.r.t. header bloat, the most sensible approach is to only allow one origin to be specified.  CSP by-design facilitates the use of multiple origins.  As we've discussed w/Frame-Options, there is a design pattern to make the more basic single-origin approach functional.  I would hate to see hosts serving up source lists of hundreds of origins, just because they can.  I think that is exactly what will happen if we support multiple origins.

With regard to obsolescence of X-FRAME-OPTIONS, it's easy to specify exactly what happens in the FRAME-OPTIONS spec.  I don't see that CSP inherently improves on that but I may be missing something there.

The advantage I see of bringing FRAME-OPTIONS into CSP is that it makes CSP more comprehensive.  But I suspect there are plenty of other header-related security features that aren't defined by CSP (eg: the origin header, cookie security).

Finally, as Brad pointed out in the rosetta stone thread, Frame-Options provides the flexibility to perform only a top level origin check as opposed to a full ancestor check.  (Specified via the "AllAncestors" flag.)

David Ross

-----Original Message-----
From: [] On Behalf Of Hill, Brad
Sent: Monday, July 09, 2012 5:03 PM
To: Tobias Gondrom;
Subject: Re: [websec] Coordinating Frame-Options and CSP UI Safety directives


 I'm happy to move the discussion primarily to websec, and I'll drop the cc: to webappsec after this email.  Thanks for the historical clarification, as well.

I'm not terribly concerned about which group does the work, as much as arriving at the engineering solution that works best for user agent and resource authors, some of whom have expressed preference for moving this functionality into CSP.  As both a chair and an individual, I don't have a strong preference, but I think there are reasons in favor of each option and it is worth re-opening the discussion now that the WebAppSec WG has a concrete deliverable under development to address the same general class of attacks.

I'll send out a summary shortly of the similarities and differences between the various options currently proposed for some additional context.

-Brad Hill

websec mailing list