Content Security Policy Level 2

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$を指定する能 ］を制御する。 ◎ 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.
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を送信してはナラナイ†。 ◎ 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 を送信してもヨイ。 ◎ 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に応じて、次を実行するモノトスル：】

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 要素を，アリな限り文書の始めの方に配置することが`強く奨励される^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/

このとき、【この資源における】 `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:

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かつ互いに独立に）生成しなければナラナイ。 生成される値は、［ （符号化する前の時点で） 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.

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. ~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.4. 報告-法

~UAは、 %url を `報告~用に剥ぐ@ ときは，次と等価な~algoを利用するモノトスル： ◎ 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$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.
2. ~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.
3. ~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:

1. %違反 ~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.

2. 違反が生じた箇所 — 特定の行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 の中で違反が生じた行l番号。 ◎ 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を利用するモノトスル： ◎ 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. ~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:

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漏洩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.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.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の発火-法

~UAは、 `違反~eventを発火する@ ときは，次と等価な~algoを利用するモノトスル： ◎ 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する$ ⇒ 名前 `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.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:

4. ~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.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聴取-時 に，端点へ~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 指令を施行するときは，次の指令を施行するモノトスル： ◎ 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$で`制約する$モノトスル： ◎ 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:

1. %先祖~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.

2. %先祖~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閲覧~文脈$内に開く ］ような選択肢を供する，利用者に馴染易い~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.

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

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が，［ さもなければ［［ ~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 にて除去された。 ~plugin特能~自体も， ~HTML仕様から ほぼ（~PDF用の~supportを除き）廃され、 その拡張能としての能力は今やない。 】

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

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

2. `加えて^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.

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

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

  • `許容~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.

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を無視して, `かつ^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.

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 攻撃に類似なものである。 いずれの攻撃に対しても、~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 ）、この文書の次~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.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:

1. `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.

2. 同様に， `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.

文書における表記規約

【 この節の内容は、 ~W3C日本語訳 共通~page に移譲。 】

適合t~algo

【 この節の内容は、 ~W3C日本語訳 共通~page に移譲。 】

適合性~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.