Content Security Policy （日本語訳）

◎要約

この文書は、［ ~web資源に対する内容~制約の集合を宣言する］ために利用される施策~言語, および施策が施行される所にて［ ~serverから~clientへ施策を伝送する仕組み］を定義する。 ◎ 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.

【現行の仕様は，~level 3 であり、この~level 2 仕様は，実質的に歴史的な参照である（他のほとんどの仕様からは，もはや参照されていない）。】

1. 序論

◎非規範的

この文書は、［ XSS（ cross-site scripting ）などの，内容~注入の脆弱性（ content injection vulnerabilities ）の広範な~classを軽減する］ために~web~appが利用できる CSP （ Content Security Policy — 内容~security施策）と呼ばれる仕組みを定義する。 ~CSPは、［ ~web~appの作者（または~server管理者）が，［ ~app【の~client側~部分】が，資源をどこの~sourceから読込む］ものと期待しているかについて，~clientに伝える］ための，宣言的な施策である。 ◎ 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 about the sources from which the application expects to load resources.

~web~appは、~XSS攻撃を軽減するために，例えば［ ~clientは、特定の信用された~sourceからのみ，~scriptを読込む］ものと期待することを宣言できる。この宣言により、~clientは，［攻撃者により~appの中へ注入された悪意的~script ］を検出して阻止することが可能になる。 ◎ To mitigate XSS attacks, for example, a web application can declare that it only expects to load script from specific, trusted sources. This declaration allows the client to detect and block malicious scripts injected into the application by an attacker.

~CSPは、［内容~注入の脆弱性に抗する前線防御］として意図されたものではなく、［内容~注入~攻撃による被害を抑制するための多層防御］としての利用に最も適する。【すなわち、注入そのものを防ぐのでなく，注入されたものが動作するのを防ぐ。】内容~注入に抗する前線防御としては、~server運用者は、【外部からの】入力を検証して, 【~client向けの】出力を【安全な形に】符号化するべきである。 ◎ 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. As a first line of defense against content injection, server operators should validate their input and encode their output.

~CSPを既存の~web~appに適用するためには、自明でない量の作業を要することが多い。最大限に便益を享受するためには、作者は，すべての ~inline［ ~script／~style ］を~out-of-lineに — 例えば，外部~scriptへ — 移動する必要がある。 ~UAは、［ ~inline~scriptが攻撃者により注入されたものであるかどうか］を決定する術がないので。 ◎ 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の利点を得るためには、~web~appは `Content-Security-Policy^h ~HTTP~headerを給することにより，~CSPの利用を採択する。そのような施策が適用されるのは、現在の`資源~表現$に限られる。施策を~site全体に渡って給するためには、~serverは，それぞれの資源~表現に施策を伴わせて給する必要がある。 ◎ To take advantage of CSP, a web application opts into using CSP by supplying a Content-Security-Policy HTTP header. Such policies apply to the current resource representation only. To supply a policy for an entire site, the server needs to supply a policy with each resource representation.

1.1. Level 1 からの変更点

この文書は、 `~CSP仕様＠~TR/CSP/$ の発展について述べる。 Level 2 には Level 1 から次の二つの変更が加えられ、下に要約される，いくつもの新たな指令と能力~用の~supportを追加した： ◎ This document describes an evolution of the Content Security Policy specification. Level 2 makes two breaking changes from Level 1, and adds support for a number of new directives and capabilities which are summarized below:

次の変更点は、［大多数の~UAによる CSP 1 実装］と後方-互換でない： ◎ The following changes are backwards incompatible with the majority of user agent’s implementations of CSP 1:
1. ~source式の~path成分は、今や，［読込まれている資源が~redirectの結果である場合］には，無視される（`~pathと~redirect$sec）。 ◎ The path component of a source expression is now ignored if the resource being loaded is the result of a redirect, as described in §4.2.2.3 Paths and Redirects.
  
  注記： ~pathは、形上では CSP2 の新たな~~機能だが、［ ~CSPのこの改訂が完了する］前に，多くの~UAにて既に実装されている — なので、ここに挙げるまでもない変更に見えるであろう。 ◎ Note: Paths are technically new in CSP2, but they were already implemented in many user agents before this revision of CSP was completed, so noting the change here seems reasonable.
2. `保護される資源$の~worker を読込む能は、今や， `script-src$dir ではなく `child-src$dir を介して制御される。 ◎ A protected resource’s ability to load Workers is now controlled via child-src rather than script-src.
3. ~workerは、今や，それを読込んだ`保護される資源$とは別に，自前の施策を備える（`~worker$sec）。 ◎ Workers now have their own policy, separate from the protected resource which loaded them. This is described in §5.1 Workers.
この改訂による新品の指令は： ◎ The following directives are brand new in this revision:
1. `base-uri$dir は、［ `保護される資源$における`文書~基底~URL$を指定する能］を制御する。 ◎ base-uri controls the protected resource’s ability to specify the document base URL.
2. `child-src$dir は、 `frame-src$dir を非推奨にして，それを置換える — それは、［ `保護される資源$が ~frameを埋込む／~workerを読込む］能を制御する。 ◎ child-src deprecates and replaces frame-src, controlling the protected resource’s ability to embed frames, and to load Workers.
3. `form-action$dir は、［ `保護される資源$が~formを提出する能］を制御する。 ◎ form-action controls the protected resource’s ability to submit forms.
4. `frame-ancestors$dir は、［ `保護される資源$が，他の文書~内に埋込まれる能］を制御する。これは、 `X-Frame-Options$h ~HTTP要請~headerに取って代わることが意味されている。 ◎ frame-ancestors controls the protected resource’s ability be embedded in other documents. It is meant to supplant the X-Frame-Options HTTP request header.
5. `plugin-types$dir は、［ `保護される資源$が，特定の型の~pluginを読込む能］を制御する。 ◎ plugin-types controls the protected resource’s ability to load specific types of plugins.
~nonce（`妥当な~nonce$sec）や, ~hash（`妥当な~hash$sec）を介して，個々の［ ~inline~script／~stylesheet ］を~whitelist化できる。 ◎ Individual inline scripts and stylesheets may be whitelisted via nonces (as described in §4.2.4 Valid Nonces) and hashes (as described in §4.2.5 Valid Hashes).
違反に際しては、 `SecurityPolicyViolationEvent$I が発火される（`違反~eventの発火-法$sec） ◎ A SecurityPolicyViolationEvent is fired upon violations, as described in §6.3 Firing Violation Events.
違反~報告には、いくつもの新たな~fieldが追加された — ［ `report-uri$dir を介して POST されるもの］, および［ `SecurityPolicyViolationEvent$I ~eventを介して DOM に手渡されるもの］の両者に。これらには、次が含まれる：［ `effectiveDirective$m, `statusCode$m, `sourceFile$m, `lineNumber$m, `columnNumber$m ］ ◎ A number of new fields were added to violation reports (both those POSTED via report-uri, and those handed to the DOM via SecurityPolicyViolationEvent events. These include effectiveDirective, statusCode, sourceFile, lineNumber, and columnNumber.
`sandbox$dir 指令に在るいくつかの~flagは、今や， `Worker^I の作成に影響する（`~sandbox法と~worker$sec） ◎ Certain flags present in the sandbox directive now affect Worker creation, as described in §7.14.1 Sandboxing and Workers.

【この訳に特有な表記規約】

この訳では、原文~仕様の旧 W3C HTML 仕様の用語を指す~linkは、ほぼすべて WHATWG HTML 仕様のそれらを指す~link（可用なら和訳の~link）に代えている。

◎表記記号

加えて、記号 “`~ACI@” を導入する：

“%x ~EQ`~ACI$ %y” は、 %x と %y は `~ASCII大小無視$による比較で等しいことを表す。 “~NEQ`~ACI$” は、その否定を表す。
“ %x ~IN`~ACI$ %S ” は、集合 %S 内に，［ %x ~EQ`~ACI$ %y ］なる %y があることを意味する。

特に断らない限り、文字列の比較は文字大小区別とする。

次の~styleが表記に用いられる：

`production^p — ~protocol要素（~ABNF生成規則）
`example-directive^dir — ~CSP `指令~名$
`literal^lt — 文字列~literal（引用符は~dataに含まれない）。
`literal^pl — 文字列~literal。引用符も~dataに`含まれる^em。
`violation-report-key^vr — `違反~報告~obj$の各種~field
`sandboxing-flag^fl — 各種~sandbox法~flag
`Example-Header^h — ~HTTP~header名
`element^e — ~HTML要素
`attribute^a — ~HTML内容~属性
`idl-construct^I — ~IDL構成子（~IDL属性など）／他の~code類
`sample-code^s — （地の文の中の）見本~code類

見易さのため、（地の文の中でない）見本~codeの中の~HTTP~headerには，（構文上は不正な）改行を入れている箇所もある。

2. 主要な概念と各種用語

`~security施策@（ security policy ）, または単に “施策”

`~security施策指令@, または単に “指令（ directive ）”

`~security施策指令~名@, または単に “指令~名（ directive name ）”

`~security施策指令~値@, または単に “指令~値（ directive value）”

~security施策とは、［内容が演算できる~~範囲を制約する，~security上の選好］の集合を指し、また［これらの選好を成文化する／伝送する ~text片］も指す。 ◎ A security policy refers to both a set of security preferences for restrictions within which content can operate, and to a fragment of text that codifies or transmits these preferences. For example, the following string is a policy which restricts script and object content:

例えば，次の文字列は，~script, および~obj内容を制約する施策である： ◎ ↑

`script-src$dir `self^pl; `object-src$dir `none^pl

施策は、 ~security施策指令 （上の例では［ `script-src$dir …, `object-src$dir … ］）の集合を包含する — そのそれぞれは、［特定0の型の資源に対する制約を宣言する］こと, または［施策の制約の特定の側面を操作する］ことを請け負う。この仕様により定義される各種~指令の~listは、`指令$secにて。 ◎ Security policies contain a set of security policy directives (script-src and object-src in the example above), each responsible for declaring the restrictions for a particular resource type, or manipulating a specific aspect of the policy’s restrictions. The list of directives defined by this specification can be found in §7 Directives.

各~指令は、名前と値を持つ。詳細な文法は、`構文と~algo$secにて。 ◎ Each directives has a name and a value; A detailed grammar can be found in §4 Syntax and Algorithms.

`保護される資源@

~UAは、`~security施策$を，特定の`資源~表現$に適用する。この仕様では、この資源~表現のことを 保護される資源 と称する。施策を保護される資源に適用する仕組みの詳細は、`施策の送達$secを見よ。【何が保護される資源になるかは、`施策の適用能$secに。】 ◎ A security policy is applied by a user agent to a specific resource representation, known as the protected resource. See §3 Policy Delivery for details regarding the mechanisms by which policies may be applied to a protected resource.

2.1. 各種~用語への参照

次の用語は、他の仕様にて定義される：

`大域一意~識別子@（~GUID）: `RFC6454$r `§ 2.3＠~RFC6454#section-2.3$ ◎ Defined in Section 2.3 of the Origin specification. [RFC6454]; 注記：命名~権限として階層的~要素を利用しない~URL（~~例えば `data:^sc ~scheme）の`生成元$は、大域一意~識別子になる。 ◎ NOTE: URLs which do not use hierarchical elements as naming authorities (data:, for instance) have origins which are globally unique identifiers.
`~HTTP 200 応答@: `RFC7231$r `§ 6.3.1＠~RFC7231#section-6.3.1$ ◎ Defined in Section 6.3.1 of HTTP/1.1 -- Semantics and Content. [RFC7231]
`~JSON~obj@
`~JSON文字列~化@: ~JSON仕様 `RFC4627$r ◎ Defined in the JSON specification. [RFC4627]
`生成元@: Origin 仕様 `RFC6454$r 【 `§ 3.2＠~RFC6454#section-3.2$ 】 ◎ Defined by the Origin specification. [RFC6454]
`資源~表現@: `RFC7231$r `§ 3＠~RFC7231#section-3$ ◎ Defined in Section 3 of HTTP/1.1 -- Semantics and Content. [RFC7231]
`~URL@: `URL$r にて定義される ◎ Defined by [URL].
`SHA-256@
`SHA-384@
`SHA-512@: これらの~digest~algoは NIST `FIPS180$r にて定義される。 ◎ These digest algorithms are defined by the NIST. [FIPS180]

2.3. ~HTMLからの関連な概念

【 ~HTMLその他の仕様の用語には，直に~linkをあてがっているので、この節の和訳は，省略する。】

2.4. 文法~上の概念

この文書では、［ RFC5234 `ABNF$rにより指定される ~ABNF記法（ Augmented Backus-Naur Form ）］, および［ `RFC7230$r にて定義される~ABNF拡張 `#rule$p ］を利用する。 ◎ The Augmented Backus-Naur Form (ABNF) notation used in this document is specified in RFC5234. [ABNF] ◎ This document also uses the ABNF extension "#rule" as defined in Section 7 of HTTP/1.1 -- Message Syntax and Routing. [RFC7230]

次の中核~規則は、 `ABNF$r の`付録 B.1＠~RFCx/rfc5234#appendix-B.1$ にて定義される： `ALPHA@P （英字）, `DIGIT@P （十進数 0-9 ）, `WSP@P （空白）, `VCHAR@P （印字可能~文字） ◎ The following core rules are included by reference, as defined in Appendix B.1 of [ABNF]: ALPHA (letters), DIGIT (decimal 0-9), WSP (white space) and VCHAR (printing characters).

3. 施策の送達

~serverは、次のいずれかを介して，`施策$を~UAへ送達する：

`Content-Security-Policy$h ~HTTP応答~header（ `3.2$sec ）
`Content-Security-Policy-Report-Only$h ~HTTP応答~header（ `3.1$sec ）
~HTML `meta$e 要素（ `~meta要素$sec）

◎ The server delivers a policy to the user agent via an HTTP response header (defined in §3.1 Content-Security-Policy Header Field and §3.2 Content-Security-Policy-Report-Only Header Field ) or an HTML meta element (defined in §3.3 HTML meta Element).

3.1. `Content-Security-Policy^h ~header

`Content-Security-Policy@h 応答~headerが、施策を送達するときに選好される仕組みである。その~ABNF文法は： ◎ The Content-Security-Policy header field is the preferred mechanism for delivering a policy. The grammar is as follows:

"Content-Security-Policy:" 1#`policy-token$p

◎ For example, a response might include the following header field:

Content-Security-Policy:
    `script-src$dir `self^pl

【長い行をウィンドウ内に収める便宜上、この訳~全体を通して，~HTTP~headerの例示~codeでは、一律に，~header行lを折返した上で字下げした形で示すことにする — HTTP/1.1 の構文としては、許容されないことに注意。】

~serverは、所与の`資源~表現$に対し，複数個の `Content-Security-Policy^h ~headerを送信してはナラナイ†。 ◎ A server MUST NOT send more than one HTTP header field named Content-Security-Policy with a given resource representation.

【† ~headerの構文は，［ ~HTTPの要件の下では、施策（ `policy-token$p ）が複数あるときは，複数の~headerに分けることも許容される］ことを示しているが、それでも，それらの施策を`一つに結合する＠~RFC7230#section-3.2.2$ことが要求されている（次~節も同様）。その理由は、~headerの注入~攻撃を検出し易くするためと見られる。】

~serverは、［異なる資源／同じ資源の異なる`表現$ ］ごとに，~header値が異なる `Content-Security-Policy^h を送信してもヨイ。 ◎ A server MAY send different Content-Security-Policy header field values with different representations of the same resource or with different resources.

~UAは、一つ以上の `Content-Security-Policy^h ~headerを包含する~HTTP応答を受信したときは，そのような~headerのそれぞれに包含されている各~施策†を`施行-$するモノトスル。 ◎ 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.

【† 各~headerごとではなく，各 `policy-token$p ごとに（次~節も同様）。】

3.2. `Content-Security-Policy-Report-Only^h ~header

`Content-Security-Policy-Report-Only@h 応答~headerにより、~serverは，~UAに施策を（施行させるのでなく）監視させて，施策を実験できるようになる。その~ABNF文法は： ◎ The Content-Security-Policy-Report-Only header field lets servers experiment with policies by monitoring (rather than enforcing) a policy. The grammar is as follows:

"Content-Security-Policy-Report-Only:" 1#`policy-token$p

例えば，~server運用者にとっては、~security施策を反復的に開発したいと望むこともあろう。運用者は、自身の~siteがどう挙動するかについての最良な見積もりに基づいて，報告のみの施策を配備できる： ◎ For example, 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:

Content-Security-Policy-Report-Only:
    `script-src$dir `self^pl;
    `report-uri$dir /csp-report-endpoint/

~siteがこの施策に違反した場合、~UAは，［施策の `report-uri$dir 指令~内に指定された~URL ］に向けて`違反~報告を送信する$ことになるが、それに関わらず，違反している資源を読込むことは許容される。施策が~siteに適切であると確信できた所で、運用者は， `Content-Security-Policy$h ~headerを利用して，施策の施行を開始できる。 ◎ If their site violates this policy the user agent will send violation reports to the URL specified in the policy’s report-uri directive, but allow the violating resources to load regardless. Once a site has confidence that the policy is appropriate, they can start enforcing the policy using the Content-Security-Policy header field.

~serverは、所与の`資源~表現$に対し，複数個の `Content-Security-Policy-Report-Only^h ~headerを送信してはナラナイ。 ◎ A server MUST NOT send more than one HTTP header field named Content-Security-Policy-Report-Only with a given resource representation.

~serverは、［異なる資源／同じ資源の異なる`表現$ ］ごとに，~header値が異なる `Content-Security-Policy-Report-Only^h を送信してもヨイ。 ◎ 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は、一つ以上の `Content-Security-Policy-Report-Only^h ~headerを包含する~HTTP応答を受信したときは，そのような~headerのそれぞれに包含されている各~施策を`監視-$するモノトスル。 ◎ 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.

注記： `meta$e 要素~内の `Content-Security-Policy-Report-Only$h ~headerは~support`されない^em。 ◎ Note: The Content-Security-Policy-Report-Only header is not supported inside a meta element.

3.3. ~HTML `meta^e 要素

~serverは、［［ `http-equiv$a 属性の値 ~EQ`~ACI$ `Content-Security-Policy^lt ］なる，一つ以上の~HTML `meta$e 要素］を介して，施策を給してもヨイ。例えば： ◎ The server MAY supply policy via one or more HTML meta elements with http-equiv attributes that are an ASCII case-insensitive match for the string "Content-Security-Policy". For example:

<meta http-equiv="Content-Security-Policy"
    content="`script-src$dir `self^pl">

`meta$e 要素に対する `~pragma指令$には，次の~entryが追加される： ◎ Add the following entry to the pragma directives for the meta element:

~CSP（ `http-equiv="content-security-policy"^c ）

【~UAはこの~entryに応じて、次を実行するモノトスル：】

~IF 文書の `head$e 要素は， `meta$e 要素の先祖でない ⇒ ~RET ◎ If the Document’s head element is not an ancestor of the meta element, abort these steps.
~IF `meta$e 要素は， `content$a 属性を欠いている ⇒ ~RET ◎ If the meta element lacks a content attribute, abort these steps.
%施策 ~LET `meta$e 要素の `content$a 属性の値 ◎ Let policy be the value of the content attribute of the meta element.
%指令~集合 ~LET %施策を`施策として構文解析-$した結果 ◎ Let directive-set be the result of parsing policy.
%指令~集合内から，すべての［ `report-uri$dir, `frame-ancestors$dir, `sandbox$dir ］指令を除去する ◎ Remove all occurrences of report-uri, frame-ancestors, and sandbox directives from directive-set.

注記： ~UAには、これらの指令が［ `meta$e を介して送達される施策］内に含まれている場合には，［開発者へ警告を~~発する］ことが奨励される。 ◎ Note: User agents are encouraged to issue a warning to developers if one or more of these directives are included in a policy delivered via meta.
%指令~集合を成す各~指令を`その指令の型に定義される＠#directives$とおりに施行する。 ◎ Enforce each of the directives in directive-set, as defined for each directive type.

`meta$e 要素~内の施策は、それに先行する内容には適用されない。したがって，作者には、 `meta$e 要素を，アリな限り文書の始めの方に配置することが`強く奨励される^em。特に、［ `Link$h ~HTTP応答~headerや, ［ `meta$e により送達される施策に先行する［ `link$e ／ `script$e ］要素］］を利用して［ ~fetchまたは~prefetchされる］資源は、阻止されないことに注意。 ◎ Authors are strongly encouraged to place meta elements as early in the document as possible, because policies in meta elements are not applied to content which precedes them. In particular, note that resources fetched or prefetched using the Link HTTP response header field, and resources fetched or prefetched using link and script elements which precede a meta-delivered policy will not be blocked.

注記： `meta$e 要素を介して指定される`施策$は、保護される資源にて作動中な他の施策とともに — 他の施策がどこで指定されたかに関わらず — 施行される。複数の施策が施行されるときの一般的な影響iは、`複数の施策の施行-法$secにて述べる。 ◎ Note: A policy specified via a meta element will be enforced along with any other policies active for the protected resource, regardless of where they’re specified. The general impact of enforcing multiple policies is described in §3.4 Enforcing multiple policies..

注記：要素が構文解析された後に， `meta$e 要素の `content$a 属性を改変しても、無視される。 ◎ Note: Modifications to the content attribute of a meta element after the element has been parsed will be ignored.

注記： `meta$e 要素においては、 `Content-Security-Policy-Report-Only$h ~headerは，`~supportされない^em。 ◎ Note: The Content-Security-Policy-Report-Only header is not supported inside a meta element.

3.4. 複数の施策の施行-法

◎非規範的

上の節（`~meta要素$sec）では、施策が複数~在るときは、それぞれが，その型に則って施行する／報告するモノトスルと記されている。実施において，これがどう働くものとされるべきか、明確化する例を示す。何らかの理由で、ある~siteから【の資源に伴って】次の ~HTTP~headerが送達されてきたとする： ◎ The above sections note that when multiple policies are present, each must be enforced or reported, according to its type. An example will help clarify how that ought to work in practice. The behavior of an XMLHttpRequest might seem unclear given a site that, for whatever reason, delivered the following HTTP headers:

Content-Security-Policy:
    `default-src$dir `self^pl http://example.com http://example.net;
    `connect-src$dir `none^pl;

Content-Security-Policy:
    `connect-src$dir http://example.com/;
    `script-src$dir http://example.com/

【 `3.1$secでは、この~headerは複数個送信されてはナラナイと記されているが、ここでは，~~記述の便宜上，二つに分けて示していると見られる（他の例示~codeも同様）。】

このとき、【この資源における】 `XMLHttpRequest$I による `example.com^s への接続は許容されるか？ — 答えは、許容されない，である。両~施策の施行は、［起こりうる接続が，両者ともに無傷で合格しなければならない］ことを意味する。二番目の施策がこの接続を許容するとしても，最初の施策が `connect-src$dir `none^pl を包含するので、その施行nにより接続は阻止される。施行する施策の~listに，施策を追加することによる影響iは、保護される資源の能力に制約を追加しこそすれ，それを~~緩めることはない。 ◎ Is a connection to example.com allowed or not? The short answer is that the connection is not allowed. Enforcing both policies means that a potential connection would have to pass through both unscathed. Even though the second policy would allow this connection, the first policy contains connect-src 'none', so its enforcement blocks the connection. The impact is that adding additional policies to the list of policies to enforce can only further restrict the capabilities of the protected resource.

更にデモるため、この~page上の~script~tagを考える。最初の施策は，~scriptを `default-src$dir 指令による { `self^pl, `http://example.com^s, `http://example.net^s } の枠内に絞る一方、二番目の施策は， `http://example.com/^s からの~scriptのみを許容する。 ~scriptが読込まれるのは，両~施策の判定基準を満たす場合に限るので、合致し得る生成元は `http://example.com^s のみになる。 ◎ To demonstrate that further, consider a script tag on this page. The first policy would lock scripts down to 'self', http://example.com and http://example.net via the default-src directive. The second, however, would only allow script from http://example.com/. Script will only load if it meets both policy’s criteria: in this case, the only origin that can match is http://example.com, as both policies allow it.

3.5. 施策の適用能

◎非規範的

施策は、`保護される資源$に結付けられ，その資源に対し `施行-$／`監視-$ される。新たな実行~文脈を作成しない資源（例えば，文書の中に［ ~script／画像／~stylesheet ］を含ませる資源）に伴って送達される施策は，効果を及ぼさずに破棄される。その実行は、［そのような資源を含める側の文脈］の施策（たち）の~subjectになる。次の表tに，これらの関係性の例を要旨する： ◎ Policies are associated with an protected resource, and enforced or monitored for that resource. If a resource does not create a new execution context (for example, when including a script, image, or stylesheet into a document), then any policies delivered with that resource are discarded without effect. Its execution is subject to the policy or policies of the including context. The following table outlines examples of these relationships:

資源の型 ◎ Resource Type		どの `施策$が適用されるか？ ◎ What policy applies?
~top-levelの文脈 ◎ Top-level Contexts	新たな`~top-level閲覧~文脈$としての~HTML ◎ HTML as a new, top-level browsing context	資源に伴って送達される施策 ◎ The policy delivered with the resource
~top-levelの文脈 ◎ Top-level Contexts	~top-level文書としての SVG ◎ SVG, as a top-level document	同上 ◎ Policy delivered with the resource
埋込まれた文脈 ◎ Embedded Contexts	［ `iframe$e ／ `object$e ／ `embed$e ］を介して含められる資源 ◎ Any resource included via iframe, object, or embed	何が埋込まれてもヨイかは、埋込んでいる資源の施策が制御する。埋込まれた資源に適用されるのは、資源に伴って送達される施策になる — ただし、資源が`~GUID$（または `srcdoc$a ~frame）による場合は，埋込んでいる資源の施策になる。 ◎ The policy of the embedding resource controls what may be embedded. The embedded resource, however, is controlled by the policy delivered with the resource, or the policy of the embedding resource if the embedded resource is a globally unique identifier (or a srcdoc frame).
	埋込まれた文書としての SVG ◎ SVG, as an embedded document	その埋込まれた資源に伴って送達された施策 — ただし，資源が`~GUID$から作成される場合は、それを作成している文脈の施策。 ◎ The policy delivered with the resource, or policy of the creating context if created from a globally unique identifier.
	［ Worker ／ Shared Worker／ Service Worker ］としての~JavaScript ◎ JavaScript, as a Worker, Shared Worker or Service Worker	同上 ◎ The policy delivered with the resource, or policy of the creating context if created from a globally unique identifier
下位資源 ◎ Subresources	`svg$e を介して~inline化された SVG ◎ SVG, inlined via svg	その資源を含めている文脈における施策。 ◎ Policy of the including context
	資源~文書としての SVG ◎ SVG, as a resource document	同上 ◎ Policy of the including context
	XMLHttpRequest により~~取得される~HTML ◎ HTML via XMLHttpRequest	~fetchを遂行した側の文脈の施策。 ◎ Policy of the context that performed the fetch
	`img$e 要素による画像 ◎ Image via img element	その資源を含めている文脈における施策。 ◎ Policy of the including context
	`script$e 要素による~JavaScript ◎ JavaScript via a script element	同上 ◎ Policy of the including context
	`img$e による SVG ◎ SVG, via img	施策なし。 JPG と同じく安全であるべき。【上の img 要素の記述と同じでないのは何故？】 ◎ No policy; should be just as safe as JPG
	WebFont としての SVG ◎ SVG, as a WebFont	施策なし。 WOFF と同じく安全であるべき。 ◎ No policy; should be just as safe as WOFF

4. 構文と~algo

4.1. 施策の構文

~CSPは、~SEMICOLONで区切られた，いくつかの指令（ `directive-token$p ）からなる~listである。各指令は、次の~ABNFにより定義される `指令~名$（ `directive-name$p ）, および`指令~値$（ `directive-value$p, 場合によっては省略可能）からなる： ◎ A Content Security Policy consists of a U+003B SEMICOLON (;) delimited list of directives. Each directive consists of a directive name and (optionally) a directive value, defined by the following ABNF:

`policy-token@p
	= [ `directive-token$p *( ";" [ `directive-token$p ] ) ]
`directive-token@p
	= *`WSP$P [ `directive-name$p [ `WSP$P `directive-value$p ] ]
`directive-name@p
	= 1*( `ALPHA$P / `DIGIT$P / "-" )
`directive-value@p
	= *( `WSP$P / < `;^lt と `,^lt を除く `VCHAR$P > )

4.1.1. 施策の構文解析-法

~UAは、 %施策（ `policy-token$p ）を `施策として構文解析-@ するときは，次と等価な~algoを利用するモノトスル： ◎ To parse the policy policy, the user agent MUST use an algorithm equivalent to the following:

%指令~集合 ~LET 空~集合 ◎ Let the set of directives be the empty set.
`区切子で厳密に分割する$( %施策, ~SEMICOLON ) — その結果を成す~EACH (空でない~token) に対し： ◎ For each non-empty token returned by strictly splitting the string policy on the character U+003B SEMICOLON (;):
1. `空白を読飛ばす$ ◎ Skip whitespace.
2. %指令~名 ~SET `~ASCII空白$以外の`符号位置~並びを収集する$ ◎ Collect a sequence of characters that are not space characters. The collected characters are the directive name.
3. ~IF %~token 内に残りの文字がある ⇒ 正確に 1 個だけ，文字（`~ASCII空白$である筈）を読飛ばす ◎ If there are characters remaining in token, skip ahead exactly one character (which must be a space character).
4. %指令~値 ~SET %~token 内の残りの文字（もしあれば）【ない場合は空~文字列？】 ◎ The remaining characters in token (if any) are the directive value.
5. ~IF %指令~集合内に，［名前 ~EQ`~ACI$ %指令~名］なる指令が既にある ⇒ ~CONTINUE（この指令~instanceを無視する）† ◎ If the set of directives already contains a directive whose name is a case insensitive match for 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.
~RET %指令~集合 ◎ Return the set of directives.

【† したがって、同じ名前の指令が複数個ある場合、最初のもののみが採用されることになる。】

4.2. ~source~listの構文

~CSP指令の多くは、その値（ `directive-value$p ）に，下の~ABNF文法により定義される `~source~list@ （ `source-list$p ）を利用する。【そのような指令は、 “~source~list指令” と総称される。】 ◎ Many CSP directives use a value consisting of a source list, defined in the ABNF grammar below.

~source~list内の各 `~source式@ （ `source-expression$p または `none^pl ）は、［指定された型の内容を，どの所在†から検索取得できるか］を表現する。例えば， ~source式 `none^pl は，空~集合を表現し、 ~source式 `unsafe-inline^pl は，［資源~自身にて~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 'none' represents the empty set of URLs, and the source expression 'unsafe-inline' represents content supplied inline in the resource itself.

`source-list@p
	= *`WSP$P [ `source-expression$p *( 1*`WSP$P `source-expression$p ) *`WSP$P ]
	/ *`WSP$P "`none^pl" *`WSP^P
`source-expression@p
= `scheme-source$p
	/ `host-source$p
	/ `keyword-source$p
	/ `nonce-source$p
	/ `hash-source$p
`scheme-source@p
	= `scheme-part$p ":"
`host-source@p
	= [ `scheme-part$p "://" ] `host-part$p [ `port-part$p ] [ `path-part$p ]
`keyword-source@p
	= "`self^pl"
	/ "`unsafe-inline^pl"
	/ "`unsafe-eval^pl"
`base64-value@p
	= 1*( `ALPHA$P / `DIGIT$P / "+" / "/" )*2( "=" )
`nonce-value@p
	= `base64-value$p
`hash-value@p
	= `base64-value$p
`nonce-source@p
	= "'nonce-" `nonce-value$p "'"
`hash-algo@p
	= "sha256"
	/ "sha384"
	/ "sha512"
`hash-source@p
	= "'" `hash-algo$p "-" `hash-value$p "'"
`scheme-part@p
	= < `scheme$p 生成規則, RFC 3986, § 3.1 >
`host-part@p
	= "*" / [ "*." ] 1*`host-char$p *( "." 1*`host-char$p )
`host-char@p
	= `ALPHA$P / `DIGIT$P / "-"
`path-part@p
	= < `path$p 生成規則, RFC 3986, § 3.3 >
`port-part@p
	= ":" ( 1*`DIGIT$P / "*" )

施策に `nonce-source$p 式を包含させる~serverは、その `nonce-value$p 値を，施策を伝送する各回ごとに~randomに（したがって, 新規0かつ互いに独立に）生成しなければナラナイ。生成される値は、［（符号化する前の時点で） 128 ~bit以上］, かつ［暗号的に~secureな乱数~生成器を介して生成される］ベキである。この要件は、攻撃者による `nonce-value$p の予測-を困難にするためにある。 ◎ If the policy contains a nonce-source expression, the server MUST generate a fresh value for the nonce-value directive at random and independently each time it transmits a policy. The generated value SHOULD be at least 128 bits long (before encoding), and generated via a cryptographically secure random number generator. This requirement ensures that the nonce-value is difficult for an attacker to predict.

注記：【 `script-src$dir／`style-src$dir 指令において】 ~nonceを利用して~inlineの ~script／~style を~whitelist化するのは、~nonceを利用しないでそうするときより~secureでない — ~nonceは、それが在る指令~内の制約を上書きするので。 ~nonceへの~accessを得られる攻撃者は、~~任意の~scriptを~~任意に実行できる。とは言え、古い~code上に内容~security施策の層を重ねるとき、~nonceの利用は `unsafe-inline^pl を大きく改善する。作者には、 `unsafe-inline^pl を検討するときは，代わりに~nonce（または~hash）を検討することが奨励される。 ◎ Note: Using a nonce to whitelist inline script or style is less secure than not using a nonce, as nonces override the restrictions in the directive in which they are present. An attacker who can gain access to the nonce can execute whatever script they like, whenever they like. That said, nonces provide a substantial improvement over 'unsafe-inline' when layering a content security policy on top of old code. When considering 'unsafe-inline', authors are encouraged to consider nonces (or hashes) instead.

`host-char$p 生成規則は、意図的に~ASCII文字のみを包含するようにされている。国際-化~domain名は，施策~文字列の中へは直に手入力できないので、代わりに Punycode `RFC3492$r で符号化されなければナラナイ。例えば， ~domain `üüüüüü.de^s は、 `xn--tdaaaaaa.de^s のように符号化される。 ◎ The host-char production intentionally contains only ASCII characters; internationalized domain names cannot be entered directly into a policy string, but instead MUST be Punycode-encoded [RFC3492]. For example, the domain üüüüüü.de would be encoded as xn--tdaaaaaa.de.

注記： ~IP~addressは，上の文法に合致するが、~source式~内に利用されるときに実際に合致する~URLは， `127.0.0.1^s のみである（詳細は `~source式の照合-法$secを見よ）。 ~IP~addressが備える~security上の特質には疑義があるので、アリなら~IP~addressより ~hostnameが選好されるべきである。 ◎ NOTE: Though IP addresses do match the grammar above, only 127.0.0.1 will actually match a URL when used in a source expression (see §4.2.2 Matching Source Expressions for details). The security properties of IP addresses are suspect, and authors ought to prefer hostnames to IP addresses whenever possible.

4.2.1. ~source~listの構文解析-法

~UAは、 %~source~list を `~source~listとして構文解析-@ するときは，次と等価な~algoを利用するモノトスル： ◎ To parse a source list source list, the user agent MUST use an algorithm equivalent to the following:

%~source~list ~SET `前後の~ASCII空白~列を剥ぐ$( %~source~list ) ◎ Strip leading and trailing whitespace from source list.
~IF %~source~list ~EQ`~ACI$ `none^pl （引用符も含めて） ⇒ ~RET 空~集合 ◎ If source list is an ASCII case-insensitive match for the string 'none' (including the quotation marks), return the empty set.
%~source式~集合 ~LET 空~集合 ◎ Let set of source expressions be the empty set.
`~ASCII空白で分割する$( %~source~list ) — その結果を成す~EACH( ~token ) に対し ⇒ ~IF ~tokenは `source-expression$p の文法に合致する ⇒ %~source式~集合に~tokenを追加する ◎ For each token returned by splitting source list on spaces, if the token matches the grammar for source-expression, add the token to the set of source expressions.
~RET %~source式~集合 ◎ Return the set of source expressions.

注記： ~source式~内には，［ ~SEMICOLON／~COMMA ］の様な文字は直には出現できないので、含ませたい場合は［ `%3B^lt ／ `%2C^lt ］に`~percent-符号化-$されなければならない。 ◎ Note: Characters like U+003B SEMICOLON (;) and U+002C COMMA (,) cannot appear in source expressions directly: if you’d like to include these characters in a source expression, they must be percent encoded as %3B and %2C respectively.

4.2.2. ~source式の照合-法

~URL %url は、次の~algoが `合致する^i を返すとき， %保護される資源に対する `~source式$ %式に合致するとされる： ◎ A URL url is said to match a source expression for a protected resource if the following algorithm returns does match:

【参考： ~source式 `none^pl が，この~algoに入力されることは、ない。】

%url ~LET `~URL構文解析する$( %url ) ◎ Let url be the result of processing the URL through the URL parser.
~IF ［ %式 ~EQ ~ASTERISK ］：
1. ~IF［ %url の`~scheme$url ~NIN { `blob^sc, `data^sc, `filesystem^sc } ］ ⇒ ~RET `合致する^i
2. 【 `~GUID~URL~scheme$secの記述に従うなら，ここで `非合致^i を返すべき所だが、記述がない（手続きを追っていけば，結局そうなるが、~~明瞭さに~~欠く）。】
◎ If the source expression a consists of a single U+002A ASTERISK character (*), and url’s scheme is not one of blob, data, filesystem, then return does match.
~IF %式は `scheme-source$p の文法に合致する： ◎ If the source expression matches the grammar for scheme-source:
1. ~IF %url の`~scheme$url ~EQ`~ACI$ %式の `scheme-part$p ⇒ ~RET `合致する^i ◎ If url’s scheme is an ASCII case-insensitive match for the source expression’s scheme-part, return does match.
2. ~RET `非合致^i ◎ Otherwise, return does not match.
~IF %式は `host-source$p の文法に合致する： ◎ If the source expression matches the grammar for host-source:
1. ~IF %url の`~host$url ~EQ ~NULL ⇒ ~RET `非合致^i ◎ If url’s host is null, return does not match.
2. ［ %url-scheme, %url-host, %url-port ］ ~LET 順に， %url の［ `~scheme$url, `~host$url, `~port$url ］（すなわち，生成元を成す三つ組） ◎ Let url-scheme, url-host, and url-port be the scheme, host, and port of url’s origin, respectively.
  
  注記：入力 %url に~portが指定されていなかった場合の生成元の`~port$urlは、 %url の`~scheme$urlに対する`既定~port$になる。 ◎ Note: If url doesn’t specify a port, then its origin’s port will be the default port for url’s scheme.
3. %url-path-list ~LET %url の`~path$url ◎ Let url-path-list be the path of url.
4. ~IF［ %式は `scheme-part$p を持つ］ ⇒ ~IF［ %url-scheme ~NEQ`~ACI$ `scheme-part$pの値］ ⇒ ~RET `非合致^i ◎ If the source expression has a scheme-part that is not a case insensitive match for url-scheme, then return does not match.
5. ~ELSE ： ◎ If the source expression does not have a scheme, return does not match if any of the following are true:
  1. ~IF［ %保護される資源の~URLの~scheme ~EQ`~ACI$ `HTTP^lt ］ ⇒ ~IF［ %url-scheme ~IN`~ACI$ { `HTTP^lt, `HTTPS^lt } ］ ⇒ ~RET `非合致^i ◎ the scheme of the protected resource’s URL is a case insensitive match for HTTP, and url-scheme is not a case insensitive match for either HTTP or HTTPS
  2. ~ELIF［ %url-scheme ~NEQ`~ACI$ %保護される資源の~URLの~scheme ］ ⇒ ~RET `非合致^i ◎ the scheme of the protected resource’s URL is not a case insensitive match for HTTP, and url-scheme is not a case insensitive match for the scheme of the protected resource’s URL.
6. ~IF［［ %式の `host-part$p の最初の文字］ ~EQ ~ASTERISK ］ ⇒ ~IF［［ %式の `host-part$p から最初の文字を取り除いた文字列（すなわち，先頭の~FULLSTOPも含む）］ ~NEQ`~ACI$ ［ %url-host の末尾部分の文字列］］ ⇒ ~RET `非合致^i ◎ If the first character of the source expression’s host-part 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 url-host, then return does not match.
7. ~ELIF［ %url-host ~NEQ`~ACI$ %式の `host-part$p ］ ⇒ ~RET `非合致^i ◎ If the first character of the source expression’s host-part is not an U+002A ASTERISK character (*) and url-host is not a case insensitive match for the source expression’s host-part, then return does not match.
8. ~IF %式の `host-part$p は［［ `IPv4address$p 生成規則に合致する `RFC3986$r ~AND ~NEQ `127.0.0.1^lt ］ ~OR［ `~IPv6~address$である］］ ⇒ ~RET `非合致^i ◎ If the source expression’s host-part matches the IPv4address production from [RFC3986], and is not 127.0.0.1, or is an IPv6 address, return does not match.
  
  注記：この仕様の将来~versionは、用法や需要に依存して，~literalによる［ ~IPv6 ／ ~IPv4 ］~addressを許容するかもしれない。しかしながら、名前を持つ~hostに関係する~IP~addressの~security上の特質は弱いので、作者には，アリな所では後者【~host？】を選好することが奨励される。 ◎ Note: A future version of this specification may allow literal IPv6 and IPv4 addresses, depending on usage and demand. Given the weak security properties of IP addresses in relation to named hosts, however, authors are encouraged to prefer the latter whenever possible.
9. ~IF ［ %式は `port-part$p を包含しない ］ ⇒ ~IF %url-port ~NEQ %url-scheme の`既定~port$ ⇒ ~RET `非合致^i ◎ If the source expression does not contain a port-part and url-port is not the default port for url-scheme, then return does not match.
10. ~ELIF［ %式の `port-part$p は［［ ~ASTERISKを包含しない ］~AND［ %url-port と同じ数値を表現しない ］］］ ⇒ ~RET `非合致^i ◎ If the source expression does contain a port-part, then return does not match if both of the following are true: ◎ port-part does not contain an U+002A ASTERISK character (*) ◎ port-part does not represent the same number as url-port
11. ~IF［ %式は空でない `path-part$p を包含する］~AND［ ~URLは~redirectの`結果でない^em ］： ◎ If the source expression contains a non-empty path-part, and the URL is not the result of a redirect, then:
  1. %式-path-list ~LET %path-part を~SOLIDUSで分割した結果 ◎ ↓
  2. ~IF［ %式-path-list の長さ ~GT %url-path-list の長さ］ ⇒ ~RET `非合致^i ◎ Let exact-match be true if the final character of path-part is not the U+002F SOLIDUS character (/), and false otherwise. ◎ Let source-expression-path-list be the result of splitting path-part on the U+002F SOLIDUS character (/). ◎ If source-expression-path-list’s length is greater than url-path-list’s length, return does not match.
  3. ~IF［ %式-path-list の長さ ~NEQ %url-path-list の長さ］~AND［ %path-part の~~最後の文字 ~NEQ ~SOLIDUS （すなわち，`正確な合致-を要する＠#source-list-path-patching$）］ ⇒ ~RET `非合致^i ◎ ↓↓
  4. %式-path-list 内の~EACH ( %~entry ) に対し： ◎ For each entry in source-expression-path-list:
    1. %~item ~LET %url-path-list 内の， %~entry に対応する（と同じ位置の）~item ◎ ↓
    2. ~IF［［ %~entry を`~percent-復号-$した結果］ ~NEQ`~ACI$ ［ %~item を`~percent-復号-$した結果］］ ⇒ ~RET `非合致^i ◎ Percent decode entry. ◎ Percent decode the first item in url-path-list. ◎ If entry is not an ASCII case-insensitive match for the first item in url-path-list, return does not match. ◎ Pop the first item in url-path-list off the list.
  5. † ◎ If exact-match is true, and url-path-list is not empty, return does not match.
  【† 簡潔にするため，訳では，ここの下位~手続きを一部組み替えて（末尾の段を段 3 へ移動して）等価なものに変形している。】
12. ~RET `合致する^i ◎ Otherwise, return does match.
~IF %式 ~EQ`~ACI$ `self^pl （引用符も含めて）： ◎ If the source expression is a case insensitive match for 'self' (including the quotation marks), then:
1. ~IF ［ %url の`生成元$と %保護される資源の~URLの`生成元$ とは合致する］ ⇒ ~RET `合致0^i ◎ Return does match if the origin of url matches the origin of protected resource’s URL.
  
  注記：これは~IP~addressの場合も含む。すなわち、 `https://111.111.111.111/^s に在る文書に，`施策$ `img-src 'self'^s が伴われるならば、 `https://111.111.111.111/image.png^s にある画像を読込める — 互いの生成元が合致するので。 ◎ Note: This includes IP addresses. That is, a document at https://111.111.111.111/ with a policy of img-src 'self' can load the image https://111.111.111.111/image.png, as the origins match.
~RET `非合致^i ◎ Otherwise, return does not match.

注記：この~algoは、二つの~URL `https://example.com/^s, `http://example.com./^s を `合致しない^emものと扱う。これは、［これらの~URLから~serveされる文書を別個な生成元に属するものと扱う，~browserの挙動］に整合である。 ◎ Note: This algorithm treats the URLs https://example.com/ and https://example.com./ as non-matching. This is consistent with browser behavior which treats documents served from these URLs as existing in distinct origins.

~URL %url は、［ %保護される資源に対する`~source~list$を`~source~listとして構文解析-$して得される，`~source式$の集合］内のある`~source式に合致-$するとき、その`~source~list$に `合致する@ とされる。 ◎ A URL url is said to match a source list for protected resource if at least one source expression in the set of source expressions obtained by parsing the source list matches url for protected resource.

注記： ~source式の集合が空な場合 — ~source~list `none^pl を構文解析して得される集合など — 合致する~URLは無い。 ◎ Note: No URLs match an empty set of source expressions, such as the set obtained by parsing the source list 'none'.

4.2.2.1. ~GUID~URL~schemeに対する~security上の考慮点

◎非規範的

上により定義されるように、特定の一意な内容~片を指すような，特別な~URL~scheme — `data:^sc, `blob:^sc, `filesystem:^sc など — は、施策 `*^lt に対する照合からは除外され、明示的に~listされなければナラナイ。施策の作者は、そのような~URLの内容は，［応答の本体や，文書~文脈における実行］から導出されることが多く，安全でないかもしれないことに注意するべきである。とりわけ，施策の作者は、［ `default-src$dir ／ `script-src$dir ］指令に対する，［ `data:^sc ~URLを許容することは `unsafe-inline^pl に等価になる］こと, および［ `blob:^sc ／ `filesystem:^sc ~URLを許容することは `unsafe-eval^pl に等価になる］ことを自覚しておくべきである。 ◎ As defined above, special URL schemes that refer to specific pieces of unique content, such as "data:", "blob:" and "filesystem:" are excluded from matching a policy of * and must be explicitly listed. Policy authors should note that the content of such URLs is often derived from a response body or execution in a Document context, which may be unsafe. Especially for the default-src and script-src directives, policy authors should be aware that allowing "data:" URLs is equivalent to unsafe-inline and allowing "blob:" or "filesystem:" URLs is equivalent to unsafe-eval.

4.2.2.2. ~pathの照合-法

◎非規範的

~pathを包含する~source式に対する照合~用の規則は、その見かけより単純である：文字 `/^lt で終端する~pathは、それが指す~directory下にある（~directory自身, 子孫directoryも含む）すべての~fileに合致する。文字 `/^lt で終端しない~pathは、ある特定の一つの~fileにのみ合致する。少数の例で，明瞭になるであろう： ◎ The rules for matching source expressions that contain paths are simpler than they look: paths that end with the '/' character match all files in a directory and its subdirectories. Paths that do not end with the '/' character match only one specific file. A few examples should make this clear:

~source式 `example.com^s は、~pathが無いので，その~hostから~serveされるどの~fileにも合致する。 ◎ The source expression example.com has no path, and therefore matches any file served from that host.
~source式 `example.com/scripts/^s は、 `example.com^c の `scripts^c ~directory, およびそのどの子孫directoryのどの~fileにも合致する。例えば，次のいずれも合致する。
```
https://example.com/scripts/file.js
https://example.com/scripts/js/file.js
```
◎ The source expression example.com/scripts/ matches any file in the scripts directory of example.com, and any of its subdirectories. For example, both https://example.com/scripts/file.js and https://example.com/scripts/js/file.js would match.
~source式 `example.com/scripts/file.js^s は、 `example.com^c の, `scripts^c ~directoryの, 名前 `file.js^c の~fileのみに合致する。 ◎ The source expression example.com/scripts/file.js matches only the file named file.js in the scripts directory of example.com.
同様に，~source式 `example.com/js^s は、名前 `js^c の~fileのみに合致する。特に、名前 `js^c の~directory下の~fileには合致しないことに注意。 `example.com/js/file.js^s の様な~fileに合致させるためには、 `example.com/js/^s のように，~source式の尾部を `/^lt で終端させる必要がある。 ◎ Likewise, the source expression example.com/js matches only the file named js. In particular, note that it would not match files inside a directory named js. Files like example.com/js/file.js would be matched only if the source expression ended with a trailing "/", as in example.com/js/.

注記： ~query文字列は、照合への影響iはない： ~source式 `example.com/file^s は、次のいずれにも合致する：

https://example.com/file
https://example.com/file?key=value
https://example.com/file?key=notvalue
https://example.com/file?notkey=notvalue

◎ Note: Query strings have no impact on matching: the source expression example.com/file matches all of https://example.com/file, https://example.com/file?key=value, https://example.com/file?key=notvalue, and https://example.com/file?notkey=notvalue.

4.2.2.3. ~pathと~redirect

~path情報が（ Egor Homakov 氏により論じられた `~CSP for Evil＠http://homakov.blogspot.de/2014/01/using-content-security-policy-for-evil.html$ を利用して）非同一-生成元に漏洩するのを避けるため、照合~algoは、読込まれる資源が~redirectの結果による場合には，~source式の~path成分を無視する。例えば、ある~pageにて施策 `img-src$dir example.com not-example.com/path が作動中とする： ◎ To avoid leaking path information cross-origin (as discussed in Egor Homakov’s Using Content-Security-Policy for Evil), the matching algorithm ignores the path component of a source expression if the resource being loaded is the result of a redirect. For example, given a page with an active policy of img-src example.com not-example.com/path:

`https://not-example.com/not-path^s を直に読込もうとしても，施策に合致しないので失敗するであろう。 ◎ Directly loading https://not-example.com/not-path would fail, as it doesn’t match the policy.
`https://example.com/redirector^s を直に読込むのは、 `example.com^c に合致するので，合格するであろう。 ◎ Directly loading https://example.com/redirector would pass, as it matches example.com.
`https://example.com/redirector^s から `https://not-example.com/not-path^s を~~指す~redirect応答が送達されてきたとする。この場合、~redirect先への読込nは成功するであろう — 前者の~URLは `example.com^c に合致し、かつ ~redirect先~targetに対しては~path成分は無視され， `not-example.com/path^c に合致するので。 ◎ Assuming that https://example.com/redirector delivered a redirect response pointing to https://not-example.com/not-path, the load would succeed, as the initial URL matches example.com, and the redirect target matches not-example.com/path if we ignore its path component.

この制約は、~redirectが in-play にあるとき，文書の施策の粒度を粗くする — それは，理想とは言えないが、~redirect後の~brute-forcing-pathはおよそ許容しないことが求まれるので，適理な妥協点に見受けられる。 ◎ This restriction reduces the granularity of a document’s policy when redirects are in play, which isn’t wonderful, but given that we certainly don’t want to allow brute-forcing paths after redirects, it seems a reasonable compromise.

public-webappsec@w3.org による比較的長い~thread — `CSP から~pathを除去するか？＠https://lists.w3.org/Archives/Public/public-webappsec/2014Feb/0036.html$ — にて、代案にまつわる，より詳細な論がある。 ◎ The relatively long thread "Remove paths from CSP?" from public-webappsec@w3.org has more detailed discussion around alternate proposals.

4.2.3. `nonce^a 属性

~nonce~sourceは、 `script$e, `style$e の両~要素に，新たな属性 `nonce@a の追加を要求する。 ◎ Nonce sources require a new nonce attribute to be added to both script and style elements.

partial interface `HTMLScriptElement$I {
  attribute DOMString `nonce$m;
};

DOMString `nonce@m: この属性は、 `script$e 要素の `nonce^a 内容~属性の値を`反映する$。 ◎ This attribute reflects the value of the element’s nonce content attribute.

partial interface `HTMLStyleElement$I {
  attribute DOMString `nonce$m;
};

DOMString `nonce@m: この属性は、 `style$e 要素の `nonce^a 内容~属性の値を`反映する$。 ◎ This attribute reflects the value of the element’s nonce content attribute.

4.2.4. 妥当な~nonce

要素が %~source式~集合に対する `妥当な~nonce@ を持つとは、要素が次を満たすことを~~意味する ⇒ ［ `前後の~ASCII空白~列を剥ぐ$( 要素の `nonce$a 属性~値 ) の結果］~IN`~ACI$［ %~source式~集合内のすべての［ `nonce-source$p 式の `nonce-value$p 成分］からなる集合］ ◎ An element has a valid nonce for a set of source expressions if the value of the element’s nonce attribute after stripping leading and trailing whitespace is a case-sensitive match for the nonce-value component of at least one nonce-source expression in set of source expressions.

4.2.5. 妥当な~hash

`要素~内容@ とは、［ `script$e 要素に対しては，`~script~blockの~source$ ］であり、［他の要素（ `style$e など）に対しては，その `textContent$m ~IDL属性の値］である。 ◎ An element’s content is the script block’s source for script elements, or the value of the element’s textContent IDL attribute for non-script elements such as style.

要素は、次の手続きの結果が true になるとき，［ %~source式~集合に対する `妥当な~hash@ を持つ］とされる： ◎ The digest of element’s content for is the result of applying an algorithm to the element’s content. ◎ To determine whether element has a valid hash for a set of source expressions, execute the following steps:

%~source式~集合内の，各 ( `hash-source$p 式 %~hash ) に対し： ◎ Let hashes be a list of all hash-source expressions in set of source expressions. ◎ For each hash in hashes:
1. %~algo ~LET %~hash の`hash-algo$p 成分に応じて： ◎ Let algorithm be:
  
  `sha256^lt
  
  `SHA-256$ ◎ SHA-256 if the hash-algo component of hash is an ASCII case-insensitive match for the string "sha256"
  
  `sha384^lt
  
  `SHA-384$ ◎ SHA-384 if the hash-algo component of hash is an ASCII case-insensitive match for the string "sha384"
  
  `sha512^lt
  
  `SHA-512$ ◎ SHA-512 if the hash-algo component of hash is an ASCII case-insensitive match for the string "sha512"
2. %期待される値 ~LET %~hash の `hash-value$p 成分 ◎ Let expected be the hash-value component of hash.
3. %~digest ~LET `要素~内容$に %~algo を適用した結果 — この値は、要素の `内容~digest@ と呼ばれる。 ◎ ↓
4. %実際の値 ~LET %~digest を`base64 符号化-$した結果 ◎ Let actual be the base64 encoding of the binary digest of element’s content using the algorithm algorithm.
5. ~IF %実際の値 ~EQ %期待される値 ⇒ ~RET true ◎ If actual is a case-sensitive match for expected, return true and abort these steps.
~RET false ◎ Return false.

注記：要素が妥当でない~hashを持つ場合、~UAが［ ~hashの %実際の値を包含する警告~message ］を追加して，作者へ失敗が報告されれば助けになるであろう。 ◎ Note: If an element has an invalid hash, it would be helpful if the user agent reported the failure to the author by adding a warning message containing the actual hash value.

4.3. ~MIME型~listの構文

`plugin-types$dir 指令は、その値に `~MIME型~list@ を利用する。【~MIME型は，原文では “`media type^en” であるが、他の仕様と一貫させるため，この訳では一律に “~MIME型” と記す。】 ◎ The plugin-types directive uses a value consisting of a media type list.

~MIME型~list内の各 `~MIME型@ は、特定の，［保護される資源~内で`~plugin$を~instance化するときに，検索取得して利用できる資源の型］を表現する。 ◎ Each media type in the media type list represents a specific type of resource that can be retrieved and used to instantiate a plugin in the protected resource.

`media-type-list@p
	= `media-type$p *( 1*`WSP$P `media-type$p )
`media-type@p
	= <type from RFC 2045> "/" <subtype from RFC 2045>

4.3.1. 構文解析-法

~UAは、 %~MIME型~list を `~MIME型~listとして構文解析-@ するときは，次と等価な~algoを利用するモノトスル： ◎ To parse a media type list media type list, the user agent MUST use an algorithm equivalent to the following:

%~MIME型~集合 ~LET 空~集合 ◎ Let the set of media types be the empty set.
`~ASCII空白で分割する$( %~MIME型~list ) — その結果を成す~EACH( ~token ) に対し ⇒ ~IF ~tokenは `media-type$p の文法に合致する ⇒ ~tokenを%~MIME型~集合に追加する ◎ For each token returned by splitting media type list on spaces, if the token matches the grammar for media-type, add the token to the set of media types. Otherwise ignore the token.
~RET %~MIME型~集合 ◎ Return the set of media types.

4.3.2. 照合-法

与えられた %~MIME型が `~MIME型~listに合致-@ するとは、 %~MIME型 ~IN`~ACI$ ［その~listを`~MIME型~listとして構文解析-$して得される~MIME型の集合］であることを~~意味する。 ◎ A media type matches a media type list if, and only if, the media type is an ASCII case-insensitive match for at least one token in the set of media types obtained by parsing the media type list.

4.4. 報告-法

%url を `報告~用に剥ぐ@ ~algoは： ◎ To strip uri for reporting, the user agent MUST use an algorithm equivalent to the following:

~IF %url の`生成元$は`~GUID$である（例えば， %url の~schemeが［ `data^sc ／ `blob^sc ／ `filesystem^sc ］のとき） ⇒ ~RET %url の`~scheme$urlを~ASCII直列化した結果 ◎ If the origin of uri is a globally unique identifier (for example, uri has a scheme of data, blob, or filesystem), then abort these steps, and return the ASCII serialization of uri’s scheme.
~IF［ %url と保護される資源］の`生成元$は、同じでない ⇒ ~RET `生成元を直列化する$( %url の`生成元$ ) ◎ If the origin of uri is not the same as the origin of the protected resource, then abort these steps, and return the ASCII serialization of uri’s origin.
~RET %url から`素片$url成分を除去した結果 ◎ Return uri, with any fragment component removed.

~UAは、 `違反~報告~objを生成-@ するときは，次と等価な~algoを利用するモノトスル： ◎ To generate a violation report object, the user agent MUST use an algorithm equivalent to the following:

%違反 ~LET ［次に挙げる各種 ~key, および対応する値］を伴う，新たな `~JSON~obj$： ◎ Prepare a JSON object violation with the following keys and values:

`blocked-uri@vr

読込ngが防止された資源の［元々の【~redirect前の】要請された~URL ］を，`報告~用に剥いだ$結果 — ただし、資源の~URLがない場合（例えば，~inlineの ~script／~style）は，空~文字列。 ◎ The originally requested URL of the resource that was prevented from loading, stripped for reporting, or the empty string if the resource has no URL (inline script and inline style, for example).

`document-uri@vr

保護される資源の`~address$を`報告~用に剥いだ$結果。 ◎ The address of the protected resource, stripped for reporting.

`effective-directive@vr

違反された施策~指令の名前。これは、違反を誘発させた施行nを与える`指令$ （例： "`script-src$dir"）を包含することになる — その指令が，施策~内に明示的に出現せず， `default-src$dir 指令により暗黙的に作動化されるものであるとしても。 ◎ The name of the policy directive that was violated. This will contain the directive whose enforcement triggered the violation (e.g. "script-src") even if that directive does not explicitly appear in the policy, but is implicitly activated via the default-src directive.

`original-policy@vr

~UAにより受信された，元の`施策$。 ◎ The original policy, as received by the user agent.

`referrer@vr

保護される資源の `~referrer0$m 属性の値。保護される資源の~referrerがないならば空~文字列になる。 ◎ The referrer attribute of the protected resource, or the empty string if the protected resource has no referrer.

`status-code@vr

保護される資源が~HTTP越しに得されていた場合は，それを包含していた~HTTP応答の`状態s~code$ ／他の場合, 数値 0 。 ◎ The status-code of the HTTP response that contained the protected resource, if the protected resource was obtained over HTTP. Otherwise, the number 0.

`violated-directive@vr

施策に出現したそのままの，違反された施策~指令。これは、`既定の~sources$に~fall-backした指令により，違反が生じた場合は、 `default-src$dir 指令を包含することになる。 ◎ The policy directive that was violated, as it appears in the policy. This will contain the default-src directive in the case of violations caused by falling back to the default sources when enforcing a directive.
違反が生じた箇所 — 特定の行lや特定の~file — を識別できる場合（例えば， `script-src$dir 指令に違反した~script実行）、~UAは，［次に挙げる各種~key, および対応する値］を %違反に追加してもヨイ： ◎ If a specific line or a specific file can be identified as the cause of the violation (for example, script execution that violates the script-src directive), the user agent MAY add the following keys and values to violation:

`source-file@vr

違反が生じた資源の~URLを，`報告~用に剥いだ$結果。 ◎ The URL of the resource where the violation occurred, stripped for reporting.

`line-number@vr

`source-file$p の中で違反が生じた行番号。 ◎ The line number in source-file on which the violation occurred.

`column-number@vr

`source-file$p の中で違反が生じた列番号。 ◎ The column number in source-file on which the violation occurred.
~RET %違反 ◎ Return violation.

注記： `blocked-uri$vr は、（一回以上の）~redirectの後に阻止された資源の最終的な所在は，包含しない。代わりに，~redirectを追従する前の，保護される資源が要請された所在のみを包含する。 ◎ Note: blocked-uri will not contain the final location of a resource that was blocked after one or more redirects. It instead will contain only the location that the protected resource requested, before any redirects were followed.

`違反~報告を送信する@ ~algoは： ◎ To send violation reports, the user agent MUST use an algorithm equivalent to the following:

%報告~obj ~LET 単独の［ ~key：値］として［ `csp-report^vr ： `違反~報告~objを生成-$した結果］を伴う，新たな `~JSON~obj$ ◎ Prepare a JSON object report object with a single key, csp-report, whose value is the result of generating a violation report object.
%報告~本体 ~LET %報告~obj を `~JSON文字列~化$した結果 ◎ Let report body be the JSON stringification of report object.
`報告~URL$ 内の~EACH ( %報告~URL ) に対し： ◎ For each report URL in the set of report URLs:
1. ~UAは、次をしてもヨイ ⇒ ~IF ［保護される資源に対する違反~報告を %報告~URL へ向けて既に送信していた］ ~AND［その報告は， %報告~本体に正確に合致する`~payload本体$を包含していた］ ⇒ ~CONTINUE ◎ If the user agent has already sent a violation report for the protected resource to report URL, and that report contained an entity body that exactly matches report body, the user agent MAY abort these steps and continue to the next report URL.
2. ［次のように設定する下で`~fetch$する］`~taskを~queueする$：
  - “resource or URL” ~SET %報告~URL
  - “from an origin” ~SET 保護される資源の生成元
  - “synchronous flag” ~SET `~F^em
  - ~HTTP~method ~SET `POST^c
  - `Content-Type^h ~header値 ~SET `application/csp-report^c
  - `~payload本体$ ~SET %報告~本体
  - “block cookies flag” ~SET ~IS［ %報告~URL と保護される資源とは，生成元が同じでない ］
  ~UAは、この資源の~fetch時に~redirectに追従しないモノトスル。（注記： ~UAは~fetchされた資源を無視する。）
  
  これらの`~task$の`~task~source$は、 `~CSP~task~source@ とする。
  ◎ Queue a task to fetch report URL from the origin of the protected resource, with the synchronous flag not set, using HTTP method POST, with a Content-Type header field of application/csp-report, and an entity body consisting of report body. If the origin of report URL is not the same as the origin of the protected resource, the block cookies flag MUST also be set. The user agent MUST NOT follow redirects when fetching this resource. (Note: The user agent ignores the fetched resource.) The task source for these tasks is the Content Security Policy task source.

`違反を報告-@ するときは，~UAは次を行うモノトスル： ◎ To report a violation, the user agent MUST:

保護される資源の `Document$I へ向けて`違反~eventを発火する$ ◎ Fire a violation event at the protected resource’s Document.
~IF `報告~URL$ は空でない ⇒ `違反~報告を送信する$ ◎ If the set of report URLs is non-empty, send violation reports to each.

注記：この仕様のこの節は、［［［［［これらの~algoにて指定されるものを超えるような，~data漏洩e ］を制限するために，違反~報告に制約を適用する］ような，~UAの能］を制限するもの］として解釈されるべきでない。例えば，~UAは、［報告ngをまるごと不能化する~option ］を，利用者に提供することもある。 ◎ Note: This section of the specification should not be interpreted as limiting user agents' ability to apply restrictions to violation reports in order to limit data leakage above and beyond what these algorithms specify. For example, a user agent might offer users the option of disabling reporting entirely.

5. 処理~model

`施策$を `施行-@ する~UAは、施策を`施策として構文解析-$して，その結果に包含される各~指令について，施行するモノトスル。各~指令の施行に対する特定の要件は、各種~指令ごとに別々に定義される（`指令$secを見よ）。 ◎ To enforce a 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 §7 Directives, below).

一般的に言って、指令の施行は，保護される資源によるある種の動作 — `~source~list$ 内に指示されるもの以外の~URLから~scriptを読込むなど — の遂行を防止する。攻撃者にとっては、この仕方で制約された資源に対してはその特権を奪えなくなるので、注入の脆弱性が資源にあるとしても，そこから突破るのはより困難になる。 ◎ Generally speaking, enforcing a directive prevents the protected resource from performing certain actions, such as loading scripts from URLs 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.

注記： ~UAは、施策の施行nを［利用者-選好／ ~bookmarklet ／ ~UA向けの第三者-主体による追加機能／他のそのような仕組み］を通して［改変したり, 迂回する］ことを，利用者に許容してもヨイ。 ◎ Note: User agents may allow users to modify or bypass policy enforcement through user preferences, bookmarklets, third-party additions to the user agent, and other such mechanisms.

施策を `監視-@ する~UAは、施策を`施策として構文解析-$して，その結果に包含される各~指令を監視するモノトスル。 ◎ To monitor a policy, the user agent MUST parse the policy and monitor each of the directives contained in the policy.

指令の監視においては、保護される資源により執行される動作を防止しない。指令の施行-時には防止されることになるどの動作も許容され、代わりに，~web~appの開発者へ向けて，違反~報告が`生成されて報告される＠#report-a-violation$。施策の監視は、その施行が~web~appに機能不全をもたらすかどうか，~testするために有用になる。 ◎ 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 allowed, but a violation report is generated and reported to the developer of the web application. Monitoring a policy is useful for testing whether enforcing the policy will cause the web application to malfunction.

~serverは、［ `Content-Security-Policy$h, `Content-Security-Policy-Report-Only$h ］両~headerを返すことにより、~UAに，ある施策を監視させつつ, 別の施策を施行させてもヨイ。例えば，ある施策を`施行-$すると同時に，より厳格な施策を実験したいと望む~server運用者は、元の施策を施行している間に，より厳格な施策を監視できる。 ~server運用者は、より厳格な施策の下でも~web~appを非互換化しないことに満足したなら，その施行を開始できる。 ◎ 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 may wish to enforce one policy but experiment with a stricter policy, she 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は、その施策が指令を全く包含しないならば，【~UAの】開発者~consoleにて警告~messageを報告するベキである。 ◎ If the user agent monitors or enforces a policy that does not contain any directives, the user agent SHOULD report a warning message in the developer console.

`監視-$ ／ `施行-$ する~UAは、施策が認識できない指令を包含するならば，その指令の名前を指示する警告~messageを，開発者~consoleにて報告するベキである。 ◎ If the user agent monitors or enforces a 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.

5.1. ~worker

~UAは、`~workerを走らす$ときには、~workerの~scriptの生成元に応じて： ◎ Whenever a user agent runs a worker:

`~GUID$である場合（例えば，［ ~workerの~scriptの~URLの~scheme ］ ~IN { `data^sc, `blob^sc, `filesystem^sc } ）： ◎ If the worker’s script’s origin is a globally unique identifier (for example, the worker’s script’s URL has a scheme of data, blob, or filesystem), then:: ~UAは，~workerの［所有者~文書, または親~worker ］に対し~CSP施策を［ `施行-$／`監視-$ ］しているならば、~workerに対しても，同じ~CSP施策を［ `施行-$／`監視-$ ］するモノトスル。 ◎ If the user agent is enforcing a CSP policy for the owner document or parent worker, the user agent MUST enforce the CSP policy for the worker. ◎ If the user agent is monitoring a CSP policy for the owner document or parent worker, the user agent MUST monitor the CSP policy for the worker.
他の場合：: ~workerの~scriptが，［［ `Content-Security-Policy^h ／ `Content-Security-Policy-Report-Only^h ］~HTTP~headerを伴って，送達されたもの］であるならば、~workerに対し，その~header値による施策を［ `施行-$／`監視-$ ］するモノトスル。 ◎ If the worker’s script is delivered with a Content-Security-Policy HTTP header containing the value policy, the user agent MUST enforce policy for the worker. ◎ If the worker’s script is delivered with a Content-Security-Policy-Report-Only HTTP header containing the value policy, the user agent MUST monitor policy for the worker.

5.2. `srcdoc^a `iframe^e

~UAは、保護される資源に対し`施策$を［ `施行-$／`監視-$ ］している下で，`~iframe-srcdoc文書$を，保護される資源の中で入子にされる閲覧~文脈にて作成する］ときは、その文書に対しても，同じ`施策$を［ `施行-$／`監視-$ ］するモノトスル。 ◎ Whenever a user agent creates an iframe srcdoc document in a browsing context nested in the protected resource, if the user agent is enforcing any policies for the protected resource, the user agent MUST enforce those policies on the iframe srcdoc document as well. ◎ Whenever a user agent creates an iframe srcdoc document in a browsing context nested in the protected resource, if the user agent is monitoring any policies for the protected resource, the user agent MUST monitor those policies on the iframe srcdoc document as well.

6. ~script~interface

6.1. `SecurityPolicyViolationEvent^I ~interface

interface `SecurityPolicyViolationEvent@I : `Event$I {
    constructor(DOMString %type, optional `SecurityPolicyViolationEventInit$I %eventInitDict);

    readonly    attribute DOMString `documentURI$m;
    readonly    attribute DOMString `referrer$m;
    readonly    attribute DOMString `blockedURI$m;
    readonly    attribute DOMString `violatedDirective$m;
    readonly    attribute DOMString `effectiveDirective$m;
    readonly    attribute DOMString `originalPolicy$m;
    readonly    attribute DOMString `sourceFile$m;
    readonly    attribute DOMString `statusCode$m;
    readonly    attribute long      `lineNumber$m;
    readonly    attribute long      `columnNumber$m;
};

readonly DOMString `documentURI@m: 違反~報告の `document-uri$vr ~propを指す。 ◎ Refer to the document-uri property of violation reports for a description of this property.
readonly DOMString `referrer@m: 違反~報告の `referrer$vr ~propを指す。 ◎ Refer to the referrer property of violation reports for a description of this property.
readonly DOMString `blockedURI@m: 違反~報告の `blocked-uri$vr ~propを指す。 ◎ Refer to the blocked-uri property of violation reports for a description of this property.
readonly DOMString `violatedDirective@m: 違反~報告の `violated-directive$vr ~propを指す。 ◎ Refer to the violated-directive property of violation reports for a description of this property.
readonly DOMString `effectiveDirective@m: 違反~報告の `effective-directive$vr ~propを指す。 ◎ Refer to the effective-directive property of violation reports for a description of this property.
readonly DOMString `originalPolicy@m: 違反~報告の `original-policy$vr ~propを指す。 ◎ Refer to the original-policy property of violation reports for a description of this property.
readonly DOMString `statusCode@m: 違反~報告の `status-code$vr ~propを指す。 ◎ Refer to the status-code property of violation reports for a description of this property.
readonly DOMString `sourceFile@m: 違反~報告の `source-file$vr ~propを指す。 ◎ Refer to the source-file property of violation reports for a description of this property.
readonly long `lineNumber@m: 違反~報告の `line-number$vr ~propを指す。 ◎ Refer to the line-number property of violation reports for a description of this property.
readonly long `columnNumber@m: 違反~報告の `column-number$vr ~propを指す。 ◎ Refer to the column-number property of violation reports for a description of this property.

6.2. `SecurityPolicyViolationEventInit^I ~interface

dictionary `SecurityPolicyViolationEventInit@I : `EventInit$I {
    DOMString `documentURI$m;
    DOMString `referrer$m;
    DOMString `blockedURI$m;
    DOMString `violatedDirective$m;
    DOMString `effectiveDirective$m;
    DOMString `originalPolicy$m;
    DOMString `sourceFile$m;
    long      `lineNumber$m;
    long      `columnNumber$m;
};

この dictionary は、 `SecurityPolicyViolationEvent$I ~objを構築するために利用される。各種~memberは、その~interfaceの同じ名前の属性を初期化する。 ◎ documentURI, of type DOMString ◎ Refer to the document-uri property of violation reports for a description of this property. ◎ referrer, of type DOMString ◎ Refer to the referrer property of violation reports for a description of this property. ◎ blockedURI, of type DOMString ◎ Refer to the blocked-uri property of violation reports for a description of this property. ◎ violatedDirective, of type DOMString ◎ Refer to the violated-directive property of violation reports for a description of this property. ◎ effectiveDirective, of type DOMString ◎ Refer to the effective-directive property of violation reports for a description of this property. ◎ originalPolicy, of type DOMString ◎ Refer to the original-policy property of violation reports for a description of this property. ◎ sourceFile, of type DOMString ◎ Refer to the source-file property of violation reports for a description of this property. ◎ lineNumber, of type long ◎ Refer to the line-number property of violation reports for a description of this property. ◎ columnNumber, of type long ◎ Refer to the column-number property of violation reports for a description of this property.

6.3. 違反~eventの発火-法

`違反~eventを発火する@ ~algoは： ◎ To fire a violation event, the user agent MUST use an algorithm equivalent to the following:

%報告~obj ~LET `違反~報告~objを生成-$した結果 ◎ Let report object be the result of generating a violation report object.
次を行う`~taskを~queueする$ ⇒ 名前 `securitypolicyviolation^et の`~eventを発火する$ — ~eventには `SecurityPolicyViolationEvent$I を利用し，各種~属性は，次のように初期化して ⇒＃ `blockedURI^m ~SET %報告~obj . `blocked-uri$vr `documentURI^m ~SET %報告~obj . `document-uri$vr `effectiveDirective^m ~SET %報告~obj . `effective-directive$vr `originalPolicy^m ~SET %報告~obj . `original-policy$vr `referrer^m ~SET %報告~obj . `referrer$vr `violatedDirective^m ~SET %報告~obj . `violated-directive$vr `sourceFile^m ~SET %報告~obj . `source-file$vr `lineNumber^m ~SET %報告~obj . `line-number$vr `columnNumber^m ~SET %報告~obj . `column-number$vr ◎ Queue a task to fire an event named securitypolicyviolation using the SecurityPolicyViolationEvent interface with the following initializations: • blockedURI MUST be initialized to the value of report object’s blocked-uri key. • documentURI MUST be initialized to the value of report object’s document-uri key. • effectiveDirective MUST be initialized to the value of report object’s effective-directive key. • originalPolicy MUST be initialized to the value of report object’s original-policy key. • referrer MUST be initialized to the value of report object’s referrer key. • violatedDirective MUST be initialized to the value of report object’s violated-directive key. • sourceFile MUST be initialized to the value of report object’s source-file key. • lineNumber MUST be initialized to the value of report object’s line-number key. • columnNumber MUST be initialized to the value of report object’s column-number key.

（ここでの記法 “%~obj . %~key” は、 %~obj の［名前 %~key に対応する値］を表す）

この`~task$の`~task~source$は、`~CSP~task~source$とする。 ◎ The task source for these tasks is the Content Security Policy task source.

7. 指令

この節では、この仕様にて導入された，内容~security施策指令について述べる。どの指令~名も大小無視である。 ◎ This section describes the content security policy directives introduced in this specification. Directive names are case insensitive.

~XSSに抗して保護するため、 ~web~app作者は，次のいずれかを含めるベキである： ◎ In order to protect against Cross-Site Scripting (XSS), web application authors SHOULD include:

`script-src$dir, `object-src$dir 指令の両者。 ◎ both the script-src and object-src directives, or
~script, ~pluginの両者を受持つ， `default-src$dir 指令。 ◎ include a default-src directive, which covers both scripts and plugins.
【上の二項の組み合せ】

いずれの事例でも、作者は，自身による施策~内に `unsafe-inline^pl ／ `data:^sc を妥当な~sourceに含ませるベキでない。両者とも，［文書~自身~内に~codeを直に含めることを許容する］ため，~XSS攻撃を可能化するので。それらは完全に避けるのが最善である。 ◎ In either case, authors SHOULD NOT include either 'unsafe-inline' or data: as valid sources in their policies. Both enable XSS attacks by allowing code to be included directly in the document itself; they are best avoided completely.

【共通な記述を簡潔に記すため、この訳では，次の２つの非公式な定義を導入する：】

［ `保護される資源$に対する`施策$ %施策］, および［ `指令~名$ %指令 , `~source式$の集合 %~fallback ］が与えられた下での，記法： `許容~sources@( %指令｜ %~fallback ) は、次で与えられる`~source式$の集合を表す：

%施策内に %指令が明示的に指定されている場合：: %指令の値を`~source~listとして構文解析-$した結果
他の場合：: %~fallback

所与の［資源への`~fetch$が伴われるような，`保護される資源$における %活動］を所与の［ `保護される資源$に対する`~source式$の集合 %許容~sources ］で `制約する@ ~algoは：

%url ~LET %活動の一環で`~fetch$することになる，資源の~URL
~IF %url は %許容~sources に`合致し$ない ⇒ 致命的~network~errorにより資源が得せなかったかのように動作した`上で^em，`違反を報告-$する。

7.1. `base-uri^dir

`base-uri@p 指令は、［ `文書~基底~URL$を指定するときに利用できる~URL ］を制約する。この指令の名前と値の~ABNF構文は： ◎ The base-uri directive restricts the URLs that can be used to specify the document base URL. The syntax for the name and value of the directive are described by the following ABNF grammar:

`directive-name$p
	= "base-uri"
`directive-value$p
	= `source-list$p

`許容~基底~URL@ は、 `許容~sources$( `base-uri$dir ｜ † ) で与えられる。 ◎ The term allowed base URLs refers to the result of parsing the base-uri directive’s value as a source list.

注記： `base-uri$dir は、 `既定の~sources$に~fall-backしない。【†何に~fall-backするのか記述がない。】 ◎ Note: base-uri does not fall back to the default sources.

HTML5 にて定義される`文書~基底~URL$を得する ~algoの step 4【？】は、次のように変更されなければナラナイ： ◎ Step 4 of the algorithm defined in HTML5 to obtain a document’s base URL MUST be changed to:

~IF［前 step が成功裡でない］~OR［以前の step の結果が `保護される資源$に対する`許容~基底~URL$に`合致し$ない］ ⇒ `文書~基底~URL$ ~SET %~fallback基底~URL （他の場合，前 step の結果のまま） ◎ If the previous step was not successful, or the result of the previous step does not match the allowed base URLs for the protected resource, then the document base URL is fallback base URL. Otherwise, it is the result of the previous step.

7.2. `child-src^dir

`child-src@dir 指令は、［ `入子な閲覧~文脈$sec／ `Worker^I 実行~文脈］の作成を統治する。この指令の名前と値の~ABNF構文は： ◎ The child-src directive governs the creation of nested browsing contexts as well as Worker execution contexts. The syntax for the name and value of the directive are described by the following ABNF grammar:

`directive-name$p
	= "child-src"
`directive-value$p
	= `source-list$p

`許容~child~sources@ は、 `許容~sources$( `child-src$dir ｜ `既定の~sources$ ) で与えられる。 ◎ The term allowed child sources refers to the result of parsing the child-src directive’s value as a source list if a child-src directive is explicitly specified, and otherwise to the default sources.

7.2.1. 入子な閲覧~文脈

~UAが `child-src$dir 指令を施行するときは、 `frame-src$dir 指令を施行するモノトスル。【前者は非推奨にされた後者の改称。】 ◎ To enforce the child-src directive the user agent MUST enforce the frame-src directive.

7.2.2. ~worker

~UAは、［ `Worker$I／`SharedWorker$I `WORKERS$r の構築子を処理する］ときに、`保護される資源$に対する`許容~child~sources$で`制約する$モノトスル。 ◎ Whenever the user agent fetches a URL while processing the Worker or SharedWorker constructors [WORKERS], the user agent MUST act as if there was a fatal network error and no resource was obtained, and report a violation if the URL does not match the allowed child sources for the protected resource.

7.3. `connect-src^dir

`connect-src@dir 指令は、［保護される資源が，~script~interfaceを利用してどの~URL【の資源】を読込めるか］を制約する。この指令の名前と値の~ABNF構文は： ◎ The connect-src directive restricts which URLs 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$p
	= "connect-src"
`directive-value$p
	= `source-list$p

`許容~接続~target@ は、 `許容~sources$( `connect-src$dir ｜ `既定の~sources$ ) で与えられる。 ◎ The term allowed connection targets refers to the result of parsing the connect-src directive’s value as a source list if the policy contains an explicit connect-src directive, or otherwise to the default sources.

~UAは、`保護される資源$における次の活動を，`許容~接続~target$で`制約する$モノトスル。 ◎ Whenever the user agent fetches a URL in the course of one of the following activities, if the URL does not match the allowed connection targets for the protected resource, the user agent MUST act as if there was a fatal network error and no resource was obtained, and report a violation:

`XMLHttpRequest$I ~objの `send()$m ~methodを処理するとき ◎ Processing the send() method of an XMLHttpRequest object.
`WebSocket$I 構築子を処理するとき ◎ Processing the WebSocket constructor.
`EventSource$I 構築子を処理するとき ◎ Processing the EventSource constructor.
`~hyperlink聴取-時＠~HTMLlinks#hyperlink-auditing$に，端点へ~pingするとき ◎ Pinging an endpoint during hyperlink auditing.
`sendBeacon()$m ~methodにより~beaconを送信するとき `BEACON$r ◎ Sending a beacon via the sendBeacon() method [BEACON]

7.3.1. 用法

◎非規範的

~JavaScriptは、［情報を送受信するために外部~serverへ直に接続する］ための，少数の仕組みを提供する： ◎ JavaScript offers a few mechanisms that directly connect to an external server to send or receive information.＼

`EventSource$I は、~push通知を受信するために，~serverへ開な~HTTP接続を保守する。 ◎ EventSource maintains an open HTTP connection to a server in order to receive push notifications,＼
`WebSocket$I は、~browser↔~server間で，双方向-通信~channelを開く。 ◎ WebSockets open a bidirectional communication channel between your browser and a server, and＼
`XMLHttpRequest$I は、~appに利するため，任意な~HTTP要請を為す。 ◎ XMLHttpRequest makes arbitrary HTTP requests on your behalf.＼

これらは、有用な機能性を可能化する強力な~APIであるが、~dataの不正転送へ誘う道も供する。 ◎ These are powerful APIs that enable useful functionality, but also provide tempting avenues for data exfiltration.

`connect-src$dir 指令は、これらの類の接続が開かれるのは，作者が信用する生成元に限られることを確保する。［この指令に対する~source式の~list ］を定義する施策の送信は、単直である。例えば，接続を `example.com^c のみに制限するときは、次の~headerを送信する： ◎ The connect-src directive allows you to ensure that these sorts of connections are only opened to origins you trust. Sending a policy that defines a list of source expressions for this directive is straightforward. For example, to limit connections to only example.com, send the following header:

Content-Security-Policy:
    `connect-src$dir example.com

この指令の下では、次のいずれも失敗することになる： ◎ All of the following will fail with the preceding directive in place:

new WebSocket("wss://evil.com/");

(new XMLHttpRequest()).open("GET", "https://evil.com/", true);

new EventSource("https://evil.com");

7.4. `default-src^dir

`default-src@dir 指令は、各種~指令に対する `既定の~source~list@ を設定する。この指令の名前と値の~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$p
	= "default-src"
`directive-value$p
	= `source-list$p

`既定の~sources@ は、 `許容~sources$( `default-src$dir ｜ { `*^lt } ) で与えられる。 ◎ Let the default sources be the result of parsing the default-src directive’s value as a source list if a default-src directive is explicitly specified, and otherwise the U+002A ASTERISK character (*).

~UAは、 `default-src$dir 指令を施行するときは，次の指令を施行するモノトスル： ◎ To enforce the default-src directive, the user agent MUST enforce the following directives:

`child-src$dir
`connect-src$dir
`font-src$dir
`img-src$dir
`media-src$dir
`object-src$dir
`script-src$dir
`style-src$dir

上に挙げた指令が，施策~内に明示的に指定されていない場合、それらの`~source~list$には`既定の~sources$を利用することになる。【`既定の~sources$も明示的に指定されていなかった場合、~ASTERISK （＝制約なし）になるので，その指令については施行-／監視しないのと~~同じことになる（ `data:^sc 等の `~GUID~URL~scheme$secは別として）。】 ◎ If not specified explicitly in the policy, the directives listed above will use the default sources as their source list.

7.4.1. 用法

◎非規範的

その名前が示すように、 `default-src$dir は，［他の`~source~list$指令が明示的に設定されなかった場合に ~fallbackとして利用されることになる，`既定の~source~list$ ］を~~供する。すなわち，次の施策~宣言を考えるとき： ◎ default-src, as the name implies, serves as a default source list which the other source list-style directives will use as a fallback if they’re not otherwise explicitly set. That is, consider the following policy declaration:

Content-Security-Policy:
    `default-src$dir `self^pl

この施策の下では、［ ~font／~frame／画像／~media／~obj／~script／~style ］が読込まれるのは，保護される資源と同じ生成元からに限られ、同じ生成元~向けに限って接続されることになる。施策により特定な宣言を追加すると、その型の資源に対する`既定の~source~list$を完全に上書きすることになる。 ◎ Under this policy, fonts, frames, images, media, objects, scripts, and styles will all only load from the same origin as the protected resource, and connections will only be made to the same origin. Adding a more specific declaration to the policy would completely override the default source list for that resource type.

Content-Security-Policy:
    `default-src$dir `self^pl;
    `script-src$dir example.com

この新たな施策の下では、~script以外については，前の例と同じになるが、~scriptの読込ngは， `example.com^c からに`限られる^em。すなわち，継承のようなものはない — `script-src$dir 指令は、許容される［ ~scriptの~source ］を設定し、その型の資源には，`既定の~source~list$は利用されない。 ◎ Under this new policy, fonts, frames, and etc. continue to be load from the same origin, but scripts will only load from example.com. There’s no inheritance; the script-src directive sets the allowed sources of script, and the default list is not used for that resource type.

この挙動の下で，~site用に施策を築く良い仕方の一つは、まず， `default-src$dir を `none^pl にする所から始め、［ ~site作者が実際に利用-中にある，保護したい~page資源の型］のみを包含するように，施策を築上げるものになるであろう。一例として、~webfontを利用しないならば， `font-src$dir に対する~source~listを指定する理由もない — 施策に指定するものを~pageが利用する資源~型に限っておけば、その~pageに対しアリな攻撃~面も，アリな限り小さくなる。 ◎ Given this behavior, one good way of building a policy for a site would be to begin with a default-src of 'none', and to build up a policy from there that contains only those resource types which are actually in use for the page you’d like to protect. If you don’t use webfonts, for instance, there’s no reason to specify a source list for font-src; specifying only those resource types a page uses ensures that the possible attack surface for that page remains as small as possible.

7.5. `font-src^dir

`font-src@dir 指令は、［保護される資源が~fontをどこから読込めるか］を制約する。この指令の名前と値の~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$p
	= "font-src"
`directive-value$p
	= `source-list$p

`許容~font~sources@ は、 `許容~sources$( `font-src$dir ｜ `既定の~sources$ ) で与えられる。 ◎ The term allowed font sources refers to the result of parsing the font-src directive’s value as a source list if the policy contains an explicit font-src, or otherwise to the default sources.

~UAは、`保護される資源$における次の活動を，`許容~font~sources$で`制約する$モノトスル： ◎ Whenever the user agent fetches a URL in the course of one of the following activities, if the URL does not match the allowed font sources for the protected resource, the user agent MUST act as if there was a fatal network error and no resource was obtained, and report a violation:

~fontにて表示するために~dataを要請するとき — `font-face$at ~CSS規則を処理するときなど。 ◎ Requesting data for display in a font, such as when processing the <<@font-face>> Cascading Style Sheets (CSS) rule.

7.6. `form-action^dir

`form-action@dir は、［ ~HTML `form$e 要素の動作として，どの~URLを利用できるか］を制約する。この指令の名前と値の~ABNF構文は： ◎ The form-action restricts which URLs can be used as the action of HTML form elements. The syntax for the name and value of the directive are described by the following ABNF grammar:

`directive-name$p
	= "form-action"
`directive-value$p
	= `source-list$p

`許容~form動作@ は、 `許容~sources$( `form-action$dir ｜ { `*^lt } ) で与えられる。 ◎ The term allowed form actions refers to the result of parsing the form-action directive’s value as a source list.

~UAは、［ ~HTML `form$e 要素の処理］を，`保護される資源$に対する`許容~form動作$で`制約する$モノトスル。 ◎ Whenever the user agent fetches a URL in the course of processing an HTML form element, if the URL does not match the allowed form actions for the protected resource, the user agent MUST act as if there was a fatal network error and no resource was obtained, and report a violation.

注記： `form-action$dir は、指令が定義されないときも，`既定の~sources$に~fall-backしない。すなわち， `form-action$dir を定義しない施策は、 `default-src$dir `none^pl を定義していようが，どの~targetへの~form提出も許容することになる。 ◎ Note: form-action does not fall back to the default sources when the directive is not defined. That is, a policy that defines default-src 'none' but not form-action will still allow form submissions to any target.

7.7. `frame-ancestors^dir

`frame-ancestors@p 指令は、［【保護される】資源を［［ `frame$e／`iframe$e／`object$e／`embed$e／`applet$e ］要素を利用して【他の資源~内に】埋込むこと, または［非~HTML資源における等価な機能性］］を，~UAが許容するべきかどうか］を指示する。この指令を利用すれば、［敵対的にもなり得る文脈の中へ，【保護される】資源が埋込まれない］ようになり、 `UI Redressing^en `UIREDRESS$r 攻撃の多くを避けれる。 ◎ The frame-ancestors directive indicates whether the user agent should allow embedding the resource using a frame, iframe, object, embed or applet element, or equivalent functionality in non-HTML resources. Resources can use this directive to avoid many UI Redressing [UIREDRESS] attacks by avoiding being embedded into potentially hostile contexts.

【 `UI Redressing^en：利用者~interfaceの “着せ替え” — 通称 “`clickjacking^en（~click行為の乗っ取り）” 】

この指令の名前と値の~ABNF構文は： ◎ The syntax for the name and value of the directive are described by the following ABNF grammar:

`ancestor-source-list@p
	= [ `ancestor-source$p *( 1*`WSP$P `ancestor-source$p ) ]
	/ "`none^pl"
`ancestor-source@p
	= `scheme-source$p
	/ `host-source$p

`directive-name$p
	= "frame-ancestors"
`directive-value$p
	= `ancestor-source-list$p

`許容~frame先祖@ は、 `許容~sources$( `frame-ancestors$dir ｜ { `*^lt } ) で与えられる。 ◎ The term allowed frame ancestors refers to the result of parsing the frame-ancestors directive’s value as a source list. If a frame-ancestors directive is not explicitly included in the policy, then allowed frame ancestors is "*".

~UAは、［ `frame-ancestors$dir 指令を施行している下で，保護される資源を `入子な閲覧~文脈$ %入子な文脈の中へ読込もうと］するときは，次の手続きを遂行するモノトスル： ◎ To enforce the frame-ancestors directive, whenever the user agent would load the protected resource into a nested browsing context, the user agent MUST perform the following steps:

%先祖~list ~LET %入子な文脈のすべての`先祖~閲覧~文脈$からなる~list ◎ Let nestedContext be the nested browsing context into which the protected resource is being loaded. ◎ Let ancestorList be the list of all ancestors of nestedContext.
%先祖~list 内の~EACH ( %先祖~文脈 ) に対し†： ◎ For each ancestorContext in ancestorList:
1. %文書 ~LET %先祖~文脈にて`作動中な文書$bc ◎ Let document be ancestorContext’s active document.
2. ~IF %文書の~URLが`保護される資源$に対する`許容~frame先祖$に`合致する$ ⇒ ~CONTINUE ◎ If document’s URL does not match the allowed frame ancestors for the protected resource, the user agent MUST:
3. 保護される資源の読込ngを中止する ◎ Abort loading the protected resource.
4. （A）次のいずれかを行う： ◎ Take one of the following actions:
  - 空な `~HTTP 200 応答$を受信したかのように動作する。 ◎ Act as if it received an empty HTTP 200 response.
  - ［阻止された~pageを新たな`~top-level閲覧~文脈$内に開くための~option ］を供するような，利用者に親切な~error~pageへ利用者を~redirectする。 ◎ Redirect the user to a friendly error page which provides the option of opening the blocked page in a new top-level browsing context.
5. （B）［ input：空~文字列； output：［新たに作成される文書の`強制d~sandbox法~flag集合$ ］］を利用して，`~sandbox法~指令を構文解析する$。 ◎ Parse a sandboxing directive using the empty string as the input and the newly created document’s forced sandboxing flag set as the output.
6. `違反を報告-$する。 ◎ Report a violation.
7. ~RET ◎ Abort these steps.

【† 繰返しの順序が指定されていない。利用者~側から見える結果は，順序に依存しないようだが、違反~報告の内容は順序に依存するかもしれない。】

段（A）, （B）は、［阻止された~frameが，通常の非同一-生成元文書の読込nとして出現する］ことを確保する。これらの手続きが無視された場合、文書の施策~状態が漏洩する可能性がある。 ◎ Steps 3.2.2 and 3.2.3 ensure that the blocked frame appears to be a normal cross-origin document’s load. If these steps are ignored, leakage of a document’s policy state is possible.

`frame-ancestors$dir 指令は、［施策を`監視-$するとき, および `meta$e 要素を介して定義される施策に包含されているとき］は無視するモノトスル。 ◎ The frame-ancestors directive MUST be ignored when monitoring a policy, and when a contained in a policy defined via a meta element.

注記： `frame-ancestors$dir は、指令が定義されないときも，`既定の~sources$に~fall-backしない。すなわち， `form-ancestors$dir を定義しない施策は、 `default-src$dir `none^pl を定義していようが，資源をどこからでも~frame化することを許容する。 ◎ Note: frame-ancestors does not fall back to the default sources when the directive is not defined. That is, a policy that defines default-src 'none' but not frame-ancestors will still allow the resource to be framed from anywhere.

~UAは、 `frame-ancestors$dir 違反に対する違反~報告を生成するときに，埋込んでいる先祖の値を `blocked-uri$vr 値に含めないモノトスル — それが保護される資源と同一-生成元でない限り — 非同一-生成元先祖の値の公開0は、 Same-Origin Policy（同一-生成元~施策）に違反するので。 ◎ When generating a violation report for a frame-ancestors violation, the user agent MUST NOT include the value of the embedding ancestor as a blocked-uri value unless it is same-origin with the protected resource, as disclosing the value of cross-origin ancestors is a violation of the Same-Origin Policy.

7.7.1. `X-Frame-Options^h との関係

この指令は、いくつかの~UAに実装されている `X-Frame-Options$h ~headerに類似する。 ~source式 `none^pl は、概ね，その~headerの［ DENY, self to SAMEORIGIN, and so on 【？】］に等価である。 ~~主な相違は、多くの~UAが［ ~top-level文書の所在に対してのみ合致するような， SAMEORIGIN ］を実装する一方で、この指令は，各~先祖ごとに検査することである。合致しない先祖があれば、読込nは取消される。 `RFC7034$r ◎ This directive is similar to the X-Frame-Options header that several user agents have implemented. The 'none' source expression is roughly equivalent to that header’s DENY, 'self' to SAMEORIGIN, and so on. The major difference is that many user agents implement SAMEORIGIN such that it only matches against the top-level document’s location. This directive checks each ancestor. If any ancestor doesn’t match, the load is cancelled. [RFC7034]

`frame-ancestors$dir 指令は、 `X-Frame-Options$h ~headerを`廃用にする^em。資源が両~施策を持つ場合、 `frame-ancestors$dir のみが施行され， `X-Frame-Options^h は無視されるベキである。 ◎ The frame-ancestors directive obsoletes the X-Frame-Options header. If a resource has both policies, the frame-ancestors policy SHOULD be enforced and the X-Frame-Options policy SHOULD be ignored.

7.7.2. 複数の~host~source値

◎非規範的

`~top-level閲覧~文脈$より複数~level下における~app部品の埋込みを孕むような局面を可能化するため、単独の施策~内の複数の `source-list$p 式も許容される（対照的に， `X-Frame-Options$h が許容するのは一つだけである）。 ◎ Multiple source-list expressions are allowed in a single policy (in contrast to X-Frame-Options, which allows only one) to enable scenarios involving embedded application components that are multiple levels below the top-level browsing context.

多くの共通的な埋込み局面（例：許可付きの埋込可能な［支払い／共有／~social ］~app）が孕む妥当な `source-list$p 式は，幾千にもなり得るが、そのような局面に適応させるときは［複数の値を~listする静的な `frame-ancestors$dir 指令］が，強く推奨される。そのような事例では、この値を，［［ ~HTTP `Referer^h ~header, または明示的に渡される値］に基づいて，各［［所与の資源］の埋込みに必要yな~source ］のみを許容するように，動的に生成することが役立つ。 ◎ Many common scenarios for permissioned embedding (e.g. embeddable payment, sharing or social apps) involve potentially many hundreds or thousands of valid source-list expressions, but it is strongly recommended against accommodating such scenarios with a static frame-ancestors directive listing multiple values. In such cases it is beneficial to generate this value dynamically, based on an HTTP Referer header or an explicitly passed-in value, to allow only the sources necessary for each given embedding of the resource.

［ `https://payments/makeEmbedded^s にある支払い用~app ］を供するような~serviceを考える。この~serviceは、この資源が［互いに競う事業者たち，［ Alice と Bob ］の両者により埋込まれる］ことを許容する。次を送信することは： ◎ Consider a service providing a payments application at https://payments/makeEmbedded. The service allows this resource to be embedded by both merchant Alice and merchant Bob, who compete with each other. Sending:

Content-Security-Policy:
    `frame-ancestors$dir https://Alice https://Bob

は、 Bob に［ Alice の資源を再~frame化して，詐欺的な~clickを作成する］こと【 `clickjacking^en 】を許容し、たぶん Alice を彼女の顧客や支払い~serviceと伴に失墜させることになる。支払い~serviceが、追加的な情報を利用して（例えば `https://payments/makeEmbedded?merchant=Alice^s のように，~URLの一部として），［［各~事業者に必要な `source-list$p 式のみを~listする］ような，個々に誂えられた~headerたち］を送信するならば、この攻撃は解消されるであろう。 ◎ would allow Bob to re-frame Alice’s resource and create fraudulent clicks, perhaps discrediting Alice with her customers or the payments service. If the payments service used additional information (e.g. as part of a URL like https://payments/makeEmbedded?merchant=alice) to send individually-tailored headers listing only the source-list expressions needed by each merchant, this attack would be eliminated.

7.8. `frame-src^dir

`frame-src@dir 指令は、【指令~名として】`非推奨にされた^em。入子な閲覧~文脈を統治したいと望む作者は、代わりに `child-src$dir 指令を利用するベキである。 ◎ The frame-src directive is deprecated. Authors who wish to govern nested browsing contexts SHOULD use the child-src directive instead.

`frame-src$dir 指令は、［保護される資源が，どこからの~frameを埋込めるか］を制約する。この指令の名前と値の~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$p
	= "frame-src"
`directive-value$p
	= `source-list$p

`許容~frame~sources@ は、 `許容~sources$( `frame-src$dir ｜ `許容~child~sources$ ) で与えられる。 ◎ The term allowed frame sources refers to the result of parsing the frame-src directive’s value as a source list if the policy contains an explicit frame-src, or otherwise to the list of allowed child sources.

~UAは、`保護される資源$における次の活動を，`許容~frame~sources$で`制約する$モノトスル： ◎ Whenever the user agent fetches a URL in the course of one of the following activities, if the URL does not match the allowed frame sources for the protected resource, the user agent MUST act as if there was a fatal network error and no resource was obtained, and report a violation:

保護される資源~内に［［ `iframe$e ／ `frame$e ］要素により作成される`入子な閲覧~文脈$ ］を表示するために，~dataを要請するとき ◎ Requesting data for display in a nested browsing context in the protected resource created by an iframe or a frame element.
そのような`入子な閲覧~文脈$を`~navigate$したとき ◎ Navigated such a nested browsing context.

7.9. `img-src^dir

`img-src@dir 指令は、［保護される資源が画像をどこから読込めるか］を制約する。この指令の名前と値の~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$p
	= "img-src"
`directive-value$p
	= `source-list$p

`許容~画像~sources@ は、 `許容~sources$( `img-src$dir ｜ `既定の~sources$ ) で与えられる。 ◎ The term allowed image sources refers to the result of parsing the img-src directive’s value as a source list if the policy contains an explicit img-src, or otherwise to the list of default sources.

~UAは、`保護される資源$における次の活動を，`許容~画像~sources$で`制約する$モノトスル： ◎ Whenever the user agent fetches a URL in the course of one of the following activities, if the URL does not match the allowed image sources for the protected resource, the user agent MUST act as if there was a fatal network error and no resource was obtained, and report a violation:

画像~用に~dataを要請するとき — 次のものを処理するときなど：
- `img$e 要素の［ `src^a ／ `srcset^a ］属性
- `input$e 要素の `src^a 属性
- `type="image"$a 型の `input$e 要素
- `video$e 要素の `poster$a 属性
- `url()$f
- 画像を読込む能力があるような，~CSS~prop上の［ `image()$f ／ `image-set()$f ］値 `CSS4-IMAGES$r
- `icon^c などの画像に関係する `rel$a 属性を伴う `link$e 要素の `href$a 属性
◎ Requesting data for an image, such as when processing the src or srcset attributes of an img element, the src attribute of an input element with a type of image, the poster attribute of a video element, the url(), image() or image-set() values on any Cascading Style Sheets (CSS) property that is capable of loading an image [CSS4-IMAGES], or the href attribute of a link element with an image-related rel attribute, such as icon.

7.10. `media-src^dir

`media-src@dir 指令は、［保護される資源が［動画／音声, およびそれに結付けられた~text~track ］をどこから読込めるか］を制約する。この指令の名前と値の~ABNF構文は： ◎ The media-src directive restricts from where the protected resource can load video, audio, and associated text tracks. The syntax for the name and value of the directive are described by the following ABNF grammar:

`directive-name$p
	= "media-src"
`directive-value$p
	= `source-list$p

`許容~media~sources@ は、 `許容~sources$( `media-src$dir ｜ `既定の~sources$ ) で与えられる。 ◎ The term allowed media sources refers to the result of parsing the media-src directive’s value as a source list if the policy contains an explicit media-src, or otherwise to the list of default sources.

~UAは、`保護される資源$における次の活動を，`許容~media~sources$で`制約する$モノトスル： ◎ Whenever the user agent fetches a URL in the course of one of the following activities, if the URL does not match the allowed media sources for the protected resource, the user agent MUST act as if there was a fatal network error and no resource was obtained, and report a violation:

動画／音声 ~clip用に~dataを要請するとき — `video$e／`audio$e／`source$e／`track$e 要素の `src^a 属性を処理するときなど。 ◎ Requesting data for a video or audio clip, such as when processing the src attribute of a video, audio, source, or track element.

7.11. `object-src^dir

`object-src@dir 指令は、［保護される資源が，~pluginをどこから読込めるか］を制約する。この指令の名前と値の~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$p
	= "object-src"
`directive-value$p
	= `source-list$p

`許容~obj~sources@ は、 `許容~sources$( `object-src$dir ｜ `既定の~sources$ ) で与えられる。 ◎ The term allowed object sources refers to the result of parsing the object-src directive’s value as a source list if the policy contains an explicit object-src, or otherwise to the list of default sources.

~UAは、`保護される資源$における次の活動を，`許容~obj~sources$で`制約する$モノトスル： ◎ Whenever the user agent fetches a URL in the course of one of the following activities, if the URL does not match the allowed object sources for the protected resource, the user agent MUST act as if there was a fatal network error and no resource was obtained, and report a violation:

~plugin用に~dataを要請するとき — 次の属性を処理するときなど
- `object$e 要素の `data$a 属性
- `embed$e 要素の `src^a 属性
- `applet$e 要素の［ `code$m／`archive$m ］属性
◎ Requesting data for a plugin, such as when processing the data attribute of an object element, the src attribute of an embed element, or the code or archive attributes of an applet element.
保護される資源にて，［［［ `object$e ／`embed$e ］要素により作成された`入子な閲覧~文脈$ ］内に表示するための~data ］を要請するとき。 ◎ Requesting data for display in a nested browsing context in the protected resource created by an object or an embed element.
`入子な閲覧~文脈$を~navigateするとき ◎ Navigating such a nested browsing context.

`object-src$dir 指令を施行するとき，要素の~dataを消費するものは、`~plugin$に限られる必要はない。［ `object$e／`embed$e／`applet$e ］要素~用の~dataへの~fetchは、`許容~obj~sources$で`制約する$モノトスル。これは、要素~dataが［さもなければ、他のいずれかの`指令＠#directives$により制約されることになる内容（~MIME型 `text/html^c の `object$e 要素など）］に意味論的に等価になるときにも該当する。 ◎ 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 §7 Directives, such as an object element with a text/html MIME type.

~UAは、［保護される資源の~URLが，`保護される資源$に対する`許容~obj~sources$に`合致し$ない］下では，［ ~URLが結付けられていない`~plugin$（例： `data$a 属性を欠く `object$e 要素）］を読込まないモノトスル。 ◎ Whenever the user agent would load a plugin without an associated URL (e.g., because the object element lacked a data attribute), if the protected resource’s URL does not match the allowed object sources for the protected resource, the user agent MUST NOT load the plugin.

7.12. `plugin-types^dir

【 `plugin-types$dir 指令は、 ~level 3 にて`除去された＠https://github.com/w3c/webappsec-csp/pull/456$。 ~plugin特能~自体も， ~HTML仕様からほぼ（~PDF用の~supportを除き）`廃され＠~HTMLissue/6003$、その拡張能としての能力は今やない。】

`plugin-types@dir 指令は、埋込める資源の型を制限することにより，［保護される資源が呼出せる~pluginの集合］を制約する。この指令の名前と値の~ABNF構文は： ◎ The plugin-types directive restricts the set of plugins that can be invoked by the protected resource by limiting the types of resources that can be embedded. The syntax for the name and value of the directive are described by the following ABNF grammar:

`directive-name$p
	= "plugin-types"
`directive-value$p
	= `media-type-list$p

`許容~plugin~MIME型@ は、 `plugin-types$dir 指令の値を `~MIME型~listとして構文解析-$した結果を指す ◎ The term allowed plugin media types refers to the result of parsing the plugin-types directive’s value as a media type list.

~UAは、［ `plugin-types$dir 指令を施行している下で %資源を取扱う際に，`~plugin$を~instance化しようとする］ときは，次を行うモノトスル： ◎ Whenever the user agent would instantiate a plugin to handle resource while enforcing the plugin-types directive, the user agent MUST instead act as though the plugin reported an error and report a violation if any of the following conditions hold:

代わりに，~pluginが~errorを報告したかのように動作する。
`加えて^em，次のいずれかの条件が成立するならば`違反を報告-$する：
- ［ ~pluginは、［ `object$e／`embed$e ］要素を介して，保護される資源の中へ埋込まれている］~AND［その要素の `type$a 属性にて，明示的に`~MIME型$xが宣言されていない］。 ◎ The plugin is embedded into the protected resource via an object or embed element that does not explicitly declare a MIME type via a type attribute.
- %資源の~MIME型は、`許容~plugin~MIME型$による`~MIME型~listに合致-$しない。 ◎ resource’s media type does not match the list of allowed plugin media types.
- ［ ~pluginは、［ `object$e ／ `embed$e ］要素を介して，保護される資源の中へ埋込まれている］~AND［［ %資源の~MIME型］~NEQ`~ACI$［要素の `type$a 属性にて宣言されている~MIME型］］ ◎ The plugin is embedded into the protected resource via an object or embed element, and the media type declared in the element’s type attribute is not an ASCII case-insensitive match for the resource’s media type.
- ［ ~pluginは、 `applet$e 要素を介して，保護される資源の中へ埋込まれている］~AND［［ %資源の~MIME型］ ~NEQ`~ACI$ `application/x-java-applet^lt ］ ◎ The plugin is embedded into the protected resource via an applet element, and resource’s media type is not an ASCII case-insensitive match for application/x-java-applet.
注記：いずれの事例でも、~UAは，`~fallback内容$を表示することになる。 ◎ Note: In any of these cases, acting as though the plugin reported an error will cause the user agent to display the fallback content.

~UAが，保護される資源に対し `plugin-types$dir 指令を［ `施行-$／`監視-$ ］している下で、［ ~plugin文書を［ `保護される資源$の`子~閲覧~文脈$にて`作動中な文書$bc ］として作成する］ときは、［ ~plugin文書~上の `plugin-types$dir 指令］についても［ `施行-$／`監視-$ ］するモノトスル。 ◎ Whenever the user agent creates a plugin document as the active document of a child browsing context of the protected resource, if the user agent is enforcing any plugin-types directives for the protected resource, the user agent MUST enforce those plugin-types directives on the plugin document as well. ◎ Whenever the user agent creates a plugin document as the active document of a child browsing context of the protected resource, if the user agent is monitoring any plugin-types directives for the protected resource, the user agent MUST monitor those plugin-types directives on the plugin document as well.

7.12.1. 用法

◎非規範的

`plugin-types$dir 指令は、［保護される資源~内に埋込まれ得る一定の~MIME型］からなる集合を~whitelist化する。例えば~siteが，［ ~PDF内容は読込みつつ, 他の~pluginは~instance化できない］ことを確保したいと求めるならば、次の指令で充足させられるであろう： ◎ The plugin-types directive whitelists a certain set of MIME types that can be embedded in a protected resource. For example, a site might want to ensure that PDF content loads, but that no other plugins can be instantiated. The following directive would satisfy that requirement:

Content-Security-Policy:
    `plugin-types$dir application/pdf

［［ `embed$e／`object$e ］要素を介して埋込まれ，内容~型 `application/pdf^lt を伴って送達される資源］は，適切な~plugin内に具現化される一方で、［他の内容~型を伴って送達される資源］は，阻止されることになる。複数の型を順序を問わず指定できる。 ~siteが追加的に Flash も許容すると裁定したなら，次の指令により指定できる： ◎ Resources embedded via an embed or object element delivered with an application/pdf content type would be rendered in the appropriate plugin; resources delivered with some other content type would be blocked. Multiple types can be specified, in any order. If the site decided to additionally allow Flash at some point in the future, it could do so with the following directive:

Content-Security-Policy:
    `plugin-types$dir application/pdf application/x-shockwave-flash

注記： `plugin-types$dir 指令~内では~wildcardは受容されない。指令~内に明示的に~listされた型の資源のみが許容される。 ◎ Note: Wildcards are not accepted in the plugin-types directive. Only the resource types explicitly listed in the directive will be allowed.

7.12.2. 期待される~MIME型の事前宣言

◎非規範的

`plugin-types$dir 指令を施行している下で、［［ `object$e ／`embed$e ］要素により埋込まれる資源］が読込まれるためには、［その資源に期待される~MIME型が，要素の `type$a 属性にて宣言される］ことが要求される。作者が~PDFの読込nを期待するならば、次のように指定することもできる： ◎ Enforcing the plugin-types directive requires that object and embed elements declare the expected media type of the resource they include via the type attribute. If an author expects to load a PDF, she could specify this as follows:

<object data="%資源~URL" type="application/pdf"></object>

%資源が実際には~PDF~fileでない場合、読込まれない。これは、［ ~UAが［作者が意図しない~pluginでも，予期せず呼出す］ように，内容を~serveする］ことに依拠するような，ある型の攻撃を防止する。 ◎ If resource isn’t actually a PDF file, it won’t load. This prevents certain types of attacks that rely on serving content that unexpectedly invokes a plugin other than that which the author intended.

注記：この局面においては、 %資源は，その~MIME型が~whitelist化されるものであっても，読込まれない：資源が読込まれるのは、その~MIME型が［ ~whitelist化されていて, `なおかつ^em 資源を包含している要素にて宣言された型に合致する］場合に限られる。 ◎ Note: resource will not load in this scenario even if its media type is otherwise whitelisted: resources will only load when their media type is whitelisted and matches the declared type in their containing element.

7.13. `report-uri^dir

`report-uri@dir 指令は、［ ~UAが施策~違反についての報告を送信する~URL ］を指定する。この指令の名前と値の~ABNF構文は： ◎ The report-uri directive specifies a URL 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$p
	= "report-uri"
`directive-value$p
	= `uri-reference$p *( 1*`WSP$P `uri-reference$p )
`uri-reference@p
	= <URI-reference from RFC 3986>

`report-uri$dir 指令の値は、 `報告~URL@ の集合を与える。そのそれぞれは，保護される資源の~URLに相対的に解決される ◎ The set of report URLs is the value of the report-uri directive, each resolved relative to the protected resource’s URL.

この指令の値~内に指定された~URLへ違反~報告を送信する処理は、この文書の`報告-法$secにより定義される ◎ The process of sending violation reports to the URLs specified in this directive’s value is defined in this document’s §4.4 Reporting section.

注記： `meta$e 要素の中の `report-uri$dir 指令は、無視される（`~meta要素$sec）。 ◎ Note: The report-uri directive will be ignored if contained within a meta element.

7.14. `sandbox^dir

`sandbox@dir 指令は、［ ~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$p
	= "sandbox"
`directive-value$p
	= ""
	/ sandbox-token *( 1*`WSP$P `sandbox-token$p )
`sandbox-token@p
	= <token from RFC 7230>

~UAが `sandbox$dir 指令を施行するときは［ input： `directive-value^p ； output：保護される資源の`強制d~sandbox法~flag集合$ ］を利用して`~sandbox法~指令を構文解析する$モノトスル `HTML5$r ◎ When enforcing the sandbox directive, the user agent MUST parse a sandboxing directive using the directive-value as the input and protected resource’s forced sandboxing flag set as the output. [HTML5]

`meta$e 要素を介して定義される施策~内の `sandbox$dir 指令は、無視される（`~meta要素$sec）。 `sandbox$dir 指令はまた、施策を`監視-$するときにも効果を及ぼさず，報告ngの要件もない。 ◎ The sandbox directive will be ignored when monitoring a policy, and when contained in a policy defined via a meta element. Moreover, this directive has no effect when monitored, and has no reporting requirements.

7.14.1. ~sandbox法と~worker

~HTTP~headerを介して送達される~CSPは、各種~sandbox法~flagは，［ `Document$I でない~JavaScript実行~環境に適用されるべきである］と指示することもある。特に関心が持たれるのは、［［ Worker ／ Shared Worker／ Service Worker ］利用に意図されている~script内容］である。各種~sandbox法~flagの多くは，そのような環境には適用されないが、 `allow-scripts$fl ／ `allow-same-origin$fl には，特別な要件がある ◎ When delivered via an HTTP header, a Content Security Policy may indicate that sandboxing flags ought to be applied to a JavaScript execution environment that is not a Document. Of particular interest is the script content intended for use as a Worker, Shared Worker, or Service Worker. Many of the sandboxing flags do not apply to such environments, but allow-scripts and allow-same-origin have special requirements.

~UAは、`~workerを走らす$~algoを実行するに伴って資源を読込むとき、次のいずれかの条件が成立する場合には、［致命的~network~errorにより，資源は得せなかった］かのように動作するモノトスル： ◎ When a resource is loaded while executing the runs a Worker algorithm, the user agent MUST act as if there was a fatal network error and no resource could be obtained if either of the following conditions holds:

資源に伴って送達された `sandbox$dir 指令は `allow-scripts$fl ~flagを`包含していない^em ◎ The sandbox directive delivered with the resource does not contain the allow-scripts flag.
資源に伴って送達された `sandbox$dir 指令は `allow-same-origin$fl ~flagを`包含していない^em, `かつ^em 新たな実行~文脈を作成するためには，それを作成している文脈と同一-生成元であることが要求されている。 ◎ The sandbox directive delivered with the resource does not contain the allow-same-origin flag, and the creation of the new execution context requires it to be same-origin with its creating context.

7.14.2. 用法

◎非規範的

HTML5 は `iframe$e 要素に対し `sandbox$a 属性を定義する — それには、［ ~web作者が、内容の能に制約を課すことにより，信用できない可能性のある内容を含む~riskを抑制できる］ようにすることが意図されている。この属性が設定された下では、 `iframe^e の内容は，一意な【他のすべての生成元と異なる】生成元に強制された上で，［ ~formを提出する／ ~scriptを走らす／他の閲覧~文脈を作成する／他の閲覧~文脈へ~navigateする／ ~pluginを走らす］ことはできなくなる。これらの制約は、属性の値にある種の~flagを設定することで緩めることもできる。 ◎ HTML5 defines a sandbox attribute for iframe elements, intended to allow web authors to reduce the risk of including potentially untrusted content by imposing restrictions on that content’s abilities. When the attribute is set, the content is forced into a unique origin, prevented from submitting forms, running script, creating or navigating other browsing contexts, and prevented from running plugins. These restrictions can be loosened by setting certain flags as the attribute’s value.

`sandbox$dir 指令は、どの資源においても — ~frame化されるかどうかを問わず — 同じ類の制約を自身に適用するかどうか依頼できるようにする。 ◎ The sandbox directive allows any resource, framed or not, to ask for the same sorts of restrictions to be applied to itself.

例えば，掲示板や~e-mail~systemには、他の利用者から供された任意な~attachmentの~downloadを供するものもある。［【利用者の意図nに関わらず】これらの~attachmentのどれかを具現化させるよう，~clientを騙す］ことに依拠する攻撃は、［資源が，ごく制約的な~sandboxの中でのみ具現化されるよう要請する］ことにより，軽減できる。そのような環境は、値が空にされた `sandbox$dir 指令を送信すれば，確立される： ◎ For example, a message board or email system might provide downloads of arbitrary attachments provided by other users. Attacks that rely on tricking a client into rendering one of these attachments could be mitigated by requesting that resources only be rendered in a very restrictive sandbox. Sending the sandbox directive with an empty value establishes such an environment:

Content-Security-Policy:
    `sandbox$dir

より信用される資源は、指令の値に `allow-*^lt ~flagを追加することにより，制約がより少ない環境の下で走らすことも許容されるであろう。例えば，~site作者は、信用している~pageにおいて，［それが~siteの他の~pageと同一-生成元であるように扱われない］ことを確保しつつ，~scriptを走らすのは許容することもできる。これは、 `allow-scripts$fl ~flagを伴わせた `sandbox$dir 指令を送信すれば成遂げれる： ◎ More trusted resources might be allowed to run in an environment with fewer restrictions by adding allow-* flags to the directive’s value. For example, you can allow a page that you trust to run script, while ensuring that it isn’t treated as same-origin with the rest of your site. This can be accomplished by sending the sandbox directive with the allow-scripts flag:

Content-Security-Policy:
    `sandbox$dir `allow-scripts^fl

~CSP指令に可用な~flagの集合は、 `iframe$e 属性にて可用なものに合致するべきである。現在、それらには次のものがある： ◎ The set of flags available to the CSP directive should match those available to the iframe attribute. Currently, those include:

`allow-forms$fl
`allow-pointer-lock$fl
`allow-popups$fl
`allow-same-origin$fl
`allow-scripts$fl
`allow-top-navigation$fl

注記： ~CSPの他の部分と同様に、 `sandbox$dir 指令には，多層防御が意味されている。 ~web作者は、標準な［ sniffing-mitigation, privilege-reduction 【？】］技法に対する`追加として^em利用することで，上手く~serveされる。 ◎ Note: Like the rest of Content Security Policy, the sandbox directive is meant as a defense-in-depth. Web authors would be well-served to use it in addition to standard sniffing-mitigation and privilege-reduction techniques.

7.15. `script-src^dir

`script-src@dir 指令は、［保護される資源がどの~scriptを実行できるか］を制約する。この指令は、［ `XSLT$r ~stylesheetなど，~UAに~scriptを実行させるような他の資源］も制御する。この指令の名前と値の~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$p
	= "script-src"
`directive-value$p
	= `source-list$p

`許容~script~sources@ は、 `許容~sources$( `script-src$dir ｜ `既定の~sources$ ) で与えられる。 ◎ The term allowed script sources refers to the result of parsing the script-src directive’s value as a source list if the policy contains an explicit script-src, or otherwise to the default sources.

~UAは、`許容~script~sources$内に［ `unsafe-inline^pl がない, または［ `nonce-source$p ／ `hash-source$p ］が在る］ならば： ◎ If 'unsafe-inline' is not in the list of allowed script sources, or if at least one nonce-source or hash-source is present in the list of allowed script sources:

次に挙げる~scriptを実行しようとするときは、実行せずに，その`違反を報告-$するモノトスル ◎ ↓
- `許容~script~sources$に対する［ `妥当な~nonce$を欠く, `かつ^em `妥当な~hash$を欠く］ような， `script$e 要素による~inline~script ◎ Whenever the user agent would execute an inline script from a script element that lacks a valid nonce and lacks a valid hash for the allowed script sources, instead the user agent MUST NOT execute script, and MUST report a violation.
- ~inline~event~handlerによる~inline~script ◎ Whenever the user agent would execute an inline script from an inline event handler, instead the user agent MUST NOT execute script, and MUST report a violation.
- `javascript:^sc ~URLに包含されている~script ◎ Whenever the user agent would execute script contained in a javascript URL, instead the user agent MUST NOT execute the script, and MUST report a violation.

~UAは、`許容~script~sources$内に `unsafe-eval^pl がないならば： ◎ If 'unsafe-eval' is not in allowed script sources:

演算子 `eval^c, 関数 `eval^c `ECMA-262$r のいずれに対しても，その引数は評価せずに `EvalError^E 例外を投出するモノトスル ◎ Instead of evaluating their arguments, both operator eval and function eval [ECMA-262] MUST throw an EvalError exception.
関数 `Function^c が構築子として~callされたときは、 `ECMA-262$r `EvalError^E 例外を投出するモノトスル ◎ When called as a constructor, the function Function [ECMA-262] MUST throw an EvalError exception.
［ `setTimeout()$m／`setInterval()$m ］関数は、その最初の引数に［ ~callableでないもの（ `IsCallable()$ が ~F を返すもの — 例えば，文字列）］を渡して~callされたときには、~timerを作成することなく 0 を返すモノトスル。 ◎ When called with a first argument that is not callable (a string, for example), the setTimeout() function MUST return zero without creating a timer. ◎ When called with a first argument that is not callable (a string, for example), the setInterval() function MUST return zero without creating a timer.

~UAは、`保護される資源$における次の活動を（~redirectに追従するときも含めて），`許容~script~sources$で`制約する$モノトスル： ◎ Whenever the user agent fetches a URL (including when following redirects) in the course of one of the following activities, if the URL does not match the allowed script sources for the protected resource, the user agent MUST act as if there was a fatal network error and no resource was obtained, and report a violation:

［ `許容~script~sources$に対する`妥当な~nonce$を欠くような， `script$e 要素］の `src^a 属性の処理に伴って，~scriptを要請するとき。 ◎ Requesting a script while processing the src attribute of a script element that lacks a valid nonce for the allowed script sources.
`WorkerGlobalScope$I `WORKERS$r ~obj上の `importScripts^c ~methodの呼出nに伴って，~scriptを要請するとき。 ◎ Requesting a script while invoking the importScripts method on a WorkerGlobalScope object. [WORKERS]
［［ `import^lt ~tokenを包含している `rel^c 属性］を伴う `link$e 要素］の `href^a 属性などの処理に伴って，~HTML部品を要請するとき。 `HTML-IMPORTS$r ◎ Requesting an HTML component, such as when processing the href attribute of a link element with a rel attribute containing the token import. [HTML-IMPORTS]
［ XML 文書~内の `<?xml-stylesheet?>^c 処理~指令 `XML11$r ／ `xsl:include^e 要素の `href^a 属性／ `xsl:import^e 要素］などの処理に伴って， `XSLT$r を要請するとき。 ◎ 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> and <xsl:import> elements.

7.15.1. `script^e 要素に対する~nonceの用法

◎非規範的

`script-src$dir 指令は、開発者が［正確に，~page上のどの `script$e 要素が、実行するものと意図されているか］を指定できるようにする。理想的には、開発者は，［ ~inline~scriptはまるごと避けて，~URLにより~scriptを~whitelist化する］方がよいが、~inline~scriptを除去するのが困難であったり不可能な事例もある。開発者は、そのような事例に対し，~randomに生成される~nonceを利用して，~scriptを~whitelist化できる。 ◎ The script-src directive lets developers specify exactly which script elements on a page were intentionally included for execution. Ideally, developers would avoid inline script entirely and whitelist scripts by URL. However, in some cases, removing inline scripts can be difficult or impossible. For those cases, developers can whitelist scripts using a randomly generated nonce.

用法は、単直である。 ~serverは、`各要請ごと^emに一意な値を~randomに生成して，それを `Content-Security-Policy^h ~header内に含ませる： ◎ Usage is straightforward. For each request, the server generates a unique value at random, and includes it in the Content-Security-Policy header:

Content-Security-Policy:
    `default-src$dir `self^pl;
    `script-src$dir `self^pl https://example.com 'nonce-$RANDOM'

これと同じ値は、実行されるべき各 `script$e 要素の `nonce$a 属性にも適用される。例えば，~serverは、~random値 `Nc3n83cnSAd3wc3Sasdfn939hc3^s を生成したなら，次の施策を送信することになる： ◎ This same value is then applied as a nonce attribute to each script element that ought to be executed. For example, if the server generated the random value Nc3n83cnSAd3wc3Sasdfn939hc3, the server would send the following policy:

Content-Security-Policy:
    `default-src$dir `self^pl;
    `script-src$dir `self^pl https://example.com 'nonce-Nc3n83cnSAd3wc3Sasdfn939hc3'

`script$e 要素は、［自身の `src^a 属性による~URLが~whitelist化されている, または`妥当な~nonce$を持つ］ならば，実行できるようになる： ◎ Script elements can then execute either because their src URLs are whitelisted or because they have a valid nonce:

<script>

// 施策に `unsafe-inline^pl が与えられてないので阻止される。
◎
alert("Blocked because the policy doesn’t have 'unsafe-inline'.")

</script>

<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa">

// `nonce^a が間違ってるので これも阻止される。
◎
alert("Still blocked because nonce is wrong.")

</script>

<script nonce="Nc3n83cnSAd3wc3Sasdfn939hc3">

// `nonce^a は妥当なので許容される。
◎
alert("Allowed because nonce is valid.")

</script>

<script src="https://example.com/allowed-because-of-src.js"
></script>

<script nonce="EDNnf03nceIOfn39fn3e9h3sdfa"
    src="https://elsewhere.com/blocked-because-nonce-is-wrong.js"
></script>

<script nonce="Nc3n83cnSAd3wc3Sasdfn939hc3"
    src="https://elsewhere.com/allowed-because-nonce-is-valid.js"
></script>

~nonceの値は、~script資源の内容（が~~正しく作られたかどうか）を検証yするような，~hashや~signature`ではない^emことに注意。それは，ごく単純に~randomな文字列であり、［どの~scriptが意図的に~pageに含められたものなのか］を~UAに伝えるものである。 ◎ Note that the nonce’s value is not a hash or signature that verifies the contents of the script resources. It’s quite simply a random string that informs the user agent which scripts were intentionally included in the page.

適正な~nonceを伴う `script^e 要素は、~inlineか外部かに関わらず実行される。適正な~nonceを伴わない `script^e 要素は、その~URLが~whitelist化されていない限り実行されない。攻撃者が、保護される資源の中へ~markupを注入できたとしても、~random値を推測できないので，攻撃は阻止される。 ◎ Script elements with the proper nonce execute, regardless of whether they’re inline or external. Script elements without the proper nonce don’t execute unless their URLs are whitelisted. Even if an attacker is able to inject markup into the protected resource, the attack will be blocked by the attacker’s inability to guess the random value.

7.15.2. `script^e 要素に対する~hashの用法

◎非規範的

`script-src$dir 指令は、開発者が ~hashを~scriptの許容~sourceとして指定することにより，特定0の~inline~scriptを~whitelist化できるようにする。 ◎ The script-src directive lets developers whitelist a particular inline script by specifying its hash as an allowed source of script.

用法は、単直である。 ~serverは、［特定0の~script~blockの内容］の~hashを算出して，それを base64 符号化した結果を `Content-Security-Policy^h ~header内に含ませる： ◎ Usage is straightforward. The server computes the hash of a particular script block’s contents, and includes the base64 encoding of that value in the Content-Security-Policy header:

Content-Security-Policy:
    `default-src$dir `self^pl;
    `script-src$dir `self^pl https://example.com 'sha256-%base64-encoded-hash'

各~inline~script~blockの内容は、~hash化された上で，~whitelist化された値に対して比較される。合致するものがあれば~scriptは実行される。例えば， `alert('Hello, world.');^s の SHA-256 ~digestは `qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=^s になる。 ◎ Each inline script block’s contents are hashed, and compared against the whitelisted value. If there’s a match, the script is executed. For example, the SHA-256 digest of alert('Hello, world.'); is qznLcsROx4GACP2dm0UCKCzCG+HiZ1guq6ZZDob/Tng=.

文字列の~digestは、例えば~command-lineで openssl ~programを用いれば得せる。例えば： ◎ You can obtain the digest of a string on the command line simply via the openssl program. For example:

echo -n "alert('Hello, world.');" | \
    openssl dgst -sha256 -binary | openssl enc -base64

~serverが次の~headerを送信した場合： ◎ If the server sent the following header:

Content-Security-Policy:
    `script-src$dir 'sha512-YWIzOWNiNzJjNDRlYzc4MTgwMDhmZDlkOWI0NTAyMjgyY2MyMWJlMWUyNjc1ODJlYWJhNjU5MGU4NmZmNGU3OAo='

次の~script~tagによる~scriptは実行されることになる： ◎ Then the following script tag would result in script execution:

<script>alert('Hello, world.');</script>

空白は有意である。次の~script~blockは、どれも~hash値が上のものと同じにならないので，`実行されない^em： ◎ Whitespace is significant. The following scripts blocks would not hash to the same value, and would therefore not execute:

<script> alert('Hello, world.');</script>
<script>alert('Hello, world.'); </script>
<script> alert('Hello, world.'); </script>
<script>
alert('Hello, world.');
</script>

また、~hashが適用されるのは，~inline~scriptに`限られる^emことに注意。値 `alert('Hello, world.');^s を包含する，外部~化された~scriptは、その生成元が~scriptの妥当な~sourceとして~whitelist化されていない限り，`実行されない^em。 ◎ Note also that the hash applies only to inline script. An externalized script containing the value alert('Hello, world.'); would not execute if its origin was not whitelisted as a valid source of script.

7.16. `style-src^dir

`style-src@dir 指令は、［保護される資源に，利用者がどの~styleを適用してもヨイか］を制約する。この指令の名前と値の~ABNF構文は： ◎ The style-src directive restricts which styles the user may applies to the protected resource. The syntax for the name and value of the directive are described by the following ABNF grammar:

`directive-name$p
	= "style-src"
`directive-value$p
	= `source-list$p

`許容~style~sources@ は、 `許容~sources$( `style-src$dir ｜ `既定の~sources$ ) で与えられる。 ◎ The term allowed style sources refers to the result of parsing the style-src directive’s value as a source list if the policy contains an explicit style-src, or otherwise to the default sources.

`許容~style~sources$の~list内に［ `unsafe-inline^pl がない, または［ `nonce-source$p ／ `hash-source$p ］が在る］場合： ◎ If 'unsafe-inline' is not in the list of allowed style sources, or if at least one nonce-source or hash-source is present in the list of allowed style sources:

~UAは、［次に挙げるものからの~style ］を適用しようとするときは、代わりに ~styleを無視して, `かつ^em `違反を報告-$するモノトスル
- `許容~style~sources$に対する［ `妥当な~nonce$を欠く, `かつ^em `妥当な~hash$を欠く］ような`style$e 要素
- `style$e 属性
◎ Whenever the user agent would apply style from a style element that lacks a valid nonce and lacks a valid hash for the allowed style sources, instead the user agent MUST ignore the style, and MUST report a violation. ◎ Whenever the user agent would apply style from a style attribute, instead the user agent MUST ignore the style, and MUST report a violation.

注記： ~inlineに対するこれらの制約は、~UAが［外部~stylesheet（例： `<link rel="stylesheet" ...>^c を介して見出されるものなど）からの~styleを適用する］ことを防止するものではない。 ◎ 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" ...>).

`許容~style~sources$内に `unsafe-eval^pl がない場合 ： ◎ If 'unsafe-eval' is not in allowed style sources, then:

~UAは、 `CSSOM$r ［ `~CSS規則を挿入する$／ `~CSS規則として構文解析する$／ `~CSS宣言~blockとして構文解析する$／ `選択子~listとして構文解析する$ ］~algoを呼出そうとするときには、代わりに `SecurityError$E 例外を投出した`上で^em，~algoを終了するモノトスル。これには、例えば， `CSSOM$r の各種［ `cssText^m 設定子や `insertRule()^m ~method ］に対するすべての呼出nも含まれる `HTML5$r ◎ Whenever the user agent would invoke the Cascading Style Sheets Object Model algorithms insert a CSS rule, parse a CSS rule, parse a CSS declaration block, or parse a group of selectors instead the user agent MUST throw a SecurityError exception and terminate the algorithm. This would include, for example, all invocations of CSSOM’s various cssText setters and insertRule methods. [CSSOM] [HTML5]

~UAは、`保護される資源$における［次により生じる，外部~stylesheetへの要請］を，`許容~style~sources$で`制約する$モノトスル： ◎ Whenever the user agent fetches a URL in the course of one of the following activities, if the URL does not match the allowed style sources for the protected resource, the user agent MUST act as if there was a fatal network error and no resource was obtained, and report a violation:

［ `rel$a 属性が~token `stylesheet$p を包含するような `link$e 要素］の `href$a を処理するとき。 ◎ Requesting an external stylesheet when processing the href of a link element whose rel attribute contains the token stylesheet.
`import$at 指令を処理するとき。 ◎ Requesting an external stylesheet when processing the <<@import>> directive.
`Link$h ~HTTP応答~header `RFC5988$r を処理するとき。 ◎ Requesting an external stylesheet when processing a Link HTTP response header field [RFC5988].

注記：この~stylesheetは `Document$I が実際に存在する前に~prefetchされることもあるので、~UAは，この要請を比較-対象にする`施策$を有意義に~instance化する方法を注意深く考慮する必要がある。詳細は，`処理の複雑化$secを見よ。 ◎ Note: As this stylesheet might be prefetched before a Document actually exists, user agents will need to carefully consider how to instantiate a meaningful policy against which to compare this request. See §10.1 Processing Complications for more detail.

注記： `style-src$dir 指令は~XSLTの利用を制約しない。 ~XSLTを制約するのは `script-src$dir 指令である。信用できない~XSLT~stylesheetを含むことの~security上の帰結は、信用できない~scriptを含むことにより被るものに類似するので。 ◎ 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.

7.16.1. `style^e 要素に対する~nonceの用法

◎非規範的

詳細は、 `script$e 要素に対する`~nonceの用法$secに。 `style$e 要素への~nonceの適用は、ここに再掲するまでもないほど， `script^e に対するときと十分~類似する。 ◎ See the script-src nonce usage information for detail; the application of nonces to style elements is similar enough to avoid repetition here.

7.16.2. `style^e 要素に対する~hashの用法

◎非規範的

詳細は、 `script$e 要素に対する`~hashの用法$secに。 `style$e 要素への~hashの適用は、ここに再掲するまでもないほど， `script^e に対するときと十分~類似する。 ◎ See the script-src hash usage information for detail; the application of hashes to style elements is similar enough to avoid repetition here.

8. 例

8.1. 施策~定義の見本

この節では、いくつかの［利用事例と, それを~supportする`施策$ ］の見本を供する。 ◎ This section provides some sample use cases and supporting policies.

資源を，自前の生成元に限って読込みたいと望む~server： ◎ A server wishes to load resources only from its own origin:

Content-Security-Policy:
    `default-src$dir `self^pl

次のものを読込みたいと望む~auction~site：［画像は，任意の~URLから／ ~plugin内容は，［信用-済みな~media~provider（内容~分散型~networkも含む）の~list ］からのみ／ ~scriptは，自身の制御の下にある~serverが~hostしている，無毒化されたもの］： ◎ An auction site wishes to load images from any URL, 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$dir `self^pl;
    `img-src$dir *;
    `object-src$dir media1.example.com media2.example.com *.cdn.example.com;
    `script-src$dir trustedscripts.example.com

~online銀行~site： ~secureでない内容~要請に対する，攻撃者による盗聴を防止するため、［ ~page内のすべての内容は， TLS 越しに読込まれる］ことを確保したいとする： ◎ An 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$dir https: 'unsafe-inline' 'unsafe-eval'

この施策は、［ ~inline内容（~inline `script$e 要素など）／ `eval^c を利用する／ ~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.

~inline `script$e 要素に依拠する~web~site — ~scriptは、［自前の生成元からの~script／意図的に~inlineに挿入した要素によるもの］についてのみ実行されることを確保したいと望むような： ◎ A website that relies on inline script elements wishes to ensure that script is only executed from its own origin, and those elements it intentionally inserted inline:

Content-Security-Policy:
    `script-src$dir `self^pl 'nonce-$RANDOM';

~inline `script$e 要素は、 `nonce$a 属性が合致するもののみ，実行されるようにする： ◎ The inline script elements would then only execute if they contained a matching nonce attribute:

<script nonce="$RANDOM">...</script>

8.2. 違反~報告の見本

この節では、保護される資源が見本の施策に違反したときに、~UAが~serverへ向けて送信するであろう，違反~報告の見本を挙げる。 ◎ This section contains an example violation report the user agent might sent to a server when the protected resource violations a sample policy.

この例では、~UAは `http://example.org/page.html^s にある資源の表現を，次の施策の下で具現化したとする： ◎ In the following example, the user agent rendered a representation of the resource http://example.org/page.html with the following policy:

`default-src$dir `self^pl; `report-uri$dir http://example.org/csp-report.cgi

`http://evil.example.com/image.png^s からの画像を読込もうとした保護される資源は、この施策に違反する。 ◎ The protected resource loaded an image from http://evil.example.com/image.png, violating the policy.

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

9. ~security上の考慮点

9.1. ~CSS（ Cascading Style Sheet ）の構文解析-法

`style-src$dir 指令は、［保護される資源が，~styleをどの所在から読込めるか］を制約する。しかしながら，~UAの~CSS構文解析-用の~algoが緩い場合、攻撃者は，他では信用に価する生成元に~hostされている悪意的 “~stylesheet” を受容するように，~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 "stylesheets" hosted by an otherwise trustworthy origin.

これらの攻撃は、 2009 年に Chris Evans 氏により示された `~CSS非同一-生成元~data漏洩e攻撃＠http://scarybeastsecurity.blogspot.com/2009/12/generic-cross-browser-cross-domain.html$ に類似する。いずれの攻撃に対しても、~UAは，同じ仕組み — ~MIME型が不適正な~stylesheetに対し，より厳格な~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.

9.2. ~redirect情報の漏洩e

この文書における違反~報告ngの仕組みは、［悪意的~web~siteが，違反~報告を利用して，他の~serverの挙動を探査する~risk ］を軽減するように設計されている。例えば，画像の~sourceとして `https://example.com^s を~whitelist化している，悪意的な~web~siteを考える。この~siteが、【 `example.com^s の~log-in用~pageの~URLである】 `https://example.com/login^s を画像として読込もうと試みた場合、 `example.com^s の~serverが，ある~identity~provider†（例えば `identityprovider.example.net^s とする）へ~redirectしたとするとき、~CSPにより，その要請は阻止されることになる。仮に、阻止された~URLを，違反~報告に全部的に包含することにした場合、違反~報告に，~redirect先の~URL内に［ ~session識別子や purported identities††などの敏感な情報］が包含されていれば，それも包含することになる。この理由から、~UAは，［阻止された~URL ］の生成元のみを含むようにされている。 ◎ 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., identityprovider.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 URL, such as session identifiers or purported identities. For this reason, the user agent includes only the origin of the blocked URL.

【† “~identity~provider” — IdP とも略称される，個人認証~serviceを専門に供する~providerを指すものと見られる。】【†† “purported identities（ある特定目的の識別情報）” — 現実の個人の識別は含意しないような，（当の~site~~専用の）異なる個人を別人として識別する類の情報と見られる。】

この軽減は完全でない。しかしながら：阻止される~redirectは、~JavaScriptから（例えば， `img.naturalHeight^m を介して）可視になり得るような副作用をもたらすことになる。この仕様の早期の~versionでは、~serverが，利用者を~redirectするのが完全に安全であったかどうか決定するために（ `Referer^h, `Origin^h ~headerと一緒に）利用することもできるような， `CSP^h 要請~header が定義された。この~headerは、CORS 処理において，ある課題があるため（ `whatwg/fetch#52＠https://github.com/whatwg/fetch/issues/52$ ）、この文書の次~versionへ~puntされた。 ◎ The mitigations are not complete, however: redirects which are blocked will produce side-effects which may be visible to JavaScript (via img.naturalHeight, for instance). An earlier version of this specification defined a CSP request header which servers could use (in conjunction with the referer and origin headers) to determine whether or not it was completely safe to redirect a user. This header caused some issues with CORS processing (tracked in whatwg/fetch#52), and has been punted to the next version of this document.

10. 実装にあたっての考慮点

`Content-Security-Policy$h ~headerは、端点間（ end-to-end ）~headerである。それは、~clientにて処理され，施行されるものであり、［資源と同じ管理v~domainに属さない，~proxyその他の`媒介者$ ］により，改変されたり除去されるベキでない。 ◎ 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.

資源が出自にしている管理v~domainは、 `Content-Security-Policy$h ~headerを，~appの直の文脈の外側にて適用したいと望むこともあろう。例えば、異なる個人や部署が管理している，多数の資源や~appを抱える巨大な組織では、それらすべてが統一的な組織-標準の~subjectになり得る。そのような状況では、 `Content-Security-Policy$h ~headerを，既存の［ ~networkに接する~security用~gateway機器や, ~web~app~firewall ］によるものに，追加する／組合せることもあり得る。複数の施策を施行するためには、管理者は，それらの施策を単独の~headerに結合するベキである。管理者は，自身が意図する意味論に応じて，異なる組合nの方法論を利用したいと望むかもしれない。 ◎ 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.

施策を組合せる方法論として，まず挙げられるのは、既定の~source集合を許容する所から始め，追加的な生成元を含めていくことにより、個々の上流の資源~所有者たちに許容される~sourceの集合を徐々に拡大していくことである。この~approachによる結果の施策は、入力の施策に許容されるすべての生成元の和集合になる。 ◎ 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.

別法として、所与の施策を絞り込んでいく方法論がある。この~approachでは、最初に，［内容が，一定の~whitelist化された生成元から来る］ように施行する所から始める — 例えば，開発者は、第三者-主体による~scriptや内容を、組織-標準と実施に違反するものとして，含めないよう除外しておくなど。この~approachでは、上流の資源~所有者から給される施策から，許容されない~hostを徐々に除去することにより、施策の組合nが形成されていく。 ◎ 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$dir と他の指令との間の相互作用が特別に考慮されるべきである。どの施策も `default-src$dir 指令を包含しない場合、新たな `*-src^dir 指令を追加した結果の施策は，より制約的になる。一方で、 `default-src$dir 指令を包含するような入力の施策が一つでもあれば、新たな `*-src^dir 指令を追加した結果の施策は、より制約的でなくなるであろう。例えば、より特定な【 `default-src^dir でない】指令により許容される生成元の集合が，【 `default-src^dir 】より寛容になる場合など。 ◎ 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.

資源~所有者が著作した入力~施策より制約的な施策の利用は、資源の具現化や運用を，想定以上に防止し得る。 ◎ Using a more restrictive policy than the input policy authored by the resource owner might prevent the resource from rendering or operating as intended.

注記： ~HTTPから~HTTPSへの移行にあたり，前と~~同じに稼働させるためには、施策の更新が要求されるかもしれない。 `http://example.com^s の様な~source式は、~HTTPS資源には`合致しない^em。例えば，管理者は、 ~app用に `HTTP Strict Transport Security＠~RFCx/rfc6797$ ~header `RFC6797$r を転開する前に，既存の施策を注意深く精査するベキである。 ◎ Note: Migration to HTTPS from HTTP may require updates to the policy in order to keep things running as before. Source expressions like http://example.com do not match HTTPS resources. For example, administrators SHOULD carefully examine existing policies before rolling out HTTP Strict Transport Security headers for an application. [RFC6797]

注記：

~server管理者は、全般の施策の一部に，他と異なる報告ng~optionが欲される場合に、複数の施策を送信したいと望むであろう。一例として、次の~headerは： ◎ Server administrators MAY wish to send multiple policies if different reporting options are desired for subsets of an overall policy. For instance, the following headers:

Content-Security-Policy:
    `frame-ancestors$dir https://example.com/
Content-Security-Policy:
    `default-src$dir https:;
    `report-uri$dir https://example.com/

~HTTP資源に対しては，違反~報告を送信することになるが、 `frame-ancestors$dir への違反に対しては，違反~報告を送信しない。これらは `,^lt を介して単独の~headerに結合しても： ◎ would send violation reports for http resources, but would not send violation reports for frame-ancestors violations. Note also that combining them via ',' into the single header

Content-Security-Policy:
    `frame-ancestors$dir https://example.com/,
    `default-src$dir https:;
    `report-uri$dir https://example.com/

効果は同じになることに注意 — 構文解析-時には，~headerは~commaにより分割されるので。 ◎ would have the same effect, as the comma splits the header during parsing.

10.1. 処理の複雑化

多くの~UAは、~pageの読込nを高速化するため，何らかの形で最適化された資源~fetch用の~algoを実装する。 ~UAは、これらの特能を実装するときに，自身による最適化が~pageの~security施策の挙動を改めないことを確保するモノトスル。 ◎ Many user agents implement some form of optimistic resource fetching algorithm to speed up page loads. In implementing these features, user agents MUST ensure that these optimizations do not alter the behavior of the page’s security policy.

ここに、実装の~bugを生じさせ易くするような，あり得る複雑化を少しだけ挙げる： ◎ Here, we’ll note a few potential complications that could cause bugs in implementations:

`frame-ancestors$dir 指令が効果を及ぼすのは、［文書が`入子な閲覧~文脈$の中へ読込まれる前, かつおよそ~script（もしあれば）が実行される前］になるモノトスル。この拘束に~approachする仕方の一つは、文書の~headerを構文解析する間に `frame-ancestors$dir 指令により定義される先祖の検査を遂行することである。これは、文書~objが全く可用でないこともあり得ることを意味する — そのため、 `self^pl, あるいは［ `~scheme$url ／ `~port$url に相対的な~source式］に対する検査が複雑化し得る。 ◎ The frame-ancestor directive MUST take effect before a document is loaded into a nested browsing context, and certainly before script is potentially executed. One way to approach this constraint is to perform the ancestor check defined in §7.7 frame-ancestors while parsing the document’s headers. This might mean that no document object is available at all, which can complicate checks against 'self', and scheme- or port-relative source expressions.
同様に， `Link$h ~HTTP応答~headerは、文書が可用になる前に，~stylesheet資源に対する要請を生成し得る。 ~UAは、［これらの要請が生成される`前に^em，応答~headerに包含されるどの施策も構文解析され, 有効になる］ことを確保するモノトスル。例えば，次の~headerを返している応答： ◎ Likewise, the Link HTTP response header could generate requests for stylesheet resources before a document is available. User agents MUST ensure that any policy contained in the response headers is parsed and effective before these requests are generated. For example, a response returning the following headers:
```
Content-Security-Policy:
    style-src `none^pl
Link:
    <awesome.css>; rel=stylesheet
```
に対する挙動は、次の~headerを返す応答と同じにするモノトスル： ◎ MUST have the same behavior as a response returning the following headers:
```
Link:
    <awesome.css>; rel=stylesheet
Content-Security-Policy:
    style-src `none^pl
```
すなわち，両者とも~stylesheetに対する要請を阻止するモノトスル。この要件を履行するためには、~UAは，すべての~headerが処理されるまで，資源の~prefetchの~~開始を待機するモノトスル。 ◎ namely, both must block requests for the stylesheet. To fulfil this requirement user agents MUST wait until all headers have been processed before beginning to prefetch resources.

11. IANA 考慮点

恒久的~message~header~registryは、次の登録により更新されるべきである： `RFC3864$r

【この訳では、各種~headerに対する記述を一括して記す。】

~header名: `Content-Security-Policy$h; `Content-Security-Policy-Report-Only$h
適用-可能な~protocol: http
位置付け: standard
著作者
変更~制御者: W3C
仕様~文書: この仕様

◎ 11.1. Content-Security-Policy ◎ Header field name • Content-Security-Policy Applicable protocol • http Status • standard Author/Change controller • W3C Specification document • This specification (See Content-Security-Policy Header Field) ◎ 11.2. Content-Security-Policy-Report-Only ◎ Header field name • Content-Security-Policy-Report-Only Applicable protocol • http Status • standard Author/Change controller • W3C Specification document • This specification (See Content-Security-Policy-Report-Only Header Field)

12. 謝辞

この文書における仕事は、 W3C Web Application Security ~WG による文書に加えて， `IETF websec ~WG＠https://tools.ietf.org/wg/websec/$ による仕事 — 特に，その~WGによる要件~文書 `draft-hodges-websec-framework-reqs＠https://tools.ietf.org/id/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.

`frame-ancestors$dir 指令は、元々は `X-Frame-Options$h `RFC7034$r として開発された。 ◎ A portion of the frame-ancestors directive was originally developed as X-Frame-Options. [RFC7034]

特に、洞察に富む~feedbackを供され, この仕様を健全に保たせた Brian Smith, Neil Matatall, Anne van Kesteren, Sigbjørn Vik 各氏に。 ◎ Brian Smith, Neil Matatall, Anne van Kesteren, and Sigbjørn Vik provided particularly insightful feedback to keep this specification sane.

適合性

文書における表記規約

【この節の内容は、 `~W3C日本語訳共通~page＠~W3Ccommon#conformance$ に移譲。】

適合t~algo

【この節の内容は、 `~W3C日本語訳共通~page＠~W3Ccommon#conformance$ に移譲。】

適合性~class

`適合t~UA@ は、［この仕様に挙げられた，~UAに適用-可能な要件］すべてを実装するモノトスル。 ◎ A conformant user agent must implement all the requirements listed in this specification that are applicable to user agents.

`適合t~server@ は、［この仕様に挙げられた，~serverに適用-可能な要件］すべてを実装するモノトスル。 ◎ A conformant server must implement all the requirements listed in this specification that are applicable to servers.