W3C

コンテント セキュリティポリシー — Content Security Policy 1.0

2012 年 11 月 15 日付 W3C 勧告候補

このバージョン:
http://www.w3.org/TR/2012/CR-CSP-20121115/
最新バージョン
http://www.w3.org/TR/CSP/
以前のバージョン
http://www.w3.org/TR/2012/WD-CSP-20120710/
最新の編集者草案
http://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-1.0-specification.html
編集
Brandon Sterne, Invited Expert (formerly of Mozilla Corporation)
Adam Barth, Google, Inc.
Copyright © 2010-2012 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.

要約

この文書は、ウェブリソースのための一連の内容 制約を宣言するために利用される,ポリシー言語、および,ポリシーを施行する際にサーバからクライアントへポリシーを伝送するための仕組みを定義する。 This document defines a policy language used to declare a set of content restrictions for a web resource, and a mechanism for transmitting the policy from a server to a client where the policy is enforced.

この文書の位置付け

この節では、発行時点における… 【 以下、この節の他の内容は W3C 日本語訳 共通ページ に委譲 】

この文書は幅広いコミュニティの中で 2010 年から論が交わされてきた提案を述べます。 Firefox と Chrome においては、それぞれ,ヘッダ名 X-Content-Security-PolicyX-WebKit-CSP を通して,試験的に実装されています。 また, Internet Explorer 10 Platform Preview でも、ヘッダ名 X-Content-Security-Policy を通して,部分的に実装されています。 This document describes a proposal that has been discussed by the broader community since 2010 There are experimental implementations in Firefox and Chrome, using the header names X-Content-Security-Policy and X-WebKit-CSP respectively. Internet Explorer 10 Platform Preview also contains a partial implementation, using the header name X-Content-Security-Policy.

W3C Web Application Security working group による文書に加え、この文書の仕事は IETF websec working group の仕事, 特にその working group の要件文書: draft-hodges-websec-framework-reqs からも影響を受けています。 In addition to the documents in the W3C Web Application Security working group, the work on this document is also informed by the work of the IETF websec working group, particularly that working group's requirements document: draft-hodges-websec-framework-reqs.

この文書は、勧告候補( Candidate Recommendation )として Web Application Security Working Group により発行されたものです。 この文書は W3C 勧告になることが企図されています。 この文書に関するコメントを寄せられたい方は、 public-webappsec@w3.orgsubscribe, archives )宛まで。 W3C は安定的と見なされている文書として勧告候補を発行しており、開発者コミュニティによる実装が奨励されています。 この勧告候補は 2012 年 11 月 30 日より前に勧告案に昇格することはありません。 フィードバックを歓迎します。 この文書の以前のバージョンとの 差分がマークアップされたバージョン も用意されています。 This document was published by the Web Application Security Working Group as a Candidate Recommendation. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-webappsec@w3.org (subscribe, archives). W3C publishes a Candidate Recommendation to indicate that the document is believed to be stable and to encourage implementation by the developer community. This Candidate Recommendation is expected to advance to Proposed Recommendation no earlier than 30 November 2012. All feedback is welcome. A diff-marked version against the previous version of this document is available.

1. 序論

この節は参考である。 This section is non-normative.

この文書は、ウェブアプリケーションが,クロスサイトスクリプティング(以下, “XSS” )などの,内容注入攻撃に対する脆弱性( content injection vulnerabilities )の広範なクラスを緩和するために利用できる仕組み、コンテント セキュリティポリシー ( Content Security Policy — 以下, “CSP” )を定義する。 CSP は、ウェブアプリケーション作者(またはサーバ管理者)(以下,単に “作者” )が,アプリケーションが予期しているリソースの読み込み先を クライアントに通知できるようにするための、宣言的なポリシーである。 This document defines Content Security Policy, a mechanism web applications can use to mitigate a broad class of content injection vulnerabilities, such as cross-site scripting (XSS). Content Security Policy is a declarative policy that lets the authors (or server administrators) of a web application inform the client from where the application expects to load resources.

ウェブアプリケーション側は、 XSS を緩和するために,例えば,予期されているスクリプトの読み込み先を宣言する。 これにより、クライアント側は,攻撃者からアプリケーションに注入される 悪意のあるスクリプトを,検出あるいは阻止することが可能になる。 To mitigate XSS, for example, a web application can declare from where it expects to load scripts, allowing the client to detect and block malicious scripts injected into the application by an attacker.

CSP は、内容注入攻撃に対する前線防御を意図するものではない。 CSP は、内容注入攻撃による被害を抑制するための,多層防御としての利用に最も適するものである。 【 すなわち、注入そのものを防ぐのでなく,注入されたものが動作するのを防ぐ。 】 Content Security Policy (CSP) is not intended as a first line of defense against content injection vulnerabilities. Instead, CSP is best used as defense-in-depth, to reduce the harm caused by content injection attacks.

既存のウェブアプリケーションに CSP を適用するためには、しばしば,自明でない量の作業を要し得る。 利点を最大限に享受するためには、作者は,すべてのインラインの[スクリプト/スタイル]を,例えば外部スクリプトなど,外部に移転させる必要がある。 利用者エージェント(以下, “UA” )は、インラインスクリプトが攻撃者から注入されたものかどうか判別する術がないので。 There is often a non-trivial amount of work required to apply CSP to an existing web application. To reap the greatest benefit, authors will need to move all inline script and style out-of-line, for example into external scripts, because the user agent cannot determine whether an inline script was injected by an attacker.

CSP の利点を得るためには、ウェブアプリケーションは, Content-Security-Policy HTTP ヘッダを通して CSP を供し, CSP をサポートするクライアントがその機能を利用できるようにする。 その種のポリシーが適用されるのは、利用中のリソース表現 resource representation のみに限られる。 サイト全体に渡ってポリシーを適用させるためには、サーバは,それぞれのリソース表現ごとにポリシーを供する必要がある。 To take advantage of CSP, a web application opts into using CSP by supplying a Content-Security-Policy HTTP header Such policies apply the current resource representation only. To supply a policy for an entire site, the server needs to supply a policy with each resource representation.

2. 適合性

【 以下、この節の他の内容は W3C 日本語訳 共通ページ に委譲 】

適合 UA は、この仕様に挙げられている, UA に適用し得るすべての要件を実装しなければならない。 また、任意選択と記されたものを実装してもよい A conformant user agent must implement all the requirements listed in this specification that are applicable to user-agents, and may implement those marked as "(Optional)".

適合サーバ は、この仕様に挙げられている,サーバに適用し得るすべての要件を実装しなければならない A conformant server must implement all the requirements listed in this specification that are applicable to servers.

2.1. 主要な概念と用語

この節では、この文書を通して利用される,いくつかの語を定義する。 This section defines several terms used throughout the document.

セキュリティポリシー, または単に ポリシー とは、この仕様の目的においては,次のいずれかを意味する: The term security policy, or simply policy, for the purposes of this specification refers to either:

  1. 内容の作用を制約するセキュリティ設定の集合体,あるいは a set of security preferences for restrictions within which the content can operate, or
  2. それらのセキュリティ設定が成文化されたテキスト片。 a fragment of text that codifies these preferences.

この文書にて定義されるセキュリティポリシーは、個別のリソース表現ごとに, UA に適用される。 特に、 UA が,与えられたリソース表現に伴ってポリシーを受信した際には、そのポリシーはそのリソース表現のみに適用される。 この文書では,しばしば、そのリソース表現を 被保護リソース と称する。 The security policies defined by this document are applied by a user agent on a per-resource representation basis. Specifically, when a user agent receives a policy along with the representation of a given resource, that policy applies to that resource representation only. This document often refers to that resource representation as the protected resource.

サーバは、ある特定の被保護リソースのためのセキュリティポリシーを,一連の 指令 ( directive )として, UA に向けて伝送する。 そのそれぞれ( default-src 'self' 等)が、 UA によるリソースのインスタンス化に際し,固有の制約の集合を宣言する。 更なる詳細は 指令 節にて与えられる。 A server transmits its security policy for a particular protected resource as a collection of directives, such as default-src 'self', each of which declares a specific set of restrictions for that resource as instantiated by the user agent. More details are provided in the directives section.

指令は、それにより制御される特権を指示する 指令名, および ポリシーがそれらの特権に課す制約を指定する 指令値 からなる。 A directive consists of a directive name, which indicates the privileges controlled by the directive, and a directive value, which specifies the restrictions the policy imposes on those privileges.

生成元 は、 Origin 仕様にて定義される。 [RFC6454] The term origin is defined in the Origin specification. [RFC6454]

URI は、 URI 仕様にて定義される。 [URI] The term URI is defined in the URI specification. [URI]

リソース表現 は、 HTTP 1.1 仕様にて定義される。 [HTTP11] The term resource representation is defined in the HTTP 1.1 specification. [HTTP11]

<script>, <object>, <embed>, <img>, <video>, <audio>, <source>, <track>, <link>, <applet>, <frame>, <iframe> 要素は、 HTML5 仕様にて定義される。 [HTML5] The <script>, <object>, <embed>, <img>, <video>, <audio>, <source>, <track>, <link>, <applet>, <frame> and <iframe> elements are defined in the HTML5 specification. [HTML5]

プラグイン は、 HTML5 仕様にて定義される。 [HTML5] A plugin is defined in the HTML5 specification. [HTML5]

@font-face CSS ( Cascading Style Sheets )規則は、 CSS Fonts Module Level 3 仕様にて定義される。 [CSS3FONT] The @font-face Cascading Style Sheets (CSS) rule is defined in the CSS Fonts Module Level 3 specification. [CSS3FONT]

XMLHttpRequest オブジェクトは、 XMLHttpRequest 仕様にて定義される。 [XMLHTTPREQUEST] The XMLHttpRequest object is defined in the XMLHttpRequest specification. [XMLHTTPREQUEST]

WebSocket オブジェクトは、 WebSocket 仕様にて定義される。 [WEBSOCKETS] The WebSocket object is defined in the WebSocket specification. [WEBSOCKETS]

EventSource オブジェクトは、 EventSource 仕様にて定義される。 [EVENTSOURCE] The EventSource object is defined in the EventSource specification. [EVENTSOURCE]

この文書で利用される ABNF ( Augmented Backus-Naur Form )記法は、 RFC 5234 にて指定される。 [ABNF] The Augmented Backus-Naur Form (ABNF) notation used in this document is specified in RFC 5234. [ABNF]

この文書では、 HTTP 1.1 にて定義される ABNF 拡張, “#rule” も用いる。 [HTTP11] This document also uses the ABNF extension "#rule" as defined in HTTP 1.1. [HTTP11]

次の基本規則は [ABNF Appendix B.1] による定義を参照する: ALPHA (英字), DIGIT ( 10 進数字 0-9 ), WSP (スペース/タブ), VCHAR (任意の印字可能 US-ASCII 文字) The following core rules are included by reference, as defined in [ABNF Appendix B.1]: ALPHA (letters), DIGIT (decimal 0-9), WSP (white space) and VCHAR (printing characters).

3. フレームワーク

この節では、ポリシーの送達の仕組み, および その一般構文を含む, CSP のための一般的な枠組みを定める。 この節の次の節では、この仕様が導入する個々の指令の詳細を述べる。 This section defines the general framework for content security policies, including the delivery mechanisms and general syntax for policies. The next section contains the details of the specific directives introduced in this specification.

3.1. ポリシーの送達

サーバは HTTP 応答ヘッダを通して,ポリシーを UA へ送達する。 The server delivers the policy to the user agent via an HTTP response header.

3.1.1. Content-Security-Policy ヘッダフィールド

Content-Security-Policy ヘッダフィールドが、 CSP ポリシーの送達のために選定された仕組みである。 The Content-Security-Policy header field is the preferred mechanism for delivering a CSP policy.

"Content-Security-Policy:" 1#policy

サーバは、与えられたリソース表現に伴い,名前 Content-Security-Policy の HTTP ヘッダフィールドを複数個送信してもよい A server may send more than one HTTP header field named Content-Security-Policy with a given resource representation.

サーバは、同じリソースの複数の異なる表現や, 異なるリソースごとに,異なる Content-Security-Policy ヘッダフィールド値を送信してもよい A server may send different Content-Security-Policy header field values with different representations of the same resource or with different resources.

UA は、少なくとも1個以上の Content-Security-Policy ヘッダフィールドが含まれている HTTP 応答の受信に際し,その種のヘッダフィールドの各々に含まれている,各々のポリシーを 施行 しなければならない Upon receiving an HTTP response containing at least one Content-Security-Policy header field, the user agent must enforce each of the policies contained in each such header field.

3.1.2. Content-Security-Policy-Report-Only ヘッダフィールド

Content-Security-Policy-Report-Only ヘッダフィールドは、ポリシーを UA に(施行の代わりに)監視させることにより,サーバがそのポリシーを試せるようにする。 The Content-Security-Policy-Report-Only header field lets servers experiment with policies by monitoring (rather than enforcing) a policy.

"Content-Security-Policy-Report-Only:" 1#policy

例えば,サーバ運用者にとっては、セキュリティポリシーは,反復的な開発が望まれるであろう。 運用者は、その時々のサイトのふるまいについて知り得る限りの評価に基づいて,報告のみを行うポリシーを配備させられる。 サイトがこのポリシーに違反したときは、 UA は,そのサイトを機能させなくする代わりに,ポリシーの中に指定された URI へ違反報告を送信することになる。 運用者は,そのポリシーがサイトに適切であるものと判断が付いた時点で、 Content-Security-Policy ヘッダフィールドを利用して,ポリシーの施行を開始する。 For example, a server operators might wish to develop their security policy iteratively. The operators can deploy a report-only policy based on their best estimate of how their site behaves. If their site violates this policy, instead of breaking the site, the user agent will send violation reports to a URI specified in the policy. Once a site has confidence that the policy is appropriate, they start enforcing the policy using the Content-Security-Policy header field.

サーバは、与えられたリソース表現に伴い,名前 Content-Security-Policy-Report-Only の HTTP ヘッダフィールドを複数個送信してもよい A server may send more than one HTTP header field named Content-Security-Policy-Report-Only with a given resource representation.

サーバは、同じリソースの複数の異なる表現や, 異なるリソースごとに,異なる Content-Security-Policy-Report-Only ヘッダフィールド値を送信してもよい A server may send different Content-Security-Policy-Report-Only header field values with different representations of the same resource or with different resources.

UA は、少なくとも1個以上の Content-Security-Policy-Report-Only ヘッダフィールドが含まれている HTTP 応答の受信に際し,その種のそれぞれのヘッダフィールドに含まれている,それぞれのポリシーを監視しなければならない Upon receiving an HTTP response containing at least one Content-Security-Policy-Report-Only header field, the user agent must monitor each of the policies contained in each such header field.

3.2. 構文とアルゴリズム

3.2.1. ポリシー

CSP ポリシー は U+003B SEMICOLON ( ; )区切りの,指令のリストからなる: A CSP policy consists of a U+003B SEMICOLON (;) delimited list of directives:

policy            = [ directive *( ";" [ directive ] ) ]

指令 は、 directive-name指令名), および 任意選択の directive-value指令値)からなる: Each directive consists of a directive-name and (optionally) a directive-value:

directive         = *WSP [ directive-name [ WSP directive-value ] ]
directive-name    = 1*( ALPHA / DIGIT / "-" )
directive-value   = *( WSP / <VCHAR except ";" and ","> )
3.2.1.1. ポリシーの構文解析

UA が, CSP ポリシー構文解析 するときは、次と等価なアルゴリズムが用いられなければならない To parse a CSP policy policy, the user agent must use an algorithm equivalent to the following:

  1. 指令の集合 を空集合とする。 Let the set of directives be the empty set.
  2. 文字列 ポリシー に対する 文字 U+003B SEMICOLON ( ; )による, 厳密な分割 により返されるトークンのリストの中の,空でない各トークンに対し: For each non-empty token returned by strictly splitting the string policy on the character U+003B SEMICOLON (;):

    1. ASCII 空白類を読み飛ばす Skip whitespace.
    2. ASCII 空白類 でない 文字並びの収集 を行う。 収集された文字並びが 指令名 である。 Collect a sequence of characters that are not space characters. The collected characters are the directive name.
    3. token にまだ文字が残っているならば、正確に1個の文字( ASCII 空白類 でなければならない)を読み飛ばす。 If there are characters remaining in token, skip ahead exactly one character (which must be a space character).
    4. token に残りの文字並びがあれば、それが 指令値 である。 The remaining characters in token (if any) are the directive value.
    5. 指令の集合 の中に 指令名 と同じ名前を持つ指令がすでに含まれている場合、このトークンの指令は無視して,次のトークンの処理へ移行する。 If the set of directives already contains a directive with name directive name, ignore this instance of the directive and continue to the next token.
    6. [ 名前: 指令名, 値: 指令値 ]の 指令指令の集合 に追加する。 Add a directive to the set of directives with name directive name and value directive value.
  3. 指令の集合 を返す。 Return the set of directives.

3.2.2. ソースリスト

多くの CSP 指令では ソースリスト からなる値が用いられる。 【 指令値がソースリストを表現する(すべてではない:例えば report-uri 指令はそうでない)。 】 Many CSP directives use a value consisting of a source list.

ソースリストの中のそれぞれの ソース式 は、指定された種別の内容に許容される取得先を表す。 例えば、ソース式 'self' は,同じ 生成元 に属する URI の集合を被保護リソースとして表現し、ソース式 'unsafe-inline' は,リソース自身にインラインで供される内容を表現する。 Each source expression in the source list represents a location from which content of the specified type can be retrieved. For example, the source expression 'self' represents the set of URIs which are in the same origin as the protected resource and the source expression 'unsafe-inline' represents content supplied inline in the resource itself.

source-list       = *WSP [ source-expression *( 1*WSP source-expression ) *WSP ]
                  / *WSP "'none'" *WSP
source-expression = scheme-source / host-source / keyword-source
scheme-source     = scheme ":"
host-source       = [ scheme "://" ] host [ port ]
ext-host-source   = host-source "/" *( <VCHAR except ";" and ","> )
                  ; ext-host-source is reserved for future use.
keyword-source    = "'self'" / "'unsafe-inline'" / "'unsafe-eval'"
scheme            = <scheme production from RFC 3986>
host              = "*" / [ "*." ] 1*host-char *( "." 1*host-char )
host-char         = ALPHA / DIGIT / "-"
port              = ":" ( 1*DIGIT / "*" )
3.2.2.1. ソースリストの構文解析

UA が ソースリスト構文解析 するときは、次と等価なアルゴリズムが用いられなければならない To parse a source list source list, the user agent must use an algorithm equivalent to the following:

  1. ソースリスト (の, 頭部と尾部の ASCII 空白類の並びを除去 したもの)が文字大小無視で,文字列 'none' に(引用符も含めて)合致する場合、空集合を返す。 If source list (with leading and trailing whitespace stripped) is a case insensitive match for the string 'none' (including the quotation marks), return the empty set.
  2. ソース式の集合 を空集合とする。 Let the set of source expressions be the empty set.
  3. ソースリストASCII 空白類で分割 した結果のリストに含まれる各トークンに対し、トークンが文法記号 source-expression または ext-host-source に合致するならば,そのトークンを ソース式の集合 に追加する。 For each token returned by splitting source list on spaces, if the token matches the grammar for source-expression or ext-host-source, add the token to the set of source expressions.
  4. ソース式の集合 を返す。 Return the set of source expressions.
3.2.2.2. ソース式との照合

UA が、 URI が ソース式に合致する かどうかを検査するときは,次と等価なアルゴリズムが用いられなければならない To check whether a URI matches a source expression, the user agent must use an algorithm equivalent to the following:

  1. ソース式が1個の U+002A ASTERISK 文字( * )からなる場合、 合致する を返す。 If the source expression a consists of a single U+002A ASTERISK character (*), then return does match.
  2. ソース式が文法記号 scheme-source に合致する場合: If the source expression matches the grammar for scheme-source:

    1. URI のスキームがソース式の scheme に文字大小無視で合致する場合、 合致する を返す。 If the URI's scheme is a case-insensitive match for the source expression's scheme, return does match.
    2. 他の場合、 合致しない を返す。 Otherwise, return does not match.
  3. ソース式が文法記号 host-source または ext-host-source に合致する場合: If the source expression matches the grammar for host-source or ext-host-source:

    1. URI にホストが含まれていない場合、 合致しない を返す。 If the URI does not contain a host, then return does not match.
    2. uri-scheme, uri-host, uri-port ]を,それぞれ URI の[ スキーム, ホスト, ポート ]とする。 URI にポートが含まれていない場合の uri-port は、 uri-scheme の既定ポートとする。 Let uri-scheme, uri-host, and uri-port be the scheme, host, and port of the URI, respectively. If the URI does not have a port, then let uri-port be the default port for uri-scheme.
    3. ソース式が uri-scheme に文字大小無視で合致しない scheme を持つ場合、 合致しない を返す。 If the source expression has a scheme that is not a case insensitive match for uri-scheme, then return does not match.
    4. ソース式に scheme が含まれていない, かつ uri-scheme が被保護リソースの URI のスキームに文字大小無視で合致しない場合、 合致しない を返す。 If the source expression does not have a scheme and if uri-scheme is not a case insensitive match for the scheme of the protected resource's URI, then return does not match.
    5. ソース式の host の最初の文字が U+002A ASTERISK 文字( * )であり, かつ 残りの文字(先頭の U+002E FULL STOP 文字( . )も含める)が, uri-host の最後尾の文字並びに文字大小無視で合致しない場合、 合致しない を返す。 If the first character of the source expression's host is an U+002A ASTERISK character (*) and the remaining characters, including the leading U+002E FULL STOP character (.), are not a case insensitive match for the rightmost characters of uri-host, then return does not match.
    6. 【 ❖ ソース式の host の最初の文字が U+002A ASTERISK 文字( * )でない, かつ 】 uri-host がソース式の host に文字大小無視で合致しない場合、 合致しない を返す。 If the first character of the source expression's host is not an U+002A ASTERISK character (*) and
      If uri-host is not a case insensitive match for the source expression's host, then return does not match.

      【 ❖ 2013 年 7 月 2 日現在の 編集者草案 にて加えられた修正による。 】

    7. ソース式に port が含まれていない, かつ uri-porturi-scheme の既定のポートでない場合、 合致しない を返す。 If the source expression does not contain a port and uri-port is not the default port for uri-scheme, then return does not match.
    8. ソース式に port が含まれていて,それが[ U+002A ASTERISK 文字( * )を含んでいない, かつ uri-port異なる数を表現している ]場合, 合致しない を返す。 If the source expression does contain a port that (a) does not contain an U+002A ASTERISK character (*) and (b) does not represent the same number as uri-port, then return does not match.
    9. 他の場合、 合致する を返す。 Otherwise, return does match.
  4. ソース式が(引用符も込みで)文字列 'self' に文字大小無視で合致し,かつ URI が被保護リソースの URI と同じ[ スキーム, ホスト, ポート( URI がポートを欠いている場合は,スキームの既定ポートをポートに利用する) ]を持つならば、 合致する を返す。 If the source expression is a case insensitive match for 'self' (including the quotation marks), then return does match if the URI has the same scheme, host, and port as the protected resource's URI (using the default port for the appropriate scheme if either or both URIs are missing ports).
  5. 他の場合、 合致しない を返す。 Otherwise, return does not match.

URI は、 ソースリストの構文解析 から得られたソース式の集合の中の,1個以上の ソース式に合致 するとき,そのときに限り、 ソースリストに合致 するものとする。 特に,空のソース式集合(ソースリスト 'none' を構文解析した結果など)には、どの URI も合致しないことに注意。 A URI matches a source list, if, and only if, the URI matches at least one source expression in the set of source expressions obtained by parsing the source list. Notice that no URIs match an empty set of source expressions, such as the set obtained by parsing the source list 'none'.

3.3. 処理モデル

CSP ポリシーを 施行 ( enforce )するためには、 UA は ポリシーを構文解析 して,そのポリシーに含まれている各 指令を施行しなければならない。 それぞれの指令の施行に課される固有の要件については、指令ごとに個別に定義される(後述の 指令 を見よ)。 To enforce a CSP policy, the user agent must parse the policy and enforce each of the directives contained in the policy, where the specific requirements for enforcing each directive are defined separately for each directive (See Directives, below).

一般に,指令の施行は、ソースリストが指示するもの以外の URI からのスクリプトの読み込みなど,被保護リソースにおけるある種の動作を防止する。 これらの制約より、攻撃者はリソースの特権を奪えなくなるので,リソースが孕むインジェクションの脆弱性を突き難くなる。 Generally speaking, enforcing a directive prevents the protected resource from performing certain actions, such as loading scripts from URIs other than those indicated in a source list. These restrictions make it more difficult for an attacker to abuse an injection vulnerability in the resource because the attacker will be unable to usurp the resource's privileges that have been restricted in this way.

CSP ポリシーの施行は、第三者による UA アドオンや JavaScript ブックマークレットなどの,利用者から供されているスクリプトの作用には、干渉すべきでない。 Enforcing a CSP policy should not interfere with the operation of user-supplied scripts such as third-party user-agent add-ons and JavaScript bookmarklets.

CSP ポリシーを 監視 ( monitor )するためには、 UA は ポリシーを構文解析 して,そのポリシーに含まれている各 指令を監視しなければならない To monitor a CSP policy, the user agent must parse the policy and monitor each of the directives contained in the policy.

指令の監視は、被保護リソースに対する動作を防止するものではない。 代わりに、指令により防止され得る動作を,ウェブアプリケーションの開発者に報告する。 CSP ポリシーの監視は、ポリシーが実際に施行に移されたときにも,ウェブアプリケーションが正常に機能し続けられるかどうか、試験するために役立つものである。 Monitoring a directive does not prevent the protected resource from undertaking any actions. Instead, any actions that would have been prevented by the directives are instead reported to the developer of the web application. Monitoring a CSP policy is useful for testing whether enforcing the policy will cause the web application to malfunction.

サーバは、 Content-Security-PolicyContent-Security-Policy-Report-Only の両方のヘッダフィールドを返すことにより、一方のポリシーは施行しつつ,他方のポリシーを UA に監視させてもよい。 例えば、あるポリシーを利用しているサーバ運用者がより厳格なポリシーを試したい場合、サーバ運用者は,元のポリシーを施行している間,より厳格なポリシーについては監視のみを行うことができる。 サーバ運用者は、より厳格なポリシーの下でもウェブアプリケーションが機能し続けることを確認した上で,より厳格なポリシーの施行を開始できるようになる。 【 両方のヘッダに同じポリシーが指定されていた場合でも、そのポリシーの施行と監視を並行して行い得るであろう。 】 A server may cause user agents to monitor one policy while enforcing another policy by returning both Content-Security-Policy and Content-Security-Policy-Report-Only header fields. For example, if a server operator is using one policy but wishes to experiment with a stricter policy, the server operator can monitor the stricter policy while enforcing the original policy. Once the server operator is satisfied that the stricter policy does not break the web application, the server operator can start enforcing the stricter policy.

UA は、 CSP ポリシーを監視または施行する際に,そのポリシーに指令が含まれていなかった場合、 【 UA の】 開発者のコンソールにて,警告メッセージを報告するべきである。 If the user agent monitors or enforces a CSP policy that does not contain any directives, the user agent should report a warning message in the developer console.

UA は、 CSP ポリシーを監視または施行する際に,そのポリシーに認識できない指令が含まれていた場合、開発者コンソールにて,認識できない指令の名前を示唆する警告メッセージを報告するべきである。 If the user agent monitors or enforces a CSP policy that contains an unrecognized directive, the user agent should report a warning message in the developer console indicating the name of the unrecognized directive.

UA が ワーカを走らせる 際は: [WEBWORKERS] Whenever a user agent runs a worker: [WEBWORKERS]

  • UA は, owner document 【ワーカを走らせている文書】 に対し CSP ポリシーを施行する際には、そのワーカに対しても CSP ポリシーを施行しなければならない If the user agent is enforcing a CSP policy for the owner document, the user agent must enforce the CSP policy for the worker.
  • UA は, owner document に対し CSP ポリシーを監視する際には、そのワーカに対しても CSP ポリシーを監視しなければならない If the user agent is monitoring a CSP policy for the owner document, the user agent must monitor the CSP policy for the worker.

4. 指令

この節は、この仕様で導入される CSP 指令について述べる。 This section describes the content security policy directives introduced in this specification.

XSS ( Cross-Site Scripting )から保護するためには、作者は,次を含めるべきである。 In order to protect against Cross-Site Scripting (XSS), web application authors should include

いずれの場合も、作者は XSS からの保護が望まれる場合、 'unsafe-inline' を CSP ポリシーに含めるべきでない。 In either case, authors should not include 'unsafe-inline' in their CSP policies if they wish to protect themselves against XSS.

4.1. default-src

default-src 指令は、他の数多の指令に対する,既定のソースリストを設定する。 指令の[名前, 値]の構文は、次の ABNF 文法で与えられる: The default-src directive sets a default source list for a number of directives. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "default-src"
directive-value   = source-list

以下の各 節において、 既定ソース集合 は, default-src指令値をソースリストとして構文解析 した結果とする。 Let the default sources be the result of parsing the directive's value as a source list.

default-src 指令を施行するためには、 UA は,次の指令を施行しなければならない To enforce the default-src directive, the user agent must enforce the following directives:

  • script-src
  • object-src
  • style-src
  • img-src
  • media-src
  • frame-src
  • font-src
  • connect-src

上に挙げられた指令がポリシーの中に明示的に指定されていない場合、その指令には 既定ソース集合 が用いられることになる。 If not specified explicitly in the policy, the directives listed above will use the default sources.

【 記述を集約するため、この訳では,次の2つの非公式な用語を定義する: 】

上に挙げられた,各指令に対し、その 許容ソース集合 とは,その指令名がポリシーの中に明示的に含まれて[ いるならば,その指令値ソースリストとして構文解析した結果 / いないならば 既定ソース集合 ]とする。

【 ポリシーの中に 当該の指令と default-src 指令の両者とも指定されていない場合の許容ソース集合は,未定義になるが、その場合には,その指令を施行/監視することはない(そのように規定されている)ものと見られる。 】【 default-src 指令が明示的に指定されている/いない場合のふるまいの差異については、 7 節にも述べられている。 】

UA が与えられた(リソース取得が生じ得るような) 活動 を,与えられた 許容ソース集合制約する とは、その活動に伴って,リソースの URI に(リダイレクトの追従も含め) 取得をかける際に, URI が許容ソース集合 に合致しない場合には、空の HTTP 400 応答 【 Bad Request 】 が受信されたかのように,動作することを意味する。

4.2. script-src

script-src 指令は、被保護リソースが実行し得るスクリプトを制約する。 この指令は、 XSLT スタイルシート [XSLT] など, UA にスクリプトを実行させ得る他のリソースも、制御する。 指令の[名前, 値]の構文は、次の ABNF 文法で与えられる: The script-src directive restricts which scripts the protected resource can execute. The directive also controls other resources, such as XSLT style sheets [XSLT], which can cause the user agent to execute script. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "script-src"
directive-value   = source-list

許容 script ソース集合 を, script-src 指令に対する許容ソース集合とする。 If the policy contains an explicit script-src, let the allowed script sources be the result of parsing the directive's value as a source list. Otherwise, let the allowed script sources be the default sources

'unsafe-inline'許容 script ソース集合 の中に含まれていない場合、 UA は: If 'unsafe-inline' is not in allowed script sources:

  • インラインスクリプトを実行してはならないscript 要素によるものも, インラインのイベントハンドラによるものも,いずれも)。 Whenever the user agent would execute an inline script (either from a script element or from an inline event handler), instead the user agent must not execute script.
  • javascript URI に含まれるスクリプトを,実行してはならない。 ( UA は、この制約の施行の下でも, “ブックマークレット” に含まれてるスクリプトについては、実行するべきである。) Whenever the user agent would execute script contained in a javascript URI, instead the user agent must not execute the script. (The user agent should execute script contained in "bookmarklets" even when enforcing this restriction.)

'unsafe-eval'許容 script ソース集合 の中に含まれていない場合、 UA は: If 'unsafe-eval' is not in allowed script sources:

  • eval 演算子, eval 関数のいずれについても、それらの引数を評価せずに,セキュリティ例外を投出しなければならない[ECMA-262] Instead of evaluating their arguments, both operator eval and function eval must throw a security exception. [ECMA-262]
  • Function 関数が構築子として呼び出された際は、セキュリティ例外を投出しなければならない[ECMA-262] When called as a constructor, the function Function must throw a security exception. [ECMA-262]
  • setTimeoutsetInterval 関数が, callable でない(例えば関数でない)第一引数を伴って呼び出された際には、タイマーを作成せずに,ゼロを返さなければならない When called with a first argument that is non-callable (e.g., not a function), the setTimeout function must return zero without creating a timer. When called with a first argument that is non-callable (e.g., not a function), the setInterval function must return zero without creating a timer.

    callable とは、 Web IDL 仕様にて定義される,1個以上の caller を持つインタフェースのオブジェクトを指す。 [WEBIDL] 【 Web IDL の当該部分へのリンク先は存在しない。 実質的には ECMAScript 言語仕様にて 定義される 。 】 The term callable refers to an object whose interface has one or more callers as defined in the Web IDL specification [WEBIDL].

UA は、次の活動を, 許容 script ソース集合制約しなければならない Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed script sources, the user agent must act as if it had received an empty HTTP 400 response:

  • script 要素の src 属性 ]/[ WorkerSharedWorker の構築子 ]の処理などに起因する、スクリプトのリクエスト。 Requesting a script, such as when processing the src attribute of a script element or when processing the Worker or SharedWorker constructors.
  • [ XML 文書 [XML11] の中の <?xml-stylesheet?> 処理命令 ]/[ <xsl:include> 要素の href 属性 ]/[ <xsl:import> 要素の href 属性 ]の処理などに起因する、 XSLT ( Extensible Stylesheet Language Transformations ) [XSLT] のリクエスト。 Requesting an Extensible Stylesheet Language Transformations (XSLT) [XSLT], such as when processing the <?xml-stylesheet?> processing directive in an XML document [XML11], the href attributes on <xsl:include> element, or the href attributes on <xsl:import> element.

4.3. object-src

object-src 指令は、被保護リソースが読み込み得るプラグインの読み込み先を制約する。 指令の[名前, 値]の構文は、次の ABNF 文法で与えられる: The object-src directive restricts from where the protected resource can load plugins. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "object-src"
directive-value   = source-list

許容 object ソース集合 を, object-src 指令に対する許容ソース集合とする。 If the policy contains an explicit object-src, let the allowed object sources be the result of parsing the directive's value as a source list. Otherwise, let the allowed object sources be the default sources

UA は、次の活動を, 許容 object ソース集合制約しなければならない Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed object sources, the user agent must act as if it had received an empty HTTP 400 response:

  • object 要素の data 属性 ]/[ embed 要素の src 属性 ]/[ applet 要素の code および archive 属性 ]の処理などに起因する、プラグインのためのデータのリクエスト。 Requesting data for a plugin, such as when processing the data attribute of an object element, the src attribute of an embed elements, or the code or archive attributes of an applet element.
  • objectembed 要素により作成される,被保護リソース内に 入れ子にされている閲覧文脈 に表示するためのデータのリクエスト。 Requesting data for display in a nested browsing context in the protected resource created by an object or an embed element.
  • その種の 入れ子にされている閲覧文脈 におけるページ遷移。 Navigating such a nested browsing context.

object-src 指令の施行においては、要素データの消費側は,プラグインに限られない。 object, embed, applet 要素のためのデータが取得されるためには、 許容 object ソース集合 に合致しなければならない。 このことは、さもなければ[ 要素データが、 MIME 型 text/htmlobject 要素など,他のいずれかの 指令 により制約されることになる内容と,意味論的に等価になる ]場合でも、成立する。 It is not required that the consumer of the element's data be a plugin in order for the object-src directive to be enforced. Data for any object, embed, or applet element must match the allowed object sources in order to be fetched. This is true even when the element data is semantically equivalent to content which would otherwise be restricted by one of the other directives, such as an object element with a text/html MIME type.

URI が結び付けられていないプラグイン(例えば, data 属性を欠いている object 要素)に対しては、被保護リソースの URI が 許容 object ソース集合 に合致 しないならば, UA はそのプラグインを読み込んではならない Whenever the user agent would load a plugin without an associated URI (e.g., because the object element lacked a data attribute), if the protected resource's URI does not match the allowed object sources, the user agent must not load the plugin.

4.4. style-src

style-src 指令は、利用者が被保護リソースに適用し得るスタイルを制約する。 指令の[名前, 値]の構文は、次の ABNF 文法で与えられる: The style-src directive restricts which styles the user applies to the protected resource. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "style-src"
directive-value   = source-list

許容 style ソース集合 を, style-src 指令に対する許容ソース集合とする。 If the policy contains an explicit style-src, let the allowed style sources be the result of parsing the directive's value as a source list. Otherwise, let the allowed style sources be the default sources

'unsafe-inline'許容 style ソース集合 の中に含まれていない場合: If 'unsafe-inline' is not in allowed style sources:

  • UA は、 style 要素によるスタイルを適用してはならない Whenever the user agent would apply style from a style element, instead the user agent must ignore the style.
  • style 属性によるスタイルを適用してはならない Whenever the user agent would apply style from a style attribute, instead the user agent must ignore the style.

注記: インラインに対するこれらの制約は、 UA における(例えば、 <link rel="stylesheet"> を通した)外部スタイルシートによるスタイルの適用を防止するものではない。 また、 CSSOM ( Cascading Style Sheets Object Model ) [CSSOM] によるスタイルの適用を防止するものでもない。 Note: These restrictions on inline do not prevent the user agent from applying style from an external stylesheet (e.g., found via <link rel="stylesheet">). The user agent is also not prevented from applying style from Cascading Style Sheets Object Model (CSSOM). [CSSOM]

UA は、次の活動を, 許容 style ソース集合制約しなければならない Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed style sources, the user agent must act as if it had received an empty HTTP 400 response:

  • [[[ stylesheet トークンを含んだ rel 属性 ]を伴う link 要素 ]の href 属性 ]/[ スタイルシート内の @import 指令 ]の処理などに起因する、外部スタイルシートのリクエスト。 Requesting external style sheets, such as when processing the href attribute of a link element with a rel attribute containing the token stylesheet or when processing the @import directive in a stylesheet.

注記: style-src 指令は、 XSLT の利用を制約するものではない。 XSLT は、信用できない XSLT スタイルシートが含まれることによるセキュリティ上の影響が,信用できないスクリプトが含まれることによる影響と類似する理由で、 script-src 指令により制約される。 Note: The style-src directive does not restrict the use of XSLT. XSLT is restricted by the script-src directive because the security consequences of including an untrusted XSLT stylesheet are similar to those incurred by including an untrusted script.

4.5. img-src

img-src 指令は、被保護リソースにおける画像の読み込み先を制約する。 指令の[名前, 値]の構文は、次の ABNF 文法で与えられる: The img-src directive restricts from where the protected resource can load images. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "img-src"
directive-value   = source-list

許容 img ソース集合 を, img-src 指令に対する許容ソース集合とする。 If the policy contains an explicit img-src, let the allowed image sources be the result of parsing the directive's value as a source list. Otherwise, let the allowed image sources be the default sources

UA は、次の活動を, 許容 image ソース集合制約しなければならない Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed image sources, the user agent must act as if it had received an empty HTTP 400 response:

  • img 要素のsrc 属性 ]/[ url()image() 値など,画像を読み込み得る CSS プロパティ [CSS3-Images] ]/[[[ icon などの画像関連の rel 属性 ]を伴う link 要素 ]の href 属性 ]の処理などに起因する、画像データのリクエスト。 Requesting data for an image, such as when processing the src attribute of an img elements, the url() or image() values on any Cascading Style Sheets (CSS) property that is capable of loading an image [CSS3-Images], or the href attribute of a link element with an image-related rel attribute, such as icon.

4.6. media-src

media-src 指令は、被保護リソースにおける,動画と音声の読み込み先を制約する。 指令の[名前, 値]の構文は、次の ABNF 文法で与えられる: The media-src directive restricts from where the protected resource can load video and audio. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "media-src"
directive-value   = source-list

許容 media ソース集合 を, media-src 指令に対する許容ソース集合とする。 If the policy contains an explicit media-src, let the allowed media sources be the result of parsing the directive's value as a source list. Otherwise, let the allowed media sources be the default sources

UA は、次の活動を, 許容 media ソース集合制約しなければならない Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed media sources, the user agent must act as if it had received an empty HTTP 400 response:

  • video, audio, source, track 要素の src 属性の処理などに起因する、動画や音声クリップのデータのリクエスト。 Requesting data for a video or audio clip, such as when processing the src attribute of a video, audio, source, or track elements.

4.7. frame-src

frame-src 指令は、被保護リソースに埋め込まれるフレームの読み込み先を制約する。 指令の[名前, 値]の構文は、次の ABNF 文法で与えられる: The frame-src directive restricts from where the protected resource can embed frames. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "frame-src"
directive-value   = source-list

許容 frame ソース集合 を, frame-src 指令に対する許容ソース集合とする。 If the policy contains an explicit frame-src, let the allowed frame sources be the result of parsing the directive's value as a source list. Otherwise, let the allowed frame sources be the default sources

UA は、次の活動を, 許容 frame ソース集合制約しなければならない Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed frame sources, the user agent must act as if it had received an empty HTTP 400 response:

4.8. font-src

font-src 指令は、被保護リソースにおけるフォントの読み込み先を制約する。 指令の[名前, 値]の構文は、次の ABNF 文法で与えられる: The font-src directive restricts from where the protected resource can load fonts. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "font-src"
directive-value   = source-list

許容 font ソース集合 を, font-src 指令に対する許容ソース集合とする。 If the policy contains an explicit font-src, let the allowed font sources be the result of parsing the directive's value as a source list. Otherwise, let the allowed font sources be the default sources

UA は、次の活動を, 許容 font ソース集合制約しなければならない Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed font sources, the user agent must act as if it had received an empty HTTP 400 response:

  • CSS の @font-face 規則の処理などに起因する,フォントを表示するためのデータのリクエスト。 Requesting data for display in a font, such as when processing the @font-face Cascading Style Sheets (CSS) rule.

4.9. connect-src

connect-src 指令は、被保護リソースにおいて,スクリプトインタフェースを利用して読み込み得る URI を制約する。 指令の[名前, 値]の構文は、次の ABNF 文法で与えられる: The connect-src directive restricts which URIs the protected resource can load using script interfaces. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "connect-src"
directive-value   = source-list

許容 接続先集合 を, connect-src 指令に対する許容ソース集合とする。 If the policy contains an explicit connect-src, let the allowed connection targets be the result of parsing the directive's value as a source list. Otherwise, let the allowed connection targets be the default sources

UA は、次の活動を, 許容 接続先集合制約しなければならない【 原文誤記: allowed font sources → allowed connection targets 】 Whenever the user agent fetches a URI (including when following redirects) in the course of one of the following activities, if the URI does not match the allowed font sources, the user agent must act as if it had received an empty HTTP 400 response:

4.10. sandbox (任意選択)

sandbox 指令のサポートは 【 UA 側の】 任意選択である。 The sandbox directive is optional.

sandbox 指令は、 UA が被保護リソースに適用する HTML sandboxポリシーを指定する。 指令の[名前, 値]の構文は、次の ABNF 文法で与えられる: The sandbox directive specifies an HTML sandbox policy that the user agent applies to the protected resource. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "sandbox"
directive-value   = token *( 1*WSP token )
token             = <token from RFC 2616>

sandbox 指令の施行においては、 sandbox 指令をサポートする UA は, directive-value入力として, sandbox 指令を構文解析 して、その出力として,被保護リソースの sandbox 化 強制フラグをセット しなければならない[HTML5] When enforcing the sandbox directive, a user agent that supports the sandbox directive must parse the sandboxing directive using the directive-value as the input and protected resource's forced sandboxing flag set as the output. [HTML5]

4.11. report-uri

report-uri 指令は、 UA がポリシー違反について報告する際の送信先を指定する。 指令の[名前, 値]の構文は、次の ABNF 文法で与えられる: The report-uri directive specifies a URI to which the user agent sends reports about policy violation. The syntax for the name and value of the directive are described by the following ABNF grammar:

directive-name    = "report-uri"
directive-value   = uri-reference *( 1*WSP uri-reference )
uri-reference     = <URI-reference from RFC 3986>

報告先 URI 集合 を、 report-uri 指令の値 【を上の ABNF に従って構文解析して得られる URI の集合】 とする。 ただし、それぞれの相対 URI は,被保護リソースの URI に相対的に解決されているものとする。 Let the set of report URIs be the value of the report-uri directive, each resolved relative to the protected resource's URI.

UA は、 違反報告を送信 する際に,次と等価なアルゴリズムを用いなければならない To send a violation report, the user agent must use an algorithm equivalent to the following:

  1. 次のキーと値を持つ JSON オブジェクト [RFC4627] 違反オブジェクト を用意する 【具体例は 5.2 節に】 Prepare a JSON object violation-object with the following keys and values: [RFC4627]

    csp-report

    次のキーと値を持つ JSON オブジェクト: A JSON object containing the following keys and values:

    document-uri
    被保護リソースの アドレス 。 ただし, <fragment> 成分は除去しておく。 The address of the protected resource, with any <fragment> component removed
    referrer
    被保護リソースの referrer 属性 The referrer attribute of the protected resource
    blocked-uri
    ポリシー違反により読み込みが防止されたリソースの URI。 ただし, <fragment> 成分は除去しておく。 URI of the resource that was prevented from loading due to the policy violation, with any <fragment> component removed
    violated-directive
    違反されたポリシー指令。 The policy directive that was violated
    original-policy
    UA に受信された元々のポリシー。 The original policy as received by the user-agent.
  2. blocked-uri の生成元が被保護リソースの生成元と同じでない場合、 blocked-uriblocked-uri の生成元の ASCII 直列化に置換する。 If the origin of the blocked-uri is not the same as the origin of the protected resource, then replace the blocked-uri with the ASCII serialization of the blocked-uri's origin.
  3. 違反報告違反オブジェクト の JSON 文字列化とする。 Let the violation report be the JSON stringification of the violation-object.
  4. 報告先 URI 集合 の中の各 報告先 URI に対し: For each report URI in the set of report URIs:

    1. 被保護リソースの生成元から 報告先 URI に向けて、同期フラグはクリアした下で, HTTP POST メソッドを用いて 取得をかける。 その際の HTTP リクエストの Content-Type ヘッダフィールドは application/json とし, エンティティボディは 違反報告 からなるものとする。 また、このリソース取得の際に, UA はリダイレクトに追従してはならない。 (注記: UA は、このリクエストにより取得されたリソースを無視する。) Fetch the report URI from origin of the protected resource, with the synchronous flag not set, using HTTP method POST, with a Content-Type header field of application/json with an entity body consisting of the violation report. The user agent must not follow redirects when fetching this resource. (Note: The user agent ignores the fetched resource.)

5. 例

5.1. ポリシー定義の見本

この節は参考である。 This section is non-normative.

この節では、セキュリティポリシーに付随する,いくつかのユースケースを取り挙げる。 This section provides some sample use cases and accompanying security policies.

例1: サーバがリソースの読み込み先を自身の生成元のみに限定する: Example 1: A server wishes to load resources only form its own origin:

Content-Security-Policy: default-src 'self'

例2: (オークションサイト) リソースの読み込み先を、[ 画像は任意の URI から / プラグイン内容は(コンテンツ配信ネットワークも含め)信用できるメディアプロバイダのリストに含まれるもののみ / スクリプトはサイトの制御下にあり,無害化( sanitize )された ECMAScript をホストしているサーバからのみ ]に限定する: Example 2: An auction site wishes to load images from any URI, plugin content from a list of trusted media providers (including a content distribution network), and scripts only from a server under its control hosting sanitized ECMAScript:

Content-Security-Policy: default-src 'self'; img-src *;
                         object-src media1.example.com media2.example.com *.cdn.example.com;
                         script-src trustedscripts.example.com

例3: (オンライン銀行サイト) 攻撃者によるセキュアでない内容リクエストの盗聴を防止する目的で、ページのすべての内容が TLS を通して読み込まれることを確保する: Example 3: Online banking site wishes to ensure that all of the content in its pages is loaded over TLS to prevent attackers from eavesdropping on insecure content requests:

Content-Security-Policy: default-src https: 'unsafe-inline' 'unsafe-eval'

このポリシーは、[ インライン内容(インライン script 要素など) / eval の利用 / https を通したリソースの読み込み ]を許容する。 注記: このポリシーは、 XSS の脆弱性に対する保護を提供するものではない。 This policy allows inline content (such as inline script elements), use of eval, and loading resources over https. Note: This policy does not provide any protection from cross-site scripting vulnerabilities.

例4: (ソーシャルネットワーク) 利用者により生成される内容が,スクリプトとして解釈されてしまうことを防止する目的で、すべてのスクリプトの読み込み先を特定のパスに限定する: Example 4: A social network wishes to ensure that all scripts are loaded from a specific path to prevent user-generated content from being interpreted as script:

Content-Security-Policy: default-src 'self'; script-src https://example.com/js/

残念ながら、このユースケースは, CSP 1.0 ではサポートされない。 UA は,パスを無視して、ポリシーの script-src 指令の値が https://example.com を持っているかのように動作することになる。 しかしながら,将来バージョンの CSP ではこれらのパス制約による施行のサポートが見込まれている。 【現時点での CSP 1.1 仕様 ではサポートされている模様( “Path Matching” )。】 Unfortunately, this use case is not supported in CSP 1.0. The user agent will ignore the path and act as if the policy contained a script-src directive with value https://example.com. A future version of CSP might begin enforcing these path restrictions, however.

5.2. 違反報告の例

この節は参考である。 This section is non-normative.

この節では、ポリシーの見本を与えて、被保護リソースに対する違反が生じた際に, UA がサーバに送信し得る違反報告の例を挙げる。 This section contains an example violation report the user agent might sent to a server when the protected resource violations a sample policy.

UA は、次の CSP ポリシーが伴われた,リソース http://example.org/page.html の表現を処理して出力しているとする: In the following example, the user agent rendered a representation of the resource http://example.org/page.html with the following CSP policy:

default-src 'self'; report-uri http://example.org/csp-report.cgi

被保護リソースにおける, http://evil.example.com/image.png からの画像の読み込みは、ポリシー違反になる。 その場合の違反報告は、次の様になる: The protected resource loaded an image from http://evil.example.com/image.png, violating the policy.

{
  "csp-report": {
    "document-uri": "http://example.org/page.html",
    "referrer": "http://evil.example.com/haxor.html",
    "blocked-uri": "http://evil.example.com/image.png",
    "violated-directive": "default-src 'self'",
    "original-policy": "default-src 'self'; report-uri http://example.org/csp-report.cgi"
  }
}

6. セキュリティ上の考慮点

6.1. CSS の構文解析

style-src 指令は、被保護リソースが読み込み得るスタイルの読み込み先を制約する。 しかしながら、 UA の CSS 構文解析アルゴリズムが緩い場合、攻撃者は, UA を騙して,信用できない生成元でホストされている悪意のある “スタイルシート” を受け入れさせることが可能になる。 The style-src directive restricts the locations from which the protected resource can load styles. However, if the user agent uses a lax CSS parsing algorithm, an attacker might be able to trick the user agent into accepting malicious "style sheets" hosted by an otherwise trustworthy origin.

これらの攻撃は、2009 年に Chris Evans により示された CSS cross-origin data leakage ( CSS クロス生成元データ漏洩)攻撃に類似するものである。 UA は、不正な MIME 型のスタイルシートに対し,より厳格な CSS 構文解析規則を適用して、同様の仕組みを利用する攻撃に対し,防御策を講じるべきである。 These attacks are similar to the CSS cross-origin data leakage attack described by Chris Evans in 2009. User agents should defend against both attacks using the same mechanism: stricter CSS parsing rules for style sheets with improper MIME types.

6.2. 違反報告

この文書による違反報告の仕組みは、悪意のあるウェブサイトが,違反報告の機能を悪用して他のサーバのふるまいを調査するリスクを、緩和するように設計されている。 例えば、画像の読み込み先として https://example.com をホワイトリストに入れている,悪意のあるウェブサイトを考える。 そのサイトが https://example.com/login を画像として読み込もうとした場合【†】example.com サーバは,そのリクエストを identity プロバイダ 【††】 (例えば, idenityprovider.example.net とする)にリダイレクトし, CSP により,そのリクエストは阻止されることになる。 もし完全な形の阻止された URL が違反報告に含まれてしまった場合、その内容にはセッション識別子や purported identities 【†††】 などの,リダイレクト先の URI に含まれ得る,取り扱いに注意を要する情報も含まれてしまうことになる。 この理由から、 UA は,阻止された URI の生成元のみを含めるものとする,と規定されている。 The violation reporting mechanism in this document has been designed to mitigate the risk that a malicious web site could use violation reports to probe the behavior of other servers. For example, consider a malicious web site that white lists https://example.com as a source of images. If the malicious site attempts to load https://example.com/login as an image, and the example.com server redirects to an identity provider (e.g., idenityprovider.example.net), CSP will block the request. If violation reports contained the full blocked URL, the violation report might contain sensitive information contained in the redirected URI, such as session identifiers or purported identities. For this reason, the user agent includes only the origin of the blocked URI.

【† — すなわち,そのサイトのページが、(意図的に)実際は画像ではない, 標的サイトの個人識別ログインページを指しているリンクを,ページ内の画像の URL に設定していた場合、(大抵の場合, UA (ブラウザ)は画像については,(受動的なリソースであり,セキュリティ上のリスクが小さいと見なされているため)ページ内に表示するために自動的に読み込みを試みるように設定されているので)利用者がそのページを閲覧しただけで,そのログインページへのアクセスが生じる。】

【†† “identity provider”— IdP とも略称される,個人認証サービスを専門に提供するプロバイダを指すものと見られる。】

【††† “purported identities” — 個人識別情報?(個人は特定しないまま,異なる個人を別人として識別するための情報/当該サイト専用の識別情報?)】

7. 実装における考慮点

Content-Security-Policy ヘッダは、エンドツーエンドヘッダである。 それはクライアントにより処理, および施行されるものであり、リソースと同じ管理ドメインに属さないプロキシや他の中継点から,変更が加えられたり, 除去されるべきでない。 The Content-Security-Policy header is an end-to-end header. It is processed and enforced at the client and, therefore, should not be modified or removed by proxies or other intermediaries not in the same administrative domain as the resource.

リソースの大元の管理ドメインにとっては、 Content-Security-Policy ヘッダが,アプリケーションの直接的な実行文脈( immediate context )の外側で適用されることも望まれるであろう。 例えば,巨大な組織は、異なる個人やチームが管理している,多数のリソースとアプリケーションを持ち,それらすべてが統一的な組織標準の対象になり得る。 その種の状況においては、 Content-Security-Policy ヘッダを,既存のネットワークに接するセキュリティゲートウェイ機器やウェブアプリケーション ファイアウォールに追加, あるいは組み合せて用い得る。 複数のポリシーを施行するためには、管理者は,ポリシーを単独のヘッダ内に結合するべきである。 管理者にとっては、必要な意味論に応じて,異なるポリシー組み合せの方法論も望まれ得る。 The originating administrative domain for a resource might wish to apply a Content-Security-Policy header outside of the immediate context of an application. For example, a large organization might have many resources and applications managed by different individuals or teams but all subject to a uniform organizational standard. In such situations, a Content-Security-Policy header might be added or combined with an existing one at a network-edge security gateway device or web application firewall. To enforce multiple policies, the administrator should combine the policy into a single header. An administrator might wish to use different combination algorithms depending on his or her intended semantics.

ポリシー組み合せの方法論として,まず挙げられるのは、最初に,既定で許容されるソースの集合を与える所から始め、しかる後,追加の生成元を含めていくことにより、個別のアップストリームリソース所有者たちとして許容されるソース集合を徐々に拡大していくことである。 このアプローチによる結果のポリシーは、入力ポリシーの中で許容されるすべての生成元の和集合になる。 One sensible policy combination algorithm is to start by allowing a default set of sources and then letting individual upstream resource owners expand the set of allowed sources by including additional origins. In this approach, the resultant policy is the union of all allowed origins in the input policies.

別の方法論としては、与えられたポリシーを次第に制約していくことが考えられる。 このアプローチでは、最初に,一定の生成元のホワイトリストからの内容の施行を義務付ける所から始める。 例えば,サードパーティによるスクリプトや内容は、組織標準とその実施に違反するものとして,あらかじめ除外するなど。 このアプローチでは、アップストリームリソース所有者から供されるポリシーから,許容されないホストを漸次取り除いていくことにより、ポリシーの組み合せが形成されていく。 Another sensible policy combination algorithm is to intersect the given policies. This approach enforces that content comes from a certain whitelist of origins, for example, preventing developers from including third-party scripts or content in violation of organizational standards and practices. In this approach, the combination algorithm forms the combined policy by removing disallowed hosts from the policies supplied by upstream resource owners.

default-src と他の指令との間の相互作用は、ポリシーを組み合せる際に特別に考慮されるべきである。 どのポリシーにも default-src 指令が含まれていない場合、新たな “…-src” 指令の追加による結果は,より制約的なポリシーになる。 しかしながら、1個以上の入力ポリシーに default-src 指令が含まれている場合、新たな “…-src” 指令の追加により,ポリシーが緩められ得る。 例えば、より固有性の高い default-src でない】 指令が, default-src より寛容な許容生成元の集合を含む場合が挙げられる。 Interactions between the default-src and other directives should be given special consideration when combining policies. If none of the policies contains a default-src directive, adding new src directives results in a more restrictive policy. However, if one or more of the input policies contain a default-src directive, adding new src directives might result in a less restrictive policy, for example, if the more specific directive contains a more permissive set of allowed origins.

【 例えば、 default-src 指令の値に 'none' を与えた下では、他の “…-src” 指令を,その既定を 'none' にした上で 全て施行/監視させることになるので,最も厳しい制約になり、したがって 他の指令の設定は純粋に制約の緩和になる。 一方で, default-src を与えない(あるいは '*' を与えた)下では(すなわち,最も緩い)、他の指令の設定は純粋に制約の追加になる。 】

リソース所有者たちが著作した入力ポリシーよりも制約的なポリシーの利用は、想定以上にリソースの出力や作用を抑制し得る。 Using a more restrictive policy than the input policy authored by the resource owner might prevent the resource from rendering or operating as intended.

8. IANA Considerations

恒久的メッセージヘッダフィールド レジストリ( [RFC3864] を参照)は、次の登録により更新されるべきである: The permanent message header field registry (see [RFC3864]) should be updated with the following registrations:

8.1. Content-Security-Policy

ヘッダフィールド名: Content-Security-Policy Header field name: Content-Security-Policy

適用プロトコル: http Applicable protocol: http

位置付け:標準 Status: standard

作成者/変更管理者: W3C Author/Change controller: W3C

仕様文書:この仕様( Content-Security-Policy ヘッダフィールド を参照) Specification document: this specification (See Content-Security-Policy Header Field)

8.2. Content-Security-Policy-Report-Only

ヘッダフィールド名: Content-Security-Policy-Report-Only Header field name: Content-Security-Policy-Report-Only

適用プロトコル: http Applicable protocol: http

位置付け:標準 Status: standard

作成者/変更管理者: W3C Author/Change controller: W3C

仕様文書:この仕様( Content-Security-Policy-Report-Only ヘッダフィールド を参照) Specification document: this specification (See Content-Security-Policy-Report-Only Header Field)

A. 参照文献

A.1. 参照文献(規範)

[ABNF]
D. Crocker and P. Overell. Augmented BNF for Syntax Specifications: ABNF. January 2008. Internet RFC 5234.
[CSS3FONT]
Michel Suignard; Chris Lilley. CSS3 module: Fonts. 2 August 2002. W3C Working Draft. (Work in progress.)
[CSSOM]
Glenn Adams; Shane Stephens. CSS Object Model (CSSOM). 14 March 2012. W3C Working Draft. (Work in progress.)
[ECMA-262]
ECMAScript Language Specification. June 2011.
[EVENTSOURCE]
Ian Hickson. Server-Sent Events. 26 April 2012. W3C Working Draft. (Work in progress.)
[HTML5]
Ian Hickson; David Hyatt. HTML5. 29 March 2012. W3C Working Draft. (Work in progress.)
[HTTP11]
R. Fielding; et al. Hypertext Transfer Protocol - HTTP/1.1. June 1999. Internet RFC 2616.
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Internet RFC 2119.
[RFC4627]
D. Crockford. The application/json Media Type for JavaScript Object Notation (JSON) July 2006. Internet RFC 4627.
[RFC6454]
A. Barth. The Web Origin Concept. December 2011. Internet RFC 6454.
[URI]
T. Berners-Lee; R. Fielding; L. Masinter. Uniform Resource Identifiers (URI): generic syntax. January 2005. Internet RFC 3986.
[WEBIDL]
Cameron McCormack. Web IDL. 27 September 2011. W3C Working Draft. (Work in progress.)
[WEBSOCKETS]
Ian Hickson. The WebSocket API. 24 May 2012. W3C Working Draft. (Work in progress.)
[WEBWORKERS]
Ian Hickson. Web Workers. 1 September 2011. W3C Working Draft. (Work in progress.)
[XML11]
Eve Maler; et al. Extensible Markup Language (XML) 1.1 (Second Edition). 16 August 2006. W3C Recommendation.
[XMLHTTPREQUEST]
Anne van Kesteren. The XMLHttpRequest Object. 15 April 2008. W3C Working Draft. (Work in progress.)
[XSLT]
James Clark. XSL Transformations (XSLT) Version 1.0. 16 November 1999. W3C Recommendation.