[websec] Frame-Options: Why a header and not a CSP directive?

Adam Barth <ietf@adambarth.com> Thu, 03 May 2012 23:59 UTC

Return-Path: <ietf@adambarth.com>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id B942E11E8085 for <websec@ietfa.amsl.com>; Thu, 3 May 2012 16:59:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id xaHAmw+VeKRX for <websec@ietfa.amsl.com>; Thu, 3 May 2012 16:59:34 -0700 (PDT)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id EBC5711E8080 for <websec@ietf.org>; Thu, 3 May 2012 16:59:33 -0700 (PDT)
Received: by wgbdr13 with SMTP id dr13so1537803wgb.13 for <websec@ietf.org>; Thu, 03 May 2012 16:59:30 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type :x-gm-message-state; bh=mucgRhpovUjJjJcdtbrySyZOytrQVZkHxfiFJZpLws0=; b=KYqNn4J9L/3rr8D419GmqGkwFFAkTaThOadma9IPBLpZo+857hEy0+Y3JLSqJxgsRi Q0cDjZRa54wzkqnx3YCruxbCagka9jRUb/FngbTWboT/oGglxRmAHrK4td0RJj7gz1P6 Jx+3KOvKEUsJCTcYP7N4pw+ZN7hY4rdS1Mcymw22681xfdRzCd2i5b/o5WusnpycgWcJ +VaRTD3Ku3eUsTKe71Hs69Jie7de4tBms0zJ0NQRyDpAlF5urupGqq3sezjcvk2Z4yEZ Nxtwz5jOe8e226BgHRJ5CcmFla2+5SMohRkCDmt0r3ERf9bX0oGLWKtocU7VVmfEweOC muoQ==
Received: by with SMTP id s6mr7625735wiy.8.1336089570317; Thu, 03 May 2012 16:59:30 -0700 (PDT)
Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com []) by mx.google.com with ESMTPS id gg2sm8577325wib.7.2012. (version=SSLv3 cipher=OTHER); Thu, 03 May 2012 16:59:29 -0700 (PDT)
Received: by lbbgo11 with SMTP id go11so1895492lbb.31 for <websec@ietf.org>; Thu, 03 May 2012 16:59:28 -0700 (PDT)
Received: by with SMTP id sv9mr3762109lab.12.1336089568611; Thu, 03 May 2012 16:59:28 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Thu, 3 May 2012 16:58:58 -0700 (PDT)
From: Adam Barth <ietf@adambarth.com>
Date: Thu, 03 May 2012 16:58:58 -0700
Message-ID: <CAJE5ia_82uobXnKiWf=+hH-QYtkLJvZ+bYChD7i_rjq3vjsD+g@mail.gmail.com>
To: websec <websec@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
X-Gm-Message-State: ALoCoQn0gN69IWH4IfhosbubAK3+P4D0FIEzUjKE9ZIwpNNhOWx9Ot1/mJiZCjii6qjwh6epO5WJ
Subject: [websec] Frame-Options: Why a header and not a CSP directive?
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 May 2012 23:59:34 -0000

In http://tools.ietf.org/html/draft-gondrom-frame-options-02 we're
introducing a new HTTP header called Frame-Options.  Is there a
particular reason to create yet-another-HTTP-header for carrying this
security policy?  Rather than inventing a new HTTP header, we can use
the extensible Content-Security-Policy header.

== Proposed in draft-gondrom-frame-options ==

Frame-Options: XYZ

Where XYZ is the Frame-Options policy.

== Using Content-Security-Policy ==

Content-Security-Policy: frame-options XYZ

There are added benefits to using a common policy header.  For
example, Content-Security-Policy has a report-uri directive that web
sites can use to learn when their security policies are violated:

Content-Security-Policy: frame-options XYZ; report-uri /csp-reports.cgi

Note: Content-Security-Policy 1.0 is very close to WGLC in the W3C
WebAppSec working group.  You can find the current draft  at

The WebAppSec working group is soliciting proposals for CSP 1.1:


In particular, we have an item on the wiki about coordinating with
this working group about frame-options.  It's entirely possible to
define the frame-options directive in this working group and to have
CSP 1.1 refer to whatever document this working group produces.  In
the long term, we'll probably want an IANA registry for CSP
directives, but we haven't quite reached that level of technology yet.

Kind regards,