内容保安施策（ Level 2 ） — Content Security Policy

1.1. Level 1 からの変更点

この文書は、 ~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:

1. 次の変更点は、［ 大多数の~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.

2. この改訂による新品の指令は： ◎ The following directives are brand new in this revision:

   1. `base-uri$dir は、［ `被保護~資源$における`文書~基底~URL$xを指定する能 ］を制御する。 ◎ 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に取って代わることが意図0されている。 ◎ 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.
3. ~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).
4. 違反に際しては、 `SecurityPolicyViolationEvent$I が発火される（`違反~eventの発火法$sec 節） ◎ A SecurityPolicyViolationEvent is fired upon violations, as described in §6.3 Firing Violation Events.
5. 違反~報告には、いくつもの新たな~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.
6. `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.

2.1. 各種~用語への参照

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

`大域一意~識別子@（~GUID）

`RFC6454$r 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 節 ◎ 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 節】 ◎ Defined by the Origin specification. [RFC6454]

`資源~表現@

`RFC7231$r 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 にて定義される： `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.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

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

~serverは、所与の`資源~表現$に対し，複数個の `Content-Security-Policy^h ~headerを送信しては~MUSTNOT0†。 ◎ 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に分けることも許容される ］ことを示しているが、それでも，それらの施策を 一つに結合する ことが要求されている（次~節も同様）。 その理由は、~headerの注入~攻撃を検出し易くするためと見られる。 】

~serverは、［ 異なる資源 ／ 同じ資源の異なる`表現$ ］ごとに，~header値が異なる `Content-Security-Policy^h を送信しても~MAY0。 ◎ 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応答を受信したときは，~such~headerのそれぞれに包含されている各~施策†を`施行-$し~MUST0。 ◎ 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運用者にとっては、保安~施策を反復的に開発したいと望むこともあろう。 運用者は、自身の~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を送信しては~MUSTNOT0。 ◎ 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 を送信しても~MAY0。 ◎ 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応答を受信したときは，~such~headerのそれぞれに包含されている各~施策を`監視-$し~MUST0。 ◎ 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されない。 ◎ 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 要素 ］を介して，施策を給して~MAY0。 例えば： ◎ 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指令$xには，次の~entryが追加される： ◎ Add the following entry to the pragma directives for the meta element:

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

【~UAはこの~entryに応じて、次を実行し~MUST0：】

1. ~IF 文書の `head$e 要素は， `meta$e 要素の先祖でない ⇒ ~RET ◎ If the Document’s head element is not an ancestor of the meta element, abort these steps.
2. ~IF `meta$e 要素は， `content$a 属性を欠いている ⇒ ~RET ◎ If the meta element lacks a content attribute, abort these steps.
3. %施策 ~LET `meta$e 要素の `content$a 属性の値 ◎ Let policy be the value of the content attribute of the meta element.
4. %指令~集合 ~LET %施策 を`施策として構文解析-$した結果 ◎ Let directive-set be the result of parsing policy.

5. %指令~集合 内から，すべての［ `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.

6. %指令~集合 内の各 指令を，その指令の型に定義されるように施行する。 ◎ Enforce each of the directives in directive-set, as defined for each directive type.

`meta$e 要素~内の施策は、それに先行する内容には適用されない。 したがって，作者には、 `meta$e 要素を，可能0な限り文書の始めの方に配置することが強く奨励される。 特に、［ `Link$h ~HTTP応答~headerや, ［ `meta$e により送達される施策に先行する［ `link$e ／ `script$e ］要素 ］］を利用して［ ~fetchまたは事前fetchされる ］資源は、阻止されないことに注意。 ◎ 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 要素を介して指定される`施策$は、被保護~資源にて作動中の他の施策とともに — 他の施策がどこで指定されたかに関わらず — 施行される。 複数の施策が施行されるときの一般的な影響0は、`複数の施策の施行$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されない。 ◎ Note: The Content-Security-Policy-Report-Only header is not supported inside a meta element.

3.4. 複数の施策の施行

上の節（ `~meta要素$ 節）では、 施策が複数~在するときは、それぞれが，その型に則って 施行され／報告され ~mustと記されている。 実施において，これがどう働くものとされるべきか、明確化する例を示す。 何らかの理由で、ある~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/

このとき、【この資源における】 `XMLHttpRequest$I による `example.com^s への接続は許容されるか？ — 答えは、許容されない，である。 両~施策の施行は、［ 起こりうる接続が，両者ともに無傷で合格しなければならない ］ことを意味する。 二番目の施策がこの接続を許容するとしても，最初の施策が `connect-src$dir `none^pl を包含するので、その施行mentにより接続は阻止される。 施行する施策の~listに，施策を追加することによる影響0は、被保護~資源の能力に制約を追加しこそすれ，それを~~緩めることはない。 ◎ 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／~image／~stylesheet ］を含ませる資源）に伴って送達される施策は，効果を及ぼさずに破棄される。 その実行は、［ そのような資源を含める側の文脈 ］の施策（たち）の対象になる。 次の一覧に，これらの関係性の例を概略する： ◎ 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:

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.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かつ互いに独立に）生成し~MUST0。 生成される値は、［ （符号化する前の時点で） 128 ~bit以上 ］, かつ［ 暗号的に保安的な 乱数~生成器を介して生成される ］~SHOULD0である。 この要件は、攻撃者による `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を利用しないでそうするときより保安的でない — ~nonceは、それが在する指令~内の制約を上書きするので。 ~nonceへの~accessを得られる攻撃者は、~~任意の~scriptを~~任意に実行できる。 とは言え、古い~code上に内容~保安~施策の層を重ねるとき、~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 で符号化され~MUST0。 例えば， ~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が備える保安~上の特質には疑義があるので、可能0なら~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.

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

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

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

4.3. 媒体~型~listの構文

`plugin-types$dir 指令は、その値に `媒体~型~list@ を利用する。 ◎ The plugin-types directive uses a value consisting of a media type list.

媒体~型~list内の各 `媒体~型@ は、特定の，［ 被保護~資源~内で`~plugin$xを~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.4. 報告-法

~UAは、 %url を `報告~用に削ぐ@ ときは，次と等価な~algoを利用し~MUST0： ◎ To strip uri for reporting, the user agent MUST use an algorithm equivalent to the following:

1. ~IF %url の`生成元$は`~GUID$である（例えば， %url の~schemeが［ `data^sc ／ `blob^sc ／ `filesystem^sc ］のとき） ⇒ ~RET %url の`~scheme$xを~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.
2. ~IF［ %url と 被保護~資源 ］の`生成元$は、同じでない ⇒ ~RET ［ %url の`生成元$ ］を `~ASCII直列化した$x結果 ◎ 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.
3. ~RET %url から`素片$x 成分を除去した結果 ◎ Return uri, with any fragment component removed.

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

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

   `blocked-uri@vr

   読込みが防止された資源の［ 元々の【~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$xを`報告~用に削いだ$結果。 ◎ The address of the protected resource, stripped for reporting.

   `effective-directive@vr

   違反された施策~指令の名前。 これは、違反を誘発させた施行mentを与える`指令$ （例： "`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応答の`状態code$x ／ 他の場合, 数値 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.

2. 違反が生じた箇所 — 特定の行0や特定の~file — を識別できる場合（例えば， `script-src$dir 指令に違反した~script実行）、~UAは，［ 次に挙げる各種~key, および対応する値 ］を %違反 に追加して~MAY0： ◎ 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 の中で違反が生じた行0番号。 ◎ The line number in source-file on which the violation occurred.

   `column-number@vr

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

3. ~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.

~UAは、 `違反~報告を送信する@ ときは，次と等価な~algoを利用し~MUST0： ◎ To send violation reports, the user agent MUST use an algorithm equivalent to the following:

1. %報告~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.
2. %報告~本体 ~LET %報告~obj を `~JSON文字列化$した結果 ◎ Let report body be the JSON stringification of report object.

3. `報告~URL$ 内の~EACH ( %報告~URL ) に対し： ◎ For each report URL in the set of report URLs:

   1. ~IF ［ ~UAは 被保護~資源に対する違反~報告を %報告~URL へ向けて 既に送信していた ］ ~AND［ その報告は， %報告~本体 に正確に合致する`~payload本体$xを包含していた ］ ⇒ ~UAの任意選択で ⇒ ~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$xする ］`~taskを~queueする$x：

      • “resource or URL” ~SET %報告~URL
      • “from an origin” ~SET 被保護~資源の生成元
      • “synchronous flag” ~SET ~OFF
      • ~HTTP~method ~SET `POST^c
      • `Content-Type^h ~header値 ~SET `application/csp-report^c
      • `~payload本体$x ~SET %報告~本体
      • “block cookies flag” ~SET ［ %報告~URL と被保護~資源とは，生成元が同じでない ならば ~ON ／ ~ELSE_ ~OFF ］

      ~UAは、この資源の~fetch時に~redirectに追従しては~MUSTNOT0。 （注記： ~UAは~fetchされた資源を無視する。）

      これらの`~task$xの`~task源$xは、 `~CSP~task源@ とする。

      ◎ 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は次をし~MUST0： ◎ To report a violation, the user agent MUST:

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

注記： この仕様のこの節は、［［［［［ これらの~algoにて指定されるものを超えるような，~data漏洩 ］を制限するために，違反~報告に制約を適用する ］ような，~UAの能 ］を制限するもの ］として解釈されるべきでない。 例えば，~UAは、［ 報告ingをまるごと不能化する~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.1. ~worker

~UAは、`~workerを走らせる$xときには、~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施策を［ `施行-$／`監視-$ ］し~MUST0。 ◎ 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値による施策を［ `施行-$／`監視-$ ］し~MUST0。 ◎ 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文書$を，被保護~資源の中で入子にされる閲覧文脈にて作成する ］ときは、その文書に対しても，同じ`施策$を［ `施行-$／`監視-$ ］し~MUST0。 ◎ 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.1. `SecurityPolicyViolationEvent^I ~interface

[`Constructor^m(DOMString `type^m, optional `SecurityPolicyViolationEventInit$I %eventInitDict)]
interface `SecurityPolicyViolationEvent@I : `Event$I {
    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 ~propertyを指す。 ◎ Refer to the document-uri property of violation reports for a description of this property.

readonly DOMString `referrer@m

違反~報告の `referrer$vr ~propertyを指す。 ◎ Refer to the referrer property of violation reports for a description of this property.

readonly DOMString `blockedURI@m

違反~報告の `blocked-uri$vr ~propertyを指す。 ◎ Refer to the blocked-uri property of violation reports for a description of this property.

readonly DOMString `violatedDirective@m

違反~報告の `violated-directive$vr ~propertyを指す。 ◎ Refer to the violated-directive property of violation reports for a description of this property.

readonly DOMString `effectiveDirective@m

違反~報告の `effective-directive$vr ~propertyを指す。 ◎ Refer to the effective-directive property of violation reports for a description of this property.

readonly DOMString `originalPolicy@m

違反~報告の `original-policy$vr ~propertyを指す。 ◎ Refer to the original-policy property of violation reports for a description of this property.

readonly DOMString `statusCode@m

違反~報告の `status-code$vr ~propertyを指す。 ◎ Refer to the status-code property of violation reports for a description of this property.

readonly DOMString `sourceFile@m

違反~報告の `source-file$vr ~propertyを指す。 ◎ Refer to the source-file property of violation reports for a description of this property.

readonly long `lineNumber@m

違反~報告の `line-number$vr ~propertyを指す。 ◎ Refer to the line-number property of violation reports for a description of this property.

readonly long `columnNumber@m

違反~報告の `column-number$vr ~propertyを指す。 ◎ 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の発火法

~UAは、 `違反~eventを発火する@ ときは，次と等価な~algoを利用し~MUST0： ◎ To fire a violation event, the user agent MUST use an algorithm equivalent to the following:

1. %報告~obj ~LET `違反~報告~objを生成-$した結果 ◎ Let report object be the result of generating a violation report object.

2. 次を行う`~taskを~queueする$x ⇒ 名前 `securitypolicyviolation^et の`~eventを発火する$x — ~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$xの`~task源$xは、`~CSP~task源$とする。 ◎ The task source for these tasks is the Content Security Policy task source.

7.1. `base-uri^dir

`base-uri@p 指令は、［ `文書~基底~URL$xを指定するときに利用できる~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$xを得る ~algoの step 4【？】は、次のように変更され~MUST0： ◎ Step 4 of the algorithm defined in HTML5 to obtain a document’s base URL MUST be changed to:

4. ~IF［ 前 step が成功裡でない ］~OR［ 以前の step の結果が `被保護~資源$に対する`許容~基底~URL$に`合致し$ない ］ ⇒ `文書~基底~URL$x ~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.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$で`制約し$~MUST0。 ◎ 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聴取-時 に，端点へ~pingするとき ◎ Pinging an endpoint during hyperlink auditing.
• `sendBeacon()$m ~methodにより~beaconを送信するとき `BEACON$r ◎ Sending a beacon via the sendBeacon() method [BEACON]

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

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 指令を施行するときは，次の指令を施行し~MUST0： ◎ 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.

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

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

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$で`制約し$~MUST0： ◎ 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動作$で`制約し$~MUST0。 ◎ 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 `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 — 利用者~interfaceの “着せ替え” — 通称 “~clickjacking（ ~click行為の~hijacking）” 】

この指令の名前と値の~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 指令を施行している下で，被保護~資源を `入子の閲覧文脈$x %入子の文脈 の中へ読込もうと ］するときは，次の手続きを遂行し~MUST0： ◎ 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:

1. %先祖~list ~LET %入子の文脈 のすべての`先祖~閲覧文脈$xからなる~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.

2. %先祖~list 内の~EACH ( %先祖~文脈 ) に対し†： ◎ For each ancestorContext in ancestorList:

   1. %文書 ~LET %先祖~文脈 にて`作動中の文書$x ◎ 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. 被保護~資源の読込みを中止する ◎ 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閲覧文脈$x内に開く ］ような選択肢を供する，利用者に馴染易い~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： ［ 新たに作成される文書の`強制~sandbox法~flag集合$x ］］を利用して，`~sandbox法~指令を構文解析-$xする。 ◎ 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が，通常の非同一生成元 文書の読込-として出現する ］ことを確保する。 これらの手続きが無視された場合、文書の施策~状態が漏洩する可能性がある。 ◎ 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 要素を介して定義される施策に包含されているとき ］は無視され~MUST0。 ◎ 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 値に含めては~MUSTNOT0 — それが被保護~資源と同一生成元でない限り — 非同一生成元 先祖の値の公開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.

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

7.8. `frame-src^dir

`frame-src@dir 指令は、【指令~名として】非推奨にされた。 入子の閲覧文脈を統治したいと望む作者は、代わりに `child-src$dir 指令を利用する~SHOULD0である。 ◎ 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$で`制約し$~MUST0： ◎ 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 ］要素により作成される`入子の閲覧文脈$x ］を表示するために，~dataを要請するとき ◎ Requesting data for display in a nested browsing context in the protected resource created by an iframe or a frame element.
• ~such`入子の閲覧文脈$xを【へ？】 `~navigate$xしたとき ◎ Navigated such a nested browsing context.

7.9. `img-src^dir

`img-src@dir 指令は、［ 被保護~資源が~imageをどこから読込めるか ］を制約する。 この指令の名前と値の~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

`許容~image~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は、`被保護~資源$における次の活動を，`許容~image~sources$で`制約し$~MUST0： ◎ 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:

• ~image用に~dataを要請するとき — 次のものを処理するときなど：

  • `img$e 要素の［ `src^a ／ `srcset^a ］属性
  • `input$e 要素の `src^a 属性
  • `type="image"$a 型の `input$e 要素
  • `video$e 要素の `poster$a 属性
  • `url()$f
  • ~imageを読込む能力があるような，~CSS~property上の［ `image()$f ／ `image-set()$f ］値 `CSS4-IMAGES$r
  • `icon^c などの~imageに関係する `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

`許容~媒体~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は、`被保護~資源$における次の活動を，`許容~媒体~sources$で`制約し$~MUST0： ◎ 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$で`制約し$~MUST0： ◎ 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 ］要素により作成された`入子の閲覧文脈$x ］内に表示するための~data ］を要請するとき。 ◎ Requesting data for display in a nested browsing context in the protected resource created by an object or an embed element.
• `入子の閲覧文脈$xの~navigating ◎ Navigating such a nested browsing context.

`object-src$dir 指令を施行するとき，要素の~dataを消費するものは、`~plugin$xに限られる必要はない。 ［ `object$e／`embed$e／`applet$e ］要素~用の~dataへの~fetchは、`許容~obj~sources$で`制約され$~MUST0。 これは、要素~dataが，［ さもなければ［［ ~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$x（例： `data$a 属性を欠く `object$e 要素） ］を読込んでは~MUSTNOT0。 ◎ 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 指令は、埋込める資源の型を制限することにより，［ 被保護~資源が呼出せる~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媒体~型@ は、 `plugin-types$dir 指令の値を `媒体~型~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$xを~instance化しようとする ］ときは，次をし~MUST0： ◎ 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:

1. 代わりに，~pluginが~errorを報告したかのように動作する。

2. 加えて，次のいずれかの条件が成立するならば`違反を報告-$する：

   • ［ ~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.
   • %資源 の媒体~型は、`許容~plugin媒体~型$による`媒体~型~listに合致$しない。 ◎ resource’s media type does not match the list of allowed plugin media types.
   • ［ ~pluginは、［ `object$e ／ `embed$e ］要素を介して，被保護~資源の中へ埋込まれている ］~AND［［ %資源 の媒体~型 ］~NEQ`~ACI$［ 要素の `type$a 属性にて宣言されている媒体~型 ］］ ◎ 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［［ %資源 の媒体~型 ］ ~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内容$xを表示することになる。 ◎ 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文書$xを［ `被保護~資源$の`~child閲覧文脈$xにて`作動中の文書$x ］として作成する ］ときは、［ ~plugin文書~上の `plugin-types$dir 指令 ］についても［ `施行-$／`監視-$ ］し~MUST0。 ◎ 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.

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

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

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

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要素$に中の `report-uri$dir 指令は、無視される。 ◎ 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： 被保護~資源の`強制~sandbox法~flag集合$x ］を利用して`~sandbox法~指令を構文解析-$xし~MUST0 `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要素$を介して定義される施策~内の `sandbox$dir 指令は、無視される。 `sandbox$dir 指令はまた、施策を`監視-$するときにも効果を及ぼさず，報告ingの要件もない。 ◎ 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.

Content-Security-Policy:
    `sandbox$dir

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

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を実行しようとするときは、実行せずに，その`違反を報告-$し~MUST0 ◎ ↓

  • `許容~script~sources$に対する［ `妥当な~nonce$を欠く, かつ `妥当な~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 例外を投出し~MUST0 ◎ 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 例外を投出し~MUST0 ◎ When called as a constructor, the function Function [ECMA-262] MUST throw an EvalError exception.
• ［ `setTimeout()$m／`setInterval()$m ］関数は、その最初の引数に［ ~callableでないもの（ `IsCallable()$x が ~F を返すもの — 例えば，文字列） ］を渡して~callされたときには、~timerを作成することなく~zeroを返さ~MUST0。 ◎ 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$で`制約し$~MUST0： ◎ 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の呼出に伴って，~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.

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

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

<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>

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

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

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

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

<script> alert('Hello, world.');</script>
<script>alert('Hello, world.'); </script>
<script> alert('Hello, world.'); </script>
<script>
alert('Hello, world.');
</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を無視し~MUST0, かつ `違反を報告-$し~MUST0

  • `許容~style~sources$に対する［ `妥当な~nonce$を欠く, かつ `妥当な~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規則を挿入する$x／ `~CSS規則として構文解析する$x／ `~CSS宣言~blockとして構文解析する$x／ `選択子~listとして構文解析する$x ］~algoを呼出そうとするときには、代わりに `SecurityError$E 例外を投出した上で，~algoを終了させ~MUST0。 これには、例えば， `CSSOM$r の各種［ `cssText^m 設定子や `insertRule()^m ~method ］に対するすべての呼出も含まれる `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$で`制約し$~MUST0： ◎ 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 が実際に存在する前に事前fetchされることもあるので、~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を含むことの保安~上の帰結は、信用できない~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.

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漏洩 攻撃に類似するものである。 いずれの攻撃に対しても、~UAは，同じ仕組み — ~MIME型が不適正な~stylesheetに対し，より厳格な~CSS構文解析-用の規則を適用する — で防御する~SHOULD0である： ◎ 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情報の漏洩

この文書における違反~報告ingの仕組みは、［ 悪意的~web~siteが，違反~報告を利用して，他の~serverの挙動を探査する~risk ］を軽減するように設計されている。 例えば，~imageの~sourceとして `https://example.com^s を~whitelist化している，悪意的~web~siteを考える。 この~siteが、【 `example.com^s の~log-in用~pageの~URLである】 `https://example.com/login^s を~imageとして読込もうと試みた場合、 `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 ）、この文書の次~versionへ先送りされた。 ◎ 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.1. 処理の複雑化

多くの~UAは、~pageの読込-を高速化するため，何らかの形で最適化された資源~fetching~algoを実装する。 ~UAは、これらの特色機能を実装するときに，自身による最適化が~pageの保安~施策の挙動を改めないことを確保し~MUST0。 ◎ 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:

1. `frame-ancestors$dir 指令が効果を及ぼすのは、［ 文書が`入子の閲覧文脈$xの中へ読込まれる前, かつ およそ~script（もしあれば）が実行される前 ］で~MUST0。 この拘束に取組む仕方の一つは、文書の~headerを構文解析する間に `frame-ancestors$dir 指令により定義される 先祖の検査を遂行することである。 これは、文書~objが全く可用でないこともあり得ることを意味する — そのため、 `self^pl, あるいは［ `~scheme$x ／ `~port$x に相対的な~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.

2. 同様に， `Link$h ~HTTP応答~headerは、文書が可用になる前に，~stylesheet資源に対する要請を生成し得る。 ~UAは、［ これらの要請が生成される前に，応答~headerに包含される どの施策も 構文解析され, 有効になる ］ことを確保し~MUST0。 例えば，次の~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を返す応答と同じになら~MUST0： ◎ 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に対する要請を阻止し~must。 この要件を履行するためには、~UAは，すべての~headerが処理されるまで，資源の事前fetchの~~開始を待機し~MUST0。 ◎ 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.

文書における表記規約

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

適合的~algo

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

適合性~class

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

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