1. 序論
~INFORMATIVEこの文書は、 `Content Security Policy^en ( “内容~保安~施策”, または単に “施策” ) — 略して `~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と記すことにする。 】
~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.
この文書は,~CSP Level 2 の繰り返しであるが、次の二点を目標にしている:
- 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 Inc の~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の特権を抑制できるようにする ]ための,施策の枠組みを供する。 ◎ 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 からの変更点
この文書は、~CSP Level 2 仕様からの発展を述べる。 `CSP2$r からの変更点についての,高次からの概観は: ◎ 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 Worker )が,~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:
- CSP Level 2 で非推奨にされた `frame-src$dir 指令は,非推奨でなくなったが、無い場合は `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).
- 専用~workerは、今や常に,作成-元~の施策を継承する。 ◎ Dedicated workers now always inherit their creator’s policy.
-
~URL照合~algoは、今や 非保安的[ ~scheme/~port ]を その保安的~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と同じでない どの非`~network~scheme$も,明示的に在することが要求されるようになった — `~urlは ( 生成元, ~redirect回数 ) について式に合致するか?$A を見よ。 ◎ The source expression matching has been changed to require explicit presence of any non-network scheme, rather than local scheme, unless that non-network scheme is the same as the scheme of protected resource, as described in §6.6.1.6 Does url match expression in origin with redirect count?.
- ~hashに基づく~source式は、今や,外部~scriptに合致し得る — 要請を誘発する当の `script$e 要素が[ 完全性~metadataの集合を指定していて,それが現在の施策~内に~listされている ]ならば。 詳細は、 ~hashを介して外部~JSを許容する 節を見よ。 ◎ 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.
-
`disown-opener$dir 指令は、内容に対する制御を別の閲覧文脈に与えるような仕方では,資源を開けないことを確保する。 ◎ The disown-opener directive ensures that a resource can’t be opened in such a way as to give another browsing context control over its contents.
`disown-opener^dir はまだ策定段階にある。 `194$Issue ◎ disown-opener is a work in progress. <https://github.com/w3c/webappsec-csp/issues/194>
- `navigate-to$dir 指令は、~naviを起動できる端点に対する制御を,資源に与える。 ◎ The navigate-to directive gives a resource control over the endpoints to which it can initiate navigation.
- ~inline違反に対し生成される報告は、関連する指令が `report-sample$pl 式を包含する場合には,空でない`見本$vrを包含することになる。 ◎ Reports generated for inline violations will contain a sample attribute if the relevant directive contains the 'report-sample' expression.
【この訳に固有の表記規約】
この訳の,~algoや定義の記述に利用されている各種記号( ~LET, ~EQ, ~IF, ~THROW, 等々)の意味や定義の詳細は、~SYMBOL_DEF_REFを~~参照されたし。
記号[ ~EQ, ~NEQ, ~IN, ~NIN ]に添えられる “`~ACI@” は、記号の意味を `~ASCII大小無視$による比較に基づくように改めることを表す。 (特に断らない限り、文字列の比較は文字大小区別とする。)
~protocol要素 `ALPHA@P, `DIGIT@P, `VCHAR@P は、 `RFC5234$r B.1 節 にて定義される。 ~protocol要素 `OWS@P, `RWS@P, は、 `RFC7230$r 3.2.3 節 にて定義される。 尚,これらを含む他の仕様に定義される~protocol要素は — 実際には~byte列を表現しているものが多いが — この仕様の中では,暗黙的に`同型に復号-$された`~ASCII文字列$と同一視されている(この仕様に現れる~protocol要素は、どれも~ASCII範囲の[ ~byte/文字 ]のみからなる)。
次の符号位置も利用される:
表記 | 符号位置 |
---|---|
`~asterisk@ | U+002A ASTERISK ( `*^l ) |
`~semicolon@ | U+003B SEMICOLON ( `;^l ) |
`~slash@ | U+002F SOLIDUS ( `/^l ) |
`~comma@ | U+002C COMMA ( `,^l ) |
次の~styleが表記に用いられる:
- `production^p — ~protocol要素( ABNF 生成規則)
- `example-directive$dir — ~CSP `指令$
- `literal^l — 文字列~literal(引用符は~dataに含まれない)
- `literal^pl — 文字列~literal。 引用符も~dataに含まれる。
- `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 の構文としては、折り返しは許容されないことに注意。
次に挙げる用語は、 `FETCH$r 仕様に定義されていたが,現在は廃されている。 それに伴い,この仕様も更新される必要がある:
- `要請$の `~target閲覧文脈@rq — `~target~client~id$rqに代えられた。
2. 枠組み
2.1. 基盤
この文書は、 `RFC5234$r に定義される~ABNF文法を利用して構文を指定する。 また、 `RFC7230$r 7 節 に定義される `#rule^P ~ABNF拡張にも依拠する。 ◎ This document uses ABNF grammar to specify syntax, as defined in [RFC5234]. It also relies on the #rule ABNF extension defined in Section 7 of [RFC7230].
この文書の~algoと注釈文に利用する いくつかの基礎的な概念は、 Infra Standard `INFRA$r に依存する。 ◎ This document depends on the Infra Standard for a number of foundational concepts used in its algorithms and prose [INFRA].
2.2. 施策
`施策@ は、[ 許容される/制約される ]挙動たちを定義する。 それを適用し得るのは[ `Window$I / `WorkerGlobalScope$I / `WorkletGlobalScope$I ]であり、[ `大域~objの~CSP~listを初期化する$A~algo ]に述べられる。 ◎ A policy defines allowed and restricted behaviors, and may be applied to a Window, WorkerGlobalScope, or WorkletGlobalScope as described in §4.2.2 Initialize a global object’s CSP list.
各~施策には、次のものが結付けられる: ◎ ↓
- `指令~集合@ ( `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 )
- 次のいずれか: `enforce^l / `report^l ◎ Each policy has an associated disposition , which is either "enforce" or "report".
- 【 順に,[ 施策を施行する/施策~違反を報告する ]ことに対応する。 】
- `~source@ ( `source^en )
- 次のいずれか: `header^l / `meta^l ◎ Each policy has an associated source, which is either "header" or "meta".
- 【 順に,当の施策は[ ~HTTP~header/ `meta^e 要素 ]により与えられたことを表す。 】
同じ資源には,複数の`施策$を適用し得る — それらは、 `~CSP~list@ と称される`施策$の`~list$に収集される。 ◎ Multiple policies can be applied to a single resource, and are collected into 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 )とは、一連の`直列形の指令$を`~semicolon$で区切って連結した `~ASCII文字列$であり,次の`~ABNF$文法に従う: ◎ 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 *( `OWS$P ";" [ `OWS$P `serialized-directive$p ] ) ; OWS is defined in section 3.2.3 of RFC 7230
`直列形の~CSP~list@ とは、一連の`直列形の~CSP$を`~comma$で区切って連結した`~ASCII文字列$であり,次の`~ABNF$文法に従う: ◎ 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
;
'`#^P' 規則は `RFC7230$r, 7 節 に定義される。
◎
; The '#' rule is defined in section 7 of RFC 7230
2.2.1. 直列形の~CSPを構文解析する
`直列形の~CSPを構文解析する@A ときは、所与の ( `直列形の~CSP$ %直列形, `~source$ %~source, `処置先$ %処置先 ) に対し,以下を実行する。 ◎ To parse a serialized CSP, given a serialized CSP (serialized), a source (source), and a disposition (disposition), execute the following steps.
この~algoは、`施策$ ~objを返す。 %直列形 を構文解析できなかった場合、結果の`施策$の`指令~集合$は空になる。 ◎ This algorithm returns a Content Security Policy object. If serialized could not be parsed, the object’s directive set will be empty.
- %指令~集合 ~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 (;):
- %~list ~LET `~ASCII空白で分割する$( %~token ) ◎ Strip leading and trailing ASCII whitespace from token. ◎ If token is an empty string, continue.
- ~IF[ %~list は空である ] ⇒ ~CONTINUE ◎ ↑
- %指令~名 ~LET %~list の先頭の~item ◎ Let directive name be the result of collecting a sequence of code points from token which are not ASCII whitespace.
-
~IF[ %指令~集合 内に[ `名前$ ~EQ %指令~名 ]なる`指令$はある ] ⇒ ~CONTINUE ◎ If policy’s directive set contains a directive whose name is directive name, continue.
この事例では、~UAは,重複する指令が無視されたことを~web開発者に通知する~SHOULDである。 例えば,~consoleによる警告が適切になるであろう。 ◎ 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~listを構文解析する
`直列形の~CSP~listを構文解析する@A ときは、所与の ( `直列形の~CSP~list$ %~list, `~source$ %~source, `処置先$ %処置先 ) に対し,以下を実行する。 ◎ To parse a serialized CSP list, given a serialized CSP list (list), a source (source), and a disposition (disposition), execute the following steps.
この~algoは、一連の`施策$からなる`~list$を返す。 %~list を構文解析できなかった場合の結果は,空~listになる。 ◎ This algorithm returns a list of Content Security Policy objects. If list cannot be parsed, the returned list will be empty.
- %施策たち ~LET 空`~list$ ◎ Let policies be an empty list.
-
`~commaで分割する$( %~list ) — その結果を成す ~EACH( %~token ) に対し: ◎ For each token returned by splitting list on commas:
- %施策 ~LET `直列形の~CSPを構文解析する$A( %~token, %~source, %処置先 ) ◎ Let policy be the result of parsing token, with a source of source, and disposition of disposition.
- ~IF[ %施策 の`指令~集合$は空である ] ⇒ ~CONTINUE ◎ If policy’s directive set is empty, continue.
- %施策たち に %施策 を`付加する$ ◎ Append policy to policies.
- ~RET %施策たち ◎ Return policies.
2.3. 指令
各`施策$は、いくつかの `指令@ からなる`有順序~集合$(`指令~集合$)を包含する — そのそれぞれは、特定の挙動を制御する。 この文書にて定義される各種~指令の詳細は、 ~CSP指令 節にて述べられる。 ◎ 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.
各 `指令$は[ `名前@, `値@ ]の~pairである。 `名前$は 空でない`文字列$であり,`値$は[ 空でない`文字列$ ]からなる`有順序~集合$†である。 `値$は空にもなり得る。 ◎ Each directive is a name / value pair. The name is a non-empty string, and the value is a set of non-empty strings. The value MAY be empty.
【† と記されているが、文脈に応じて,直列形の文字列( `directive-value$p )を表している箇所も一部ある。 】
所与の ( `名前$ %名前, `値$ %値 ) からなる`指令$は, `指令$( %名前, %値 ) とも記される。
`直列形の指令@ は、次の`~ABNF$文法に従うような,空白~区切りの,一個以上の~tokenからなる`~ASCII文字列$である: ◎ 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 [ `RWS$P `directive-value$p ] `directive-name@p = 1*( `ALPHA$P / `DIGIT$P / "-" ) `directive-value@p = *( `09^hex / `20^hex-`2B^hex / `2D^hex-`3A^hex / `3C^hex-`7E^hex )
指令~値( `directive-value$p )は、空白, および[ `~semicolon$, `~comma$ を除く `VCHAR$P ]を包含して~MAY/できる。 ◎ ; Directive values may contain whitespace and VCHAR characters, ; excluding ";" and "," ; RWS is defined in section 3.2.3 of RFC7230. ALPHA, DIGIT, and ; VCHAR are defined in Appendix B.1 of RFC 5234.
各 `指令$には、【その種別ごとに】次の~algoが結付けられる: ◎ Directives have a number of associated algorithms:
- `要請前~検査@A
- 次を引数にとる ⇒# `要請$, `施策$ ◎ A pre-request check, which takes a request and a policy as an argument,\
- 次を行う間に実行される ⇒ `要請は~CSPにより阻止されるべきか?$A ◎ and is executed during §4.1.3 Should request be blocked by Content Security Policy?.\
- 他から指定されない限り†,この~algoは `許容ed^i を返す。 ◎ This algorithm returns "Allowed" unless otherwise specified.
- 【† 当の指令に対し,特に~algoが定義されていない場合には。 以下も同様。 】
- `要請後~検査@A
- 次を引数にとる ⇒# `要請$, `応答$, `施策$ ◎ A post-request check, which takes a request, a response, and a policy as arguments,\
- 次を行う間に実行される ⇒ `要請に対する応答は~CSPにより阻止されるべきか?$A ◎ and is executed during §4.1.4 Should response to request be blocked by Content Security Policy?.\
- 他から指定されない限り,この~algoは `許容ed^i を返す。 ◎ This algorithm returns "Allowed" unless otherwise specified.
- `応答~検査@A
- 次を引数にとる ⇒# `要請$, `応答$, `施策$ ◎ A response check, which takes a request, a response, and a policy as arguments,\
- 次を行う間に実行される ⇒ `要請に対する応答は~CSPにより阻止されるべきか?$A ◎ and is executed during §4.1.4 Should response to request be blocked by Content Security Policy?.\
- 他から指定されない限り,この~algoは `許容ed^i を返す。 ◎ This algorithm returns "Allowed" unless otherwise specified.
- `~inline検査@A
- 次を引数にとる ⇒# `要素$, 型~文字列, ~source文字列 ◎ An inline check, which takes an Element a type string, and a source string as arguments,\
- 次を行う間に実行される ⇒# `要素における~inline型の挙動は~CSPにより阻止されるべきか?$A ◎ and is executed during §4.2.4 Should element’s inline type behavior be blocked by Content Security Policy?\
- `javascript_^sc 要請に対しては,次を行う間に実行される ⇒ `~sourceから~targetを~navigateするある種別の要請は~CSPにより阻止されるべきか?$A ◎ and during §4.2.5 Should navigation request of type from source in target be blocked by Content Security Policy? for javascript: requests.\
- 他から指定されない限り,この~algoは `許容ed^i を返す。 ◎ This algorithm returns "Allowed" unless otherwise specified.
- `初期化@A
- 次を引数にとる ⇒# `文書$または`大域~obj$, `応答$, `施策$ ◎ An initialization, which takes a Document or global object, a response, and a policy as arguments.\
- 次を行う間に実行される ⇒ `文書の~CSP~listを初期化する$A ◎ This algorithm is executed during §4.2.1 Initialize a Document's CSP list,\
- 他から指定されない限り,この~algoは何もしない。 ◎ and has no effect unless otherwise specified.
- `~navi前~検査@A
- 次を引数にとる ⇒# `要請$, ~navi種別~文字列 ~IN { `form-submission^l, `other^l }, `閲覧文脈$, `閲覧文脈$, `施策$ ◎ A pre-navigation check, which takes a request, a navigation type string ("form-submission" or "other"), two browsing contexts, and a policy as arguments,\
- 次を行う間に実行される ⇒ `~sourceから~targetを~navigateするある種別の要請は~CSPにより阻止されるべきか?$A ◎ and is executed during §4.2.5 Should navigation request of type from source in target be blocked by Content Security Policy?.\
- 他から指定されない限り,この~algoは `許容ed^i を返す。 ◎ It returns "Allowed" unless otherwise specified.
- `~navi応答~検査@A
- 次を引数にとる ⇒# `要請$, ~navi種別~文字列 ~IN { `form-submission^l, `other^l }, `応答$, `閲覧文脈$, `閲覧文脈$, 検査~種別~文字列 ~IN { `source^l, `response^l }, `施策$ ◎ A navigation response check, which takes a request, a navigation type string ("form-submission" or "other"), a response, two browsing contexts, a check type string ("source" or "response"), and a policy as arguments,\
- 次を行う間に実行される ⇒ `~sourceから~targetを~navigateするある種別の要請に対する応答は~CSPにより阻止されるべきか?$A ◎ and is executed during §4.2.6 Should navigation response to navigation request of type from source in target be blocked by Content Security Policy?.\
- 他から指定されない限り,この~algoは `許容ed^i を返す。 ◎ It returns "Allowed" unless otherwise specified.
2.3.1. ~source~list
各種 `指令$のうち,多くのものは、 `~source~list@ ( `serialized-source-list$p )をその`値$にとる。 各`~source~list$は、一連の`文字列$からなる集合である — その各 `文字列$は、[ ~fetchし得る内容であって[ 埋込まれ得る/実行され得る ]もの ]を識別するような,次のいずれかの型の `~source式@ ( `source-expression$p )を表現する: ◎ Many directives' values 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$文法に従うような,空白~区切りの,一連の`~source式$からなる`~ASCII文字列$である: ◎ 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 *( `RWS$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^s ; / `*.example.com^s ; / `https://*.example.com:12/path/to/file.js^s `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 ; 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" ; ~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"
`host-char$p 生成規則は、意図的に~ASCII文字のみを包含するようにされている。 国際化~domain名は,`直列形の~CSP$の一部として直に手入力できないので、代わりに Punycode `RFC3492$r に符号化され~MUST。 例えば, ~domain `üüüüüü.de^s は、 `xn--tdaaaaaa.de^s として表現され~MUST。 ◎ 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が備える保安~上の特質には疑義があるので、可能なら~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.6.1.5 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. 違反
`違反@ は、`大域~obj$に結付けられている`施策$~objの集合に反した[ 動作/資源 ]を表現する。 ◎ A violation represents an action or resource which goes against the set of policy objects associated with a global object.
各 `違反$は、次のものを持つ: ◎ ↓
- `大域~obj@vr
- 違反された`施策$を持つ`大域~obj$ ◎ Each violation has a global object, which is the global object whose policy has been violated.
- `~url@vr
- この違反の`大域~obj$vrの`~URL$ ◎ Each violation has a url which is its global object’s URL.
- `状態code@vr
- [ 大域~objを~instance化させた資源 ]の`~HTTP状態code$を表現する,非負~整数 ◎ Each violation has a status which is a non-negative integer representing the HTTP status code of the resource for which the global object was instantiated.
- `資源@vr
- 施策に違反した資源を表現する — 次のいずれか ⇒ `null^l / `inline^l / `eval^l / `~URL$ ◎ Each violation has a resource, which is either null, "inline", "eval", or a URL. It represents the resource which violated the policy.
- `~referrer@vr
- 施策に違反した資源の~referrerを表現する — 次のいずれか ⇒ ~NULL / `~URL$ ◎ Each violation has a referrer, which is either null, or a URL. It represents the referrer of the resource whose policy was violated.
- `施策@vr
- 違反された`施策$。 ◎ Each violation has a policy, which is the policy that has been violated.
- `処置先@vr
- 違反された施策の`処置先$。 ◎ Each violation has a disposition, which is the disposition of the policy that has been violated.
- `有効な指令@vr
- [ 施行により この違反を生じさせた,`施策$vr内の`指令$ ]を表現する,空でない文字列。 ◎ Each violation has an effective directive which is a non-empty string representing the directive whose enforcement caused the violation.
- `~source~file@vr
- 次のいずれか ⇒ ~NULL / `~URL$ ◎ Each violation has a source file, which is either null or a URL.
- `行番号@vr
- 非負~整数。 ◎ Each violation has a line number, which is a non-negative integer.
- `列番号@vr
- 非負~整数。 ◎ Each violation has a column number, which is a non-negative integer.
- `要素@vr
- ~NULL または要素。 ◎ Each violation has a element, which is either null or an element.
- `見本@vr
- 文字列。 他から指定されない限り,空~文字列とする。 ◎ 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^l ◎ 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を生成元のみに剥いで,意図されない漏洩を避ける必要がある。 ◎ 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 の `document$m の `referrer^m ◎ If global is a Window object, set violation’s referrer to global’s document's referrer.
-
%違反 の`状態code$vr ~SET %違反 の`大域~obj$vrに結付けられている資源の~HTTP状態code ◎ Set violation’s status to the HTTP status code for the resource associated with violation’s global object.
状態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), and a string (directive), the following algorithm creates a new violation object, and populates it with an initial set of data:
- %違反 ~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ではなく — 後者は、[ ~pageから~accessされては~MUST_NOTような,~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は、個々の`資源~表現$に対し,`施策$を宣言して~MAY — `施策$を`直列化-$した上で,~HTTP応答~headerの値に与えることにより。 この仕組みは、[ `Content-Security-Policy^h / `Content-Security-Policy-Report-Only^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
`Content-Security-Policy$h: `script-src$dir `self$pl; `report-to$dir csp-reporting-endpoint
~serverは、同じ資源の異なる`表現$ごとに,異なる `Content-Security-Policy^h ~header値を送信して~MAY。 ◎ A server MAY send different Content-Security-Policy header field values with different representations of the same resource.
~serverは、`資源~表現$を送信する際に,複数の `Content-Security-Policy^h ~headerを伴わせる~SHOULDでない。 ◎ A server SHOULD NOT send more than one HTTP response header field named "Content-Security-Policy" with a given resource representation.
`Content-Security-Policy^h ~headerを受信した~UAは、それが包含する各 `直列形の~CSP$を`構文解析-$した上で,[ `~Fetchとの統合$ / `~HTMLとの統合$ ]節にしたがって それを`施行-$し~MUST。 ◎ 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
この~headerにより、~web開発者は,自身の手による保安~施策を,すでに施行-中のものと同時に,報告のみ行わせて、反復的に開発することが可能になる — その違反~報告から得られる,~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値を送信して~MAY。 ◎ A server MAY send different Content-Security-Policy-Report-Only header field values with different representations of the same resource.
~serverは、`資源~表現$を送信する際に,複数の[ `Content-Security-Policy-Report-Only^h ~header ]を伴わせる~SHOULDでない。 ◎ A server SHOULD NOT send more than one HTTP response header field named "Content-Security-Policy-Report-Only" with a given resource representation.
`Content-Security-Policy-Report-Only^h ~headerを受信した~UAは、それが包含する各 `直列形の~CSP$を`構文解析-$した上で,[ `~Fetchとの統合$ / `~HTMLとの統合$ ]節にしたがって,それを`監視-$し~MUST。 ◎ 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 要素
`文書$は、いくつかの[ ~HTML `meta$e 要素であって, [ その `http-equiv$a 属性~値 ~EQ`~ACI$ `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:
<meta http-equiv="Content-Security-Policy" content="script-src `self$pl" >
実装の詳細は~HTMLの `~CSP状態 http-equiv 処理命令$ `HTML$r にて見出せる。 ◎ 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 要素を 可能な限り文書の始めの方に配置する ]ことが強く奨励される。 特に、[ `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 要素を介して指定される`施策$は、被保護~資源にて作動中の他の施策とともに — 他の施策がどこで指定されたかに関わらず — 施行される。 複数の施策が施行されるときの一般的な影響0は、 複数の施策による効果 節にて述べる。 ◎ 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. 他の仕様との統合
~INFORMATIVEこの文書は、~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との統合
`指令$のうち一部は、何らかの仕方で,資源の読込みを制御する。 この仕様は、 `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の中から~callされる。 これにより、各 `要請$に対し,[ それが~networkを叩く前, および それが資源に達するまでに生じ得る各~redirectに対し ],指令の`要請前~検査$Aを実行できるようになる。 ◎ §4.1.3 Should request be blocked by Content Security Policy? is called as part of step #5 of its 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の中から~callされる。 これにより、~networkまたは Service Worker から送達された`応答$に対し,指令の[ `要請後~検査$A/`応答~検査$A ]を実行できるようになる。 ◎ §4.1.4 Should response to request be blocked by Content Security Policy? is called as part of step #13 of its Main Fetch algorithm. This allows directives' post-request checks and response checks to be executed on the response delivered from the network or from a Service Worker.
`施策$は,一般に `大域~obj$に対し施行されるが、[ `応答$の詳細~についての知識も要求する指令 ]を取扱うため、~UAは,[ ~HTTP応答~headerを介して送達される どの施策も,`大域~obj$が作成される前に`構文解析-$する ]必要がある。 よって: ◎ A policy is generally enforced upon a global object, but the user agent needs to parse any policy delivered via an HTTP response header field before any global object is created in order to handle directives that require knowledge of a response’s details. To that end:
- `応答$には、`~CSP~list$rsが結付けられる — この~listは、`応答$の`~header~list$rs内に送達される施策~objたちを包含する。 ◎ A response has an associated CSP list which contains any policy objects delivered in the response’s header list.
-
`応答の~CSP~listを設定する$A手続きが,[ `~HTTP~fetch$ / `~HTTP-network~fetch$ ]~algoの中から~callされる ◎ §4.1.1 Set response’s CSP list is called in the HTTP fetch and HTTP-network fetch algorithms.
注記: `応答$がどう作成されたかに関わらず、これら 2 つの~callにより,`応答$の`~CSP~list$rsは必ず設定されるようにするべきである。 ~networkを( `~HTTP-network~fetch$を介して)叩いたのなら、応答に伴われる施策を, `Set-Cookie^h ~headerを取扱う前に構文解析することになる。 応答を(`~HTTP~fetch$を介して) Service Worker から取得したのなら、応答を呼び出し元に~~渡し~~返す前に,その`~CSP~list$rsを処理することになる。 ◎ Note: These two calls should ensure that a response’s CSP list is set, regardless of how the response is created. If we hit the network (via HTTP-network fetch, then we parse the policy before we handle the Set-Cookie header. If we get a response from a Service Worker (via HTTP fetch, we’ll process its CSP list before handing the response back to our caller.
4.1.1. %応答 の~CSP~listを設定する
次の~algoは、所与の ( `応答$ %応答 ) に対し,[ その`~header~list$rsを,一連の`直列形の~CSP$値として評価した結果 ]に基づいて, %応答 の`~CSP~list$rsを拡充する: ◎ Given a response (response), this algorithm evaluates its header list for serialized CSP values, and populates its CSP list accordingly:
- %~CSP~list ~LET 空~list ◎ Set response’s CSP list to the empty list.
- %~CSP~list に次の結果を成す各~itemを順に付加する ⇒ `直列形の~CSP~listを構文解析する$A( 次の結果, `header^l, `enforce^l ) ⇒ `~header~listから値を抽出する$A( %応答 の`~header~list$rs, `Content-Security-Policy^h ) ◎ Let policies be the result of parsing the result of extracting header list values given Content-Security-Policy and response’s header list, with a source of "header", and a disposition of "enforce".
- %~CSP~list に次の結果を成す各~itemを順に付加する ⇒ `直列形の~CSP~listを構文解析する$A( 次の結果, `header^l, `report^l ) ⇒ `~header~listから値を抽出する$A( %応答 の`~header~list$rs, `Content-Security-Policy-Report-Only^h ) ◎ Append to policies the result of parsing the result of extracting header list values given Content-Security-Policy-Report-Only and response’s header list, with a source of "header", and a disposition of "report".
- %応答 の`~CSP~list$rs ~SET %~CSP~list ◎ For each policy in policies: • Insert policy into response’s CSP list.
4.1.2. %要請 に対する~CSP違反を報告する
次の~algoは、所与の ( `要請$ %要請 ) に対し, `~client$rqの “報告のみ” の施策に基づいて違反を報告する: ◎ Given a request (request), this algorithm reports violations based on client’s "report only" policies.
- %~CSP~list ~LET %要請 の`~client$rqの`大域~obj$enVの`~CSP~list$gO ◎ Let CSP list be request’s client’s global object’s CSP list.
-
%~CSP~list 内の ~EACH( %施策 ) に対し: ◎ For each policy in CSP list:
- ~IF[ %施策 の`処置先$ ~EQ `enforce^l ] ⇒ ~CONTINUE ◎ If policy’s disposition is "enforce", then skip to the next policy.
- %違反ed指令 ~LET `要請は施策に違反するか?$A( %要請, %施策 ) ◎ Let violates be the result of executing §6.6.1.1 Does request violate policy? on request and policy.
- ~IF[ %違反ed指令 ~NEQ `非違反^i ] ⇒ `違反を報告する$A( `新たな違反~obj$A( %要請, %施策, %違反ed指令 ) ) ◎ If violates is not "Does Not Violate", then execute §5.3 Report a violation on the result of executing §2.4.2 Create a violation object for request, policy, and directive on request, policy, and violates.
4.1.3. %要請 は~CSPにより阻止されるべきか?
次の~algoは、所与の ( `要請$ %要請 ) に対し,[ `阻止ed^i / `許容ed^i ]を返した上で、 %要請 の`~client$rqの~CSPに基づいて違反を報告する: ◎ Given a request (request), this algorithm returns Blocked or Allowed and reports violations based on request’s client’s Content Security Policy.
- %~CSP~list ~LET %要請 の`~client$rqの`大域~obj$enVの`~CSP~list$gO ◎ Let CSP list be request’s client’s global object’s CSP list.
- %結果 ~LET `許容ed^i ◎ Let result be "Allowed".
-
%~CSP~list 内の ~EACH( %施策 ) に対し: ◎ For each policy in CSP list:
- ~IF[ %施策 の`処置先$ ~EQ `report^l ] ⇒ ~CONTINUE ◎ If policy’s disposition is "report", then skip to the next policy.
- %違反ed指令 ~LET `要請は施策に違反するか?$A( %要請, %施策 ) ◎ Let violates be the result of executing §6.6.1.1 Does request violate policy? on request and policy.
-
~IF[ %違反ed指令 ~NEQ `非違反^i ]: ◎ If violates is not "Does Not Violate", then:
- `違反を報告する$A( `新たな違反~obj$A( %要請, %施策, %違反ed指令 ) ) ◎ Execute §5.3 Report a violation on the result of executing §2.4.2 Create a violation object for request, policy, and directive on request, policy, and violates.
- %結果 ~SET `阻止ed^i ◎ Set result to "Blocked".
- ~RET %結果 ◎ Return result.
4.1.4. %要請 に対する %応答 は~CSPにより阻止されるべきか?
次の~algoは、所与の ( `応答$ %応答, `要請$ %要請 ) に対し,[ `阻止ed^i / `許容ed^i ]を返した上で、 %要請 の `~client$rqの~CSPに基づいて違反を報告する: ◎ Given a response (response) and a request (request), this algorithm returns Blocked or Allowed, and reports violations based on request’s client’s Content Security Policy.
- %~CSP~list ~LET %要請 の`~client$rqの`大域~obj$enVの`~CSP~list$gO ◎ Let CSP list be request’s client’s global object’s CSP list.
- %結果 ~LET `許容ed^i ◎ Let result be "Allowed".
-
%~CSP~list 内の ~EACH( %施策 ) に対し: ◎ For each policy in CSP list:
-
%施策 内の ~EACH( %指令 ) に対し: ◎ For each directive in policy:
-
~IF[ %指令 の`要請後~検査$Aを実行した結果 ~EQ `阻止ed^i ]: ◎ If the result of executing directive’s post-request check is "Blocked", then:
- `違反を報告する$A( `新たな違反~obj$A( %要請, %施策, %指令 ) ) ◎ Execute §5.3 Report a violation on the result of executing §2.4.2 Create a violation object for request, policy, and directive on request, policy, and directive.
- ~IF[ %施策 の`処置先$ ~EQ `enforce^l ] ⇒ %結果 ~SET `阻止ed^i ◎ If policy’s disposition is "enforce", then set result to "Blocked".
-
注記: 検査のこの部位は、~pageが応答を読込めるかどうかを検証0する。 すなわち, Service Worker が、~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.
-
-
%応答 の`~CSP~list$rs内の ~EACH( %施策 ) に対し: ◎ For each policy in response’s CSP list:
-
%施策 内の ~EACH( %指令 ) に対し: ◎ For each directive in policy:
-
~IF[ ( %要請, %応答, %施策 ) に対し,%指令 の`応答~検査$Aを実行した結果 ~EQ `阻止ed^i ]: ◎ If the result of executing directive’s response check on request, response, and policy is "Blocked", then:
- `違反を報告する$A( `新たな違反~obj$A( %要請, %施策, %指令 ) ) ◎ Execute §5.3 Report a violation on the result of executing §2.4.2 Create a violation object for request, policy, and directive on request, policy, and directive.
- ~IF[ %施策 の`処置先$ ~EQ `enforce^l ] ⇒ %結果 ~SET `阻止ed^i ◎ If policy’s disposition is "enforce", then set result to "Blocked".
-
注記: 検査のこの部位は、応答に伴って送達されてきた施策が,応答の送達を許容するかどうかを決定できるようにする。 ◎ Note: This portion of the check allows policies delivered with the response to determine whether the response is allowed to be delivered.
-
- ~RET %結果 ◎ Return result.
4.2. ~HTMLとの統合
-
各[ `Document$I / `WorkerGlobalScope$I / `WorkletGlobalScope$I ]~objは、~CSP~listを持つ — それは、所与の文脈で作動中の`施策$~objすべてを保持する。 この~listは、指定されない限り空であり, `大域~objの~CSP~listを初期化する$A ~algoを介して拡充される。 ◎ The Document, WorkerGlobalScope, and WorkletGlobalScope objects have 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 via the §4.2.2 Initialize a global object’s CSP list algorithm.
この概念は、 W3C 版の Workers にはない( `187^IssW3C )。 ◎ This concept is missing from W3C’s Workers. <https://github.com/w3c/html/issues/187>
- `大域~obj$ %G の `~CSP~list@gO は、次の結果を返す ⇒ `~objの~CSP~listを得る$A( %G ) 【定義が循環参照になっている。】 ◎ A global object’s CSP list is the result of executing §4.2.3 Retrieve the CSP list of an object with the global object as the object.
- `施策$は、`大域~obj$の`~CSP~list$gO内に挿入されることにより,`大域~obj$に対し[ `施行-@ / `監視-@ ]されることになる。 ◎ A policy is enforced or monitored for a global object by inserting it into the global object’s CSP list.
- `大域~objの~CSP~listを初期化する$A手続きは、[ `応答$に結付けられた`施策$~objの集合 ]を[ 新たに作成された[ `Document$I / `WorkerGlobalScope$I / `WorkletGlobalScope$I ]に束縛する ]ために,[ `新たな文書~objを初期化する$, あるいは `~workerを走らす$ ]~algoの中から~callされる。 ◎ §4.2.2 Initialize a global object’s CSP list is called during the initializing a new Document object and run a worker algorithms in order to bind a set of policy objects associated with a response to a newly created Document, WorkerGlobalScope or WorkletGlobalScope.
-
`要素における~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.4 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.
- 所与の`文書$ %C に対し,次を満たす`文書$ %D が存在するならば、 %D を指して %C を `埋込んでいる文書@ という ⇒ %D が`属する閲覧文脈$は, %C が`属する閲覧文脈$を %D を`通して入子に$している ◎ A Document's embedding document is the Document through which the Document's browsing context is nested.
-
HTML は、[ 資源の読込みに責を負う要素 ]からの関連する~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の読込みは、まだ W3C 版~HTMLにおける~Fetchには統合されていない( <https://github.com/whatwg/html/issues/198> ) ◎ Stylesheet loading is not yet integrated with Fetch in W3C’s HTML. <https://github.com/whatwg/html/issues/198>
~stylesheetの読込みは、まだ WHATWG 版~HTMLにおける~Fetchには統合されていない( <https://github.com/whatwg/html/issues/968> ) ◎ Stylesheet loading is not yet integrated with Fetch in WHATWG’s HTML. <https://github.com/whatwg/html/issues/968>
- %文書 に対する %基底 は許容されるか? は、 `href$a 属性の値が妥当になることを確保するため, `base$e の`凍結~基底~URLを設定する$間に~callされる ◎ §6.2.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.
-
%~plugin要素 は~CSPにより先天的に阻止されるべきか? は、 `object$e / `embed$e / `applet$e 要素の処理に際し,それが ~fetchを誘発してよいかどうかを決定する間に~callされる ◎ §6.2.2.2 Should plugin element be blocked a priori by Content Security Policy?: is called during the processing of object, embed, and applet elements to determine whether they may trigger a fetch.
注記: ~fetchされた~plugin資源は、 `要請に対する応答は~CSPにより阻止されるべきか?$A にて取扱われる。 ◎ Note: Fetched plugin resources are handled in §4.1.4 Should response to request be blocked by Content Security Policy?.
この~hookは W3C 版~HTMLにはまだない。 `547^IssW3C ◎ This hook is missing from W3C’s HTML. <https://github.com/w3c/html/issues/547>
-
`~sourceから~targetを~navigateするある種別の要請は~CSPにより阻止されるべきか?$Aは、`~navigate~fetchを処理する$A間に~callされる。 `~sourceから~targetを~navigateするある種別の要請に対する応答は~CSPにより阻止されるべきか?$Aは、`~navigate応答を処理する$A間に~callされる。 いずれも,指令の~navi検査を適用する。 後者は `javascript_^sc ~URLへの~naviに対する~inline検査を適用する。 ◎ §4.2.5 Should navigation request of type from source in target be blocked by Content Security Policy? is called during the process a navigate fetch algorithm, and §4.2.6 Should navigation response to navigation request of type from source in target be blocked by Content Security Policy? is called during the process a navigate response algorithm to apply directive’s navigation checks, as well as inline checks for navigations to javascript: URLs.
W3C 版~HTMLは ~Fetchに基づいておらず,`~navigate応答を処理する$A~algoを~hookする場がない。 `548^IssW3C ◎ W3C’s HTML is not based on Fetch, and does not have a process a navigate response algorithm into which to hook. <https://github.com/w3c/html/issues/548>
4.2.1. 文書の~CSP~listを初期化する
この手続きは、所与の ( `文書$ %文書, `応答$ %応答 ) に対し, %文書 の`~CSP~list$docを初期化する: ◎ Given a Document (document), and a response (response), the user agent performs the following steps in order to initialize document’s CSP list:
-
~IF[ %応答 の`~url$rsの`~scheme$urlは `局所~scheme$である ]: ◎ If response’s url’s scheme is a local scheme:
- %文書たち ~LET 空~list ◎ Let documents be an empty list.
- ~IF[ %文書 を`埋込んでいる文書$ %D はある ] ⇒ %D を %文書たち に追加する ◎ If document has an embedding document (embedding), then add embedding to documents.
- ~IF[ %文書 を`開いた閲覧文脈$ %B はある ] ⇒ %B にて`作動中の文書$を %文書たち に追加する ◎ If document has an opener browsing context, then add its active document to documents.
- %文書たち 内の ~EACH( %D ) に対し ⇒ %D の`~CSP~list$doc内の ~EACH( %施策 ) に対し ⇒ %文書 の`~CSP~list$docの中に %施策 の複製を挿入する ◎ For each doc in documents: • For each policy in doc’s CSP list: ••Insert a copy of policy into document’s CSP list.
注記: `局所~scheme$には `about_^sc も含まれるので、この~algoは, `~iframe-srcdoc文書$を`埋込んでいる文書$の施策を複製する。 ◎ Note: local scheme includes about:, and this algorithm will therefore copy the embedding document’s policies for an iframe srcdoc Document.
注記: この段は、次を確保するためにある ⇒ [ ~frameを埋込む / 新たな~windowを~pop-upする ]ことにより,~pageが制御する内容( `blob_^sc 資源, `document.write()^c など)が~pageの`施策$を迂回することは、できない。 ◎ Note: We do all this to ensure that a page cannot bypass its policy by embedding a frame or popping up a new window containing content it controls (blob: resources, or document.write()).
- %応答 の`~CSP~list$rs内の ~EACH( %施策 ) に対し ⇒ %文書 の`~CSP~list$docの中に %施策 を挿入する ◎ For each policy in response’s CSP list, insert policy into document’s CSP list.
- %文書 の`~CSP~list$doc内の ~EACH( %施策 ) に対し ⇒ %施策 内の ~EACH( %指令 ) に対し ⇒ ( %文書, %応答 ) を与える下で, %指令 の`初期化$A~algoを実行する ◎ For each policy in document’s CSP list: • For each directive in policy: •• Execute directive’s initialization algorithm on document and response.
4.2.2. 大域~objの~CSP~listを初期化する
この手続きは、所与の ( `大域~obj$ %大域~obj, `応答$ %応答 ) に対し, %大域~obj の`~CSP~list$gOを初期化する: ◎ Given a global object (global), and a response (response), the user agent performs the following steps in order to initialize global’s CSP list:
-
~IF[ %応答 の`~url$rsの`~scheme$urlは `局所~scheme$である ]~OR[ %大域~obj は `DedicatedWorkerGlobalScope$I である ]: ◎ If response’s url’s scheme is a local scheme, or if global is a DedicatedWorkerGlobalScope:
- %大域~obj の`所有者~集合$ 内の ~EACH( %所有者 ) に対し ⇒ %所有者 の`~CSP~list$gO内の ~EACH( %施策 ) に対し ⇒ %大域~obj の`~CSP~list$gOの中に %施策 の複製を挿入する ◎ Let owners be an empty list. ◎ Add each of the items in global’s owner set to owners. ◎ For each owner in owners: • For each policy in owner’s CSP list: •• Insert a copy of policy into global’s CSP list.
注記: `局所~scheme$には `about_^sc も含まれる — したがってこの~algoは、`~iframe-srcdoc文書$を`埋込んでいる文書$の施策を複製する。 ◎ Note: local scheme includes about:, and this algorithm will therefore copy the embedding document’s policies for an iframe srcdoc Document.
- ~IF[ %大域~obj は[ `SharedWorkerGlobalScope$I / `ServiceWorkerGlobalScope$I ]である ] ⇒ %応答 の`~CSP~list$rs内の ~EACH( %施策 ) に対し ⇒ %大域~obj の`~CSP~list$gOの中に %施策 を挿入する ◎ If global is a SharedWorkerGlobalScope or ServiceWorkerGlobalScope: • For each policy in response’s CSP list, insert policy into global’s CSP list.
- ~IF[ %大域~obj は `WorkletGlobalScope$I である ] ⇒ %大域~obj の`所有者~文書$の`~CSP~list$gO内の ~EACH( %施策 ) に対し ⇒ %大域~obj の`~CSP~list$gOの中に %施策 の複製を挿入する ◎ If global is a WorkletGlobalScope: • Let owner be global’s owner document. • For each policy in owner’s CSP list: •• Insert a copy of policy into global’s CSP list.
4.2.3. %~obj の~CSP~listを得る
%~obj の`~CSP~list$gOを得るときは %~obj に応じて,次を返す ⇒# `文書$であるならば %~obj の`~CSP~list$doc / `Window$I であるならば %~obj に`結付けられている文書$の`~CSP~list$doc / `WorkerGlobalScope$I であるならば %~obj の`~CSP~list$gO / `WorkletGlobalScope$I であるならば %~obj の`~CSP~list$gO / ~ELSE_ ~NULL ◎ To obtain object’s CSP list: • If object is a Document return object’s CSP list. • If object is a Window return object’s associated Document’s CSP list. • If object is a WorkerGlobalScope, return object’s CSP list. • If object is a WorkletGlobalScope, return object’s CSP list. • Return null.
4.2.4. %要素 における~inline型の挙動は~CSPにより阻止されるべきか?
この~algoは、所与の ( `要素$ %要素, 文字列 %型, 文字列 %~source ) に対し, %要素 における[ ~inline定義による特定0の型の挙動( ~script実行, ~styleの適用, ~event~handler, 等々) ]が[ 許容されるならば `許容ed^i / 許容されないならば `阻止ed^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 `許容ed^i ◎ Let result be "Allowed".
-
%要素 の`文書$の`大域~obj$の`~CSP~list$gO 内の ~EACH( %施策 ) に対し: ◎ For each policy in element’s Document's global object’s CSP list:
-
%施策 の`指令~集合$内の ~EACH( %指令 ) に対し: ◎ For each directive in policy’s directive set:
- ~IF[ %指令 の`~inline検査$A( %要素, %型, %~source ) の結果 ~EQ `許容ed^i ] ⇒ ~CONTINUE ◎ If directive’s inline check returns "Allowed" when executed upon element, type, and source, skip to the next directive.
- %違反 ~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’s 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.3 Report a violation on violation.
- ~IF[ %施策 の`処置先$ ~EQ `enforce^l ] ⇒ %結果 ~SET `阻止ed^i ◎ If policy’s disposition is "enforce", then set result to "Blocked".
-
- ~RET %結果 ◎ Return result.
4.3. ECMAScript との統合
ECMAScript では、~host環境が 文字列から ECMAScript ~codeへの~compilationを阻止できるようにする `HostEnsureCanCompileStrings$jA() 抽象演算が定義されている。 この文書は、その抽象演算の実装を定義する — それは、関連する`~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 thich examines the relevant CSP list to determine whether such compilation ought to be blocked.
4.3.1. `EnsureCSPDoesNotBlockStringCompilation^jA(%callerRealm, %calleeRealm, %source)
この~algoは、所与の 2 つの`~realm$ ( %callerRealm, %calleeRealm ), および ( 【~scriptの~sourceを与える文字列】%~source ) に対し,文字列の~compilationが許容されないならば `EvalError^E を投出し,他の場合は何もしない: ◎ Given two realms (callerRealm and calleeRealm), and a string (source), this algorithm returns normally if string compilation is allowed, and throws an "EvalError" if not:
- %大域~obj~list ~LET [ %callerRealm の`大域~obj$rM, %calleeRealm の`大域~obj$rM ]からなる~list ◎ Let globals be a list containing callerRealm’s global object and calleeRealm’s global object.
-
%大域~obj~list 内の ~EACH( %大域~obj ) に対し: ◎ For each global in globals:
- %結果 ~LET `許容ed^i ◎ Let result be "Allowed".
-
%大域~obj の`~CSP~list$gO内の ~EACH( %施策 ) に対し: ◎ For each policy in global’s CSP list:
- %~source~list ~LET ~NULL ◎ Let source-list be null.
- ~IF[ %施策 内に[ `名前$ ~EQ `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[ %施策 内に[ `名前$ ~EQ `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`~ACI$ `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 `inline^l ◎ Set violation’s resource to "inline".
- ~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 source containing its first 40 characters.
- `違反を報告する$A( %違反 ) ◎ Execute §5.3 Report a violation on violation.
- ~IF[ %施策 の`処置先$ ~EQ `enforce^l ] ⇒ %結果 ~SET `阻止ed^i ◎ If policy’s disposition is "enforce", then set result to "Blocked".
- ~IF[ %結果 ~EQ `阻止ed^i ] ⇒ ~THROW `EvalError^E ◎ If result is "Blocked", throw an EvalError exception.
`HostEnsureCanCompileStrings$jA() は、~compileされようとしている文字列を~parameterにとらない。 その値が~CSPを通して~pipeされるよう,~HTMLを更新する必要がある。 <https://github.com/tc39/ecma262/issues/938> ◎ HostEnsureCanCompileStrings() does not include the string which is going to be compiled as a parameter. We’ll also need to update HTML to pipe that value through to CSP. <https://github.com/tc39/ecma262/issues/938>
5. 報告-法
一つ以上の`施策$の指令が違反されたときは、 `違反~報告@ が生成され,[ `施策$に結付けられている`報告先$( `reporting endpoint^en ) ]に向けて送信されてよい。 ◎ When one or more of a policy’s directives is violated, a violation report may be generated and sent out to a reporting endpoint associated with the policy.
5.1. 違反 DOM ~event
enum `SecurityPolicyViolationEventDisposition@I { `enforce@l, `report@l }; [`Constructor@m( DOMString %type, optional `SecurityPolicyViolationEventInit$I %eventInitDict )] interface `SecurityPolicyViolationEvent@I : `Event$I { readonly attribute USVString `documentURI@m; readonly attribute USVString `referrer@m; readonly attribute USVString `blockedURI@m; readonly attribute DOMString `violatedDirective@m; readonly attribute DOMString `effectiveDirective@m; readonly attribute DOMString `originalPolicy@m; readonly attribute USVString `sourceFile@m; readonly attribute DOMString `sample@m; readonly attribute `SecurityPolicyViolationEventDisposition$I `disposition@m; readonly attribute unsigned short `statusCode@m; readonly attribute unsigned long `lineNumber@m; readonly attribute unsigned long `columnNumber@m; }; dictionary `SecurityPolicyViolationEventInit@I : `EventInit$I { required USVString `documentURI@d; USVString `referrer@d = ""; USVString `blockedURI@d = ""; required DOMString `violatedDirective@d; required DOMString `effectiveDirective@d; required DOMString `originalPolicy@d; USVString `sourceFile@d = ""; DOMString `sample@d = ""; required `SecurityPolicyViolationEventDisposition$I `disposition@d; required unsigned short `statusCode@d; unsigned long `lineNumber@d = 0; unsigned long `columnNumber@d = 0; };
5.2. %違反 の直列化を得る(非推奨)
次の~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.
-
%~obj ~LET 各種~propが次のように初期化された,新たな~JS ~obj ◎ Let object be a new JavaScript object with properties initialized as follows:
- `document-uri^l ~SET `~URLを直列化する$( %違反 の`~url$vr, `素片は除外する^i ) ◎ "document-uri" • The result of executing the URL serializer on violation’s url, with the exclude fragment flag set.
- `referrer^l ~SET `~URLを直列化する$( %違反 の`~referrer$vr, `素片は除外する^i ) ◎ "referrer" • The result of executing the URL serializer on violation’s referrer, with the exclude fragment flag set.
- `blocked-uri^l ~SET `~URLを直列化する$( %違反 の`資源$vr, `素片は除外する^i ) ◎ "blocked-uri" • The result of executing the URL serializer on violation’s resource, with the exclude fragment flag set.
- `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 %違反 の`状態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$m のように。 ◎ 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.
-
~IF[ %違反 の`~source~file$vr ~NEQ ~NULL ] ⇒ %~obj の各種~propを次のように設定する: ◎ If violation’s source file is not null:
- `source-file^l ~SET `~URLを直列化する$( %違反 の`~source~file$vr, `素片は除外する^i ) ◎ Set object’s "source-file" property to the result of executing the URL serializer on violation’s source file, with the exclude fragment flag set.
- `line-number^l ~SET %違反 の`行番号$vr ◎ Set object’s "line-number" property to violation’s line number.
- `column-number^l ~SET %違反 の`列番号$vr ◎ Set object’s "column-number" property to violation’s column number.
- ~Assert:[ %~obj の `blocked-uri^l ~prop ~NEQ `inline^l ]ならば[ %~obj の `sample^l ~prop ~NEQ 空~文字列 ] ◎ Assert: If object’s "blocked-uri" property is not "inline", then its "sample" property is the empty string.
- ~RET [ %~obj に対し `JSON.stringify()$c を実行した結果 ] ◎ Return the result of executing JSON.stringify() on object.
5.3. %違反 を報告する
次の~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する$: ◎ 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 be violation’s global object.
- ~IF[ %~target は `Window$I ~objである ] ⇒ %~target ~SET %~target に`結付けられている文書$ ◎ If target is a Window, set target to target’s associated Document.
-
%~target に向けて,名前 `securitypolicyviolation$et の`~eventを発火する$ — `SecurityPolicyViolationEvent$I ~interfaceを利用し,次のように初期化して: ◎ Fire an event named securitypolicyviolation that uses the SecurityPolicyViolationEvent interface at target with its attributes initialized as follows:
- `documentURI$m ~SET `~URLを直列化する$( %違反 の`~url$vr, `素片は除外する^i ) ◎ documentURI • The result of executing the URL serializer on violation’s url, with the exclude fragment flag set.
- `referrer$m ~SET `~URLを直列化する$( %違反 の`~referrer$vr, `素片は除外する^i ) ◎ referrer • The result of executing the URL serializer on violation’s referrer, with the exclude fragment flag set.
- `blockedURI$m ~SET `~URLを直列化する$( %違反 の`資源$vr, `素片は除外する^i ) ◎ blockedURI • The result of executing the URL serializer on violation’s resource, with the exclude fragment flag set.
- `effectiveDirective$m ~SET %違反 の`有効な指令$vr ◎ effectiveDirective • violation’s effective directive
- `violatedDirective$m ~SET %違反 の`有効な指令$vr ◎ violatedDirective • violation’s effective directive
- `originalPolicy$m ~SET %違反 の`施策$vr を`直列化-$した結果 ◎ originalPolicy • The serialization of violation’s policy
- `disposition$m ~SET %違反 の`処置先$vr ◎ disposition • violation’s disposition
- `sourceFile$m ~SET %違反 の`~source~file$vr に応じて ⇒# ~NULL ならば 空~文字列 / ~ELSE_ `~URLを直列化する$( %違反 の`~source~file$vr, `素片は除外する^i ) ◎ sourceFile • The result of executing the URL serializer on violation’s source file, with the exclude fragment flag set if the violation’s source file it not null and the empty string otherwise.
- `statusCode$m ~SET %違反 の`状態code$vr ◎ statusCode • violation’s status
- `lineNumber$m ~SET %違反 の`行番号$vr ◎ lineNumber • violation’s line number
- `columnNumber$m ~SET %違反 の`列番号$vr ◎ columnNumber • violation’s column number
- `sample$m ~SET %違反 の`見本$vr ◎ sample • violation’s sample
- `bubbles$m ~SET ~T ◎ bubbles • true
- `composed$m ~SET ~T ◎ composed • true
注記: [ `effectiveDirective$m, `violatedDirective$m ]の両者とも同じ値にされる。 これは,後方互換性を保守するためであり、意図的である。 ◎ Note: Both effectiveDirective and violatedDirective are the same value. This is intentional to maintain backwards compatibility.
注記: ここでは `composed$m 属性を設定する。 すなわち、この~eventは ~shadow木にも伝播することになる — `target$m その他の~~詳細は、~~自動的に,~light木が正しく視野に入るようにされる。 ◎ 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.
-
`(A)^i:
~IF[ %違反 の`施策$vrの`指令~集合$内に[ `名前$ ~EQ `report-uri$dir ]なる`指令$ %指令 はある ]: ◎ If violation’s policy’s directive set contains a directive named "report-uri" (directive):- ~IF[ %違反 の`施策$の`指令~集合$内に[ `名前$ ~EQ `report-to$dir ]なる`指令$はある ] ⇒ ~BREAK `(A)^i ◎ If violation’s policy’s directive set contains a directive named "report-to", skip the remaining substeps.
-
%指令 の`値$を成す ~EACH( %~token ) に対し: ◎ For each token returned by splitting a string on ASCII whitespace with directive’s value as the input.
- %報告先 ~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 `(A)^i ◎ If endpoint is not a valid URL, skip the remaining substeps.
-
%要請 ~LET 次のように初期化された新たな`要請$: ◎ Let request be a new request, initialized as follows:
- `~method$rq ~SET `POST^l ◎ method • "POST"
- `~url$rq ~SET %違反 の`~url$vr ◎ url • violation’s url
- `生成元$rq ~SET %違反 の`大域~obj$vrに`関連する設定群~obj$の`生成元$enV ◎ origin • violation’s global object’s relevant settings object’s origin
- `~window$rq ~SET `no-window^l ◎ window • "no-window"
- `~client$rq ~SET %違反 の`大域~obj$vrに`関連する設定群~obj$ ◎ client • violation’s global object’s relevant settings object
- `行先$rq ~SET `report^l ◎ destination • "report"
- `起動元$rq ~SET 空~文字列 ◎ initiator • ""
- `資格証~mode$rq ~SET `same-origin^l ◎ credentials mode • "same-origin"
- `~keepalive~flag$rq ~SET ~ON ◎ keepalive flag • "true"
- `~header~list$rq ~SET [ ( 名前 ~SET `Content-Type^h / 値 ~SET `application/csp-report^l ) にされた単独の~header ]を包含する`~header~list$ ◎ header list • A header list containing a single header whose name is "Content-Type", and value is "application/csp-report"
- `本体$rq ~SET %違反 を`直列化-(非推奨)$Aした結果 ◎ body • The result of executing §5.2 Obtain the deprecated serialization of violation on violation
- `~redirect~mode$rq ~SET `error^l ◎ 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[ %違反 の`施策$の`指令~集合$内に[ `名前$ ~EQ `report-to$dir ]なる`指令$ %指令 はある ]: ◎ If violation’s policy’s directive set contains a directive named "report-to" (directive):
- %~group ~LET %指令 の`値$ ◎ Let group be directive’s value.
- %設定群~obj ~LET %違反 の`大域~obj$に`関連する設定群~obj$ ◎ Let settings object be violation’s global object’s relevant settings object.
- 次を与える下で,`報告先~group用に~dataを~queueする$A `REPORTING$r ⇒# %~data ~SET %違反, %種別 ~SET `CSP^l, %報告先~group ~SET %~group, %設定群 ~SET %設定群~obj ◎ Execute [REPORTING]'s Queue data as type for endpoint group on settings algorithm with the following arguments: data • violation type • "CSP" endpoint group • group settings • settings object
-
6. ~CSP指令
この仕様は、~web開発者が、自身の~siteの挙動のある種の側面を制御できるようにするための,いくつかの型の`指令$を定義する:
- 資源の~fetch~~処理を統治する指令( ~fetch指令 節)
- 文書の状態を統治する指令( 文書~指令 節)
- ~naviのある側面を統治する指令( ~navi指令 節)
- 報告-法を統治する指令( 指令の報告-法 節)
これらは,~CSPの中核を形成し、他の指令は補佐的な文書にて~modularに定義される( 他の文書にて定義される指令 節にて例を見れる)。
◎ 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.2 Document Directives), directives which govern aspects of navigation (in §6.3 Navigation Directives), and directives which govern reporting (in §6.4 Reporting Directives). These form the core of Content Security Policy; other directives are defined in a modular fashion in ancillary documents (see §6.5 Directives Defined in Other Documents for examples).~web開発者は、~XSS攻撃による~riskを軽減するため,次のいずれかの指令を含ませて[ ~script/~plugin ]の~sourceを規制する~SHOULDである: ◎ 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 を含ませる~SHOULDでない。 両者とも,[ 文書~自身~内に~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 指令は,~web開発者が信用する~sourceからの~scriptを許容して,~page上で実行できるようにする。 また、 `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 指令は、[ `入子の閲覧文脈$(例: `iframe$e / `frame$e ~navi ) / `Worker^I 実行~文脈 ]の作成を統治する。 この指令の名前と値の構文は、次の`~ABNF$で述べられる: ◎ The child-src directive governs the creation of nested browsing contexts (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 ~EQ `document^l ]~AND[ その`~target閲覧文脈$rqは `入子の閲覧文脈$である ] (例: `iframe$e / `frame$e 要素を拡充するような要請)。 ◎ destination is "document", and whose target browsing context is a nested browsing context (e.g. requests which will populate an iframe or frame element)
- `行先$rq ~IN { `serviceworker^l, `sharedworker^l, `worker^l } (順に,[ `ServiceWorker$I, `SharedWorker$I, `Worker$I ]に対する,`~workerを走らす$~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.6.1.11 Get the effective directive for request on request.
- ~IF[ %名前 ~NIN { `frame-src^l, `worker-src^l } ] ⇒ ~RET `許容ed^i ◎ If name is not frame-src or worker-src, return "Allowed".
- ~IF[ %施策 内に[ `名前$ ~EQ %名前 ]なる`指令$はある ] ⇒ ~RET `許容ed^i ◎ If policy contains a directive whose name is name, 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.6.1.11 Get the effective directive for request on request.
- ~IF[ %名前 ~NIN { `frame-src^l, `worker-src^l } ] ⇒ ~RET `許容ed^i ◎ If name is not frame-src or worker-src, return "Allowed".
- ~IF[ %施策 内に[ `名前$ ~EQ %名前 ]なる`指令$はある ] ⇒ ~RET `許容ed^i ◎ If policy contains a directive whose name is name, 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$m 属性 ]。 この指令はまた、 `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へ直に接続する ]ための,少数の仕組みを提供する:
- `EventSource$I は、~push通知を受信するために,~serverへ開いた~HTTP接続を保守する。
- `WebSocket$I は、~browser↔~server間で,双方向通信channelを開く。
- `XMLHttpRequest$I は、任意の~HTTP要請を,~web開発者に利するために発行する。
これらは,有用な機能性を可能化する強力な~APIだが、 `exfiltration^en 【 “フィルタを超える” — 内部から外へ秘密裏に~dataを転送する】 へ誘う道も供する。
◎ JavaScript offers a few mechanisms that directly connect to an external server to send or receive information. EventSource maintains an open HTTP connection to a server in order to receive push notifications, WebSockets open a bidirectional communication channel between your browser and a server, and XMLHttpRequest makes arbitrary HTTP requests on your behalf. These are powerful APIs that enable useful functionality, but also provide tempting avenues for data exfiltration.`connect-src$dir 指令は、[ これらの類の接続は,~web開発者が信用する生成元に限って開かれる ]ことを確保できるようにする。 [ この指令に対する~source式の~listを定義する施策 ]の送信は、簡単である。 例えば,接続を `https://example.com^s のみに制限するときは、次の~headerを送信する: ◎ The connect-src directive allows you to ensure that these and similar sorts of connections are only opened to origins you trust. Sending a policy that defines a list of source expressions for this directive is straightforward. For example, to limit connections to only 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("https://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):
- ~Assert: %施策 は利用されない。 ◎ Assert: policy is unused.
-
~IF[ %要請 の`起動元$rq ~EQ `fetch^l ]~OR[ %要請 の`行先$rq ~EQ 空~文字列 ]: ◎ If request’s initiator is "fetch" or its destination is "":
- ~IF[ `要請は~source~listに合致するか?$A( %要請, この指令の`値$ ) ~EQ `非合致^i ] ⇒ ~RET `阻止ed^i ◎ If the result of executing §6.6.1.3 Does request match source list? on request and this directive’s value is "Does Not Match", return "Blocked".
- ~RET `許容ed^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):
- ~Assert: %施策 は利用されない。 ◎ Assert: policy is unused.
-
~IF[ %要請 の`起動元$rq ~EQ `fetch^l ]~OR[ %要請 の`行先$rq ~EQ 空~文字列 ]: ◎ If request’s initiator is "fetch" or its destination is "":
- ~IF[ `要請に対する応答は~source~listに合致するか?$A( %応答, %要請, この指令の`値$ ) ~EQ `非合致^i ] ⇒ ~RET `阻止ed^i ◎ If the result of executing §6.6.1.4 Does response to request match source list? on response, request, and this directive’s value is "Does Not Match", return "Blocked".
- ~RET `許容ed^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.3 Should request be blocked by Content Security Policy? and §4.1.4 Should response to request be blocked by Content Security Policy? algorithms.
次の~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; `prefetch-src$dir `self$pl; `object-src$dir `self$pl; `script-src$dir `self$pl; `style-src$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$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; `prefetch-src$dir `self$pl; `object-src$dir `self$pl; `script-src$dir https://example.com; `style-src$dir `self$pl; `worker-src$dir `self$pl
この挙動の下で,~siteのために施策を築く良い仕方の一つは、まず, `default-src$dir を `none$pl にする所から始め、[ 施策が適用される特定0の~pageに必要とされる資源~型 ]のみが許容されるように,施策を築上げるものになるであろう。 ◎ 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.6.1.11 Get the effective directive for request on request.
- ~IF[ %名前 ~EQ ~NULL ] ⇒ ~RET `許容ed^i ◎ If name is null, return "Allowed".
- ~IF[ %施策 内に[ `名前$ ~EQ %名前 ]なる`指令$はある ] ⇒ ~RET `許容ed^i ◎ If policy contains a directive whose name is name, return "Allowed".
- ~IF[ %名前 ~EQ `frame-src^l ]~AND[ %施策 内に[ `名前$ ~EQ `child-src^l ]なる`指令$はある ] ⇒ ~RET `許容ed^i ◎ If name is "frame-src", and policy contains a directive whose name is "child-src", return "Allowed".
- ~IF[ %名前 ~EQ `worker-src^l ]~AND[ %施策 内に[ `名前$ ~IN { `script-src^l, `child-src^l } ]なる`指令$はある ] ⇒ ~RET `許容ed^i ◎ If name is "worker-src", and policy contains a directive whose name is "script-src" or a directive whose name is "child-src" , return "Allowed".
- ~RET [ `指令$( %名前, この指令の値 ) の`要請前~検査$A ]( %要請, %施策 ) を実行した結果 ◎ Otherwise, 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.6.1.11 Get the effective directive for request on request.
- ~IF[ %名前 ~EQ ~NULL ] ⇒ ~RET `許容ed^i ◎ If name is null, return "Allowed".
- ~IF[ %施策 内に[ `名前$ ~EQ %名前 ]なる`指令$はある ] ⇒ ~RET `許容ed^i ◎ If policy contains a directive whose name is name, return "Allowed".
- ~IF[ %名前 ~EQ `frame-src^l ]~AND[ %施策 内に[ `名前$ ~EQ `child-src^l ]なる`指令$はある ] ⇒ ~RET `許容ed^i ◎ If name is "frame-src", and policy contains a directive whose name is "child-src", return "Allowed".
- ~IF[ %名前 ~EQ `worker-src^l ]~AND[ %施策 内に[ `名前$ ~IN { `script-src^l, `child-src^l } ]なる`指令$はある ] ⇒ ~RET `許容ed^i ◎ If name is "worker-src", and policy contains a directive whose name is "script-src" or a directive whose name is "child-src" , return "Allowed".
- ~RET [ `指令$( %名前, この指令の値 ) の`要請後~検査$A ]( %要請, %応答, %施策 ) を実行した結果 ◎ Otherwise, 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.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):
- ~Assert: %施策 は利用されない。 ◎ Assert: policy is unused.
-
~IF[ %要請 の`行先$rq ~EQ `font^l ]: ◎ If request’s destination is "font":
- ~IF[ `要請は~source~listに合致するか?$A( %要請, この指令の`値$ ) ~EQ `非合致^i ] ⇒ ~RET `阻止ed^i ◎ If the result of executing §6.6.1.3 Does request match source list? on request and this directive’s value is "Does Not Match", return "Blocked".
- ~RET `許容ed^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):
- ~Assert: %施策 は利用されない。 ◎ Assert: policy is unused.
-
~IF[ %要請 の`行先$rq ~EQ `font^l ]: ◎ If request’s destination is "font":
- ~IF[ `要請に対する応答は~source~listに合致するか?$A( %応答, %要請, この指令の`値$ ) ~EQ `非合致^i ] ⇒ ~RET `阻止ed^i ◎ If the result of executing §6.6.1.4 Does response to request match source list? on response, request, and this directive’s value is "Does Not Match", return "Blocked".
- ~RET `許容ed^i ◎ Return "Allowed".
6.1.5. `frame-src^dir
`frame-src@dir 指令は、[ どの~URLを`入子の閲覧文脈$内に読込んでよいか ]を制約する。 この指令の名前と値の構文は、次の`~ABNF$で述べられる: ◎ The frame-src directive restricts the URLs which may be loaded into nested browsing contexts. 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):
- ~Assert: %施策 は利用されない。 ◎ Assert: policy is unused.
-
~IF[ %要請 の`行先$rq ~EQ `document^l ]~AND[ %要請 の`~target閲覧文脈$rqは`入子の閲覧文脈$である ]: ◎ If request’s destination is "document" and target browsing context is a nested browsing context:
- ~IF[ `要請は~source~listに合致するか?$A( %要請, この指令の`値$ ) ~EQ `非合致^i ] ⇒ ~RET `阻止ed^i ◎ If the result of executing §6.6.1.3 Does request match source list? on request and this directive’s value is "Does Not Match", return "Blocked".
- ~RET `許容ed^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):
- ~Assert: %施策 は利用されない。 ◎ Assert: policy is unused.
-
~IF[ %要請 の`行先$rq ~EQ `document^l ]~AND[ %要請 の`~target閲覧文脈$rqは`入子の閲覧文脈$である ]: ◎ If request’s destination is "document" and target browsing context is a nested browsing context:
- ~IF[ `要請に対する応答は~source~listに合致するか?$A( %応答, %要請, この指令の`値$ ) ~EQ `非合致^i ] ⇒ ~RET `阻止ed^i ◎ If the result of executing §6.6.1.4 Does response to request match source list? on response, request, and this directive’s value is "Does Not Match", return "Blocked".
- ~RET `許容ed^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):
- ~Assert: %施策 は利用されない。 ◎ Assert: policy is unused.
-
~IF[ %要請 の`行先$rq ~EQ `image^l ]: ◎ If request’s destination is "image":
- ~IF[ `要請は~source~listに合致するか?$A( %要請, この指令の`値$ ) ~EQ `非合致^i ] ⇒ ~RET `阻止ed^i ◎ If the result of executing §6.6.1.3 Does request match source list? on request and this directive’s value is "Does Not Match", return "Blocked".
- ~RET `許容ed^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):
- ~Assert: %施策 は利用されない。 ◎ Assert: policy is unused.
-
~IF[ %要請 の`行先$rq ~EQ `image^l ]: ◎ If request’s destination is "image":
- ~IF[ `要請に対する応答は~source~listに合致するか?$A( %応答, %要請, この指令の`値$ ) ~EQ `非合致^i ] ⇒ ~RET `阻止ed^i ◎ If the result of executing §6.6.1.4 Does response to request match source list? on response, request, and this directive’s value is "Does Not Match", return "Blocked".
- ~RET `許容ed^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):
- ~Assert: %施策 は利用されない。 ◎ Assert: policy is unused.
-
~IF[ %要請 の`行先$rq ~EQ `manifest^l ]: ◎ If request’s destination is "manifest":
- ~IF[ `要請は~source~listに合致するか?$A( %要請, この指令の`値$ ) ~EQ `非合致^i ] ⇒ ~RET `阻止ed^i ◎ If the result of executing §6.6.1.3 Does request match source list? on request and this directive’s value is "Does Not Match", return "Blocked".
- ~RET `許容ed^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):
- ~Assert: %施策 は利用されない。 ◎ Assert: policy is unused.
-
~IF[ %要請 の`行先$rq ~EQ `manifest^l ]: ◎ If request’s destination is "manifest":
- ~IF[ `要請に対する応答は~source~listに合致するか?$A( %応答, %要請, この指令の`値$ ) ~EQ `非合致^i ] ⇒ ~RET `阻止ed^i ◎ If the result of executing §6.6.1.4 Does response to request match source list? on response, request, and this directive’s value is "Does Not Match", return "Blocked".
- ~RET `許容ed^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):
- ~Assert: %施策 は利用されない。 ◎ Assert: policy is unused.
-
~IF[ %要請 の`行先$rq ~IN { `audio^l, `video^l, `track^l } ]: ◎ If request’s destination is one of "audio", "video", or "track":
- ~IF[ `要請は~source~listに合致するか?$A( %要請, この指令の`値$ ) ~EQ `非合致^i ] ⇒ ~RET `阻止ed^i ◎ If the result of executing §6.6.1.3 Does request match source list? on request and this directive’s value is "Does Not Match", return "Blocked".
- ~RET `許容ed^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):
- ~Assert: %施策 は利用されない。 ◎ Assert: policy is unused.
-
~IF[ %要請 の`行先$rq ~IN { `audio^l, `video^l, `track^l } ]: ◎ If request’s destination is one of "audio", "video", or "track":
- ~IF[ `要請に対する応答は~source~listに合致するか?$A( %応答, %要請, この指令の`値$ ) ~EQ `非合致^i ] ⇒ ~RET `阻止ed^i ◎ If the result of executing §6.6.1.4 Does response to request match source list? on response, request, and this directive’s value is "Does Not Match", return "Blocked".
- ~RET `許容ed^i ◎ Return "Allowed".
6.1.9. `prefetch-src^dir
`prefetch-src@dir 指令は、[ どの~URLから資源を ~prefetch / ~prerender してよいか ]を制約する。 この指令の名前と値の構文は、次の`~ABNF$で述べられる: ◎ The prefetch-src directive restricts the URLs from which resources may be prefetched or prerendered. The syntax for the directive’s name and value is described by the following ABNF:
`directive-name$p = "prefetch-src" `directive-value$p = `serialized-source-list$p
~pageが次の~CSPを伴うならば: ◎ Given a page with the following Content Security Policy:
Content-Security-Policy: `prefetch-src$dir https://example.com/
次の~codeによる~fetchは,~network~errorを返すことになる — 供された~URLは, `prefetch-src$dir の`~source~list$に合致しないので: ◎ Fetches for the following code will return network errors, as the URLs provided do not match prefetch-src's source list:
<link rel="prefetch" src="https://example.org/"></link> <link rel="prerender" src="https://example.org/"></link>
6.1.9.1. `prefetch-src^dir 要請前~検査
次の~algoが、この指令の`要請前~検査$Aを与える: ◎ This directive’s pre-request check is as follows:
所与の ( `要請$ %要請, `施策$ %施策 ) に対し: ◎ Given a request (request) and a policy (policy):
- ~Assert: %施策 は利用されない。 ◎ Assert: policy is unused.
-
~IF[ %要請 の`起動元$rq ~IN { `fetch^l, `prerender^l } ]: ◎ If request’s initiator is "prefetch" or "prerender":
- ~IF[ `要請は~source~listに合致するか?$A( %要請, この指令の`値$ ) ~EQ `非合致^i ] ⇒ ~RET `阻止ed^i ◎ If the result of executing §6.6.1.3 Does request match source list? on request and this directive’s value is "Does Not Match", return "Blocked".
- ~RET `許容ed^i ◎ Return "Allowed".
6.1.9.2. `prefetch-src^dir 要請後~検査
次の~algoが、この指令の`要請後~検査$Aを与える: ◎ This directive’s post-request check is as follows:
所与の ( `要請$ %要請, `応答$ %応答, `施策$ %施策 ) に対し: ◎ Given a request (request), a response (response), and a policy (policy):
- ~Assert: %施策 は利用されない。 ◎ Assert: policy is unused.
-
~IF[ %要請 の`起動元$rq ~IN { `fetch^l, `prerender^l } ]: ◎ If request’s initiator is "prefetch" or "prerender":
- ~IF[ `要請に対する応答は~source~listに合致するか?$A( %応答, %要請, この指令の`値$ ) ~EQ `非合致^i ] ⇒ ~RET `阻止ed^i ◎ If the result of executing §6.6.1.4 Does response to request match source list? on response, request, and this directive’s value is "Does Not Match", return "Blocked".
- ~RET `許容ed^i ◎ Return "Allowed".
6.1.10. `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> <applet archive="https://example.org/flash"></applet>
~URLを伴わない~pluginにより内容が読込まれる場合(おそらく、 `object$e 要素は `data$a 属性を欠いていて,指定された `type^a に基づいて何らかの既定~pluginを読込もうとしている)、 `object-src$dir の値が `none$pl ならば,阻止され~MUST — 他の場合、許容されることになる。 ◎ 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 / `applet$e ]要素がそれ自身のために発行する どの要請に対しても動作する。 これには、前者の二つ(~naviも含む)により生成される `入子の閲覧文脈$を拡充させるような要請も含まれる。 このことは、[ MIME 型が `text/html^c であるような `object$e 要素 ]など,~dataが[ さもなければ別の指令により制約されるような内容 ]に意味論的に等価であるときにも該当する。 ◎ Note: The object-src directive acts upon any request made on behalf of an object, embed, or applet element. This includes requests which would populate the nested browsing context 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されるとき(すなわち、`閲覧文脈$内の`~plugin文書$として — `embed$e / `object$e / `applet$e を介して下位資源として埋込まれるものでない)、その資源に伴って送達された`施策$は,その`~plugin文書$に適用されることになる。 よって開発者は、具体的には,応答に 施策 `object-src 'none'^dir を伴わせて送達することにより、~pluginを内容とする任意の資源の実行を防止できることになる。 これにより、力を備えた~plugin(および Flash その他がときに呈する, “面白い” 保安~model)がある下でも, Rosetta Flash の様な攻撃手法の~riskを軽減できるようになる。 ◎ Note: When a plugin resource is navigated to directly (that is, as a plugin document in the top-level browsing context or a nested browsing context, and not as an embedded subresource via embed, object, or applet), any policy delivered along with that resource will be applied to the plugin document. This means, for instance, that developers can prevent the execution of arbitrary resources as plugin content by delivering the policy object-src 'none' along with a response. Given plugins' power (and the sometimes-interesting security model presented by Flash and others), this could mitigate the risk of attack vectors like Rosetta Flash.
6.1.10.1. `object-src^dir 要請前~検査
次の~algoが、この指令の`要請前~検査$Aを与える: ◎ This directive’s pre-request check is as follows:
所与の ( `要請$ %要請, `施策$ %施策 ) に対し: ◎ Given a request (request) and a policy (policy):
- ~Assert: %施策 は利用されない。 ◎ Assert: policy is unused.
-
~IF[ %要請 の`行先$rq ~IN { `object^l, `embed^l } ]: ◎ If request’s destination is "object" or "embed":
- ~IF[ `要請は~source~listに合致するか?$A( %要請, この指令の`値$ ) ~EQ `非合致^i ] ⇒ ~RET `阻止ed^i ◎ If the result of executing §6.6.1.3 Does request match source list? on request and this directive’s value is "Does Not Match", return "Blocked".
- ~RET `許容ed^i ◎ Return "Allowed".
6.1.10.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):
- ~Assert: %施策 は利用されない。 ◎ Assert: policy is unused.
-
~IF[ %要請 の`行先$rq ~IN { `object^l, `embed^l } ]: ◎ If request’s destination is "object" or "embed":
- ~IF[ `要請に対する応答は~source~listに合致するか?$A( %応答, %要請, この指令の`値$ ) ~EQ `非合致^i ] ⇒ ~RET `阻止ed^i ◎ If the result of executing §6.6.1.4 Does response to request match source list? on response, request, and this directive’s value is "Does Not Match", return "Blocked".
- ~RET `許容ed^i ◎ Return "Allowed".
6.1.11. `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 指令は、次について統治する: ◎ The script-src directive governs five things:
- ~script`要請$は、 `要請は~CSPにより阻止されるべきか?$A に合格し~MUST。 ◎ Script requests MUST pass through §4.1.3 Should request be blocked by Content Security Policy?.
- ~script`応答$は、 `要請に対する応答は~CSPにより阻止されるべきか?$A に合格し~MUST。 ◎ Script responses MUST pass through §4.1.4 Should response to request be blocked by Content Security Policy?.
-
~inline `script$e 要素~blockは、 `要素における~inline型の挙動は~CSPにより阻止されるべきか?$A に合格し~MUST。 その挙動は、どの施策も 次のいずれかにより~inline~scriptを許容していない限り,阻止されることになる:
- `script-src$dir (または `default-src$dir )指令を指定しないことにより、暗黙的に。
- その~inline~blockに合致する[ `unsafe-inline$pl / `nonce-source$p / `hash-source$p ]を,明示的に指定することにより。
-
次の~JS実行~sink†は、 `unsafe-eval$pl ~source式で通過制御される: ◎ The following JavaScript execution sinks are gated on the "unsafe-eval" source expression:
- `eval()$c ◎ eval()
- `Function()$c ◎ Function()
- 第一~引数は~callableでない, `setTimeout()$m ◎ setTimeout() with an initial argument which is not callable.
- 第一~引数は~callableでない, `setInterval()$m ◎ setInterval() with an initial argument which is not callable.
注記: `setImmediate()^m や `execScript()^m の様な非~標準~sinkを実装する~UAは、それらも `unsafe-eval$pl 上で通過制御する~SHOULDである。 ◎ Note: If a user agent implements non-standard sinks like setImmediate() or execScript(), they SHOULD also be gated on "unsafe-eval".
【† 保安~文脈における~sink( “槽” )とは、~data~flowにおいて,最初に~app層に渡される,外部からの信用できない~data源を意味する( 参考 )。 実行~sink( `execution sink^en )とは、~scriptの~sourceとして構文解析された上で実行され得る(したがって脆弱性の源になり得る)ような文字列~data源となる~sinkを意味する。 】
- `javascript_^sc ~URLへの~naviは、 `script-src^dir ~inline検査 に合格し~MUST。 ◎ Navigation to javascript: URLs MUST pass through §6.1.11.3 script-src Inline Check.
6.1.11.1. `script-src^dir 要請前~検査
次の~algoが、この指令の`要請前~検査$Aを与える: ◎ This directive’s pre-request check is as follows:
所与の ( `要請$ %要請, `施策$ %施策 ) に対し: ◎ Given a request (request) and a policy (policy):
- ~IF[ %要請 に対する`有効な指令を取得-$Aした結果 ~EQ `worker-src$dir ]~AND[ %施策 内に[ `名前$ ~IN { `worker-src^l, `child-src^l } ]なる`指令$はある ] ⇒ ~RET `許容ed^i ◎ If the result of executing §6.6.1.11 Get the effective directive for request on request is "worker-src", and policy contains a directive whose name is "worker-src" or a directive whose name is "child-src", return "Allowed".
- %~list ~LET この指令の`値$ ◎ ↓
-
~IF[ %要請 の`行先$rqは`~scriptに類する$ ]: ◎ If request’s destination is script-like:
- ~IF[ `~nonceは~source~listに合致するか?$A( %要請 の`暗号用~nonce~metadata$rq, %~list ) ~EQ `合致es^i ] ⇒ ~RET `許容ed^i ◎ If the result of executing §6.6.1.2 Does nonce match source list? on request’s cryptographic nonce metadata and this directive’s value is "Matches", return "Allowed".
-
~IF[ %~list 内に[ `hash-source$p 文法に合致するような `~source式$ ]がある ]: ◎ Let integrity expressions be the set of source expressions in this directive’s value that match the hash-source grammar. ◎ If integrity expressions is not empty:
- %完全性~sourceたち ~LET %要請 の`完全性~metadata$rqを渡して,`~metadataを構文解析-$した結果 `SRI$r ◎ Let integrity sources be the result of executing the algorithm defined in Subresource Integrity §parse-metadata on request’s integrity metadata. [SRI]
-
~IF[ 次のすべてが満たされる ]…:
- %完全性~sourceたち ~NEQ `~metadataなし^i
- %完全性~sourceたち は空でない
- %完全性~sourceたち 内のどの %~source に対しても,[
次の両者を満たす `~source式$ %式
]が %~list 内にある:
- %~source の `hash-algo^P 成分 ~EQ %式 の `hash-algorithm$p 成分
- %~source の `base64-value^P 成分 ~EQ %式 の `base64-value$p 成分
…ならば ⇒ ~RET `許容ed^i
◎ If integrity sources is "no metadata" or an empty set, skip the remaining substeps. ◎ Let bypass due to integrity match be true. ◎ For each source in integrity sources: ◎ If this directive’s value does not contain a source expression whose hash-algorithm is a case-sensitive match for source’s hash-algo component, and whose base64-value is a case-sensitive match for source’s base64-value, then set bypass due to integrity match to false. ◎ If bypass due to integrity match is true, return "Allowed".
注記: ここで検証0するのは、[ %要請 の`完全性~metadata$rqで与えられる~metadataの集合 ]が[ この指令が指定する `hash-source$p `~source式$たちの集合 ]に包含されているかどうかまでである。 これは、応答において合致しない資源を阻止するときに,~browserによる Subresource Integrity `SRI$r の施行に依拠している。 ◎ Note: Here, we verify only that the request contains a set of integrity metadata which is a subset of the hash-source source expressions specified by this directive. We rely on the browser’s enforcement of Subresource Integrity [SRI] to block non-matching resources upon response.
-
~IF[ %~list は[ `~source式$ ~EQ`~ACI$ `strict-dynamic$pl ]を包含する ]: ◎ If this directive’s value contains a source expression that is an ASCII case-insensitive match for the "'strict-dynamic'" keyword-source:
-
~IF[ %要請 の`構文解析器~metadata$rq ~EQ `parser-inserted$l ] ⇒ ~RET `阻止ed^i ◎ If the request’s parser metadata is "parser-inserted", return "Blocked".
~ELSE ⇒ ~RET `許容ed^i ◎ 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 `阻止ed^i ◎ If the result of executing §6.6.1.3 Does request match source list? on request and this directive’s value is "Does Not Match", return "Blocked".
- ~RET `許容ed^i ◎ Return "Allowed".
6.1.11.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):
- ~IF[ %要請 に対する`有効な指令を取得-$Aした結果 ~EQ `worker-src$dir ]~AND[ %施策 内に[ `名前$ ~IN { `worker-src^l, `child-src^l } ]なる`指令$はある ] ⇒ ~RET `許容ed^i ◎ If the result of executing §6.6.1.11 Get the effective directive for request on request is "worker-src", and policy contains a directive whose name is "worker-src" or a directive whose name is "child-src", return "Allowed".
- %~list ~LET この指令の`値$ ◎ ↓
-
~IF[ %要請 の`行先$rqは`~scriptに類する$ ]: ◎ If request’s destination is script-like:
- ~IF[ `~nonceは~source~listに合致するか?$A( %要請 の`暗号用~nonce~metadata$rq, %~list ) ~EQ `合致es^i ] ⇒ ~RET `許容ed^i ◎ If the result of executing §6.6.1.2 Does nonce match source list? on request’s cryptographic nonce metadata and this directive’s value is "Matches", return "Allowed".
- ~IF[ %~list 内に `strict-dynamic$pl がある ]~AND[ %要請 の`構文解析器~metadata$rq ~EQ `parser-inserted$l ] ⇒ ~RET `許容ed^i ◎ If this directive’s value contains "'strict-dynamic'", and request’s parser metadata is not "parser-inserted", return "Allowed".
- ~IF[ `要請に対する応答は~source~listに合致するか?$A( %応答, %要請, %~list ) ~EQ `非合致^i ] ⇒ ~RET `阻止ed^i ◎ If the result of executing §6.6.1.4 Does response to request match source list? on response, request, and this directive’s value is "Does Not Match", return "Blocked".
- ~RET `許容ed^i ◎ Return "Allowed".
6.1.11.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), and a string (source):
- %~list ~LET この指令の`値$ ◎ ↓
-
~IF[ %型 ~IN { `script^l, `script attribute^l, `navigation^l } ]: ◎ If type is "script", "script attribute" or "navigation":
- ~Assert: [ %要素 ~NEQ ~NULL ]~OR[ %型 ~EQ `navigation^l ] ◎ Assert: element is not null or type is "navigation".
- ~IF[ `要素 は ( 型, ~source ) について~source~listに合致するか?$A( %要素, %~list, %型, %~source ) ~EQ `非合致^i ] ⇒ ~RET `阻止ed^i ◎ If the result of executing §6.6.2.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 `許容ed^i ◎ Return "Allowed".
6.1.12. `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 に合格し~MUST。 これには、次のものが含まれる: ◎ Style requests MUST pass through §4.1.3 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 に合格し~MUST。 ◎ Responses to style requests MUST pass through §4.1.4 Should response to request be blocked by Content Security Policy?.
-
~inline `style$e 要素~blockは、 `要素における~inline型の挙動は~CSPにより阻止されるべきか?$A に合格し~MUST。 その~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 ]に対する すべての呼出が含まれることになる。 `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. <https://github.com/w3c/webappsec-csp/issues/212>
6.1.12.1. `style-src^dir 要請前~検査
次の~algoが、この指令の`要請前~検査$Aを与える: ◎ This directive’s pre-request check is as follows:
所与の ( `要請$ %要請, `施策$ %施策 ) に対し: ◎ Given a request (request) and a policy (policy):
- ~Assert: %施策 は利用されない。 ◎ Assert: policy is unused.
- %~list ~LET この指令の`値$ ◎ ↓
-
~IF[ %要請 の`行先$rq ~EQ `style^l ]: ◎ If request’s destination is "style":
- ~IF[ `~nonceは~source~listに合致するか?$A( %要請 の`暗号用~nonce~metadata$rq, %~list ) ~EQ `合致es^i ] ⇒ ~RET `許容ed^i ◎ If the result of executing §6.6.1.2 Does nonce match source list? on request’s cryptographic nonce metadata and this directive’s value is "Matches", return "Allowed".
- ~IF[ `要請は~source~listに合致するか?$A( %要請, %~list ) ~EQ `非合致^i ] ⇒ ~RET `阻止ed^i ◎ If the result of executing §6.6.1.3 Does request match source list? on request and this directive’s value is "Does Not Match", return "Blocked".
- ~RET `許容ed^i ◎ Return "Allowed".
6.1.12.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):
- ~Assert: %施策 は利用されない。 ◎ Assert: policy is unused.
- %~list ~LET この指令の`値$ ◎ ↓
-
~IF[ %要請 の`行先$rq ~EQ `style^l ]: ◎ If request’s destination is "style":
- ~IF[ `~nonceは~source~listに合致するか?$A( %要請 の`暗号用~nonce~metadata$rq, %~list ) ~EQ `合致es^i ] ⇒ ~RET `許容ed^i ◎ If the result of executing §6.6.1.2 Does nonce match source list? on request’s cryptographic nonce metadata and this directive’s value is "Matches", return "Allowed".
- ~IF[ `要請に対する応答は~source~listに合致するか?$A( %応答, %要請, %~list ) ~EQ `非合致^i ] ⇒ ~RET `阻止ed^i ◎ If the result of executing §6.6.1.4 Does response to request match source list? on response, request, and this directive’s value is "Does Not Match", return "Blocked".
- ~RET `許容ed^i ◎ Return "Allowed".
6.1.12.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), and a string (source):
- %~list ~LET この指令の`値$ ◎ ↓
-
~IF[ %型 ~IN { `style^l, `style attribute^l } ]: ◎ If type is "style" or "style attribute":
- ~IF[ `要素 は ( 型, ~source ) について~source~listに合致するか?$A( %要素, %~list, %型, %~source ) ~EQ `非合致^i ] ⇒ ~RET `阻止ed^i ◎ If the result of executing §6.6.2.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 `許容ed^i ◎ Return "Allowed".
6.1.12.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.13. `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.1.13.1. `worker-src^dir 要請前~検査
次の~algoが、この指令の`要請前~検査$Aを与える: ◎ This directive’s pre-request check is as follows:
所与の ( `要請$ %要請, `施策$ %施策 ) に対し: ◎ Given a request (request) and a policy (policy):
- ~Assert: %施策 は利用されない。 ◎ Assert: policy is unused.
-
~IF[ %要請 の`行先$rq ~IN { `serviceworker^l, `sharedworker^l, `worker^l } ]: ◎ If request’s destination is one of "serviceworker", "sharedworker", or "worker":
- ~IF[ `要請は~source~listに合致するか?$A( %要請, %~list ) ~EQ `非合致^i ] ⇒ ~RET `阻止ed^i ◎ If the result of executing §6.6.1.3 Does request match source list? on request and this directive’s value is "Does Not Match", return "Blocked".
- ~RET `許容ed^i ◎ Return "Allowed".
6.1.13.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):
- ~Assert: %施策 は利用されない。 ◎ Assert: policy is unused.
-
~IF[ %要請 の`行先$rq ~IN { `serviceworker^l, `sharedworker^l, `worker^l } ]: ◎ If request’s destination is one of "serviceworker", "sharedworker", or "worker":
- ~IF[ `要請に対する応答は~source~listに合致するか?$A( %応答, %要請, %~list ) ~EQ `非合致^i ] ⇒ ~RET `阻止ed^i ◎ If the result of executing §6.6.1.4 Does response to request match source list? on response, request, and this directive’s value is "Does Not Match", return "Blocked".
- ~RET `許容ed^i ◎ Return "Allowed".
6.2. 文書~指令
この節の指令は、施策が適用される[ 文書/~worker ]環境の~propを統治する。 ◎ The following directives govern the properties of a document or worker environment to which a policy applies.
6.2.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の,`凍結~基底~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.2.1.1. %文書 に対する %基底 は許容されるか?
次の~algoは、 ( `~URL$ %基底, `文書$ %文書 ) が与えられた下で,[ %基底 を `base$e 要素の `href$a 属性の値として利用できるならば `許容ed^i / ~ELSE_ `阻止ed^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$gO内の ~EACH( %施策 ) に対し: ◎ For each policy in document’s global object’s csp list:
- %~source~list ~LET ~NULL ◎ Let source list be null.
- ~IF[ %施策 の`指令~集合$内に[ `名前$ ~EQ `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, %文書 の`~fallback基底~URL$の`生成元$url ) ~EQ `非合致^i ]: ◎ If the result of executing §6.6.1.5 Does url match source list in origin with redirect count? on base, source list, document’s fallback base URL’s 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.3 Report a violation on violation.
- ~IF[ %施策 の`処置先$ ~EQ `enforce^l ] ⇒ ~RET `阻止ed^i ◎ If policy’s disposition is "enforce", return "Blocked".
注記: ここで~fallback基底~URLと比較するのは、不透明な生成元の中へ~sandbox化された`~iframe-srcdoc文書$などを正しく扱うためである。 ◎ 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 `許容ed^i ◎ Return "Allowed".
6.2.2. `plugin-types^dir
`plugin-types@dir 指令は、読込める資源の型を制限することにより,文書の中に埋込める~pluginの集合を制約する。 この指令の名前と値の構文は、次の`~ABNF$で述べられる: ◎ The plugin-types directive restricts the set of plugins that can be embedded into a document by limiting the types of resources which can be loaded. The directive’s syntax is described by the following ABNF grammar:
`directive-name$p = "plugin-types" `directive-value$p = `media-type-list$p `media-type-list@p = `media-type$p *( `RWS$P `media-type$p ) `media-type@p = `type$p "/" `subtype$p ; type and subtype are defined in RFC 2045
`plugin-types^dir 指令が在する場合、 `embed$e / `object$e 要素の~instance化は、次のいずれかの条件が満たされるならば失敗することになる: ◎ If a plugin-types directive is present, instantiation of an embed or object element will fail if any of the following conditions hold:
- 要素は、 `type$a 属性を介して,`妥当な~MIME型$を明示的に宣言していない。 ◎ The element does not explicitly declare a valid MIME type via a type attribute.
- 宣言された型は指令の値~内の どの~itemにも合致しない。 ◎ The declared type does not match one of the items in the directive’s value.
- ~fetchされた資源は、宣言された型に合致しない。 ◎ The fetched resource does not match the declared type.
次の~CSPを伴う~pageが与えられた場合: ◎ Given a page with the following Content Security Policy:
`Content-Security-Policy$h: `plugin-types$dir application/pdf
次のいずれの~codeによる~fetchも,~network~errorになる: ◎ Fetches for the following code will all return network errors:
<!-- `type^a 宣言がない ◎ No 'type' declaration --> <object data="https://example.com/flash" ></object> <!-- `type^a 宣言が合致しない ◎ Non-matching 'type' declaration --> <object data="https://example.com/flash" type="application/x-shockwave-flash" ></object> <!-- 資源が合致しない ◎ Non-matching resource --> <object data="https://example.com/flash" type="application/pdf" ></object>
~pageが次の~headerを送信して Flash 内容を許容した場合: ◎ If the page allowed Flash content by sending the following header:
`Content-Security-Policy$h: `plugin-types$dir application/x-shockwave-flash
上の二番目の~itemは、成功裡に読込まれる: ◎ Then the second item above would load successfully:
<!--
`type^a 宣言, 資源の両者とも合致する
◎
Matching 'type' declaration and resource
-->
<object
data="https://example.com/flash"
type="application/x-shockwave-flash"
></object>
6.2.2.1. `plugin-types^dir 要請後~検査
次の~algoが、この指令の`要請後~検査$Aを与える: ◎ This directive’s post-request check algorithm is as follows:
所与の ( `要請$ %要請, `応答$ %応答, `施策$ %施策 ) に対し: ◎ Given a request (request), a response (response), and a policy (policy):
- ~Assert: %施策 は利用されない。 ◎ Assert: policy is unused.
-
~IF[ %要請 の`行先$rq ~IN { `object^l, `embed^l } ]: ◎ If request’s destination is either "object" or "embed":
- %型 ~LET `~MIME型を抽出する$A( %応答 の`~header~list$rs ) ◎ Let type be the result of extracting a MIME type from response’s header list.
- ~IF[ %型 ~NIN`~ACI$ この指令の`値$ ] ⇒ ~RET `阻止ed^i ◎ If type is not an ASCII case-insensitive match for any item in this directive’s value, return "Blocked".
- ~RET `許容ed^i ◎ Return "Allowed".
6.2.2.2. %~plugin要素 は~CSPにより先天的に阻止されるべきか?
この~algoは、所与の`要素$ %~plugin要素 に対し,[ %~plugin要素 の `type^a 属性と %~plugin要素 が属する文書に適用されている施策 ]に基づいて,[ `阻止ed^i または `許容ed^i ]を返す ◎ Given an Element (plugin element), this algorithm returns "Blocked" or "Allowed" based on the element’s type attribute and the policy applied to its document:
-
%~plugin要素 の`~node文書$の`~CSP~list$doc内の ~EACH( %施策 ) に対し: ◎ For each policy in plugin element’s node document’s CSP list:
-
~IF[ %施策 内に[ `名前$ ~EQ `plugin-types$dir ]なる`指令$ %指令 はある ]: ◎ If policy contains a directive (directive) whose name is plugin-types:
- %型 ~LET [ %~plugin要素 は `applet$e 要素である ならば `application/x-java-applet^l / ~ELSE_ %~plugin要素 は `type^a 属性を有するならば その値 / ~ELSE_ `null^l ] ◎ Let type be "application/x-java-applet" if plugin element is an applet element, or plugin element’s type attribute’s value if present, or "null" otherwise.
-
~IF[ 次のいずれかが満たされる ] ⇒ ~RET `阻止ed^i: ◎ Return "Blocked" if any of the following are true:
- %型 ~EQ `null^l ◎ type is null.
- %型 は`妥当な~MIME型$でない ◎ type is not a valid MIME type.
- %型 ~NIN`~ACI$ %指令 の`値$ ◎ type is not an ASCII case-insensitive match for any item in directive’s value.
-
- ~RET `許容ed^i ◎ Return "Allowed".
6.2.3. `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で~MUST: ◎ 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 *( `RWS$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.2.3.1. `sandbox^dir 応答~検査
次の~algoが、この指令の`応答~検査$Aを与える: ◎ This directive’s response check algorithm is as follows:
所与の ( `要請$ %要請, `応答$ %応答, `施策$ %施策 ) に対し: ◎ Given a request (request), a response (response), and a policy (policy):
- ~Assert: %応答 は利用されない。 ◎ Assert: response is unused.
- ~IF[ %施策 の`処置先$ ~NEQ `enforce^l ] ⇒ ~RET `許容ed^i ◎ If policy’s disposition is not "enforce", then return "Allowed".
-
~IF[ %要請 の`行先$rq ~IN { `serviceworker^l, `sharedworker^l, `worker^l } ]: ◎ If request’s destination is one of "serviceworker", "sharedworker", or "worker":
- %出力 ~LET この指令の`値$を入力に,`~sandbox法~指令を構文解析-$した結果 ◎ ↓
-
~IF[ `閲覧文脈~sandbox化( ~script )~flag$ ~IN %出力 ]~OR[ `閲覧文脈~sandbox化( 生成元 )~flag$ ~IN %出力 ] ⇒ ~RET `阻止ed^i ◎ If the result of the Parse a sandboxing directive algorithm using this directive’s value as the input 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 `許容ed^i ◎ Return "Allowed".
6.2.3.2. `sandbox^dir 初期化
次の~algoが、この指令の`初期化$Aを与える。 それは、その施策~内に `sandbox$dir 値が在するかどうかに則って,`文書$の`強制~sandbox法~flag集合$を次に従って調整する責を負う: ◎ This directive’s initialization algorithm is responsible for adjusting a Document's forced sandboxing flag set according to the sandbox values present in its policies, as follows:
所与の ( `文書$または`大域~obj$ %文脈, `応答$ %応答, `施策$ %施策 ) に対し: ◎ Given a Document or global object (context), a response (response), and a policy (policy):
- ~Assert: %応答 は利用されない。 ◎ Assert: response is unused.
-
~IF[ %施策 の`処置先$ ~NEQ `enforce^l ]~OR[ %文脈 は`文書$でない ] ⇒ ~RET ◎ If policy’s disposition is not "enforce", or context is not a Document, then abort this algorithm.
注記: この段は、~workerを~sandbox化できるようにした場合には,変更する必要がある。 そうするのは、相当に理に適うものに見える。 ◎ Note: This will need to change if we allow Workers to be sandboxed, which seems like a pretty reasonable thing to do.
- この指令の`値$を入力に, %文脈 の`強制~sandbox法~flag集合$を出力とする下で, `~sandbox法~指令を構文解析-$する ◎ Parse a sandboxing directive using this directive’s value as the input, and context’s forced sandboxing flag set as the output.
6.2.4. `disown-opener^dir
`disown-opener@dir 指令は、[ ~navigateされた資源【を呈示する閲覧文脈】の`未所有化~flag$が ~ON にされる ]ことを確保する。 この指令の名前と値の構文は、次の`~ABNF$で述べられる: ◎ The disown-opener directive ensures that a resource will disown its opener when navigated to. The directive’s syntax is described by the following ABNF grammar:
`directive-name$p = "disown-opener" `directive-value$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.
この~modelが正当かどうかは確かでない。 その逆 も~careされることを確保する必要がある — 文書を開いた側( `opener^en ), 開かれた側( `openee^en )の両者とも包摂するような、もっと上手い構文があるかもしれない。 `disown-openee^dir は変だ。 `disown 'opener' 'openee'^P はどうか? 生成元の制約は、片方または両方に課す必要はあるのか? ◎ Not sure this is the right model. We need to ensure that we take care of the inverse as well, and there might be a cleverer syntax that could encompass both a document’s opener, and a document’s openees. disown-openee is weird. Maybe disown 'opener' 'openee'? Do we need origin restrictions on either/both?
6.2.4.1. `disown-opener^dir 初期化
次の~algoが、この指令の`初期化$Aを与える: ◎ This directive’s initialization algorithm is as follows:
所与の ( `文書$または`大域~obj$ %文脈, `応答$ %応答, `施策$ %施策 ) に対し: ◎ Given a Document or global object (context), a response (response), and a policy (policy):
- ~Assert: %応答, %施策 は利用されない。 ◎ Assert: response and policy are unused.
- ~IF[ %文脈 の`担当の閲覧文脈$enVを`開いた閲覧文脈$はある ] ⇒ %文脈 の`未所有化~flag$ ~SET ~ON ◎ If context’s responsible browsing context has an opener browsing context, disown its opener.
これは `iframe$e 内では何をする? 何かある? ◎ What should this do in an iframe? Anything?
6.4. 指令の報告-法
この文書~内の各種~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, policy, and directive or §2.4.1 Create a violation object for global, policy, and directive, and passing that object to §5.3 Report a violation to deliver the report.
6.4.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の挙動が防止されたとき,`違反~報告$の送信-先になる~netowrk端点 — の集合を定義する。 ◎ The report-uri directive defines a set of endpoints to which violation reports will be sent when particular behaviors are prevented.
`directive-name$p = "report-uri" `directive-value$p = `uri-reference$p *( `RWS$P `uri-reference$p ) ; The uri-reference grammar is defined in Section 4.1 of RFC 3986.
この指令は、それ自身は効果を持たず,他の指令との組合せにおいてのみ効果を~~発揮する。 ◎ The directive has no effect in and of itself, but only gains meaning in combination with other directives.
6.4.2. `report-to^dir
`report-to@dir 指令は、違反~報告の送信-先とされるべき`報告先~group$ `REPORTING$r を定義する。 この指令の挙動は、`違反を報告する$A~algoにて定義される。 この指令の名前と値の構文は、次の`~ABNF$で述べられる: ◎ The report-to directive defines a reporting group to which violation reports ought to be sent [REPORTING]. The directive’s behavior is defined in §5.3 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.5. 他の文書にて定義される指令
この文書は、中核を成す指令の集合を定義し、他の仕様が~modularに拡張するための枠組みを整える。 この文書が~~発行された時点では、次の安定的な文書が~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 指令を定義する。 ◎ [MIX] defines block-all-mixed-content
- `UPGRADE-INSECURE-REQUESTS$r は、 `upgrade-insecure-requests$dir 指令を定義する。 ◎ [UPGRADE-INSECURE-REQUESTS] defines upgrade-insecure-requests
- `SRI$r は、 `require-sri-for$dir 指令を定義する。 ◎ [SRI] defines require-sri-for
~CSPに対する拡張は、 `RFC7762$r に従って登録され~MUST。 特に、その文書の 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, `初期化$A — を利用して,自身を~Fetch/~HTMLに統合する~SHOULDである。 ◎ New directives SHOULD use the pre-request check, post-request check, response check, and initialization hooks in order to integrate themselves into Fetch and HTML.
6.6. 各種~照合~algo
6.6.1. URL 照合
6.6.1.1. %要請 は%施策 に違反するか?
次の~algoは、所与の ( `要請$ %要請, `施策$ %施策 ) に対し,[ %要請 が %施策 に違反するならば 違反された`指令$ / 違反しないならば `非違反^i ]を返す: ◎ 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.
- %違反ed指令 ~LET `非違反^i ◎ Let violates be "Does Not Violate".
-
%施策 内の ~EACH( %指令 ) に対し: ◎ For each directive in policy:
- %結果 ~LET ( %要請, %施策 ) に対し, %指令 の`要請前~検査$Aを実行した結果 ◎ Let result be the result of executing directive’s pre-request check on request and policy.
- ~IF[ %結果 ~EQ `阻止ed^i ] ⇒ %違反ed指令 ~LET %指令 ◎ If result is "Blocked", then let violates be directive.
- ~RET %違反ed指令 ◎ Return violates.
6.6.1.2. %~nonce は %~source~list に合致するか?
次の~algoは、所与の ( `要請$の`暗号用~nonce~metadata$rq %~nonce, `~source~list$ %~source~list ) に対し,[ %~nonce が %~source~list 内のいずれかの式に合致するならば `合致es^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 in source list:
- ~IF[ %式 は `nonce-source$p 文法に合致する ]~AND[ %~nonce ~EQ %式 の `base64-value$p 成分 ] ⇒ ~RET `合致es^i ◎ If expression matches the nonce-source grammar, and nonce is a case-sensitive match for expression’s base64-value part, return "Matches".
- ~RET `非合致^i ◎ Return "Does Not Match".
6.6.1.3. %要請 は %~source~list に合致するか?
この~algoは、所与の ( `要請$ %要請, `~source~list$ %~source~list ) に対し,次を返す ⇒ `~urlは ( 生成元, ~redirect回数 ) について~source~listに合致するか?$A( %要請 の`現在の~url$rq, %~source~list, %要請 の`生成元$rq, %要請 の`~redirect回数$rq ) ◎ Given a request (request), and a source list (source list), this algorithm returns the result of executing §6.6.1.5 Does url match source list in origin with redirect count? on request’s current url, source list, request’s origin, and request’s redirect count.
注記: これは,一般に、所与の`要請$を検証0するために `指令$の`要請前~検査$A~algoから利用される。 ◎ Note: This is generally used in directives' pre-request check algorithms to verify that a given request is reasonable.
6.6.1.4. %要請 に対する %応答 は %~source~list に合致するか?
この~algoは、所与の ( `応答$ %応答, `要請$ %要請, `~source~list$ %~source~list ) に対し,次を返す ⇒ `~urlは ( 生成元, ~redirect回数 ) について~source~listに合致するか?$A( %応答 の`~url$rs, %~source~list, %要請 の`生成元$rq, %要請 の`~redirect回数$rq ) ◎ Given a request (request), and a source list (source list), this algorithm returns the result of executing §6.6.1.5 Does url match source list in origin with redirect count? on response’s url, source list, request’s origin, and request’s redirect count.
注記: これは,一般に、所与の`応答$を検証0するために `指令$の`要請後~検査$A~algoから利用される。 ◎ Note: This is generally used in directives' post-request check algorithms to verify that a given response is reasonable.
6.6.1.5. %~url は ( %生成元, %~redirect回数 ) について %~source~list に合致するか?
次の~algoは、所与の ( `~URL$ %~url, `~source~list$ %~source~list, `生成元$ %生成元, 整数 %~redirect回数 ) に対し, %~url は %~source~list 内のいずれかの`~source式$に[ 合致するならば `合致es^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 an empty list, return "Does Not Match".
-
~IF[ %~source~list は単独の文字列 %s のみからなる ]~AND[ %s ~EQ`~ACI$ "`none$pl" ] ⇒ ~RET `非合致^i ◎ If source list contains a single item which 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.
-
%~source~list 内の ~EACH( %式 ) に対し: ◎ For each expression in source list:
- ~IF[ `~urlは ( 生成元, ~redirect回数 ) について式に合致するか?$A( %~url, %式, %生成元, %~redirect回数 ) ~EQ `合致es^i ] ⇒ ~RET `合致es^i ◎ If §6.6.1.6 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.6.1.6. %~url は ( %生成元, %~redirect回数 ) について %式 に合致するか?
次の~algoは、 ( `~URL$ %~url, `~source式$ %式, `生成元$ %生成元, 整数 %~redirect回数 ) が与えられた下で, %~url が %式 に[ 合致するならば `合致es^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.
-
~IF[ %式 ~EQ `~asterisk$ ]~AND[ %~url の`~scheme$url ~IN { `~network~scheme$, %生成元 の`~scheme$o } ] ⇒ ~RET `合致es^i ◎ If expression is the string "*", return "Matches" if one or more of the following conditions is met: • url’s scheme is a network scheme. • url’s scheme is the same as origin’s scheme.
注記: この~logicは、非`~network~scheme$からの資源を許容するためには,[ 明示的にそう指定するか(例: `default-src * data: custom-scheme-1: custom-scheme-2:^s ),または 被保護~資源は同じ~schemeから読込まれ~MUST ]ことを意味する。 ◎ Note: This logic means that in order to allow a resource from a non-network 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$url ) ◎ 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$url ~EQ ~NULL ] ⇒ ~RET `非合致^i ◎ If url’s host is null, return "Does Not Match".
- ~IF[ %式 は `scheme-part$p を含む ]~AND[ `~scheme成分は合致するか?$A( %式 の `scheme-part$p, %~url の`~scheme$url ) ~EQ `非合致^i ] ⇒ ~RET `非合致^i ◎ ↑
-
~IF[ %式 は `scheme-part$p を含まない ]~AND[ `~scheme成分は合致するか?$A( %生成元 の`~scheme$o, %~url の`~scheme$url ) ~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".
注記: 上の `scheme-part$p に対するときと同様に、~schemeを伴わない `host-source$p 式は,非保安的~schemeから保安的~schemeへの昇格を許容する。 ◎ 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$url ) ~EQ `非合致^i ] ⇒ ~RET `非合致^i ◎ If expression’s host-part does not host-part match url’s host, return "Does Not Match".
- %~port成分 ~LET [ %式 は `port-part$p を含むならば それ / ~ELSE_ ~NULL ] ◎ Let port-part be expression’s port-part if present, and null otherwise.
- ~IF[ `~port成分は合致するか?$A(%~port成分, %~url の`~port$url, %~url の`~scheme$url ) ~EQ `非合致^i ] ⇒ ~RET `非合致^i ◎ If port-part does not port-part match url’s port and url’s scheme, 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の各~成分を`~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 `合致es^i ◎ Return "Matches".
-
~IF[ %式 ~EQ`~ACI$ "`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 `合致es^i ◎ origin is the same as url’s origin
-
~IF[ 次のすべてが満たされる ] ⇒ ~RET `合致es^i:
- %生成元 の`~host$url ~EQ %~url の`~host$url
- %生成元 の`~port$url ~EQ %~url の`~port$url — この比較においては ⇒ 両~urlのそれぞれに対し、その`~port$urlに対する~NULL値は,その`~scheme$url用の`既定~port$と見なす。
- [ %生成元 の`~scheme$url ~EQ `http^l ]~OR[ %~url の`~scheme$url ~IN { `https^l, `wss^l } ]
注記: 上の `scheme-part$p の~logicと同様に、 "`self$pl" 照合~algoは、そうするのが安全なときには,保安的~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.6.1.7. `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 に合致しない。
また,明示的に非保安的な式からの保安的への昇格は、常に許容される。 例えば、次の表の 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 |
-
~IF[ 次のいずれかが満たされる ] ⇒ ~RET `合致es^i: ◎ More formally, two ASCII strings (A and B) are said to scheme-part match if the following algorithm returns "Matches": ◎ If one of the following is true, return "Matches":
- %A ~EQ`~ACI$ %B ◎ A is an ASCII case-insensitive match for B.
- [ %A ~EQ`~ACI$ `http^l ]~AND[ %B ~EQ`~ACI$ `https^l ] ◎ A is an ASCII case-insensitive match for "http", and B is an ASCII case-insensitive match for "https".
- [ %A ~EQ`~ACI$ `ws^l ]~AND[ %B ~IN`~ACI$ { `wss^l, `http^l, `https^l } ] ◎ A is an ASCII case-insensitive match for "ws", and B is an ASCII case-insensitive match for "wss", "http", or "https".
- [ %A ~EQ`~ACI$ `wss^l ]~AND[ %B ~EQ`~ACI$ `https^l ] ◎ A is an ASCII case-insensitive match for "wss", and B is an ASCII case-insensitive match for "https".
- ~RET `非合致^i ◎ Return "Does Not Match".
6.6.1.8. `host-part^p の照合
`~host成分は合致するか?@A ( %A, %B ) (いずれも`~ASCII文字列$)は、~CSP~source式の `host-part$p %A が ~URLの`~host$url %B に合致するかどうかを検査する: ◎ An ASCII string host-part matches another ASCII string if a CSP source expression that contained the first as a host-part could potentially match a URL containing the latter as a host. For example, we say that "www.example.com" host-part matches "www.example.com". ◎ More formally, two ASCII strings (A and B) are said to host-part match if the following algorithm returns "Matches":
注記: この関係は非対称であり、 %A, %B を入れ替えた結果は同じになるとは限らない。 例えば、 ( %A, %B ) に対する ( `*.example.com^s, `www.example.com^s ) の結果は `合致es^i になるが, ( `www.example.com^s, `*.example.com^s ) の結果は `非合致^i になる。 ◎ Note: The matching relation is asymmetric. That is, A matching B does not mean that B will match A. For example, *.example.com host-part matches www.example.com, but www.example.com does not host-part match *.example.com.
-
~IF[ %A の最初の文字 ~EQ `~asterisk$ ]: ◎ If the first character of A is an U+002A ASTERISK character (*):
- %A ~SET %A から先頭の文字を除去した結果 ◎ Let remaining be the result of removing the leading ("*") from A.
- ~RET[ %A ~EQ`~ACI$[ %B の~~尾部( %A と同じ文字~数の) ]ならば `合致es^i / ~ELSE_ `非合致^i ] ◎ If remaining (including the leading U+002E FULL STOP character (.)) is an ASCII case-insensitive match for the rightmost characters of B, then return "Matches". Otherwise, return "Does Not Match".
- ~IF[ %A ~NEQ`~ACI$ %B ] ⇒ ~RET `非合致^i ◎ If A is not an ASCII case-insensitive match for B, return "Does Not Match".
-
~IF[ 次のいずれかの条件が満たされる ] ⇒ ~RET `非合致^i:
- [ %A は `IPv4address$p 規則 `RFC3986$r に合致する ]~AND[ %A ~NEQ `127.0.0.1^l ]
- %A は `~IPv6~address$である
注記: この仕様の将来~versionは、用法や需要に依存して,~literalによる[ IPv6 / IPv4 ]~addressを許容するかもしれない。 しかしながら、 IP ~addressの保安~上の特質は,名前を有する~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.
- ~RET `合致es^i ◎ Return "Matches".
6.6.1.9. `port-part^p の照合
`~port成分は合致するか?@A ( %A, %B, %~scheme ) (いずれも`~ASCII文字列$)は、 ~CSP~source式の `port-part$p %A が ~URLの[ `~port$url %B, `~scheme$url %~scheme ]に合致するかどうかを検査する: ◎ An ASCII string (port A) port-part matches two other ASCII strings (port B and scheme B) if a CSP source expression that contained the first as a port-part could potentially match a URL containing the latter as port and scheme. For example, "80" port-part matches matches "80"/"http".
- %既定~port ~LET %~scheme 用の`既定~port$
-
~RET[ 次のいずれかが満たされるならば `合致es^i / ~ELSE_ `非合致^i ]:
- [ %A ~EQ 空 ]~AND[ %B ~EQ %既定~port ]
- %A ~EQ `~asterisk$
- [ %A ~NEQ 空 ]~AND[ %A ~EQ %B † ]
- [ %B ~EQ 空 ]~AND[ %A ~EQ %既定~port ]
【 %A, %B には ~NULL も渡され得るが、おそらく,ここでの 空( `empty^en )を意味する。 】【 `既定~port$が未定義の場合にどう解釈されるのか不明。 】【† この比較は 数として解釈する下で行うのかどうか、はっきりしない(~URLの`~port$urlは、実際には整数として定義されている)。 例えば `080^l は~port番号 80 と異なるものと扱われるかもしれない。 】
6.6.1.10. `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 `合致es^i ◎ If path A is empty, return "Matches".
- ~IF[ %A ~EQ `~slash$ ]~AND[ %B ~EQ 空~文字列 ] ⇒ ~RET `合致es^i ◎ If path A consists of one character that is equal to the U+002F SOLIDUS character (/) and path B is empty, 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列を~byte列に~percent-復号する$( %listA[ %i ] ) ~NEQ `~byte列を~byte列に~percent-復号する$( %listB[ %i ] ) ] ⇒ ~RET `非合致^i ◎ For each piece A in path list A: • Let piece B be the next item in path list B. • Percent decode piece A. • Percent decode piece B. • If piece A is not a case-sensitive match for piece B, return "Does Not Match".
- ~RET `合致es^i ◎ Return "Matches".
6.6.1.11. %要請 に対する有効な指令を取得する
各種 `~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:
-
%要請 の`行先$rqに応じて: ◎ Switch on request’s destination, and execute the associated steps:
- 空~文字列
- ~IF[ %要請 の`起動元$rq ~EQ 空~文字列 ] ⇒ ~RET `connect-src$dir ◎ If the request’s initiator is the empty string, return connect-src.
- `manifest^l
- ~RET `manifest-src$dir
- `object^l
- `embed^l
- ~RET `object-src$dir
- `prefetch^l
- `prerender^l
- ~RET `prefetch-src$dir
- `document^l
- ~IF[ %要請 の`~target閲覧文脈$rqは`入子の閲覧文脈$である ] ⇒ ~RET `frame-src$dir ◎ If the request’s target browsing context is a nested browsing context, 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$dir ◎ Return style-src.
- `script^l
- `xslt^l
- ~RET `script-src$dir ◎ Return script-src.
- `sharedworker^l
- `worker^l
- ~RET `worker-src$dir ◎ Return worker-src.
- ~RET ~NULL ◎ Return null.
6.6.2. 要素に対する照合~algo
6.6.2.1. %要素 は~nonce可能か?
この~algoは、所与の`要素$ %要素 に対し, `nonce-source$p 式を[ 適用できるならば( ~nonceの盗用 節 を見よ) `~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 Stealing), 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 要素である ] ⇒ %要素 内の ~EACH( %属性 ) に対し: ◎ If element is a script element, then for each attribute in element:
- ~IF[ %属性 の名前 ~IN`~ACI$ { `<script^l, `<style^l } ] ⇒ ~RET `~nonce可能でない^i ◎ If attribute’s name is an ASCII case-insensitive match for the string "<script" or the string "<style", return "Not Nonceable".
- ~IF[ %属性 の値は `~ASCII大小無視$で[ `<script^l, `<style^l ]のいずれかに合致する文字列を包含している ] ⇒ ~RET `~nonce可能でない^i ◎ If attribute’s value contains an ASCII case-insensitive match the string "<script" or the string "<style", return "Not Nonceable".
-
~IF[ %要素 を~token化したときに duplicate-attribute 構文解析-~error が生じている ] ⇒ ~RET `~nonce可能でない^i ◎ If element had a duplicate-attribute parse error during tokenization, return "Not Nonceable".
この~errorを記録するための 何らかの類の~hookが~HTML内に必要である — それをここで用いるのを計画しているならば。 <https://github.com/whatwg/html/issues/3257> ◎ We need some sort of hook in HTML to record this error if we’re planning on using it here. <https://github.com/whatwg/html/issues/3257>
- ~RET `~nonce可能^i ◎ Return "Nonceable".
この処理には、既存の要素から~nonceを盗用して 注入する~scriptを読込ませるような,~dangling-markup攻撃の~riskを軽減することが~~意図されている。 しかしながら、~scriptを実行すべきかどうか決定するときに,すべての属性と その値を走査するぶん,高価でもある。 ここでは、この検査を,要素が~nonceを有していて `script$e 要素であるときに限り走査することにより,その影響0をできるだけ抑えようとしているが、その影響0を知るまでは,この~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. <https://github.com/w3c/webappsec-csp/issues/98>
6.6.2.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内容すべてが許容されるならば `許容s^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 in 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`~ACI$ `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 ならば `許容s^i / ~ELSE_ `非許容^i ] ◎ If allow all inline is true, return "Allows". Otherwise, return "Does Not Allow".
【 `非許容^i の意味論が, “すべてを許容する” の論理的な[ 裏( “すべてを許容しない” )/ 否定( “許容しないものがある” ) ]のいずれを表すのか、はっきりしない。 】【 “すべて” が[ “~inline”, “挙動” ]のどちらにかかるのか、はっきりしない。 】
次の`~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.6.2.3. %要素 は ( %型, %~source ) について %~source~list に合致するか?
次の~algoは、 ( `要素$ %要素, `~source~list$ %~list, 文字列 %型, 文字列 %~source ) が与えられた下で,[ `合致es^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 は、自身が埋込まれる~pageの符号化法で解釈されることになる。 詳細は、`~HTMLとの統合$ 節における統合~点を見よ。 ◎ Note: source will be interpreted with the encoding of the page in which it is embedded. See the integration points in §4.2 Integration with HTML for more detail.
- ~IF[ `~source~listは型に対するすべての~inlineの挙動を許容するか?$A( %~list, %型 ) の結果 ~EQ `許容s^i ] ⇒ ~RET `合致es^i ◎ If §6.6.2.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.6.2.1 Is element nonceable? returns "Nonceable" when executed upon element:
-
%~list 内の ~EACH( %式 ) に対し: ◎ For each expression in list:
- ~IF[ %式 は `nonce-source$p 文法に合致する ]~AND[ %要素 は `nonce$a 属性を有していて[ その値 ~EQ %式 の `base64-value$p 成分 ]] ⇒ ~RET `合致es^i ◎ If expression matches the nonce-source grammar, and element has a nonce attribute whose value is a case-sensitive match for 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~flag ~LET ~F ◎ Let unsafe-hashes flag be false.
-
%~list 内の ~EACH( %式 ) に対し: ◎ For each expression in list:
- ~IF[ %式 ~EQ`~ACI$ `unsafe-hashes$pl ] ⇒# %非安全~hash~flag ~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~flag ~EQ ~T ]: ◎ If type is "script" or "style", or unsafe-hashes flag is true:
-
%~list 内の ~EACH( %式 ) に対し: ◎ For each expression in list:
- ~IF[ %式 は `hash-source$p 文法に合致しない ] ⇒ ~CONTINUE ◎ If expression matches the hash-source grammar:
- %~algo ~LET [ `~ASCII小文字~化する$( %式 の`hash-algorithm$p 成分 ) の結果 ]に応じて,次で与えられる~algo `SHA2$r ⇒ `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 `合致es^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 a case-sensitive match for 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.
-
- ~RET `非合致^i ◎ Return "Does Not Match".
7. 保安と~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は、施策の各~伝送-ごとに一意な値を生成し~MUST。 生成される値は、攻撃者による予測-が困難になる~SHOULDであり,[ (符号化する前の時点で) 128 ~bit以上 ], かつ[ 暗号的に保安的な乱数生成器を介して生成される ]~SHOULDである。 ◎ 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を利用しないでそうするときより保安的でない — ~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の盗用
`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.6.2.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.
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 氏が述べた,~CSS非同一生成元~data漏洩~攻撃 `CSS-ABUSE$r に類似するものである。 いずれの攻撃に対しても、~UAは,同じ仕組み — ~MIME型が不適正な~stylesheetに対しては,より厳格な~CSS構文解析~規則を適用する — で防御する~SHOULDである: ◎ 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 の~log-in用~pageの~URLである】 `https://example.com/login^s を画像として読込もうと試みた場合、 `example.com^s の~serverが,ある identity provider†(例えば `identityprovider.example.net^s とする)へ~redirectしたとするとき、~CSPにより,その要請は阻止されることになる。 仮に、阻止された~URLを,違反~報告に全部的に包含することにした場合、違反~報告に,~redirect先の~URL内に[ ~session識別子や purported identities††などの敏感な情報 ]が包含されていれば,それも包含することになる。 この理由から、~UAは,~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” — IdP とも略称される,個人認証サービスを専門に供するプロバイダを指すものと見られる。 】【†† “purported identities(ある特定目的の識別情報)” — 現実の個人の識別-は含意しないような,(当の~site~~専用の)異なる個人を別人として識別する類の情報と見られる。 】
違反~報告は、攻撃者により制御される~dataと見なされるべきである。 開発者は,~dashboardに類する~service内に違反~報告を収集したいと望むときは、内容を具現化する前に,適正に~escapeするよう注意深くなるべきである(また,おそらく、注入の~riskを更に軽減するため,それ自体も~CSPを利用するべきである)。 このことは,とりわけ、[ 違反~報告の `script-sample^l ~prop/ `SecurityPolicyViolationEvent$I の `sample$m 属性 ]に該当する — 両者とも完全に攻撃者により制御される文字列なので。 ◎ 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 氏により論じられた Using Content-Security-Policy for Evil により)非同一生成元に漏洩されるのを避けるため、読込まれている資源が~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応答を送達するとする。 この場合、読込みは成功することになる — 初期~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が生じることになるとき,文書の施策の細かさを抑制する。 それは、この型の総当たりによる情報~漏洩-を避けるために必要とされる妥協点である。 ◎ 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?" ( “~CSPから~pathを除去するか?” )にて,代替-提案に関する詳細が論じられている。 ◎ The relatively long thread "Remove paths from CSP?" from public-webappsec@w3.org has more detailed discussion around alternate proposals.
7.7. 保安的~昇格
Yan Zhu 氏による Sniffly の様な,ある種の履歴走査~攻撃( `history-scanning^en )を軽減するため、~CSPは,~pageが[ `script-src http://example.com^s の様な施策を介して,自身を非保安的~URLに~lockする ]ことは許容しない。 `scheme-part^p の照合~節 に述べたように、~source式の~scheme成分に対しては,常に保安的~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.6.1.7 scheme-part matching, the scheme portion of a source expression will always allow upgrading to a secure variant.
7.8. 迂回を避けるための~CSPの継承-法
[ `文書の~CSP~listを初期化する$A, `大域~objの~CSP~listを初期化する$A ]にて述べたように、`局所~scheme$から読込まれる文書は,それを[ `埋込んでいる文書$ / `開いた閲覧文脈$ ]の`~CSP~list$gO内の施策を複製して継承することになる。 その目標は、次を確保することである ⇒ ~pageが[ 次に挙げるような,自身が全体を制御できる内容 ]を包含している[ ~frameを埋込む / 新たな~windowを開く ]ことで,自身の施策を迂回することは、できない ⇒ `document.write()^m 等々を介して操作できるような[ `~iframe-srcdoc文書$ / `blob_^sc ~URL / `data_^sc ~URL / `about_blank^sc 文書 ] ◎ As described in §4.2.1 Initialize a Document's CSP list and §4.2.2 Initialize a global object’s CSP list, documents loaded from local schemes will inherit a copy of the policies in the CSP list of the embedding document or opener browsing context. 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 を伴わずとも,~inline~scriptを実行できるようになる — 単に `srcdoc^a を伴う `iframe^e を埋込むことで: ◎ 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>
[ `埋込んでいる文書$ / `開いた閲覧文脈$ ]の`~CSP~list$gOは、複製されることに注意。 新たな`文書$の`~CSP~list$gOは,関連する施策の作成-時における~snapshotであり、一方の`~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 embedding document or opener browsing context’s CSP list or vice-versa.
次の例の~iframeの内側にある画像は、読込まれないことになる — それは~iframeの `meta^e ~tag内の施策により阻止されるので。 ~iframeの外側にある画像は、(~~元の~pageの施策により阻止されなければ)読込まれることになる — ~iframe内に挿入される施策は、~~元の~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特色機能の運用には、干渉する~SHOULDでない。 `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. 指令の登記簿
Content Security Policy Directive (~CSP 指令)登記簿は、次の登録と参照により更新されるべきである `RFC7762$r 【 “参照” の欄は、各~指令のリンク先と同じなので省略する】 : ◎ 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
- `disown-opener$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
- `plugin-types$dir
- `report-uri$dir
- `report-to$dir
- `sandbox$dir
- `script-src$dir
- `style-src$dir
- `worker-src$dir
10.2. ~header登録
恒久的~message~header登記簿は、次の登録により更新されるべきである: `RFC3864$r ◎ 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.