[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 [127.0.0.1]) 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-Level:
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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (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 [74.125.82.44]) 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 10.180.83.198 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 [209.85.217.172]) by mx.google.com with ESMTPS id gg2sm8577325wib.7.2012.05.03.16.59.29 (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 10.152.145.169 with SMTP id sv9mr3762109lab.12.1336089568611; Thu, 03 May 2012 16:59:28 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.112.48.229 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 <http://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html>. The WebAppSec working group is soliciting proposals for CSP 1.1: http://www.w3.org/Security/wiki/Content_Security_Policy#Proposals_for_Version_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, Adam