<mtd> - MathML

<mtd>
=====

MathML の `<mtd>` 要素は表組み・行列のセルを表します。`<mtr>` 要素の中にしか現れません。この要素は HTML の `<td>` 要素に似ています。

属性
--

class, id, style

Provided for use with stylesheets.

columnalign

 セル内の水平方向の揃えを指定します。`<mtable>` や `<mtr>` で指定された値を上書きします。
 取り得る値は `left，`center`，`right` です。

columnspan

セルが何列分を占めるかを非負整数で指定します。

groupalign

...

href

Used to set a hyperlink to a specified URI.

mathbackground

The background color. You can use `#rgb`, `#rrggbb` and HTML color names.

mathcolor

The text color. You can use `#rgb`, `#rrggbb` and HTML color names.

rowalign

 セル内の垂直方向の揃えを指定します。`<mtable>` や `<mtr>` で指定された値を上書きします。
 取り得る値は `axis`，`baseline`，`bottom，center，top` です。

rowspan

セルが何行分を占めるかを非負整数で指定します。

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

仕様
--

| Specification |
| --- |
| MathML Core # entry-in-table-or-matrix-mtd |

関連情報
----

* `<mtable>`
* `<mtr>`


<mover> - MathML

<mover>
=======

 MathML の `<mover>` 要素はアクセントかリミットを上に載せるために使われます。構文は次の通りです： `<mover> base overscript </mover>`
 訳注：アクセントは例えばドットやハットなどの記号です。リミットとは，定積分の区間の端点などのことです。
 overscript には定着した訳語がないようです。superscript（上付き）が肩に付く添字であるのに対し，overscript は真上に付く添字です。そのまま「オーバースクリプト」と書くことにします。

属性
--

accent

 これが `true` の場合，オーバースクリプトはアクセントであり，本体に近く表示されます。
 `false`（既定値）の場合，オーバースクリプトは本体の上に載せるリミットです。
 訳注：既定値は実際にはもう少し複雑で，オーバースクリプトが `<mo>` 要素の場合，その `accent` 属性が既定値となるというルールがあります。詳細は仕様書を参照。また，`accent` 属性の値によって大きさが違って表示される場合もあります。

align

オーバースクリプトの揃え位置。取り得る値は：`left`, `center` および `right`.

class, id, style

Provided for use with stylesheets.

href

Used to set a hyperlink to a specified URI.

mathbackground

The background color. You can use `#rgb`, `#rrggbb` and HTML color names.

mathcolor

The text color. You can use `#rgb`, `#rrggbb` and HTML color names.

例
-

Sample rendering:
 ![x+y+z](/ja/docs/Web/MathML/Element/mover/mover.png)

Rendering in your browser:

x
+
y
+
z

⏞

```html
<math>
  <mover accent="true">
    <mrow>
      <mi> x </mi>
      <mo> + </mo>
      <mi> y </mi>
      <mo> + </mo>
      <mi> z </mi>
    </mrow>
    <mo>
      ⏞
      <!--TOP CURLY BRACKET-->
    </mo>
  </mover>
</math>
```

仕様書
---

| Specification |
| --- |
| MathML Core # underscripts-and-overscripts-munder-mover-munderover |

ブラウザ実装状況
--------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `<munder>` (Underscript)
* `<munderover> (en-US)` (Underscript-overscript pair)


<msqrt> - MathML

<msqrt>
=======

MathML の `<msqrt>` 要素は平方根（根指数のついていない累乗根）を表示するために用いられます。 引数は一つだけで、構文は `<msqrt> base </msqrt>` となります。

属性
--

class, id, style

CSSを用いて修飾を行なう際に使われます。

href

ハイパーリンクを設定する際に用いられます。

mathbackground

数式の背景色を指定するために使われます。`#rgb`、`#rrggbb`のような 16 進表現のほか、HTML で定められた色キーワードを用いることができます。

mathcolor

根号を含んだ数式の文字の色を指定するために使われます。`#rgb`、`#rrggbb`のような 16 進表現のほか、HTML で定められた色キーワードを用いることができます。

例
-

レンダリングのサンプル(画像):
 ![root-x](/ja/docs/Web/MathML/Element/msqrt/msqrt.png)

ブラウザのレンダリング結果:

x

```html
<math>
  <msqrt>
    <mi>x</mi>
  </msqrt>
</math>
```

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

仕様
--

| Specification |
| --- |
| MathML Core # radicals-msqrt-mroot |

関連情報
----

* `<mroot>` (Radical with an index)


同一オリジンポリシー - ウェブセキュリティ

同一オリジンポリシー
==========

**同一オリジンポリシー**は重要なセキュリティの仕組みであり、あるオリジンによって読み込まれた文書やスクリプトが、他のオリジンにあるリソースにアクセスできる方法を制限するものです。

これにより、悪意のある可能性のあるドキュメントを隔離し、起こりうる攻撃のベクターを減らすことができます。例えば、インターネット上の悪意のあるウェブサイトがブラウザー内で JS を実行して、 (ユーザーがサインインしている) サードパーティのウェブメールサービスや (公開 IP アドレスを持たないことで攻撃者の直接アクセスから保護されている) 企業のイントラネットからデータを読み取り、そのデータを攻撃者に中継することを防ぎます。

オリジンの定義
-------

二つのページのプロトコル、ポート番号 (もしあれば)、ホストが等しい場合、両者のページは同じオリジンです。これは「スキーム/ホスト/ポート番号のタプル」または時に単に「タプル」として参照されます (「タプル」は共に全体を構成する三つの部分の組み合わせを表します)。

以下の表は、各行の URL が `http://store.company.com/dir/page.html` と同じオリジンであるかを比較したものです。

| URL | 結果 | 理由 |
| --- | --- | --- |
| `http://store.company.com/dir2/other.html` | 同一オリジン | パスだけが異なる |
| `http://store.company.com/dir/inner/another.html` | 同一オリジン | パスだけが異なる |
| `https://store.company.com/page.html` | 不一致 | プロトコルが異なる |
| `http://store.company.com:81/dir/page.html` | 不一致 | ポート番号が異なる (`http://` は既定で 80 番ポート) |
| `http://news.company.com/dir/page.html` | 不一致 | ホストが異なる |

### オリジンの継承

`about:blank` や `javascript:` の URL のページから実行されたスクリプトは、その URL にオリジンのサーバーについての情報が明示的に含まれていないため、その URL を開いた文書のオリジンを継承します。

**メモ:** 例えば、 `about:blank` は (例えば `Window.open()` メカニズムを使用して) 新しい空のポップアップウィンドウを生成し、その中に親スクリプトがコンテンツを書き込むために使用されます。ポップアップウィンドウにもコードが含まれた場合、そのコードはそれを生成したスクリプトと同じオリジンを継承します。

**警告:** `data:` の URL は新しく、空のセキュリティコンテキストを生成します。

### IE における例外事項

Internet Explorer では、同一オリジンポリシーについて二つの大きな例外があります。

信頼済みゾーン

双方のドメインが*高く信頼されたゾーン* (企業のドメインなど) である場合は、同一オリジンの制限が適用されません。

ポート番号

IE は同一オリジンの確認要素にポート番号を含みません。従って、 `http://company.com:81/index.html` と `http://company.com/index.html` は同一オリジンとみなされ、制限は適用されません。

これらの例外事項は標準外であり、他のブラウザーはこのような挙動に対応していません。

オリジンの変更
-------

**警告:** ここで説明している (`document.domain` セッターを使用する) 方法は非推奨です。同一オリジンポリシーによるセキュリティ保護を弱め、ブラウザーのオリジンモデルを複雑にして、相互運用性の問題やセキュリティバグを引き起こすためです。

ページのオリジンは、いくつかの制限の下で変更されることがあります。スクリプトを用いると、 `document.domain` の値を現在のドメインまたは上位ドメインに変更できます。スクリプトによって現在のドメインの上位ドメインへオリジンが変更された場合、より短くなったドメイン名は次回のオリジン検査時に用いられます。

例えば、 `http://store.company.com/dir/other.html` にあるドキュメント内のスクリプトが以下のコードを実行したと仮定します。

```js
document.domain = "company.com";
```

このコードが実行された後、そのページは `http://company.com/dir/page.html` におけるオリジンの検査を通過できます (許可を明示するために `http://company.com/dir/page.html` が自身の `document.domain` を "`company.com`" に変更したと仮定します。詳しくは `document.domain` を参照してください)。しかし、 `company.com` が自身の `document.domain` を `othercompany.com` に変更することは**できません**。なぜなら `company.com` の上位ドメインではないためです。

ブラウザーはポート番号を個別に検査します。 `document.domain` を呼び出すと、 `document.domain = document.domain` の場合も含め、ポート番号が `null` で上書きされます。従って、スクリプトの最初に `document.domain = "company.com"` を設定しただけでは、 `company.com:8080` と `company.com` とは互いにアクセス**できません**。双方のポートが `null` になるように、双方で設定しなければなりません。

この仕組みにはいくつかの制限があります。例えば、 `document-domain` の `Feature-Policy` が有効になっている場合や、文書がサンドボックス化された `<iframe>` 内にある場合は、 "`SecurityError`" の `DOMException` が発生します。また、この方法でオリジンを変更しても、多くの Web API (`localStorage`, `indexedDB`, `BroadcastChannel`, `SharedWorker` など) で使用されているオリジンチェックには影響しません。失敗事例のより詳細なリストは、 Document.domain > Failures にあります。

**メモ:** サブドメインから親ドメインへアクセスさせるために `document.domain` を使用する際は、親ドメインとサブドメインの双方で同じ値を `document.domain` に設定することが必要です。この作業は、親ドメインを元の値に戻す際にも必要です。これを怠ると権限エラーが発生します。

異なるオリジンへのネットワークアクセス
-------------------

`XMLHttpRequest` や `<img>` 要素を使用する場合など、 同一オリジンポリシーは 2 つのオリジン間における通信を制御します。一般にこれらの通信は 3 つのカテゴリに分類されます。

* 異なるオリジンへの*書き込み*は、概して許可されます。例えばリンクやリダイレクト、フォームの送信などがあります。まれに使用される HTTP リクエストの際はプリフライトが必要です。
* 異なるオリジンの*埋め込み*は、概して許可されます。例は後述します。
* 異なるオリジンからの*読み込み*は一般に許可されませんが、埋め込みによって読み取り権限がしばしば漏れてしまいます。例えば埋め込み画像の幅や高さ、埋め込みスクリプトの動作内容、あるいは埋め込みリソースでアクセス可能なものを読み取ることができます。

以下に挙げるのは、異なるオリジンに埋め込むことができるリソースの例です。

* JavaScript を `<script src="..."></script>` で使用する場合。構文に関するエラーメッセージは、同一オリジンのスクリプトについてのみ読み取り可能です。
* CSS を `<link rel="stylesheet" href="...">` で使用する場合。 CSS は緩い構文規則を持っているため、オリジンをまたぐ CSS には適切な `Content-Type` ヘッダーを付加することが必要です。制約はブラウザーにより異なり、ブラウザーごとの詳細は Internet Explorer, Firefox, Chrome, Safari (日本語訳) (CVE-2010-0051 までスクロールしてください), Opera の各項目を参照してください。
* `<img>` で表示された画像。
* `<video>` および `<audio>` で再生されたメディア。
* `<object>` または `<embed>` で埋め込まれた外部リソース。
* `@font-face` が適用されたフォント。異なるオリジンのフォントを許容するブラウザーもありますが、同一オリジンを要求するものもあります。
* `<iframe>` に関連するあらゆること。このような形のオリジン間のやりとりを防ぐため、サイトに `X-Frame-Options` ヘッダーを使用することができます。
### 異なるオリジンへのアクセスを許可する方法

異なるオリジンへのアクセスを許可するには、 CORS を使用してください。 CORS は HTTP の一部で、ブラウザーがコンテンツの読み込みを許可する他のホストをサーバーが指定できるようにするものです。

### 異なるオリジンへのアクセスをブロックする方法

* 異なるオリジンへの書き込みを防ぐには、リクエスト内の Cross-Site Request Forgery (CSRF) トークンと呼ばれる推測できないトークンをチェックしてください。このトークンを知っているページのオリジンをまたがった読み込みを防ぎます。
* 異なるオリジンからのリソースの読み込みを防ぐには、そのリソースが埋め込まれないようにします。リソースの埋め込まれると情報が漏えいする場合があるため、多くの場合は埋め込みの抑止が必要になります。
* 異なるオリジンによる埋め込みを防ぐには、リソースの形式が先ほど述べたような埋め込み可能な形式だと思われないようにします。ほとんどの場合、ブラウザーは `Content-Type` を尊重しません。例えば `<script>` タグで HTML 文書を指した場合、ブラウザーは HTML を JavaScript としてパースしようとします。リソースがサイトの入口ではない場合は、埋め込みを抑止するため CSRF トークンも使用するとよいでしょう。
異なるオリジンへのスクリプトからの API によるアクセス
-----------------------------

`iframe.contentWindow`, `window.parent`, `window.open`, `window.opener` といった JavaScript API を用いると、ドキュメントが直接互いに参照することができます。2 つのドキュメントが同一のオリジンではない場合、 `Window` オブジェクトや `Location` オブジェクトなど、限られたオブジェクトにのみアクセスすることができます。詳しくは次の 2 つのセクションで説明します。

`window.postMessage` を使用すると、異なるオリジンの文書間における通信がさらに可能となります。

仕様書: HTML Living Standard § Cross-origin objects.

### Window

以下に示した `Window` のプロパティは、異なるオリジンからのアクセスが許可されています。

| メソッド |
| --- |
| `window.blur` |
| `window.close` |
| `window.focus` |
| `window.postMessage` |

| 属性 |  |
| --- | --- |
| `window.closed` | 読み取り専用 |
| `window.frames` | 読み取り専用 |
| `window.length` | 読み取り専用 |
| `window.location` | 読み取り/書き込み |
| `window.opener` | 読み取り専用 |
| `window.parent` | 読み取り専用 |
| `window.self` | 読み取り専用 |
| `window.top` | 読み取り専用 |
| `window.window` | 読み取り専用 |

一部のブラウザーでは、仕様書で定められたものより多くのプロパティでアクセスが許可されています。

### Location

以下に示した `Location` のプロパティは、異なるオリジンからのアクセスが許可されています。

| メソッド |
| --- |
| `location.replace` |

| 属性 |  |
| --- | --- |
| `URLUtils.href` | 書き込みのみ |

一部のブラウザーでは、仕様書で定められたものより多くのプロパティでアクセスが許可されています。

オリジンをまたいだデータストレージアクセス
---------------------

ウェブストレージや IndexedDB など、ブラウザー内部に保存されるデータへのアクセスは、オリジンによって権限が分かれています。それぞれのオリジンが個別にストレージを持ち、あるオリジンの JavaScript から別のオリジンに属するストレージを読み書きすることはできません。

Cookie におけるオリジンの定義は異なります。ページは自身のドメインまたは任意の親ドメイン (親ドメインが public suffix ではない場合に限る) 用の Cookie を設定できます。 ドメインが public suffix であるかを判断する際、Firefox と Chrome は Public Suffix List を使用します。 Internet Explorer は独自の方法で public suffix であるかを判断します。使用しているスキーム (HTTP/HTTPS) やポートに関係なく、ブラウザーはサブドメインも含めて Cookie を使用可能にします。Cookie の設定時に `Domain`, `Path`, `Secure`, `HttpOnly` の各フラグを用いることで、その Cookie の利用範囲を制限できます。Cookie を読み取るとき、Cookie を設定した場所から知ることはできません。安全な https 接続のみ使用していたとしても、参照している Cookie は安全でない接続を通じて設定された可能性があります。

関連情報
----

* Same Origin Policy at W3C
* Same-origin policy at web.dev
* `Cross-Origin-Resource-Policy`
* `Cross-Origin-Embedder-Policy`
原典情報
----

* 著者: Jesse Ruderman


Transport Layer Security - ウェブセキュリティ

Transport Layer Security
========================

Transport Layer Security (TLS) を使用した接続のセキュリティは、選択されている暗号スイートとセキュリティ引数に強く依存します。この記事の目的は、クライアントとサーバーの間の機密性と完全性の通信を確実にするために、選択の参考になることです。 Mozilla Operations Security (OpSec) チームは、サーバーの設定項目のリファレンスが付いたウィキ記事を管理しています。

Transport Layer Security (TLS) プロトコルは、ネットワークで結ばれた 2 つのアプリケーションや端末が、私的にかつ強固に情報交換するための標準です。 TLS を使用するアプリケーションは、セキュリティ引数を選択することができ、これは、データのセキュリティと信頼性に大きな影響を与える可能性があります。この記事では、 TLS の概要と、コンテンツを保護するために必要な決定の種類について説明します。

歴史
--

HTTPS が導入されたときは Secure Sockets Layer (SSL) 2.0 という、 Netscape がもたらした技術に基づいていました。その後で間もなく SSL 3.0 に更新され、用途が拡大し、ウェブブラウザーとサーバーの間の相互運用性を保証するために、共通で標準化された暗号化技術を規定することが必要になりました。 Internet Engineering Task Force (IETF) は TLS 1.0 を RFC 2246 で 1999 年 1 月に規定しました。 TLS の現在のバージョンは 1.3 (RFC 8446) です。

ウェブでは暗号化に TLS を使用するようになったという事実に関わらず、多くの人々はまだ習慣的に "SSL" と呼んでいます。

TLS はどのような低水準のトランスポートプロトコルの上でも使用することができますが、このプロトコルの本来の目標は HTTP トラフィックを暗号化することでした。 HTTP を TLS で暗号化することは、一般に HTTPS と呼ばれています。暗号化されていない HTTP が既定で 80 番ポートを使用するのに対し、 TLS で暗号化されたウェブトラフィックは、慣習として既定で 443 番ポートで交わされます。 HTTPS は引き続き、 TLS の重要な用途です。

HTTP over TLS
-------------

TLS は、それと交換されるデータの安全性とセキュリティを確保するための 3 つの主要なサービスを提供しています。

認証

認証は、通信の各当事者が相手が自分の主張する人物であることを確認することを可能にします。

暗号化

データは、ユーザーエージェントとサーバーの間で送信されている間は暗号化されており、権限のない者によって読み取られたり解釈されたりすることを防ぐことができます。

完全性

TLS は、データの暗号化から送信、復号化までの間に、情報の紛失、破損、改ざん、偽造がないことを保証します。

TLS 接続は、クライアントとサーバーが共有シークレットに合意し、暗号スイートのような重要なパラメーターがネゴシエートされるハンドシェイクフェーズから始まります。一旦、パラメーターと HTTP などのアプリケーションデータが交換されるデータ交換モードになります。

### 暗号スイート

TLS のハンドシェイクがネゴシエートする主なパラメーターは cipher suite です。

TLS 1.2 およびそれ以前のバージョンでは、ネゴシエートされた暗号スイートには、共有秘密のネゴシエート、サーバーの認証手段、データの暗号化に使用される方法を提供する一連の暗号アルゴリズムが含まれています。

TLS 1.3 の暗号化スイートは主にデータの暗号化を管理し、鍵の合意と認証には個別のネゴシエーション方法が使用されます。

異なるソフトウェアでは、同じ暗号スイートに対して異なる名前を使用している場合があります。例えば、OpenSSL や GnuTLS で使われている名前は TLS 標準のものとは異なります。Mozilla OpSec チームの TLS 設定に関する記事の暗号名対応表には、これらの名前と互換性やセキュリティレベルに関する情報が記載されています。

### サーバーの構築

サーバーを正しく設定することは非常に重要です。一般的には、サイトに接続できるようにしたいブラウザと互換性のある、可能な限り最新の暗号をサポートするようにしてください。Mozilla OpSec ガイドの TLS 設定では、推奨される設定についての詳細な情報を提供しています。

サイトの設定を支援するために、Mozilla は以下のウェブサーバー用の設定ファイルを生成する便利な TLS 設定ジェネレーターを提供しています。

* Apache
* Nginx
* Lighttpd
* HAProxy
* Amazon Web Services CloudFormation Elastic Load Balancer

必要に応じて設定を作成するには、コンフィグレーターを使用することをお勧めします。設定ファイルをコピーしてサーバー上の適切なファイルに貼り付け、サーバーを再起動して変更を反映させます。設定ファイルにはカスタム設定を含めるための調整が必要な場合がありますので、使用する前に生成された設定を確認してください。ドメイン名などの参照が正しいことを確認せずに設定ファイルをインストールすると、サーバーが動作しなくなります。

TLS 1.3
-------

RFC 8446: TLS 1.3 は、TLS のメジャーリビジョンです。TLS 1.3 には、セキュリティとパフォーマンスを向上させる多数の変更が含まれています。TLS 1.3 の目標は以下の通りです。

* TLS 1.2 の未使用で安全でない機能を削除します
* 強力なセキュリティ分析を設計に含めます
* プロトコルをより多く暗号化することで、プライバシーを向上させます
* ハンドシェイクを完了するまでの時間を短縮します

TLS 1.3 はプロトコルの基本的な部分の多くを変更していますが、以前のバージョンの TLS と同様に基本的な機能のほとんどすべてを保持しています。ウェブでは、TLS 1.3 はいくつかのまれな例外を除いて、互換性に影響を与えることなく有効にすることができます (以下を参照)。

TLS 1.3 の主な変更点は以下の通りです。

* TLS 1.3 のハンドシェイクは、ほとんどの場合 1 回のラウンドトリップで完了し、ハンドシェイクの待ち時間を短縮します
* サーバーは 0-RTT (ゼロラウンドトリップタイム) ハンドシェイクを有効にすることができます。サーバーに再接続したクライアントはすぐにリクエストを送ることができ、TLS ハンドシェイクの待ち時間を完全に排除できます。0-RTT によるパフォーマンスの向上は大きなものですが、リプレイ攻撃のリスクもありますので、この機能を有効にする前には注意が必要です
* TLS 1.3 は、接続が再開されるか、事前に共有された鍵を使用しない限り、フォワードセキュアモードのみをサポートしています
* TLS 1.3 は、TLS 1.3 専用の新しい暗号スイートを定義しています。これらの暗号化スイートはすべて最新の Authenticated Encryption with Associated Data (AEAD) アルゴリズムを使用しています
* TLS 1.3 のハンドシェイクは、共有シークレットを確立するために必要なメッセージを除き、暗号化されています。特に、これはサーバー証明書とクライアント証明書が暗号化されていることを意味します。ただし、クライアントがサーバーに送信するサーバー ID (サーバー名または SNI 拡張子) は暗号化されないことに注意してください
* 数多くのメカニズムが無効化されています: リネゴシエーション、一般的なデータ圧縮、デジタル署名アルゴリズム。(DSA) 証明書、静的 RSA 鍵交換、カスタム Diffie-Hellman (DH) グループとの鍵交換

TLS 1.3 のドラフト版の実装が公開されています。TLS 1.3 は 0-RTT モードを含むいくつかのブラウザで有効になっています。TLS 1.3 を有効にしているウェブサーバーでは、TLS 1.3 が正常に動作するように設定を調整する必要があるかもしれません。

TLS 1.3 では、重要な新しいユースケースが 1 つだけ追加されました。0-RTT ハンドシェイクは、ウェブのようなレイテンシに敏感なアプリケーションに大きなパフォーマンスの向上をもたらします。0-RTT を有効にするには、導入を確実に成功させ、リプレイ攻撃のリスクを管理するための追加のステップが必要です。

TLS 1.3 でリネゴシエーションが削除されたことは、証明書を使ったクライアント認証に依存する一部のウェブサーバーに影響を与える可能性があります。一部のウェブサーバーは、クライアント証明書が暗号化されていることを確実にするため、あるいは特定のリソースが要求されたときにのみクライアント証明書を要求するために、リネゴシエーションを使用しています。クライアント証明書のプライバシーを守るために、TLS 1.3 ハンドシェイクの暗号化によってクライアント証明書の暗号化が確実に行われますが、これにはソフトウェアの変更が必要になるかもしれません。証明書を使ったリアクティブなクライアント認証は TLS 1.3 でサポートされていますが、広くは実装されていません。代替のメカニズムは現在開発中で、HTTP/2 もサポートする予定です。

古いバージョンの TLS の引退
----------------

より現代的で安全なウェブに向けての取り組みにより、2020 年第 1 四半期に TLS 1.0 および 1.1 のサポートがすべての主要ブラウザーから削除されます。ウェブサーバーが今後 TLS 1.2 または 1.3 をサポートすることを確認する必要があります。

Firefox はバージョン 74 以降、古い TLS バージョンを使用してサーバーに接続すると Secure Connection Failed エラーを返します (Firefox バグ 1606734) 。

TLS ハンドシェイクタイムアウト値
------------------

何らかの理由で TLS ハンドシェイクが遅くなったり、反応しなくなったりすると、ユーザーの体験に大きな影響を与える可能性があります。この問題を軽減するために、最近のブラウザはハンドシェイクのタイムアウトを実装しています。

* バージョン 58 以降、Firefox は TLS ハンドシェイクのタイムアウトを既定値の 30 秒で実装しています。タイムアウトの値は、about:config の `network.http.tls-handshake-timeout` 設定値を編集することで変更できます
関連情報
----

* Mozilla SSL Configuration Generator および Cipherlist.eu は、サーバーがサイトの安全を確保するための構成ファイルを生成するのに役立つかもしれません。
* Mozilla Operations Security (OpSec) チームは、 reference TLS configurations の wiki ページを保守しています。
* Mozilla Observatory, SSL Labs, Cipherscan はサイトの TLS 構成がどれだけ安全かを確認するテストに役立ちます。
* 安全なコンテキスト
* Strict-Transport-Security HTTP ヘッダー


サブリソース完全性 - ウェブセキュリティ

サブリソース完全性
=========

**サブリソース完全性** (Subresource Integrity, SRI) は、 (CDN などから) 取得したリソースが意図せず改ざんされていないかをブラウザーが検証するセキュリティ機能です。 SRI を利用する際には、取得したリソースのハッシュ値と一致すべきハッシュ値を指定します。

**メモ:** サブリソース完全性の検証において、サブリソースが埋め込まれる文書のオリジン以外から提供されたリソースについては、ブラウザーはオリジン間リソース共有 (CORS) を使用してリソースに追加のチェックを行い、オリジンがリソースがリクエストしたオリジンに共有されることを許可しているかどうかを確認します。

サブリソース完全性の必要性
-------------

複数のサイトで使われるスクリプトやスタイルシートなどのファイルをコンテンツ配信ネットワーク (CDN) にホストすることにより、読み込みに必要な時間や通信帯域を減らすことができます。しかし、 CDN はリスクにもなり得ます。仮に攻撃者が CDN を掌握できれば、攻撃者は CDN 上のファイルに悪意あるコンテンツを挿入することにより (あるいは完全に置き換えることにより)、その CDN からファイルを読み込む全てのサイトを攻撃対象とすることができます。

サブリソース完全性は、ウェブアプリケーションやウェブ文書が (CDN など任意の場所から) 取得したファイルについて、第三者によってファイルの中に別のものが挿入されていないか、そして、それらのファイルに対してその他の改ざんが行われていないかを検証することにより、先程のような攻撃のリスクを軽減します。

サブリソース完全性の使い方
-------------

サブリソース完全性の機能は、ブラウザーが取得するリソース (ファイル) のハッシュ値を base64 エンコードし、その値を `<script>` や `<link>` 要素の `integrity` 属性に指定することによって使用します。

`integrity` 属性の値は、ハッシュアルゴリズムを示す接頭辞 (現在利用できる接頭辞は `sha256`, `sha384`, `sha512` です) と、 base64 でエンコードされたハッシュ値をダッシュで繋いだ文字列です。

**メモ:** `integrity` 属性値には、ホワイトスペースで区切って複数のハッシュ値を含めることができます。リソースはこれらのハッシュ値のいずれかに一致した場合に読み込まれます。

base64 でエンコードされた sha384 ハッシュを含む `integrity` 文字列の例
```

sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC
```

従って、 `oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC` がハッシュ値の部分であり、接頭辞の `sha384` が sha384 ハッシュであることを示します。

**メモ:** 厳密に言うと、 `integrity` 属性値におけるハッシュ値の部分は、あるハッシュ関数にデータを入力 (スクリプトやスタイルシートファイル) して生成された**暗号学的ダイジェスト値**です。しかし、一般的には短く「ハッシュ」と言えば*暗号学的ダイジェスト値*を意味するので、本記事でもそのように呼んでいます。

### SRI ハッシュを生成するツール

次の **openssl** コマンドにより SRI ハッシュを生成することができます。

```bash
cat FILENAME.js | openssl dgst -sha384 -binary | openssl base64 -A
```

または、次のような **shasum** コマンドの呼び出しでも実現できます。

```bash
shasum -b -a 384 FILENAME.js | awk '{ print $1 }' | xxd -r -p | base64
```

**メモ:**

* パイプで `xxd` を通る過程で、 `shasum` からの出力を取り、バイナリへ変換します。
* パイプで `awk` を通る過程は、 `shasum` がハッシュ化されたファイル名を `xxd` へ渡すために必要です。ファイル名が有効な 16 進数の文字を持っている場合に有害な影響を与える可能性があるからです。 `xxd` はそれを復号して、 `base64` に渡す可能性があるからです。

また、**SRI Hash Generator** (https://www.srihash.org/) によりオンラインで SRI ハッシュを生成することもできます。

### オリジン間リソース共有とサブリソース完全性

サブリソース完全性の検証において、サブリソースが埋め込まれる文書のオリジン以外から提供されたリソースについては、ブラウザーはオリジン間リソース共有 (CORS) を使用してリソースに追加のチェックを行い、オリジンがリソースがリクエストしたオリジンに共有されることを許可しているかどうかを確認します。従って、次の例のように、リソースが要求されたオリジンに共有できるよう `Access-Control-Allow-Origin` ヘッダーを付けて提供する必要があります。
```

Access-Control-Allow-Origin: *
```

例
-

以下の例では、 `oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC` が特定のスクリプト `example-framework.js` の期待される SHA-384 ハッシュ値としてすでに知られており、スクリプトのコピーが `https://example.com/example-framework.js` にホストされているものとします。

### <script> 要素のサブリソース完全性

次の `<script>` 要素により、ブラウザーが `https://example.com/example-framework.js` を実行する前に、まず想定されるハッシュ値とスクリプトのハッシュ値が一致することをブラウザーに確認させることができます。

```html
<script
 src="https://example.com/example-framework.js"
 integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
 crossorigin="anonymous"></script>
```

**メモ:** **crossorigin** 属性については CORS 設定属性を参照してください。

サブリソース完全性のブラウザーでの扱い
-------------------

ブラウザは SRI を以下のように処理します。

**メモ:** サブリソース完全性の検証において、サブリソースが埋め込まれる文書のオリジン以外から提供されたリソースについては、ブラウザーはオリジン間リソース共有 (CORS) を使用してリソースに追加のチェックを行い、オリジンがリソースがリクエストしたオリジンに共有されることを許可しているかどうかを確認します。

1. ブラウザは `integrity` 属性を持った `<script>` または `<link>` 属性を見つけると、スクリプトや `<link>` 属性で指定された任意のスタイルシートを適用する前に、`integrity` 属性のハッシュ値とスクリプトやスタイルシートのハッシュ値を比較しなくてはなりません。
2. スクリプトやスタイルシートが対応する `integrity` 属性値と一致しない場合、ブラウザーはスクリプトを実行したりスタイルシートを適用してはいけません。その代わりに、スクリプトやスタイルシートの取得が失敗したというネットワークエラーを返さなくてはなりません。
仕様
--

| Specification |
| --- |
| HTML Standard # attr-link-integrity |
| Subresource Integrity # the-integrity-attribute |
| HTML Standard # attr-script-integrity |

ブラウザの互換性
--------

### html.elements.link.integrity

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

### html.elements.script.integrity

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* Content Security Policy
* `Content-Security-Policy`
* A CDN that can not XSS you: Using Subresource Integrity
* Subresource Integrity test from W3C
* SRI Hash Generator


安全なコンテキスト - ウェブセキュリティ

安全なコンテキスト
=========

**安全なコンテキスト** (セキュアコンテキスト) とは、認証と機密性の一定の最低基準を満たしている `Window` や `Worker` のことです。多くの Web API や機能は安全なコンテキストでのみアクセス可能です。安全なコンテキストの主な目的は、中間者攻撃 が攻撃の犠牲者をさらに危険にさらす可能性のある強力な API にアクセスすることを防ぐことです。

機能をアクセス制限すべき理由
--------------

Web の API には強力なものもあり、攻撃者に対して以下のような (それよりも多くの) 能力を与えてしまう可能性があります。

* ユーザーのプライバシーを侵害する
* ユーザーのコンピューターに対して低水準のアクセス権限を得る
* ユーザーの認証情報のようなデータへのアクセス権限を得る
コンテキストが安全とみなされるのはいつですか？
-----------------------

コンテキストは、Secure Contexts 仕様で定義されている認証および機密性の一定の最低基準を満たしている場合に、安全ななコンテキストとみなされます。特定の文書が安全なコンテキストであるトップレベルのブラウジングコンテキスト (基本的には、安全なコンテキストであるウィンドウやタブを含むコンテキスト) のアクティブな文書である場合、その文書は安全なコンテキストにあるとみなされます。

例えば、`<iframe>` 内で TLS 上で配信された文書であっても、TLS 上で配信されなかった祖先がある場合には、そのコンテキストは安全であるとは見なされ**ません**。

しかし、安全ではないコンテキストによって (noopener を指定してもしなくても) 新しいウィンドウが作成された場合、 オープナーが安全ではないという事実は、新しいウィンドウが安全であるとみなされるかどうかに影響を与えないことに注意してください。これは、特定の文書が安全なコンテキストにあるかどうかの判断は、それが関連付けられているトップレベルのブラウジングコンテキスト内でそれを考慮することにのみ基づいており、安全でないコンテキストがたまたまその文書を作成するために使用されたかどうかではないからです。

`http://127.0.0.1` の URL、`http://localhost` の URL、`http://*.localhost` の URL (例 `http://dev.whatever.localhost/`) 、`file://` の URL など、ローカルに配信されたリソースも安全に配信されていると考えられます。

**メモ:** Firefox 84 以降では、`http://localhost` や `http://*.localhost` というURLを信頼できるオリジンとして扱っています (以前のバージョンでは、`localhost` がローカル/ループバックアドレスにマップされると保証されていなかったため、信頼できるオリジンとしては扱っていませんでした) 。

ローカルではないリソースが安全であるとみなされるためには、以下の基準を満たす必要があります。

* *https://* または *wss://* URL で提供されなければなりません
* リソースを配信するために使用されるネットワークチャネルのセキュリティプロパティは、非推奨と見なされてはなりません
機能の判別
-----

グローバルスコープで利用できる `isSecureContext` の真偽値を用いることで、そのページ自身が安全なコンテキストの中にいるかどうか確かめることができます。

```js
if (window.isSecureContext) {
  // Service Worker が実行されているので、このページは安全なコンテキストです
  navigator.serviceWorker.register("/offline-worker.js").then(() => {
    // …
  });
}
```

仕様
--

| Specification |
| --- |
| Secure Contexts  |

関連情報
----

* 安全なコンテキストに制限されたプラットフォーム機能 — 安全なコンテキストでのみ使用できる機能のリスト
* `isSecureContext`
* https://permission.site — HTTP と HTTPS を使用して、ブラウザーが使用している API のアクセス許可チェックを確認できるサイト。
* Strict-Transport-Security HTTP ヘッダー


Subdomain takeovers - ウェブセキュリティ

Subdomain takeovers
===================

subdomain takeover は、攻撃者がターゲットドメインのサブドメインの制御権を獲得したときに発生します。一般的には、サブドメインがドメインネームシステム (DNS) に正規名 (CNAME) を持っているが、そのサブドメインにコンテンツを提供しているホストがいない場合に発生します。これは、バーチャルホストがまだ公開されていないか、バーチャルホストが削除されているために起こる可能性があります。攻撃者は、自分のバーチャルホストを提供して、そのサブドメインのコンテンツをホストすることで、そのサブドメインを乗っ取ることができます。

攻撃者がこれを行うことができれば、メインドメインから設定されたクッキーを読み取ったり、クロスサイトスクリプティングを行ったり、コンテンツセキュリティポリシーを回避したりすることが可能となり、保護された情報 (ログインを含む) を取得したり、不審なユーザーに悪意のあるコンテンツを送信したりすることが可能となります。

サブドメインはコンセントのようなものです。自分のアプライアンス (ホスト) をコンセントに差し込んでおけば、すべてが問題ありません。しかし、あなたがコンセントから自分のアプライアンスを取り外すと (またはまだコンセントを差し込んでいない場合)、誰かが別のアプライアンスを差し込んでしまう可能性があります。コンセントが他の人に使われるのを防ぐためには、ブレーカーやヒューズボックス (DNS) で電源を切る必要があります。

どのようにして起こるのでしょうか？
-----------------

バーチャルホストのプロビジョニングやデプロビジョニング (削除) のプロセスが適切に処理されていない場合、攻撃者がサブドメインを乗っ取る機会がある可能性があります。

### プロビジョニング時

攻撃者は、ホスティングプロバイダで購入したサブドメイン名の仮想ホストを先に設定します。

あなたがドメイン example.com を管理しているとします。あなたは blog.example.com にブログを追加したいと思っていて、あなたはブログプラットフォームを維持しているホスティングプロバイダを使用することにしました。(「ブログ」は、「電子商取引プラットフォーム」や「顧客サービスプラットフォーム」、あるいは他の「クラウドベース」の仮想ホスティング・シナリオでも代用可能です)。あなたが通過するプロセスは、次のように見えるかもしれません。

1. ドメインレジストラに "blog.example.com" という名前を登録します
2. blog.example.com にアクセスしたいブラウザをバーチャルホストに誘導するために DNS レコードを設定します
3. ホスティングプロバイダでバーチャルホストを作成します

ホスティングプロバイダが、バーチャルホストを設定したエンティティが実際にサブドメイン名の所有者であることを確認するように細心の注意を払わない限り、あなたよりも手っ取り早い攻撃者が、あなたのサブドメイン名を使って、同じホスティングプロバイダでバーチャルホストを作成することができます。このような場合、ステップ 2 で DNS を設定するとすぐに、攻撃者はあなたのサブドメイン上でコンテンツをホストすることができます。

### デプロビジョニング時

あなたはバーチャルホストを削除したが、攻撃者は同じ名前とホスティングプロバイダを使用して新しいバーチャルホストをセットアップすることがあります。

あなた (またはあなたの会社) はもうブログを維持したくないと判断したので、ホスティングプロバイダからバーチャルホストを削除します。しかし、ホスティングプロバイダを指す DNS エントリを削除しなければ、攻撃者はそのプロバイダで独自のバーチャルホストを作成し、あなたのサブドメインを主張し、そのサブドメインの下で独自のコンテンツをホストすることができるようになります。

どうすれば防げるのでしょうか？
---------------

サブドメインの乗っ取りを防ぐことは、バーチャルホストや DNS のライフサイクル管理における業務の順序の問題です。組織の規模にもよりますが、これには複数の部署間でのコミュニケーションと調整が必要となり、脆弱性のある誤設定の可能性が高まるだけです。

* ホストのプロビジョニングとデプロビジョニングの標準プロセスを定義します。すべての手順を可能な限り密接に行います
    + バーチャルホストを主張してプロビジョニングを開始し、*最後に* DNS レコードを作成します
    + *最初に* DNS レコードを削除してデプロビジョニングを開始します
* 組織のすべてのドメインとそのホスティングプロバイダのインベントリを作成し、変化に応じて更新することで、何もぶら下がったままにならないようにします
* バーチャルホストを主張する人が実際にドメイン名への正当な主張を持っていることをどのように検証するのかを尋ねてください。あなたの組織内での作業は、ベンダーの資格プロセスの一部にするためです
サブドメインが乗っ取られてしまいました。どうすればいいですか？
-------------------------------

ドメインのサブドメインが乗っ取られているのを発見した場合、可能であれば、最初のステップは、サブドメインの DNS エントリを削除して「電力をカット」することです。サイトに仮想化の複数のレイヤー (例えば、仮想ホスティングに加えて CDN) がある場合、攻撃者がどこで仮想ホストの主張を主張してドメインを乗っ取ったのかを確認するために、各レイヤーを調べる必要があるかもしれません。

詳細はこちら
------

* 'Deep Thoughts' on Subdomain Takeover Vulnerabilities
* Subdomain Takeover: Basics


安全でないパスワード - ウェブセキュリティ

安全でないパスワード
==========

HTTP を通じてログインフォームを提供することは、ユーザーのパスワードを暴くための広範にわたる攻撃に対して特に危険です。ネットワークの盗聴者は、ネットワークを覗き見たり、転送によって提供されたページを変更したりしてユーザーのパスワードを盗むことができます。

HTTPS プロトコルは、ネットワーク上での盗聴（機密性）や改ざん（完全性）といった脅威から、ユーザーのデータを保護できるように設計されています。ユーザーのデータを扱うウェブサイトは、ユーザーを攻撃者から守るために HTTPS を使用してください。 HTTPS を使わなければ、ユーザーの情報（ログインの資格情報など）が盗まれるのは当たり前になってしまいます。このことを Firesheep が証明したのは有名です。

この問題を修正するためには、 SSL/TLS 証明書をサーバーにインストールし構成してください。様々なベンダーが無料または有料の証明書を提供しています。クラウドプラットフォームを使用しているのであれば、 HTTPS を有効にする方法を独自に持っているかもしれません。

パスワードの使い回しに関するメモ
----------------

ウェブサイトがユーザー名とパスワードを求めても、実際には微妙なデータを保存しないことがあります。例えば、あるニュースサイトがユーザーが読み返したい記事を保存しても、ユーザーに関する他のデータを保存しない場合などです。ニュースサイトのウェブ開発者は、サイトやユーザーの資格情報を安全にする必要があるとはあまり考えないかもしれません。

残念ながら、パスワードの使い回しは大きな問題です。ユーザーは複数のサイト (ニュースサイト、SNS、メールサービス、銀行) で同じパスワードを使用します。つまり、サイトが管理するユーザー名とパスワードに何者かがアクセスしたところで、自分たちに大きなリスクがあると思えなくとも、銀行のウェブサイトでも同じパスワードでログインしているユーザーにとっては非常に大きなリスクなのです。攻撃者はより賢くなっており、一つのサイトでユーザ名とパスワードの組を盗んだ後には、より金目のあるサイトに同じ組でログインできないか試しているのです。

関連情報
----

* No More Passwords over HTTP, Please! — detailed blog post with more information, and FAQ.


ユーザーによる有効化によって制御される機能 - ウェブセキュリティ

ユーザーによる有効化によって制御される機能
=====================

挙動が望むものでないとき悪いユーザー体験をもたらす API をアプリケーションに濫用させないため、ユーザーが「アクティブに操作中」の状態、すなわちユーザーが現在ウェブページを操作しているか、もしくは少なくとも 1 回ページを操作したか、のときのみ使用可能な API があります。ブラウザーは、悪意のあるスクリプトがこれらの機能を濫用するのを防ぐため、ポップアップ、フルスクリーン、振動などの機微な API へのアクセスを制限します。このページでは、ユーザーによる有効化の後にのみ利用可能になるウェブプラットフォームの機能を挙げています。

ユーザーによる有効化は、ユーザーが最近ページを操作した、またはページを読み込んでから操作を完了したことを表します。通常、これはボタンのクリックや他の UI の操作です。

より正確には、*有効化を起こす入力イベント* とは以下の条件を満たすイベントです。

* `isTrusted` 属性が `true` に設定されており、かつ
* 以下の種類のイベントである
    + `keydown` (`Esc` およびユーザーエージェントによって予約されているショートカットキーを除く)
    + `mousedown`
    + `pointerdown` (`pointerType` が "mouse" であるとき)
    + `pointerup` (`pointerType` が "mouse" でないとき)
    + `touchend`

有効化が起きる時、ユーザーエージェントは「粘着的」と「一時的」の 2 種類のウインドウのユーザーによる有効化状態を区別します。

一時的な有効化
-------

一時的な有効化は､ユーザーが最近ボタンを押したか､マウスを動かしたか､メニューを使用したか､他の何らかの操作をしたことを表すウインドウの状態です｡一時的な有効化は (他の操作によって更新されなければ) タイムアウトによって無効になり、(`Window.open()` のような) API によって消費されることもあります。

以下が、一時的な有効化を必要とする API の例です。

* `beforeunload` イベント
* `Clipboard.read()`
* `Clipboard.readText()`
* `Clipboard.writeText()`
* `Document.requestStorageAccess()`
* `Element.requestFullScreen()`
* `Element.requestPointerLock()`
* `GPUAdapter.requestAdapterInfo()`
* `HID.requestDevice()`
* `HTMLInputElement.showPicker()`
* `HTMLVideoElement.requestPictureInPicture()`
* `IdleDetector.requestPermission()` (en-US)
* `MediaDevices.selectAudioOutput()`
* `MediaStreamTrack.sendCaptureAction()`
* `MediaDevices.getViewportMedia()`
* `MediaDevices.getDisplayMedia()`
* `Navigator.share()`
* `PaymentRequest.show()`
* `PresentationRequest.start()` (en-US)
* `RemotePlayback.prompt()` (en-US)
* `USB.requestDevice()`
* `Keyboard.lock()`
* `Window.open()`
* `Window.showOpenFilePicker()`
* `Window.showSaveFilePicker()`
* `Window.showDirectoryPicker()`
* `Window.getScreenDetails()`
* `Window.queryLocalFonts()`
* `XRSystem.requestSession()` (en-US)
粘着的な有効化
-------

粘着的な有効化は、ユーザーがボタンを押したか、マウスを動かしたか、メニューを使用したか、他の何らかの操作をしたことを表すウインドウの状態です。これは、(一時的な有効化と違って) 最初にセットされた後はリセットされません。

以下が､粘着的な有効化を必要とする API の例です｡

* `Navigator.vibrate()`
* `navigator.getAutoplayPolicy()`
* `navigator.virtualKeyboard.show()`
UserActivation API
------------------

ウインドウで粘着的または一時的なユーザーによる有効化がなされているかどうかをプログラムから識別するため、`UserActivation` API は `navigator.userActivation` を通じて利用可能な 2 個のプロパティを提供しています。

* `UserActivation.hasBeenActive` は、ウインドウで粘着的な有効化がなされているかを表します。
* `UserActivation.isActive` は、ウインドウで一時的な有効化がなされているかを表します｡
関連情報
----

* 一時的な有効化
* 粘着的な有効化
* `UserActivation` API
* 安全なコンテキストに制限されている機能


攻撃の種類 - ウェブセキュリティ

攻撃の種類
=====

この記事では、様々な種類のセキュリティ攻撃とそれを軽減するためのテクニックについて解説しています。

クリックジャッキング
----------

クリックジャッキングとは、ユーザーを騙して、ユーザーが思っているものとは別のリンクやボタンなどをクリックさせることです。これは、例えば、ログイン認証情報を盗んだり、マルウェアの一部をインストールするためにユーザーの無意識のうちに許可を得るために使用することができます。(クリックジャッキングは、「ユーザーインターフェースのリドレス」と呼ばれることもありますが、これは「リドレス」という用語の誤用です)。

クロスサイトスクリプティング (XSS)
--------------------

クロスサイトスクリプティング（XSS）は、攻撃者が悪意のあるクライアント側のコードをウェブサイトに注入することができるセキュリティエクスプロイトです。このコードは被害者によって実行され、攻撃者はアクセス制御を迂回したり、ユーザーになりすましたりすることができます。Open Web Application Security Project によると、XSS は 2017 年に 7 番目に多いウェブアプリの脆弱性だったという。

これらの攻撃は、ウェブアプリが十分な検証やエンコーディングを採用していない場合に成功します。ユーザーのブラウザーは、悪意のあるスクリプトが信頼できないものであることを検出できないため、クッキー、セッション トークン、またはその他のサイト固有の機密情報へのアクセスを許可したり、悪意のあるスクリプトに HTML コンテンツを書き換えさせたりします。

クロスサイトスクリプティング攻撃は、通常、1) 信頼されていないソース (多くの場合、ウェブリクエスト) を介してウェブアプリにデータが入力されたり、2) 悪意のあるコンテンツが検証されずに動的なコンテンツがウェブユーザーに送信されたりした場合に発生します。

悪意のあるコンテンツには、JavaScript が含まれていることが多いですが、HTML、Flash、またはブラウザーが実行できるその他のコードが含まれていることもあります。XSS に基づく攻撃の種類はほぼ無限にありますが、一般的には、クッキーなどのセッション情報などのプライベートデータを攻撃者に送信したり、攻撃者が管理するウェブページに被害者をリダイレクトさせたり、脆弱性のあるサイトを装ってユーザーのマシンに悪意のある操作を行ったりすることが多いです。

XSS 攻撃は、蓄積型 (持続型とも呼ばれる)、反射型 (非持続型とも呼ばれる)、DOM ベースの 3 つに分類されます。

蓄積型 XSS 攻撃

注入されたスクリプトは、ターゲットのサーバーに永続的に保存されます。そして、被害者は、ブラウザーがデータの要求を送信すると、この悪意のあるスクリプトをサーバーから取得します。

反射型 XSS 攻撃

ユーザーがだまされて悪意のあるリンクをクリックしたり、特別に細工されたフォームを送信したり、悪意のあるサイトを閲覧したりすると、注入されたコードは脆弱性のあるウェブサイトに移動します。ウェブサーバーは、注入されたスクリプトを、エラーメッセージ、検索結果、またはリクエストの一部としてサーバーに送信されたデータを含むその他の応答など、ユーザーのブラウザーに反映させます。ブラウザーは、レスポンスがユーザーが既にやり取りしたことのある「信頼できる」サーバーからのものであると想定しているため、コードを実行します。

DOM ベースの XSS 攻撃

ペイロードは、元のクライアントサイドスクリプトが使用していた DOM 環境 (被害者のブラウザー内) を変更した結果、実行されます。つまり、ページ自体は変わりませんが、DOM 環境を悪意を持って改変した結果、ページに含まれるクライアント側のコードが予期せぬ形で実行されます。

クロスサイトリクエストフォージェリー (CSRF)
-------------------------

CSRF (XSRF とも呼ぶ) は、関連するクラスの攻撃です。攻撃者はユーザーのブラウザーにユーザーの同意なく、または、知らないうちにウェブサイトのバックエンドへの要求を実行させます。攻撃者は XSS ペイロードを使用して CSRF 攻撃を開始できます。

Wikipedia には、CSRF の良い例が記載されています。この状況では、誰かが (例えば、フィルタリングされていないチャットやフォーラムで) 実際には画像ではない画像を含むが、その代わりに、それは本当にお金を引き出すためにあなたの銀行のサーバーへのリクエストです。

```html
<img
 src="https://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory" />
```

さて、あなたが銀行口座にログインしていて、クッキーがまだ有効であれば (他の検証はありません)、この画像を含む HTML を読み込むとすぐに送金されます。POST リクエストを必要とするエンドポイントでは、ページが読み込まれたときにプログラム的に <form> の送信をトリガーすることができます (おそらく不可視の <iframe> で)。

```html
<form action="https://bank.example.com/withdraw" method="POST">
  <input type="hidden" name="account" value="bob" />
  <input type="hidden" name="amount" value="1000000" />
  <input type="hidden" name="for" value="mallory" />
</form>
<script>
 window.addEventListener('DOMContentLoaded', (e) => { document.querySelector('form').submit(); }
</script>
```

これを防ぐためには、いくつかのテクニックがあります。

* GET エンドポイントは、変更を実行するアクションであって、データを取得するだけのものではなく、POST (または他の HTTP メソッド) リクエストの送信を必要とするものでなければなりません。POST エンドポイントは、クエリ文字列内のパラメータを持つ GET リクエストを相互に受け入れてはいけません
* CSRF トークンは、非表示の入力フィールドを経由して <form> 要素に含まれなければなりません。このトークンはユーザーごとに一意で、リクエストが送られたときにサーバーが期待値を調べることができるように、(たとえばクッキーに) 保存されるべきです。アクションを実行する可能性のあるすべての非 GET リクエストに対して、 この入力フィールドは期待値と比較されるべきです。不一致があった場合、リクエストは中止されるべきです
* CSRF トークンを予測できないことに依存しています。トークンはサインイン時に再生成されなければなりません
* 機密性の高い動作 (セッションクッキーなど) に使用されるクッキーは、SameSite 属性を Strict または Lax に設定して、有効期限を短くする必要があります (上記の SameSite cookies を参照)。サポートしているブラウザーでは、これはクロスサイトリクエストと一緒にセッションクッキーが送信されないようにする効果があり、そのリクエストはアプリケーションサーバーに対して事実上認証されません
* CSRF トークンと SameSite Cookie の両方を導入する必要があります。これにより、すべてのブラウザーが保護され、SameSite のクッキーでは対応できない場合 (別のサブドメインからの攻撃など) にも保護されます

より多くの予防のヒントについては、OWASP CSRF prevention チートシートを参照してください。

中間者攻撃 (MitM)
------------

第三者がウェブサーバーとクライアント（ブラウザー）間のトラフィックを傍受し、ウェブサーバーになりすましてデータ（ログイン情報やクレジットカード情報など）を取得します。トラフィックは、場合によっては変更された状態で通過します。オープン WiFi ネットワークは、この攻撃を実行する一般的な手段です。

セッションハイジャック
-----------

セッションハイジャックは、ユーザーの認証されたセッションにアクセスして悪用することです。これは、既存のセッションのクッキーを盗んだり、ユーザー (またはブラウザー) を騙して、あらかじめ設定されたセッション ID のクッキーを設定させることで起こる可能性があります。

厳密な Content-Security-Policy を展開することで、侵入経路を制限することができます。

### セッションの固定

第三者は、ユーザーのセッション識別子を判断することができ（つまり、読み取ったり、設定したりすることで）、そのユーザーとしてサーバーとやりとりをすることができます。クッキーを盗むことは、これを行う一つの方法です。

application.example.com のようなサブドメインは、`Domain` 属性を設定することで、example.com や他のサブドメインへのリクエストと一緒に送信されるクッキーを設定できることを思い出してください。
```

Set-Cookie: CSRF=e8b667; Secure; Domain=example.com
```

 脆弱性のあるアプリケーションがサブドメイン上で利用可能な場合、このメカニズムはセッション固定化攻撃で悪用される可能性があります。ユーザーが親ドメイン(または別のサブドメイン)のページを訪問したとき、アプリケーションはユーザーのクッキーで送られた既存の値を信頼するかもしれません。これにより、攻撃者は CSRF 保護を迂回したり、ユーザーがログインした後にセッションを乗っ取ったりすることができます。
 あるいは、親ドメインが `includeSubdomains` が設定された HTTP Strict-Transport-Security を使用しない場合、アクティブな MitM の対象となるユーザー (おそらくオープンな WiFi ネットワークに接続されている) は、存在しないサブドメインからの Set-Cookie ヘッダーを持つレスポンスを提供される可能性があります。ブラウザーは違法なクッキーを保存し、example.com の下の他のすべてのページにそれを送信します。

セッションの固定化は主に、ユーザーが認証するときに (たとえクッキーがすでに存在していても) セッションクッキーの値を再生成し、 CSRF トークンをユーザーに結びつけることによって緩和されるべきです。

### セッションのサイドジャッキング

### ブラウザーハイジャックマルウェア


Referer ヘッダーのプライバシーとセキュリティの考慮事項 - ウェブセキュリティ

Referer ヘッダーのプライバシーとセキュリティの考慮事項
===============================

HTTP の Referer ヘッダーにまつわるプライバシーとセキュリティのリスクがあります。この記事ではこれらを説明し、これらのリスクを回避するためのアドバイスを提案します。

リファラー問題
-------

`Referer` (綴りに注意) ヘッダーには現在リクエストされているページへのリンクをたどる元のウェブページのアドレスが含まれています。これには、分析、ログ、キャッシュの最適化など、問題のない用途がかなりあります。しかし、情報の追跡や盗用など、もっと問題になる用途や、誤って機密情報を漏らすなどの副作用もあります。

例えば、フッターにソーシャルメディアへのリンクがある「パスワードリセット」ページを想像してみてください。リンクをクリックすると、情報を共有する方法によっては、ソーシャルメディアサイトがパスワードをリセットする URL を受け取り、共有された情報が使用されると、ユーザーのセキュリティを侵害する恐れがあります。

同じ論理で、サードパーティ側でホストされている画像がページに埋め込まれている場合、機密情報がサードパーティに漏洩する可能性があります。たとえセキュリティが損なわれていなくても、その情報はユーザーが共有してほしくないものかもしれません。

どのように対処できるか
-----------

このリスクの多くは、アプリケーションの賢明な設計によって軽減することができます。賢明なアプリケーションは、パスワードリセット URL を一度だけの使用、または一意のユーザートークンと組み合わせた場合にのみ使用可能にし、機密データを異なる方法で送信することで、このようなリスクを取り除くことができます。

URL 経由で他の場所に機密データを渡すことを避けるために、可能な限り `GET` ではなく `POST` を使用すべきです。

サイトには常に HTTPS を使用してください。これには多くのセキュリティ上の利点がありますが、HTTPS サイトは参照元情報を HTTPS 以外のサイトには決して送信しないという事実もあります。Web のほとんどが HTTPS を使用するようになった現在では、これはあまり意味をなさなくなってきていますが、それでも検討する価値はあります。

さらに、パスワードリセットページ、支払いフォーム、ログインエリアなど、Web サイトの安全な領域からサードパーティのコンテンツ (`<iframe>` に埋め込まれたソーシャルネットワーキングウィジェットなど) を削除することを検討する必要があります。

また、このようなリスクを軽減するには、次のような方法があります。

* サーバ上の `Referrer-Policy` ヘッダで、`Referer` ヘッダを通してどのような情報を送るかを制御します。繰り返しになりますが、`no-referrer` ディレクティブは Referer ヘッダを完全に省略します
* そのような情報が漏れる危険性のある HTML 要素 (`<img>` や `<a>` など) 上の `referrerpolicy` 属性。これは、例えば、`Referer` ヘッダーが完全に送信されないようにするために、`no-referrer` に設定することができます
* そのような情報が漏れる危険性のある HTML 要素 (`<img>` や `<a>` など) で `no-referrer` に設定されている `rel` 属性。詳細については、リンク種別と `no-referrer` の検索を参照してください
* 技術的な終了ページ

セキュリティを意識したサーバーサイドのフレームワークは、例えば、このような問題を緩和するための機能が組み込まれていることが多いです。

* Django におけるセキュリティ (特に クロス・サイト・リクエスト・フォージェリ(CSRF)の防御 を参照してください)
* helmetjs referrer-policy— Node.js/Express アプリで Referrer-Policy を設定するためのミドルウェアです (セキュリティ規定の詳細については helmetjs も参照してください)
ポリシーと要件
-------

プロジェクトチームのために、関連するリスクを軽減するために、そのような機能の使用方法を指定したセキュリティとプライバシーの要件を書くことは理にかなっているでしょう。これらの要件を書くためには、ウェブセキュリティの専門家の助けを借りて、ユーザーのニーズと福祉の両方を考慮し、EU 一般データ保護規則 (GDPR) のような法律で施行されているポリシーや規制のような他の問題も考慮する必要があります。

あわせて参照
------

* Mozilla security team guidelines on Referrer-Policy


証明書の透明性 - ウェブセキュリティ

証明書の透明性
=======

**Certificate Transparency** は、証明書の誤発行を防止し、監視するために設計されたオープンなフレームワークです。新しく発行された証明書は、公開されている、多くの場合独立した CT ログに「記録」され、発行された TLS 証明書の追加のみの暗号的に保証された記録を維持します。

このようにして、認証局 (CA) は、はるかに大きな監視と監督を受けることができます。CA/B フォーラムの*ベースライン要件*に違反するような、潜在的に悪意のある証明書は、より迅速に検出され、失効される可能性があります。また、ブラウザベンダーやルートストアのメンテナは、不信に繋がるかもしれない問題がある CA について、より多くの情報に基づいた決定を下すことができるようになります。

背景
--

CT ログは *Merkle* ツリーのデータ構造をベースに構築されています。ノードには子ノードの*暗号化ハッシュ*がラベル付けされています。リーフノードには実際のデータのハッシュが含まれています。したがって、ルートノードのラベルは、ツリー内の他のすべてのノードに依存します。

Certificate Transparency のコンテキストでは、リーフノードによってハッシュ化されたデータは、現在運営されている様々な異なる CA によって発行された証明書です。証明書の組み込みは、対数的な O(log n) 時間で効率的に生成・検証できる*監査証明*を介して検証することができます。

Certificate Transparency は、認証局の危殆化 (2011 年の DigiNotar の違反)、疑わしい決定 (2012 年の Trustwave の下位ルート事件)、技術的な発行問題 (マレーシアの Digicert Sdn Bhd による 512 ビットの脆弱な証明書の発行) を背景に、2013 年に初めて実現しました。

実装
--

証明書が CT ログに送信されると、*署名付き証明書のタイムスタンプ* (SCT) が生成されて返されます。これは、証明書が提出され、ログに追加されることを証明する役割を果たします。

仕様では、準拠サーバは接続時にこれらの SCT を TLS クライアントに提供*しなければならない*とされています。これは、いくつかの異なるメカニズムを介して実現することができます。

* 署名付き証明書のタイムスタンプを直接リーフ証明書に埋め込む X.509 v3 証明書拡張機能
* ハンドシェイク中に送信される `signed_certificate_timestamp` 型の TLS 拡張
* OCSP のステープリング (つまり、`status_request` TLS 拡張) と、1 つ以上の SCT を持つ `SignedCertificateTimestampList` の提供

X.509 証明書の拡張では、含まれる SCT は発行 CA が決定します。このメカニズムを使用する場合、Web サーバを変更する必要はありません。

後者の方法では、必要なデータを送信するためにサーバを更新する必要があります。利点は、サーバオペレータが TLS 拡張/stapled OCSP レスポンスを介して送信される SCT を提供する CT ログソースをカスタマイズできることです。

ブラウザの要件
-------

Google Chrome では、2018 年 4 月 30 日以降の notBefore 日付を持つすべての証明書の問題に対して、CT ログのインクルードを要求しています。これにより、ユーザーは非準拠の TLS 証明書を使用したサイトを訪問できなくなります。これまで Chrome では、*Extended Validation* (EV) や Symantec が発行した証明書に対して CT のインクルードが義務付けられていました。

Apple は、Safari や他のサーバがサーバ証明書を信頼するために、さまざまな数の SCT を必要としています。

Firefox は現在、ユーザーが訪問したサイトの CT ログを確認したり、使用を義務付けたりしていません。

Expect-CT ヘッダを使用して、ブラウザが証明書の透過性の要件を常に実施するように要求することができます (Chrome などでは、証明書の発行日が 4 月以前の notBefore であっても)。

仕様
--

| 仕様書 | ステータス | コメント |
| --- | --- | --- |
| Certificate Transparency | IETF RFC |  |


サイトの安全化 - ウェブセキュリティ

サイトの安全化
=======

サイトをより安全にする方法はいくつもあります。この記事では、その方法を紹介するとともに、他のより有益な記事へのリンクを掲載しています。

**メモ:** この記事は作成途中であり、以下の事項に従うことによりあなたのサイトが完全にセキュアになることを保証するものではありません。

ユーザー情報のセキュリティ
-------------

フォームオートコンプリートを無効にするには

Geckoではフォームのオートコンプリートがサポートされています。つまり、ユーザがフォームに入力した値を記憶し、次回訪問時には自動的にその値が入力されることになります。ある特定のデータに関しては、この機能を無効にしたほうが適切かもしれません。

プライバシーと :visited セレクター

この記事では悪質なサイトがユーザーの閲覧履歴を取得できないようにするために `getComputedStyle()` メソッドに加えられた変更について議論しています。

安全なアルゴリズムを使用したパスワードのハッシュ (OWASP)

プレーンテキストでパスワードを格納すると、攻撃者がサイトのユーザーの正確なパスワードを知り、漏洩させることにつながり、ユーザーを危険にさらすことになります。古く安全ではないハッシュアルゴリズム (md5 など) を使用すると、同じ問題が浮上します。メッセージダイジェストアルゴリズム (md5 や sha) ではなくパスワード専用のハッシュアルゴリズム (Argon2, PBKDF2, scrypt, bcrypt など) を使用するようにしてください。この記事はパスワードを格納するときに使用することができるベストプラクティスのショーケースです。

コンテンツセキュリティ
-----------

サーバーの MIME タイプを正しく設定する

MIME タイプを正しく設定しないと、幾つかの潜在的なセキュリティ上の問題が発生します。この記事ではそのうちのいくつかを紹介し、サーバーで MIME タイプを正しく設定する方法を示します。

HTTP Strict Transport Security

`Strict-Transport-Security:` HTTP ヘッダーを使うと、そのサイトが HTTPS でのみアクセスされるべきであるということを示すことができます。

HTTP アクセス制御

Cross-Origin Resource Sharing 標準はどのコンテンツが他のドメインから読み込まれるかを示す方法を提供します。この仕組みによりあなたのサイトが意図せず使われることを防いだり、明示的に使用を許可できます。

Content Security Policy

クロスサイトスクリプティング (XSS) やデータインジェクション攻撃を含む、特定の攻撃を検知したり軽減したりすることができる追加のセキュリティレイヤーです。これらの攻撃は、データの窃盗からサイトの改ざんやマルウェアの配布まで、あらゆることに利用されます。コードは被害者によって実行され、攻撃者がアクセス制御をバイパスしたり、成りすまししたりすることができるようになります。 Open Web Application Security Project によれば、 XSS は2017年によくあるウェブアプリの脆弱性の第7位でした。

X-Frame-Options レスポンスヘッダー

`X-Frame-Options:` HTTP レスポンスヘッダーはページを `<frame>` 内に描画して良いかどうかを示すために使われます。これを使うことにより、自身のサイトが他のサイトに埋め込まれていないことを保証できるため、クリックジャッキングを防ぐことができます。

ウェブサイトの構成によるアクセス制御

これはサイトを安全にするのに最良の方法です。 IP アドレスのブラックリスト、ウェブサイトの特定の領域へのアクセス制御、様々なファイルの保護、画像のホットリンクの防止、その他多数です。例えば、 Apache HTTP Server でホスティングされているウェブサイトでは .htaccess ファイルが使用されます。

関連情報
----

* Open Web Application Security Project (OWASP)
* Mozilla Web Security Cheat Sheet


無信頼の iframe - ウェブセキュリティ

無信頼の iframe
===========

**Experimental:** **これは実験的な機能です。**
本番で使用する前にブラウザー互換性一覧表をチェックしてください。

**非標準:** この機能は標準ではなく、標準化の予定もありません。公開されているウェブサイトには使用しないでください。ユーザーによっては使用できないことがあります。実装ごとに大きな差があることもあり、将来は振る舞いが変わるかもしれません。

**無信頼の iframe** は、開発者が新しい、一時的なコンテキストを使用して `<iframe>` でサードパーティ製のリソースを読み込むためのメカニズムを提供します。これは、通常のオリジンのネットワーク、クッキー、ストレージデータにアクセスすることはできません。最上位の文書の寿命を限度とした新しいコンテキストを使用します。結果的に `Cross-Origin-Embedder-Policy` (COEP) 埋め込みルールを解除することができるので、COEP を設定した文書に、そうでないサードパーティーの文書を埋め込むことができます。

問題
--

例えば、`SharedArrayBuffer` や high-resolution timers などの様々なウェブ API の機能が、オリジン間隔離を選択しているサイトでのみ使用できます。 これは、このような機能が Spectre 攻撃で悪用され、被害者の機密情報がサイドチャネル経由で流出し、攻撃者に捕捉される危険性があるためです。

オリジン間分離を採用するためには、リソースは `Cross-Origin-Opener-Policy` の値が `same-origin` （攻撃者からオリジンを保護）、`Cross-origin-Embedder-Policy` が `credentialless` または `require-corp` （被害者からオリジンを保護）で提供する必要があります。後者は、`Cross-Origin-Resource-Policy` またはオリジン間リソース共有 を用いて明示的に文書を許可していない、資格情報のある別オリジンのあらゆるリソースを文書が読み込むのを防止します。

オリジン間分離の採用を制限する主要な課題は、`Cross-Origin-Embedder-Policy` が再帰的に適用されることです。`Cross-Origin-Embedder-Policy` が設定された文書内の `<iframe>` に読み込まれるサードパーティーのコンテンツは、埋め込みに成功するために `Cross-Origin-Embedder-Policy` を展開している必要があります。これは、サードパーティーのコンテンツ（広告ネットワークコンテンツなど）をアプリに埋め込む開発者にとって、一般的に制御することができないため問題となります。今までは、サードパーティーのコンテンツプロバイダーが `Cross-Origin-Embedder-Policy` を実装するのを待つしかなかったからです。

この問題が、無信頼の iframe で解決できます。

解決策 — 無信頼の iframe
-----------------

`<iframe>` は、`credentialless` 属性を適用するか、同等の DOM プロパティ `HTMLIFrameElement.credentialless` を `true` を設定して信頼性を確保することができます。

```html
<iframe
 src="https://en.wikipedia.org/wiki/Spectre\_(security\_vulnerability)"
 title="Spectre vulnerability Wikipedia page"
 width="960"
 height="600"
 credentialless></iframe>
```

Or:

```html
<iframe width="960" height="600"> </iframe>
```

```js
const iframeElem = document.querySelector("iframe");

iframeElem.credentialless = true;
iframeElem.title = "Spectre vulnerability Wikipedia page";
iframeElem.src =
  "https://en.wikipedia.org/wiki/Spectre\_(security\_vulnerability)";
```

**メモ:** `window.credentialless` (en-US) プロパティは、`<iframe>` に埋め込まれた文書が、無信頼のコンテキストで実行されているかどうかを調べるために、問い合わせることができます。値が `true` の場合、埋め込まれている `<iframe>` が無信頼であることを意味します。

この結果、無信頼の `<iframe>` 内の文書は、新しい、一時的なコンテキストを使用して読み込まれることになります。それらのコンテキストは、そのオリジンに関連するデータ、例えばクッキーやローカルストレージにアクセスすることはできません。無信頼のストレージは、最上位の文書ごとに 1 回設定されるノンス ("number used once") 値で変更されたストレージキーで別個に分割されます。したがって、ある無信頼の `<iframe>` に設定されたクッキーは、同じ最上位の文書の下に埋め込まれた他の同じオリジンの無信頼の `<iframe>` からしかアクセスできなくなります。

ノンスは、同じ最上位文書の子孫であるすべての無信頼の iframe で共有されるが、ユーザーが移動したそれぞれの異なる最上位の文書では異なり、ユーザーが移動した後はもうアクセスできません。無信頼の iframe は異なるページ間でストレージを共有しません。上記のクッキーを返すと、文書を再読み込みした際、異なるコンテキストで無信頼の `<iframe>` が読み込まれるため、前回設定したクッキーはどれも利用できません。

それに加えて、以下のことが言えます。

* 無信頼の iframe で開くためのポップアップは、`rel="noopener"` を設定して開かれます。これにより、OAuth ポップアップフローが無信頼の iframe で使用されることを防ぐことができます。
* ブラウザーによる自動入力やパスワード管理機能は、無信頼の `<iframe>` では利用できません。

この結果、無信頼の `<iframe>` に読み込まれた文書は、事実上、ユーザーの機密情報でカスタマイズされていないバニラ版または「公開」版となります。これらの文書からは利用できる機密情報がないため、攻撃者にとって使用することはなく、これらの iframe では Cross-Origin Embedder Policy の要件は削除されます。

子 iframe 内の再帰的な無信頼の iframe
--------------------------

`credentialless` が `<iframe>` に設定され、その中に読み込まれた文書内に子 `<iframe>` があった場合、それらの子 `<iframe>` は無信頼の設定を継承する。

ライブデモ
-----

無信頼の iframe をその場で確認するには https://anonymous-iframe.glitch.me/ のデモを参照してください。

仕様書
---

| Specification |
| --- |
| Iframe credentialless  |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `Cross-Origin-Opener-Policy`
* `Cross-Origin-Embedder-Policy`
* `Cross-Origin-Resource-Policy`
* オリジン間リソース共有
* `<iframe`> の `credentialless` 属性
* `HTMLIFrameElement.credentialless`


混在コンテンツ - ウェブセキュリティ

混在コンテンツ
=======

ユーザが HTTPS を通じてページにアクセスすると、ユーザとウェブサーバとの接続は TLS で暗号化され、盗聴や中間者攻撃から保護されます。HTTPS のページの中に通常の平文の HTTP で送られてくるコンテンツが含まれている場合、**混在コンテンツ**と呼ばれます。このようなページは部分的にしか暗号化されておらず、盗聴者や中間者攻撃者が暗号化されていないコンテンツにアクセスできてしまいます。つまり、ページは安全ではありません。

混在コンテンツの種類
----------

混在コンテンツには **受動的な混在コンテンツ** と **能動的な混在コンテンツ** の 2 種類があります。この 2 つは、中間者攻撃によってコンテンツが改ざんされた場合に、最悪のケースとして脅威が影響を与える度合いで区別されます。受動的な混在コンテンツにおける脅威は低いものとなります (誤解を招くコンテンツが含まれているか、ユーザのクッキーが盗まれている可能性があります)。能動的な混在コンテンツの場合、その脅威としてフィッシングや機密情報の漏えい、悪意あるサイトへのリダイレクトなどが想定されます。

### 受動的な混在コンテンツ

受動的な混在コンテンツは、 HTTPS のウェブページの中で HTTP 経由で送信されるコンテンツです。しかし、そのウェブページの他の要素を混在コンテンツから変更することは出来ません。 例えば、HTTP で送信された画像に対して、攻撃者は別の不適切な画像やメッセージへと差し替えてユーザに表示させることが出来ます。 また、攻撃者はユーザへ送信される画像を盗聴することで、ユーザの行動に関する情報を推測することが可能です。 なぜなら、画像ファイルの置かれている場所がウェブサイト中のある特定のページに固定されていることがままあるからです。もし攻撃者が特定の画像に対する HTTP リクエストを覗き見れば、ユーザが閲覧しているウェブページを特定することが出来るでしょう。

#### 受動的なコンテンツの一覧

受動的なコンテンツとされる HTTP リクエストは以下の通りです。

* `<img>` (`src` 属性)
* `<audio>` (`src` 属性)
* `<video>` (`src` 属性)
* `<object>` サブリソース (`<object>` が HTTP リクエストを送信したとき)
### 能動的な混在コンテンツ

**能動的な混在コンテンツ**は、その HTTPS ページのすべて、ないしは DOM の一部にアクセスできるコンテンツです。このタイプの混在コンテンツは HTTPS ページの動作を変更することができ、ユーザから機密情報を窃取することも可能です。従って、先程説明した受動的な混在コンテンツによる脅威に加え、能動的な混在コンテンツには他の攻撃ベクタへ向けた脆弱性が存在します。

能動的な混在コンテンツの場合、中間者攻撃の攻撃者はまず HTTP のコンテンツへのリクエストを横取りすることが出来ます。 その後、攻撃者はレスポンスを改ざんして悪意ある JavaScript コードを含めることも可能です。悪意ある能動的なコンテンツは、ユーザーのログイン情報を窃取したり、ユーザーに関する機密情報を取得したり、ユーザのマシンにマルウェアのインストールを試みることが出来ます (例えば、ブラウザーやそのプラグインの脆弱性を利用することが考えられます)。

混在コンテンツに関係するリスクは、ユーザが閲覧しているウェブサイトの種類と、そのサイトにどれだけ機微な情報が含まれているかに依存します。そのウェブページには世界中に公開されているデータもあれば、認証された時のみアクセスできる機密情報もあるでしょう。 もしウェブページが公開されていて機微なデータは何もなかった場合でも、攻撃者は能動的な混在コンテンツを利用することにより、ユーザを他の HTTP ページへリダイレクトさせたり、 HTTP cookie をサイトから窃取したりできてしまうのです。

#### 能動的な混在コンテンツの例

能動的なコンテンツとされる HTTP リクエストのうち、代表的なものは以下の通りです。

* `<script>` (`src` 属性)
* `<link>` (`href` 属性) (CSS スタイルシートも含む)
* `<iframe>` (`src` 属性)
* `XMLHttpRequest` リクエスト
* `fetch()` リクエスト
* `url()` 値を用いる CSS すべて (`@font-face` / `cursor` / `background-image` など)
* `<object>` (`data` 属性)
* `Navigator.sendBeacon` (`url` 属性)

Chrome と同様に、ウェブフォントやワーカーのようなリソースタイプも能動的なコンテンツとみなされます。

ウェブコンソール内の警告
------------

閲覧しているページに混在コンテンツが含まれていた場合、Firefox のウェブコンソールには警告が表示されます。 HTTP 経由で読み込まれた混在コンテンツのリソースは赤色で表示され、このページへのリンクである「混在コンテンツ」の文字列が併記されます。

![Screen shot of the web console displaying a mixed content warning.](/ja/docs/Web/Security/Mixed_content/Mixed_content_-_Net_pane.png)

これらの警告をウェブコンソールで見つけるのと同様に、 Content Security Policy (CSP) を使用して問題を報告することができます。 SSL-check や Missing Padlock のようなオンラインクローラーと使用すると、ウェブサイトを再帰的にチェックし、安全ではないコンテンツのリンクを探すことができます。

Firefox 23 以降より、能動的な混在コンテンツはデフォルトでブロックされるようになりました (受動的な混在コンテンツは設定によりブロック可能です)。ウェブ開発者が混在コンテンツのエラーに気付きやすくなるよう、ブロックされた混在コンテンツへのリクエストはウェブコンソールのセキュリティペインにすべて記録されます。

![A screenshot of blocked mixed content errors in the Security Pane of the Web Console](/ja/docs/Web/Security/Mixed_content/mixed_content_webconsole.png)

このエラーを修正するには、 HTTP コンテンツへのリクエストをすべて HTTPS コンテンツへのリクエストに差し替えてください。よくある混在コンテンツには JavaScript ファイルやスタイルシート、画像、動画、その他のメディアファイルなどがあります。

**メモ:** Firefox 55 以降、 `http://127.0.0.1/` で混在コンテンツの読み込みが許可されました (Firefox バグ 903966 を参照)。 Chrome は `http://127.0.0.1/` 及び `http://localhost/` で混在コンテンツを許可しています。 Safari は混在コンテンツを許可しません。

関連情報
----

* Mixed Content - W3C Editor's Draft
* 混在コンテンツでブロックされるウェブサイトを修正するには


脆弱な署名アルゴリズム - ウェブセキュリティ

脆弱な署名アルゴリズム
===========

ディジタル証明書の電子署名に用いられるハッシュアルゴリズムの強度は、証明書のセキュリティにおいて核心的な要素です。この記事では、脆弱になったため、可能であれば避けるものと知られている署名アルゴリズムについて、いくらかの情報を提供します。

ハッシュアルゴリズムの脆弱性は、攻撃者が偽の証明書を作成または取得してしまうような事態を招きます。新しい攻撃手法が発見や、利用可能な攻撃技術の進歩などのため、古いアルゴリズムを使用することは避けるべきであり、いつかは対応が削除されます。

SHA-1
-----

SHA-1 の証明書は、2017 年の初めから、多くのブラウザーの開発者が安全であるとはみなさなくなりました。より安全なハッシュアルゴリズム (SHA-256 や SHA-512 など) を代わりに使用してください。

MD5
---

MD5 による署名への対応は、2012 年初めに削除されました。

関連情報
----

* SHA-1 の廃止に関する Mozilla Security Blog の記事 (参考: 日本語訳)


混在コンテンツでブロックされるウェブサイトを修正するには - ウェブセキュリティ

混在コンテンツでブロックされるウェブサイトを修正するには
============================

Firefox 23 より、 Firefox は能動的な混在コンテンツ (en-US)を既定でブロックします。この機能は Internet Explorer (バージョン 9 以降) や Chrome でも採用されています。

このページでは、ウェブ開発者として知っておくべきことを説明します。

ウェブサイトが壊れることも
-------------

ウェブサイトを HTTPS で配信している場合、ページ上にある 能動的な混在コンテンツ (en-US)はすべて既定でブロックされます。結果として、ユーザーからはそのウェブサイトが壊れているように見えるかもしれません (iframe やプラグインが読み込まれないなど)。一方、受動的な混在コンテンツ (en-US)は既定で表示されますが、このようなコンテンツをブロックするようにユーザーが設定することも可能です。

混在コンテンツは Chrome と Internet Explorer でもブロックされるため、ウェブサイトがこの２つのブラウザーで正常に動作していれば、混在コンテンツをブロックする Firefox でも正常に動作する可能性が高いと言えます。

いずれにしても、ウェブサイトが Firefox で動作しない原因を特定するには、最新の Firefox を利用すると良いでしょう。ウェブサイトを開いた上で、開発ツールのウェブコンソールを開き、「セキュリティ」のメッセージを有効にします。そうすると、混在コンテンツを引き起こしている原因が表示されます。また、 SSL-check や Missing Padlock などの無料のオンライン型クローラーや、 HTTPSChecker といったデスクトップ型のクローラー、または mcdetect などの CLI ツールを使用して、安全ではないコンテンツを指すリンクがないかどうか、ウェブサイトを再帰的に検索することが出来ます。もし混在コンテンツに関する警告が出なければ、ウェブサイトの品質は保たれていると言えます。今後も維持し続けてください。

ウェブサイトを修正する方法
-------------

混合コンテンツが原因でブロックされないためには、すべてのコンテンツを (HTTP ではなく) HTTPS で提供することが重要です。

**自分が保有するドメインの場合**、すべてのコンテンツが HTTPS で配信されるようにリンクを修正します。多くの場合、既にコンテンツは HTTPS として配信できるようになっているため、単に "s" を追加してリンクの http:// を https:// に変更するだけで対応できます。

しかし、場合によっては、問題のメディアに対してパスが正しくない可能性があります。 これを解決するためには、 linkchecker のようなオンラインツールとオフラインツール (オペレーティングシステムに依存します) があります。

**他者が保有するドメインの場合**、可能であれば HTTPS でウェブサイトに接続します。 HTTPS でアクセスできない場合は、 HTTPS を介してコンテンツを配信してもらえるよう、ドメインの管理者に連絡してみてください。


安全なコンテキストに制限されている機能 - ウェブセキュリティ

安全なコンテキストに制限されている機能
===================

このリファレンスは、安全なコンテキストでのみ使用できるウェブプラットフォーム機能の一覧です — 定義や詳細については、安全なコンテキストを参照してください。

安全なコンテキストでのみ使用できる現在の機能
----------------------

この節では、安全なコンテキストでのみ利用できる API の一覧を、制限が導入されたブラウザーのバージョンと共に示します。

**メモ:** 実際に安全なコンテキストに対応しているブラウザーのみ表示しています。安全なコンテキストの対応の詳細はこちらをご覧ください。

| API | Chrome/Opera | Edge | Safari | Firefox |
| --- | --- | --- | --- | --- |
| Async Clipboard API | 66 | 対応なし | 対応なし | 63 |
| Background Sync (例えば `SyncManager` を参照) | 49 | 対応なし | 対応なし | 対応なし |
| `Cache-Control: immutable` | 対応なし | 15 | 11 | 49 |
| Credential Management API | 51 | 対応なし | 対応なし | 対応なし |
| Generic Sensor API | 67 | 対応なし | 対応なし | 対応なし |
| Payment Request API (および Basic Card Payment) | 61 | 15 | 11.1 | 開発中 (`dom.payments.request.enabled` の設定で隠蔽)。 |
| プッシュ API | 42 | 17 | 対応なし | 44 |
| Reporting API (en-US) | 対応あり | 対応なし | 対応なし | Firefox 65 以降はフラグで隠ぺい |
| サービスワーカー | 40 | 17 | 11.1 | 44 |
| Storage API | 55 | 対応なし | 対応なし | 51 |
| Web Authentication API | 65 | In preview (17) | 開発中 | 60 |
| Web Bluetooth | 56 | 対応なし | 対応なし | 対応なし |
| Web MIDI (たとえば、 `MIDIAccess` を参照) | 43 | 対応なし | 対応なし | 対応なし |
| Web Crypto API | 60 | 79 | 対応なし | 75 |

ブラウザー独自の安全なコンテキストの制限
--------------------

ブラウザーによっては、仕様書の要件になくても、特定の API を安全ではないコンテキストでは無効にしたり、その他の制限やセキュリティ要件を課したりしていることがあります。この節では、ブラウザーによって違いがあるものの一覧を示しています。

| API | Chrome | Edge | Safari | Firefox |
| --- | --- | --- | --- | --- |
| Application Cache | Chrome 70 で安全なコンテキストに限定することを計画中 | 2018 年 2 月に非推奨化の検討が開始 | 非推奨化に対する一般の関心 WebKit bug 182442 | Firefox 62 で安全なコンテキストに限定 |
| `Geolocation` | 50 で安全なコンテキストに限定 |  | 10 で安全なコンテキストに限定 | 55 で安全なコンテキストに限定 |
| Device Orientaion / Device Motion (en-US) | 非推奨の警告 |  |  | 60 から非推奨の警告。なお、これは安全なコンテキストでも同様に適用されます。 |
| Encrypted Media Extensions (en-US) | 58 で安全なコンテキストに限定 |  |  | 計画中。 |
| getUserMedia() | Chrome 47 以降、安全なコンテキストに限定 |  |  | 一時的なアクセスのみ可能 (ユーザーは許可ダイアログで "この設定を記憶する" を選べない)。 |
| Notifications | Chrome 62 で安全なコンテキストに限定 |  |  | Firefox 67 で安全なコンテキストに限定 |
| <a ping> 属性 |  | 安全でないコンテキストでは無効 |  | Firefox 3 で対応が追加、但し既定では有効化されていない (`browser.send_pings` の設定で隠蔽)。 |
| Presentation | 61 で非推奨の警告 |  |  |  |
| Web Crypto API | 早期から HTTPS に限定 (API は HTTP で見えたが、操作には失敗した)。 Chrome 60 で安全なコンテキストに限定 (API は安全ではないコンテキストから見えなくなった). |  |  | 計画中。 |
| registerProtocolHandler() |  |  |  | Firefox 62 で安全なコンテキストに限定。 |

関連情報
----

* 安全なコンテキスト
* Privacy & Security section on Firefox Site Compatibility
* "secure context" query on Chrome Platform Status


フォームの自動補完を無効にするには - ウェブセキュリティ

フォームの自動補完を無効にするには
=================

この記事では、フォーム入力欄の自動補完をウェブサイト側から無効にする方法を説明します。

既定では、ウェブサイト上の `<input>` 欄を通じてユーザーが送信した情報はブラウザーによって記憶されます。これよってブラウザーは、自動補完 (入力を受けた入力欄の補完候補をユーザーに提示する機能) や、オートフィル (読み込まれた入力欄をあらかじめブラウザーが補完する機能) を実現しています。

これらの機能は通常は既定で有効ですが、ユーザーのプライバシーにかかわる可能性があるため、ブラウザーは無効にすることができます。しかしながら、フォームで送信される情報の中には将来利用する価値のないもの (ワンタイムパスワードなど) や、機密情報 (公的な識別番号やクレジットカード番号など) が含まれることがあります。ブラウザーの自動補完機能が有効であっても、ウェブサイトの作者としては、そのような入力欄の値をブラウザーに記憶させないほうが適切かもしれません。

なお、自動補完を無効にすると、 WCAG 2.1 の 1.3.5: Identify Input Purpose の規則を**破る**ことになることを知っておくことが重要です。 WCAG に従うウェブサイトを制作するのであれば、自動的に記入する自動補完を使用するべきです。これは、フォーム自体の自動補完がオフになっている場合でも、（個々のフォームフィールドに関連する `autocomplete` 属性を追加することで）基準に合格することができることを意味しています。

自動補完の無効化
--------

フォームにおける自動補完を無効にするには、 `autocomplete` 属性に "off" を指定することで実現できます。

```html
autocomplete="off"
```

これは、フォーム全体、またはフォーム内の特定の入力要素に対して行うことができます。

```html
<form method="post" action="/form" autocomplete="off">[…]</form>
```

```html
<form method="post" action="/form">
  […]
  <div>
    <label for="cc">クレジットカード番号:</label>
    <input type="text" id="cc" name="cc" autocomplete="off" />
  </div>
</form>
```

入力欄に `autocomplete="off"` を指定すると、以下の 2 つの効果が生じます。

* ブラウザーに対して、同様のフォームで自動補完を行うために、ユーザーが入力したデータを保存しないよう指示しますが、実際の動作はブラウザーによって異なります。
* ブラウザーがフォームデータをセッション履歴にキャッシュしないようにします。フォームデータがセッション履歴にキャッシュされた後で、フォームの送信後に「戻る」ボタンで元のページに戻った際にユーザーの入力データが表示されます。

autocomplete を off に設定してもブラウザーがサジェスト値を表示し続ける場合は、 input 要素の name 属性を変更する必要があります。

autocomplete 属性とログイン欄
---------------------

現代的なブラウザーでは、パスワードを一括管理する機能が実装されています。ユーザーがウェブサイトでユーザー名とパスワードを入力した際、ブラウザーはその値を記憶するかユーザーに尋ねます。ユーザーがそのウェブサイトを再び訪れた際には、ログイン欄がブラウザーに保存された値で自動入力されます。

加えて、ユーザーがマスターパスワードを設定すると、ログイン情報をマスターパスワードで暗号化した状態でブラウザーに保存することができます。

マスターパスワードが用いられない場合でも、ブラウザーのパスワード管理機能は純粋にセキュリティの向上につながります。パスワードをブラウザーが保存すればユーザーは覚えなくてもよいため、覚えなければならない場合よりも強固なパスワードをユーザーが設定できるようになります。

このような理由から、現代的なブラウザーの多くはログイン欄における `autocomplete="off"` に対応していません。

* ウェブサイトが `autocomplete="off"` を `<form>` に設定しており、かつそのフォーム内にユーザー名とパスワードの入力欄が含まれていた場合、ブラウザーはログイン情報を記憶するか尋ねてきて、ユーザーが同意すれば、次回の訪問時にログイン欄を自動入力します。
* ウェブサイトが `autocomplete="off"` をユーザー名とパスワードの `<input>` 欄に設定していた場合でも、ブラウザーはログイン情報を記憶するか尋ねてきて、ユーザーが同意すれば、次回の訪問時にログイン欄を自動入力します。

この挙動は Firefox 38 以降、 Google Chrome 34 以降、 Internet Explorer 11 以降で共通です。

### autocomplete="new-password" による自動入力を抑止

他人のパスワードを指定するようなユーザー管理ページを定義していて、パスワード欄の自動入力を抑止したい場合は、 `autocomplete="new-password"` を使用することができます。

これはヒントであり、ブラウザーは守る必要はありません。しかし、最近のブラウザーは `<input>` 要素に `autocomplete="new-password"` を設定すると自動入力を停止します。例えば、 Firefox バージョン 67 (Firefox バグ 1119063 を参照) はこの場合に自動入力を停止していましたが、 Firefox 70 (Firefox バグ 1565407 を参照) は安全に生成されたパスワードを提案することができるものの、保存されたパスワードを自動入力しません。詳しくは `autocomplete` の互換性テーブルを参照してください。


GeolocationPositionError - Web API

GeolocationPositionError
========================

**安全なコンテキスト用:** この機能は一部またはすべての対応しているブラウザーにおいて、安全なコンテキスト (HTTPS) でのみ利用できます。

**`GeolocationPositionError`** インターフェイスは位置情報の取得時に発生したエラーの理由を表します。

インスタンスプロパティ
-----------

*`GeolocationPositionError` インターフェイスが継承するプロパティはありません。*

`GeolocationPositionError.code` 読取専用  安全なコンテキスト用

`unsigned short` でエラーコードを表します。以下の値になる可能性があります。

| 値 | 関連付けられた定数 | 説明 |
| --- | --- | --- |
| `1` | `PERMISSION_DENIED` | ページに必要な権限がないため、位置情報の取得に失敗しました。例えば、権限ポリシーによってブロックされたなどです。 |
| `2` | `POSITION_UNAVAILABLE` | 1 つ以上の位置の内部ソースが内部エラーを返したために、位置情報の取得に失敗しました。 |
| `3` | `TIMEOUT` | 位置情報を取得するための制限時間が情報を取得する前に終了しました。 |

`GeolocationPositionError.message` 読取専用  安全なコンテキスト用

エラーの詳細を説明する、人間が読める文字列返します。仕様書の注では、主にデバッグ用途を想定しており、ユーザーインターフェイスに直接表示するものではないとしています。

インスタンスメソッド
----------

*`GeolocationPositionError` インターフェイスが実装・継承しているメソッドはありません。*

仕様書
---

| Specification |
| --- |
| Geolocation API # position\_error\_interface |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* 位置情報 API の使用
* `Geolocation`


DOMException - Web API

DOMException
============

**`DOMException`** インターフェイスは、Web API のメソッドの呼び出しやプロパティへのアクセスによって異常なイベント（**例外**と呼ばれます）が発生したことを表します。これは基本的に、Web API 内部のエラーの状態を示すものです。

それぞれの例外に**名称**があり、これはエラーまたは異常な状態を特定する "PascalCase" 形式の文字列です。

`DOMException` はシリアライズ可能オブジェクトですので、 `structuredClone()` で複製したりワーカー間で `postMessage()` を用いて複製することができたりします。

コンストラクター
--------

`DOMException()`

指定したメッセージおよび名前を持つ `DOMException` オブジェクトを返します。

プロパティ
-----

`DOMException.code`
非推奨
 読取専用

古いエラーコード定数のいずれか、または一致するものがない場合は `0` を返します。

`DOMException.message` 読取専用

文字列で、指定したエラー名に関連付けられたメッセージまたは説明を返します。

`DOMException.name` 読取専用

文字列で、エラー名に関連付けられた文字列のいずれかを返します。

エラー名
----

これは、一般的なエラー名の一覧です。API によっては独自の名前を定義しているものもありますので、必ずしも完全なリストではありません。

なお、以下の歴史的な非推奨のエラーにはエラー名がありませんが、古い定数コード値、古い定数名のみがあります。

* 古いコード値: `2`、古い定数名: `DOMSTRING_SIZE_ERR`
* 古いコード値: `6`、古い定数名: `NO_DATA_ALLOWED_ERR`
* 古いコード値: `16`、古い定数名: `VALIDATION_ERR`

**メモ:** 歴史的には、エラーは、その値があるように定義された名前付き変数に対応する数値によって識別されていたため、下記の項目の一部は、これまで使用していた古いコード値と定数名を示しています。

`IndexSizeError`

インデックスが許可された範囲から外れています。例えば、`Range` オブジェクトで発生することがあります。（古いコード: `1`、古い定数名: `INDEX_SIZE_ERR`）

`HierarchyRequestError`

ノードツリーの階層が正しくありません。（古いコード: `3`、古い定数名: `HIERARCHY_REQUEST_ERR`）

`WrongDocumentError`

オブジェクトが誤った `Document` 内に存在します。（古いコード: `4`、古い定数名: `WRONG_DOCUMENT_ERR`）

`InvalidCharacterError`

文字列に無効な文字が含まれています。（古いコード: `5`、古い定数名: `INVALID_CHARACTER_ERR`）

`NoModificationAllowedError`

オブジェクトを変更できません。（古いコード: `7`、古い定数名: `NO_MODIFICATION_ALLOWED_ERR`）

`NotFoundError`

オブジェクトが見つかりません。（古いコード: `8`、古い定数名: `NOT_FOUND_ERR`）

`NotSupportedError`

操作をサポートしていません。（古いコード: `9`、古い定数名: `NOT_SUPPORTED_ERR`）

`InvalidStateError`

オブジェクトが無効な状態です。（古いコード: `11`、古い定数名: `INVALID_STATE_ERR`）

`InUseAttributeError`

属性が使用中です。（古いコード: `10`、古い定数名: `INUSE_ATTRIBUTE_ERR`）

`SyntaxError`

文字列が期待されたパターンに一致しません。（古いコード: `12`、古い定数名: `SYNTAX_ERR`）

`InvalidModificationError`

オブジェクトをこの方法で変更できません。（古いコード: `13`、古い定数名: `INVALID_MODIFICATION_ERR`）

`NamespaceError`

XML の名前空間によって、操作は許可されていません。（古いコード: `14`、古い定数名: `NAMESPACE_ERR`）

`InvalidAccessError`

オブジェクトが操作や引数をサポートしていません。（古いコード: `15`、古い定数名: `INVALID_ACCESS_ERR`）

`TypeMismatchError`
非推奨

オブジェクトの型が、期待された型に一致しません。（古いコード: `17`、古い定数名: `TYPE_MISMATCH_ERR`）この値は非推奨です。この値を持つ `DOMException` に代わり JavaScript の `TypeError` 例外が発生するようになりました。

`SecurityError`

操作が安全ではありません。（古いコード: `18`、古い定数名: `SECURITY_ERR`）

`NetworkError`
Experimental

ネットワークのエラーが発生しました。（古いコード: `19`、古い定数名: `NETWORK_ERR`）

`AbortError`
Experimental

操作が異常終了しました。（古いコード: `20`、古い定数名: `ABORT_ERR`）

`URLMismatchError`
Experimental

与えられた URL が、別の URL と一致しません。（古いコード: `21`、古い定数名: `URL_MISMATCH_ERR`）

`QuotaExceededError`
Experimental

クォータを超過しました。（古いコード: `22`、古い定数名: `QUOTA_EXCEEDED_ERR`）

`TimeoutError`

操作がタイムアウトしました。（古いコード: `23`、古い定数名: `TIMEOUT_ERR`）

`InvalidNodeTypeError`
Experimental

ノードが正しくない、または操作に対して誤った祖先が存在します。（古いコード: `24`、古い定数名: `INVALID_NODE_TYPE_ERR`）

`DataCloneError`
Experimental

オブジェクトを複製できません。（古いコード: `25`、古い定数名: `DATA_CLONE_ERR`）

`EncodingError`
Experimental

エンコードやデコードといった、エンコーディング操作が失敗しました（古いコードおよび古い定数名はありません）。

`NotReadableError`
Experimental

入出力の読み取り操作が失敗しました（古いコードおよび古い定数名はありません）。

`UnknownError`
Experimental

未知の一時的な理由 (例えばメモリー不足) によって、操作が失敗しました（古いコードおよび古い定数名はありません）。

`ConstraintError`
Experimental

制約が満たされないため、処理の中の変更操作が失敗しました（古いコードおよび古い定数名はありません）。

`DataError`
Experimental

提供されたデータが不適切です（古いコードおよび古い定数名はありません）。

`TransactionInactiveError`
Experimental

現在アクティブではない、または終了した処理に対して要求を行いました（古いコードおよび古い定数名はありません）。

`ReadOnlyError`
Experimental

「読み取り専用」の処理で変更操作を試みました（古いコードおよび古い定数名はありません）。

`VersionError`
Experimental

現在のバージョンより古いバージョンを使用するデータベースを開こうとしました（古いコードおよび古い定数名はありません）。

`OperationError`
Experimental

操作に固有の理由で、操作が失敗しました（古いコードおよび古い定数名はありません）。

`NotAllowedError`

現在の状況において、ユーザーエージェントまたはプラットフォームが要求を許可しませんでした。ユーザーが拒否されている可能性があります（古いコードおよび古い定数名はありません）。

仕様
--

| Specification |
| --- |
| Web IDL Standard # idl-DOMException |

ブラウザー実装状況
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `DOMException` のポリフィルが `core-js` で利用できます
* `DOMError`


PresentationAvailability - Web API

PresentationAvailability
========================

**Experimental:** **これは実験的な機能です。**
本番で使用する前にブラウザー互換性一覧表をチェックしてください。

**安全なコンテキスト用:** この機能は一部またはすべての対応しているブラウザーにおいて、安全なコンテキスト (HTTPS) でのみ利用できます。

**`PresentationAvailability`** オブジェクトは利用可能なプレゼンテーション用の画面に紐付けられ、プレゼンテーションの要求に対する *プレゼンテーション用の画面の利用可能性* を表します。操作を行うユーザーエージェントが (`start()` の保留中の要求が無くても) バックグラウンドで利用可能なプレゼンテーション用の画面のリストを監視できる場合、`PresentationAvailability` オブジェクトは操作を行うブラウジングコンテキストで実装され ***なければなりません***。

`value` 属性は設定された最新の値を返さ ***なければなりません***。この値は利用可能なプレゼンテーション用画面のリストを監視するアルゴリズムにより更新されます。

`onchange` 属性はイベントハンドラーであり、対応するイベントハンドラーのイベントの種類は `change` です。

EventTarget

PresentationAvailabilityインスタンスプロパティ
-----------

`PresentationAvailability.value` 読取専用
Experimental

指定のプレゼンテーション用の画面が利用可能かを表す論理値です。`value` 属性は、設定された最新の値を返さ ***なければなりません***。

### イベント

`change`
Experimental

プレゼンテーション用の画面の利用可能性が変化したことを示します。

インスタンスメソッド
----------

なし

仕様書
---

| Specification |
| --- |
| Presentation API # interface-presentationavailability |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.


GPUSupportedFeatures - Web API

GPUSupportedFeatures
====================

**Experimental:** **これは実験的な機能です。**
本番で使用する前にブラウザー互換性一覧表をチェックしてください。

WebGPU API の **`GPUSupportedFeatures`** インターフェイスは、`GPUAdapter` が対応している追加機能を表現する `Set` 風オブジェクトです。

現在のアダプター用の `GPUSupportedFeatures` オブジェクトは、`GPUAdapter.features` 経由で参照できます。

下層のハードウェアで対応していても、対応するすべてのブラウザーの WebGPU ですべての機能が利用できるわけではないことに注意するべきです。これは、たとえば以下の場合など、下層のシステム、ブラウザー、アダプターの制限によるものである可能性があります。

* 下層のシステムが、あるブラウザーと互換性がある方式で機能を利用可能にする保証ができないかもしれません。
* ブラウザーのベンダーがある機能への対応を実装するセキュアな方法をまだ見つけていないか、単にまだ実装に手が回っていないかもしれません。

WebGPU アプリケーションにおいて特定の追加機能の恩恵を受けたい場合は、徹底的にテストを行うことを推奨します。

利用可能な機能
-------

実装や物理デバイスによって異なる可能性があり、時間の経過によっても変わる可能性があるので、ここでは WebGPU で使用可能な追加機能の完全な集合を列挙していませんリストは、仕様書内の Feature Index を参照してください。

インスタンスプロパティ
-----------

以下のプロパティは、すべての読み取り専用の `Set` 風オブジェクトで使用可能です。(以下のリンクはグローバルオブジェクト `Set` のリファレンスページです)

`size`
Experimental

集合に含まれる値の数を返します。

インスタンスメソッド
----------

以下のメソッドは、すべての読み取り専用の `Set` 風オブジェクトで使用可能です。(以下のリンクはグローバルオブジェクト `Set` のリファレンスページです)

`has()`
Experimental

指定の値の要素が集合に含まれるか否かを表す論理値を返します。

`values()`
Experimental

集合内の各要素の **値** を挿入した順に出力する新しいイテレーターオブジェクトを返します。

`keys()`
Experimental

`values()` の別名です。

`entries()`
Experimental

集合内の各要素に対応する **配列 `[value, value]`** が挿入した順に含まれる新しいイテレーターオブジェクトを返します。

`forEach()`
Experimental

集合内の各要素について挿入した順に指定のコールバック関数を 1 度ずつ呼び出します。

例
-

```js
async function init() {
  if (!navigator.gpu) {
    throw Error("WebGPU に対応していません。");
  }

  const adapter = await navigator.gpu.requestAdapter();
  if (!adapter) {
    throw Error("WebGPU のアダプターを要求できませんでした。");
  }

  const adapterFeatures = adapter.features;

  // 集合のサイズを返す
  console.log(adapterFeatures.size);

  // アダプターがある機能に対応しているかどうかをチェックする
  console.log(adapterFeatures.has("texture-compression-astc"));

  // values() を用いて集合のすべての値を走査する
  const valueIterator = adapterFeatures.values();
  for (const value of valueIterator) {
    console.log(value);
  }

  // keys() を用いて集合のすべての値を走査する
  const keyIterator = adapterFeatures.keys();
  for (const value of keyIterator) {
    console.log(value);
  }

  // entries() を用いて集合のすべての値を走査する
  const entryIterator = adapterFeatures.entries();
  for (const entry of entryIterator) {
    console.log(entry[0]);
  }

  // forEach() を用いて集合のすべての値を走査する
  adapterFeatures.forEach((value) => {
    console.log(value);
  });

  //...
}
```

仕様書
---

| Specification |
| --- |
| WebGPU # gpu-supportedfeatures |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* WebGPU API


TouchList - Web API

TouchList
=========

**`TouchList`** インターフェイスは、タッチ面上の接触点のリストを表します。例えば、ユーザーがタッチ面（画面やトラックパッドなど）を 3 本指で操作している場合、対応する `TouchList` オブジェクトは 1 本の指あたり 1 つの `Touch` オブジェクトを持ち、全部で 3 項目になります。

**メモ:** このインターフェイスは変更不可能なリストを作成しようとするもので、すでに使用しているコードを壊さないために対応しているだけです。現代の API では、代わりに ECMAScript の配列型をラップした型を使用しているので、ECMAScript の配列のように扱うことができ、同時にその使用方法に追加の意味づけをすることができます（例えば、アイテムを読み取り専用にする）。

インスタンスプロパティ
-----------

`TouchList.length` 読取専用

`TouchList` 中の `Touch` オブジェクトの個数です。

インスタンスメソッド
----------

`TouchList.item()`

リスト内の指定した位置の `Touch` オブジェクトを返します。

例
-

タッチイベントのメイン記事にある例をご覧ください。

仕様書
---

| Specification |
| --- |
| Touch Events # touchlist-interface |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* タッチイベント
* `Document.createTouchList()`


CSSStyleDeclaration - Web API

CSSStyleDeclaration
===================

**`CSSStyleDeclaration`** インターフェースは CSS 宣言ブロックのオブジェクトを表し、スタイル情報や様々なスタイルに関するメソッドやプロパティを提供します。

`CSSStyleDeclaration` オブジェクトは、下記の 3 つの API によって使用されます。

* 単一の要素のインラインスタイルを扱う `HTMLElement.style` から（例: `<div style="…">`）。
* `CSSStyleSheet` API から。例えば `document.styleSheets[0].cssRules[0].style` は、その文書の最初のスタイルシートの最初の CSS ルールを `CSSStyleDeclaration` を返します。
* `Window.getComputedStyle()` で、 `CSSStyleDeclaration` オブジェクトを**読み取り専用**インターフェイスとして返します。
属性
--

`CSSStyleDeclaration.cssText`

宣言ブロックのテキスト表現です。`HTMLElement.style` で公開されている場合のみ。この属性を設定すると、インラインスタイルが変更されます。計算された宣言ブロックのテキスト表現が必要な場合は、`JSON.stringify()` で取得することができます。

`CSSStyleDeclaration.length`読取専用

プロパティの数を表します。後述の `item()` メソッドを参照のこと。

`CSSStyleDeclaration.parentRule`読取専用

所属する `CSSRule` を表します。

### CSS プロパティ

`CSSStyleDeclaration.cssFloat`

CSS の `float` プロパティの特殊な別名です。

`CSSStyleDeclaration` の名前付きプロパティ

対応するすべての CSS プロパティを、ダッシュおよびキャメルケースにした属性です。

メソッド
----

`CSSStyleDeclaration.getPropertyPriority()`

オプションの優先度、 "important" を返します。

`CSSStyleDeclaration.getPropertyValue()`

指定されたプロパティ名のプロパティ値を返します。

`CSSStyleDeclaration.item()`

 位置から CSS プロパティ名を返します。位置が範囲を超えていた場合は空文字列を返します。
 代替方法は `nodeList[i]` にアクセスすることです (これは `i` が範囲外であった場合は `undefined` を返します)。これは JavaScript 以外の DOM 実装の多くで最も有用です。

`CSSStyleDeclaration.removeProperty()`

CSS 宣言ブロックからプロパティを削除します。

`CSSStyleDeclaration.setProperty()`

宣言ブロック内の既存の CSS プロパティを変更するか、新しい CSS プロパティを生成するかします。

`CSSStyleDeclaration.getPropertyCSSValue()`
非推奨

**Firefox の getComputedStyle のみ対応** プロパティの値を `CSSPrimitiveValue` (en-US) として、または一括指定プロパティでは `null` を返します。

例
-

```js
const styleObj = document.styleSheets[0].cssRules[0].style;
console.log(styleObj.cssText);

for (let i = styleObj.length; i--; ) {
  const nameString = styleObj[i];
  styleObj.removeProperty(nameString);
}

console.log(styleObj.cssText);
```

仕様書
---

| Specification |
| --- |
| CSS Object Model (CSSOM) # the-cssstyledeclaration-interface |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.


Comment - Web API

Comment
=======

**`Comment`** インターフェイスは、マークアップ内にある注意書きのテキストを表します。これらは通常の閲覧時には表示されず、このようなコメントはブラウザーのソースビュー表示時に閲覧可能です。

HTML や XML でコメントは、'`<!--`' と '`-->`' で囲んだコンテンツとして記述します。XML 構文においては、'`--`' をコメント内に記述することはできません。

EventTarget

Node

CharacterData

Commentプロパティ
-----

*このインターフェイスに固有のプロパティはありませんが、親インターフェイスである `CharacterData`、および間接的に `Node` のプロパティを継承しています。*

コンストラクター
--------

`Comment()`

引数をテキストコンテンツとして持つ、新しい `Comment` オブジェクトを返します。存在しない場合の既定値は、空文字列 `''` です。

メソッド
----

*このインターフェイスに固有のメソッドはありませんが、親インターフェイスである `CharacterData`、および間接的に `Node` のメソッドを継承しています。*

仕様書
---

| Specification |
| --- |
| DOM Standard # interface-comment |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* DOM インターフェイスの索引


MutationRecord - Web API

MutationRecord
==============

**`MutationRecord`** は、 DOM に生じた個々の変更を表します。これは `MutationObserver` のコールバック関数に渡されるオブジェクトです。

プロパティ
-----

|  |  |  |
| --- | --- | --- |
| プロパティ | 型 | 意味 |
| `MutationRecord.type` (en-US) | `String` |
 属性値の変更の場合は `"attributes"`、`CharacterData`
 ノードに対する変更の場合は
 `"characterData"`、ノードのツリーに対する変更の場合は
 `"childList"` を返します。
  |
| `MutationRecord.target` (en-US) | `Node` |
 変更の影響を受けたノードを、
 `MutationRecord.type` (en-US) に応じて返します。`attributes`
 の場合、属性が変更された要素となります。`characterData`
 の場合、`CharacterData` ノードとなります。`childList`
 の場合、子ノードが変更されたノードとなります。
  |
| `MutationRecord.addedNodes` (en-US) | `NodeList` |
 追加されたノードを返します。何もノードが追加されていなかった場合は、空の
 `NodeList` を返します。
  |
| `MutationRecord.removedNodes` (en-US) | `NodeList` |
 削除されたノードを返します。何もノードが削除されていなかった場合は、空の
 `NodeList` を返します。
  |
| `MutationRecord.previousSibling` (en-US) | `Node` |
 追加あるいは削除されたノードの直前にあるノード、もしくは
 `null` を返します。
  |
| `MutationRecord.nextSibling` (en-US) | ``Node`` |
 追加あるいは削除されたノードの直後にあるノード、もしくは
 `null` を返します。
  |
| `MutationRecord.attributeName` (en-US) | `String` | 変更された属性のローカル名、もしくは `null` を返します。 |
| `MutationRecord.attributeNamespace` (en-US) | `String` | 変更された属性の名前空間、もしくは `null` を返します。 |
| `MutationRecord.oldValue` (en-US) | `String` |
 返値は `MutationRecord.type` (en-US)
 に応じて以下のように変わります。`attributes`
 の場合、変更された属性の変更前の属性値となります。`characterData`
 の場合、変更されたノードの変更前のデータとなります。`childList`
 の場合、`null` となります。

 なお、この機能が正常に動作するためには、
 `MutationObserver`
observe
 メソッドの対応する
 MutationObserverInit (en-US)
 引数で、 `attributeOldValue` または
 `characterDataOldValue` が
 `true` に設定されている必要があります

 |

仕様書
---

| Specification |
| --- |
| DOM Standard # interface-mutationrecord |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.


PerformanceMeasure - Web API

PerformanceMeasure
==================

**`PerformanceMeasure`** は、"`measure`" の `entryType` を持つ`PerformanceEntry` オブジェクトの抽象インターフェイスです。このタイプのエントリは、`performance.measure()` を呼び出して、ブラウザーのパフォーマンスタイムラインの 2 つのマークの間に*名前付き* `DOMHighResTimeStamp` (*measure*) を追加することによって作成されます。

PerformanceEntry

PerformanceMeasureプロパティ
-----

このインターフェイスはプロパティを持ちませんが、以下のようにプロパティを修飾/制約することで以下の `PerformanceEntry` プロパティを拡張します。

`PerformanceEntry.entryType`

"`measure`" を返します。

`PerformanceEntry.name`

メジャーが`performance.measure()`の呼び出しで作成されたときにメジャーに付けられた名前を返します。

`PerformanceEntry.startTime`

`performance.measure()` が呼び出されたときにメジャーに与えられた`タイムスタンプ`を返します。

`PerformanceEntry.duration`

小節の長さである `DOMHighResTimeStamp` を返します (通常、小節の終了マークのタイムスタンプから開始マークのタイムスタンプを引いたもの)。

メソッド
----

このインターフェイスにはメソッドがありません。

例
-

ユーザータイミング API の使用 (en-US)の例を参照してください。

仕様書
---

| Specification |
| --- |
| User Timing # performancemeasure |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

あわせて参照
------

* User Timing (Overview) (en-US)
* Using the User Timing API (en-US)


PeriodicWave - Web API

PeriodicWave
============

**`PeriodicWave`** インターフェイスは、`OscillatorNode` の出力を形成するのに利用できる周期的な波形を定義します。

`PeriodicWave` には入力も出力もありません。これは、`OscillatorNode.setPeriodicWave()` を呼ぶ際にカスタム発振器を定義するために用います。`PeriodicWave` 自体は `BaseAudioContext.createPeriodicWave` により作成され、返されます。

コンストラクター
--------

`PeriodicWave()`

全てのプロパティについてデフォルトの値を使用し、新しい `PeriodicWave` を作成します。最初からプロパティの値をカスタムしたい場合は、かわりに `BaseAudioContext.createPeriodicWave` ファクトリーメソッドを使ってください。

インスタンスプロパティ
-----------

なし。`PeriodicWave` はプロパティの継承もしません。

インスタンスメソッド
----------

なし。`PeriodicWave` はメソッドの継承もしません。

例
-

単純な正弦波を表す `PeriodicWave` オブジェクトを作成する方法のサンプルコードは、`BaseAudioContext.createPeriodicWave` を参照してください。

仕様書
---

| Specification |
| --- |
| Web Audio API # PeriodicWave |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* Web Audio API の使用


CSSSupportsRule - Web API

CSSSupportsRule
===============

**`CSSSupportsRule`** インターフェイスは、1 個の CSS `@supports` アット規則 を表すオブジェクトを表します。

CSSRule

CSSGroupingRule

CSSConditionRule

CSSSupportsRuleプロパティ
-----

*祖先である `CSSConditionRule`, `CSSGroupingRule`, `CSSRule` からプロパティを継承しています。*

メソッド
----

*祖先である `CSSConditionRule`, `CSSGroupingRule`, `CSSRule` からメソッドを継承しています。*

例
-

 この CSS には CSS 機能クエリーとして `@supports` アットルールを使用しており、その中にスタイルルールを 1 つ含んでいます。これは `document.styleSheets[0].cssRules` が最初に返す CSSRule になります。
 したがって、 `myRules[0]` は `CSSSupportsRule` オブジェクトを返します。

```css
@supports (display: grid) {
  body {
    color: blue;
  }
}
```

```js
let myRules = document.styleSheets[0].cssRules;
console.log(myRules[0]); // CSSSupportsRule は機能クエリーを表す。
```

仕様書
---

| Specification |
| --- |
| CSS Conditional Rules Module Level 3 # the-csssupportsrule-interface |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `@supports`


ScreenOrientation - Web API

ScreenOrientation
=================

Screen Orientation API の **`ScreenOrientation`** インターフェイスは、文書の現在の向きの情報を提供します。

**`ScreenOrientation`** オブジェクトのインスタンスは、`screen.orientation` プロパティで取得できます。

EventTarget

ScreenOrientationインスタンスプロパティ
-----------

`ScreenOrientation.type` 読取専用

文書の現在の向きのタイプを返します。`"portrait-primary"`、`"portrait-secondary"`、`"landscape-primary"`、`"landscape-secondary"` のいずれかです。

`ScreenOrientation.angle` 読取専用

文書の現在の向きの角度を返します。

### イベントハンドラー

`ScreenOrientation.onchange` (en-US)

画面の向きが変わるたびに呼ばれるイベントハンドラーです。

インスタンスメソッド
----------

`ScreenOrientation.lock()`

含んでいる文書の向きをデフォルトの向きに固定し、`Promise` を返します。

`ScreenOrientation.unlock()`

含んでいる文書の向きのデフォルトの向きへの固定を解除します。

仕様書
---

| Specification |
| --- |
| Screen Orientation # screenorientation-interface |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.


LinearAccelerationSensor - Web API

LinearAccelerationSensor
========================

Sensor APIs の **`LinearAccelerationSensor`** インターフェイスは、デバイスの 3 軸それぞれにかかっている加速度の測定値を、重力の影響を除いて提供します。

このセンサーを使用するには、ユーザーが Permissions API により `'accelerometer'` デバイスセンサーを使用する許可を与える必要があります。さらに、この機能はサーバーで設定された Permissions Policy でブロックされる可能性があります。

EventTarget

Sensor

Accelerometer

LinearAccelerationSensorコンストラクター
--------

`LinearAccelerationSensor()`

新しい `LinearAccelerationSensor` オブジェクトを生成します。

インスタンスプロパティ
-----------

*祖先の `Accelerometer`、`Sensor`、`EventTarget` からプロパティを継承しています。*

インスタンスメソッド
----------

*`LinearAccelerationSensor` には独自のメソッドはありません。しかし、親インターフェイスの `Sensor` および `EventTarget` からメソッドを継承しています。*

イベント
----

*`LinearAccelerationSensor` には独自のイベントはありません。しかし、親インターフェイスの `Sensor` からイベントを継承しています。*

例
-

線形加速度は通常 `reading` イベントコールバックで取得します。以下の例では、これを 1 秒に 60 回行います。

```js
let laSensor = new LinearAccelerationSensor({ frequency: 60 });

laSensor.addEventListener("reading", (e) => {
  console.log(`X 軸方向の線形加速度 ${laSensor.x}`);
  console.log(`Y 軸方向の線形加速度 ${laSensor.y}`);
  console.log(`Z 軸方向の線形加速度 ${laSensor.z}`);
});
laSensor.start();
```

仕様書
---

| Specification |
| --- |
| Accelerometer # linearaccelerationsensor-interface |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.


DirectoryEntrySync - Web API

DirectoryEntrySync
==================

**非標準:** この機能は標準ではなく、標準化の予定もありません。公開されているウェブサイトには使用しないでください。ユーザーによっては使用できないことがあります。実装ごとに大きな差があることもあり、将来は振る舞いが変わるかもしれません。

**非推奨:** この機能は非推奨になりました。まだ対応しているブラウザーがあるかもしれませんが、すでに関連するウェブ標準から削除されているか、削除の手続き中であるか、互換性のためだけに残されている可能性があります。使用を避け、できれば既存のコードは更新してください。このページの下部にある互換性一覧表を見て判断してください。この機能は突然動作しなくなる可能性があることに注意してください。

`DirectoryEntrySync` インターフェイスは、ファイルシステム内のディレクトリーを表します。ディレクトリー内のファイルの作成、読み込み、検索、および再帰的に削除するためのメソッドが含まれています。

**メモ:** このインターフェイスは非推奨で、標準路線ではなくなりました。
 *もう使用しないでください。* 代わりにファイルおよびディレクトリー項目 APIを使用してください。

基本的なコンセプト
---------

サブディレクトリーを作成する場合は、順番に各子ディレクトリーを作成する必要があります。まだ存在しない親ディレクトリーを含むフルパスを使用してディレクトリーを作成しようとすると、エラーが発生します。したがって、親ディレクトリーを作成した後、新しいパスを再帰的に追加して階層を作成します。

### 例

`getFile()` メソッドは、ファイルシステム内のファイルを表す `FileEntrySync` を返します。以下は、ルートディレクトリーに `logs.txt` という名前の空のファイルを作成します。

```js
const fileEntry = fs.root.getFile("logs.txt", { create: true });
```

`getDirectory()` メソッドは、ファイルシステム内のファイルを表す `DirectoryEntrySync` を返します。以下は、ルートディレクトリーに `project_dir` という新しいディレクトリーを作成します。

```js
const dirEntry = fs.root.getDirectory("project\_dir", { create: true });
```

メソッド概要
------

* createReader()
* getFile()
* getDirectory()
* removeRecursively()
メソッド
----

### createReader()

このディレクトリーから項目を読み込むための新しい `DirectoryReaderSync` を作成します。

#### 構文
```

DirectoryReaderSync createReader (
) raises (FileException);
```

##### 返値

`DirectoryReaderSync` (en-US)

ファイルシステム内のディレクトリーを表します。

##### 引数

なし

##### 例外

このメソッドは、次のコードで `DOMException` が発生する場合があります。

| 例外 | 説明 |
| --- | --- |
| `NOT_FOUND_ERR` | ディレクトリーが存在しません。 |
| `SECURITY_ERR` | ブラウザはメタデータを検索するのは安全ではないと判断しました。[ TODO: 理由を説明してください ] |

### getFile()

`options` 引数をどのように設定したかに応じて、このメソッドはファイルを作成するか、既存のファイルを検索します。

#### 構文
```

getFile(path)
getFile(path, options)
```

##### 引数

`path`

検索または作成するファイルへのディレクトリーからの絶対パスまたは相対パス。直属の親が存在しないファイルを作成することはできません。最初に親ディレクトリーを作成してください。

`options`

メソッドの動作を記述するオブジェクトリテラル。ファイルが存在しない場合は作成されます。

| オブジェクトリテラル | 条件 | 結果 |
| --- | --- | --- |
| `create: true``exclusive: true` | パスが既に存在する | エラーが発生します。 |
| `create: true``exclusive: false` | パスが存在せず、他のエラーが発生していない | ファイルが作成されます。ファイルが既に存在していれば、エラーが発生しません。 |
| `create: false`(`exclusive` は無視) | パスが存在する | ファイルが返されます。 |
| `create: false`(`exclusive` は無視) | パスが存在しない | エラーが発生します。 |
| `create: false`(`exclusive` は無視) | パスが存在しますが、ディレクトリーです。 | エラーが発生します。 |

##### 返値

`FileEntrySync` (en-US)

ファイルシステム内のファイルを表します。

##### 例外

このメソッドは、次のコードで `DOMException` が発生する場合があります。

| 例外 | 説明 |
| --- | --- |
| `ENCODING_ERR` | 指定されたパスは無効です。 |
| `NOT_FOUND_ERR` | パスは構造的には正しいのですが、存在しないリソースを参照しています。 |
| `NO_MODIFICATION_ALLOWED_ERR` | これはパーミッションの問題です。対象のディレクトリーまたはファイルは書き込み可能ではありません。 |
| `PATH_EXISTS_ERR` | ファイルは既に存在しています。同じパスで別のファイルを作成することはできません。 |
| `QUOTA_EXCEEDED_ERROR` | この操作により、アプリケーションがストレージのクォータを超えてしまいます。 |
| `SECURITY_ERR` | アプリケーションは path で参照される要素にアクセスする権限を持っていません。[ todo: 理由を説明してください ] |
| `TYPE_MISMATCH_ERR` | 指定されたパスは存在しますが、ディレクトリーではありません。 |

### getDirectory()

ディレクトリーを作成または検索します。このメソッドは DirectoryEntrySync が渡される `getFile()` に似ています。

#### 構文
```

getDirectory(path)
getDirectory(path, options)
```

##### 引数

`path`

検索または作成するファイルへのディレクトリーからの絶対パスまたは相対パス。直属の親が存在しないファイルを作成することはできません。最初に親ディレクトリーを作成してください。

`options`

（オプション）ファイルが存在しない場合のメソッドの動作を記述するオブジェクトリテラル。

| オブジェクトリテラル | 条件 | 結果 |
| --- | --- | --- |
| `create: true``exclusive: true` | パスが既に存在する | エラーが発生します。 |
| `create: true``exclusive: false` | パスが存在せず、他のエラーが発生しない | ディレクトリーが作成されます。既にファイルが存在する場合はエラーは発生しません。 |
| `create: false`(`exclusive` は無視される) | パスが存在する | ディレクトリーが返されます。 |
| `create: false`(`exclusive` は無視される) | パスが存在しない | エラーが発生します。 |
| `create: false`(`exclusive` は無視される) | パスが存在するが、ディレクトリーである | エラーが発生します。 |

##### 返値

`DirectoryEntrySync` (en-US)

ファイルシステム内のディレクトリーを表します。

##### 例外

このメソッドは、次のコードで `DOMException` が発生する場合があります。

| 例外 | 説明 |
| --- | --- |
| `ENCODING_ERR` | 指定されたパスは無効です。 |
| `NOT_FOUND_ERR` | パスは構造的には正しいのですが、存在しないリソースを参照しています。 |
| `NO_MODIFICATION_ALLOWED_ERR` | これはパーミッションの問題です。対象のディレクトリーまたはファイルは書き込み可能ではありません。 |
| `PATH_EXISTS_ERR` | ファイルは既に存在しています。同じパスで別のファイルを作成することはできません。 |
| `QUOTA_EXCEEDED_ERROR` | この操作により、アプリケーションがストレージのクォータを超えてしまいます。 |
| `SECURITY_ERR` | アプリケーションは path で参照される要素にアクセスする権限を持っていません。[ todo: 理由を説明してください ] |
| `TYPE_MISMATCH_ERR` | 指定されたパスは存在しますが、ディレクトリーではありません。 |

### removeRecursively()

ディレクトリーとそのすべての内容を削除します。ファイルシステムのルートディレクトリーは削除できません。

削除できないファイルを含むディレクトリーを削除した場合や、削除中にエラーが発生した場合、内容の一部が削除されないことがあります。このような場合は、エラーコールバックでキャッチし、削除を再試行してください。

#### 構文
```

removeRecursively()
```

##### 引数

なし

##### 返値

`undefined`
##### 例外

このメソッドは、次のコードで `DOMException` が発生する場合があります。

| 例外 | 説明 |
| --- | --- |
| `NOT_FOUND_ERR` | 対象となるディレクトリーが存在しません。 |
| `INVALID_STATE_ERR` | このディレクトリーは、削除された以外の何らかの理由で有効ではありません。
 [todo: 説明してください ] |
| `NO_MODIFICATION_ALLOWED_ERR` | ディレクトリー、その親ディレクトリー、ディレクトリー内のコンテンツの一部が書き込み不可です。 |
| `SECURITY_ERR` | このアプリケーションは、ターゲットディレクトリー、その親ディレクトリー、またはそのコンテンツの一部にアクセスする権限を持っていません。 |

仕様書
---

 この機能は、現在のどの仕様にも含まれていません。標準化される予定はありません。
 代わりにファイルとディレクトリー項目 API を使用してください。

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* ファイルおよびディレクトリー項目 API
* ファイルおよびディレクトリー項目 API 入門


WorkerGlobalScope - Web API

WorkerGlobalScope
=================

**`WorkerGlobalScope`** はウェブワーカー API のインターフェイスで、あらゆるワーカーのスコープを表します。ワーカーには閲覧コンテキストがありません。このスコープには、通常 `Window` オブジェクトによって伝えられる情報が含まれます。この場合では、イベントハンドラーやコンソール、関連する `WorkerNavigator` オブジェクトのことです。ぞれぞれの `WorkerGlobalScope` は独自のイベントループを持ちます。

このインターフェイスは通常、 それぞれのワーカーの種類に合わせて特化されます。 `DedicatedWorkerGlobalScope` は専用ワーカーため、 `SharedWorkerGlobalScope` は共有ワーカーのため、 `ServiceWorkerGlobalScope` はサービスワーカーのためのものです。 `self` プロパティはそれぞれのコンテキストに特化したスコープを返します。

EventTarget

WorkerGlobalScopeインスタンスプロパティ
-----------

*このインターフェイスには、 `EventTarget` インターフェイスから継承したプロパティがあります。*

### 標準プロパティ

`WorkerGlobalScope.navigator` 読取専用

ワーカーに関連した `WorkerNavigator` を返します。これは特化された navigator オブジェクトであり、ほぼ閲覧スコープの `Navigator` のサブセットですが、ワーカーに適合したものです。

`WorkerGlobalScope.self` 読取専用

`WorkerGlobalScope` 自身の参照を返します。ほとんどの場合、 `DedicatedWorkerGlobalScope`, `SharedWorkerGlobalScope`, `ServiceWorkerGlobalScope` のような特化されたスコープです。

`WorkerGlobalScope.location` 読取専用

ワーカーに関連した `WorkerLocation` を返します。これは特化された location オブジェクトであり、ほぼ閲覧スコープのの `Location` のサブセットですが、ワーカーに適合したものです。

`WorkerGlobalScope.fonts` 読取専用

このワーカーに関連付けられた `FontFaceSet` を返します。

### 非標準プロパティ

`WorkerGlobalScope.performance` (en-US) 読取専用
Non-standard

ワーカーに関連した `Performance` を返す。これは、通常の performance オブジェクトですが、ワーカーで利用可能なプロパティやメソッドのみを持つサブセットであることが異なります。

`WorkerGlobalScope.console` 読取専用
Non-standard

ワーカーに関連付けられた `console` オブジェクトを返します。

### 他の場所で実装されているインスタンスプロパティ

`caches` 読取専用

現在のコンテキストに関連付けられた `CacheStorage` オブジェクトを返します。このオブジェクトは、オフラインで使用するための資産の保存や、リクエストに対するカスタムレスポンスの生成といった機能を実現します。

`indexedDB` 読取専用

アプリケーションが索引付きデータベースの機能に非同期でアクセスするための機構を提供し、 `IDBFactory` オブジェクトを返します。

`isSecureContext` 読取専用

現在のコンテキストが安全か (`true`) そうでないか (`false`) を示す論理値を返します。

`origin` 読取専用

グローバルオブジェクトのオリジンを文字列としてシリアライズしたものを返します。

`scheduler` (en-US) 読取専用

 現在のコンテキストに関連付けられた `Scheduler` (en-US) オブジェクトを返します。
 これは優先度付きタスクスケジューリング API (en-US) を使用する入口です。

### イベント

`error`

エラーが発生したときに発行されます。

`offline`

ブラウザーがネットワークへのアクセスを失ったときに発行され、 `navigator.onLine` の値が `false` に切り替わります。

`online`

ブラウザーがネットワークへアクセスできるようになったときに発行され、 `navigator.onLine` の値が `true` に切り替わります。

`languagechange`

ユーザーの優先言語が変更された際に、グローバル/ワーカースコープで発行されます。

`rejectionhandled`
Non-standard

`Promise` の拒否イベントが処理された際に発行されます。

`unhandledrejection`
Non-standard

`Promise` の拒否イベントが処理されなかったときに発行されます。

インスタンスメソッド
----------

*このインターフェイスは、`EventTarget` インターフェイスから継承したメソッドがあります。*

### 標準メソッド

`WorkerGlobalScope.importScripts()`

ワーカーののスコープに 1 つ以上のスクリプトをインポートします。カンマ区切りで任意の数を指定できます。例：`importScripts('foo.js', 'bar.js');`

### 非標準メソッド

`WorkerGlobalScope.dump()`
非推奨

Non-standard

標準出力、たとえば端末にメッセージを書き込むことができます。これは Firefox の `window.dump` ですが、ワーカーのためのものです。

### 他で実装されているインスタンスメソッド

`atob()`

base-64 エンコーディングを使用してエンコードされた文字データをデコードする。

`btoa()`

バイナリーデータ文字列から base-64 エンコードされた ASCII 文字列を生成する。

`clearInterval()`

`setInterval()` を使用して設定された繰り返し処理をキャンセルする。

`clearTimeout()`

`setTimeout()` を使用して設定された繰り返し処理をキャンセルする。

`createImageBitmap()`

さまざまな画像ソースを受け入れ、プロミス (`Promise`) を返します。これは `ImageBitmap` に解決されます。オプションとして、ソースを *(sx, sy)* を原点とする幅 sw, 高さ sh のピクセル矩形に切り詰めます。

`fetch()`

リソースのネットワークからの取得プロセスを開始します。

`setInterval()`

指定したミリ秒周期で実行されるように関数をスケジュールします。

`setTimeout()`

指定された時間内に実行されるように関数をスケジューリングします。

`reportError()`

処理されない例外をエミュレートして、スクリプトのエラーを報告します。

例
-

コード内で `WorkerGlobalScope` に直接アクセスすることはありません。しかし、プロパティやメソッドが `DedicatedWorkerGlobalScope` や `SharedWorkerGlobalScope` のような特化されたグローバルスコープに継承されています。たとえば、ワーカーがほかのスクリプトをインポートした場合、ワーカースコープの `navigator` オブジェクトの内容を以下の 2 行で表示することができます。

```js
importScripts("foo.js");
console.log(navigator);
```

**メモ:** ワーカースクリプトのグローバルスコープは、実行しているワーカーのグローバルスコープ（`DedicatedWorkerGlobalScope` やその他）と、 `WorkerGlobalScope` からメソッドやプロパティなどを継承しているすべてのワーカーのグローバルスコープで有効であるため、上記のように親オブジェクトを指定しなくとも実行できます。

仕様書
---

| Specification |
| --- |
| HTML Standard # the-workerglobalscope-common-interface |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連項目
----

* その他のグローバルオブジェクトインターフェイス: `Window`、 `DedicatedWorkerGlobalScope`、 `SharedWorkerGlobalScope`、 `ServiceWorkerGlobalScope`
* その他のワーカー関連インターフェイス: `Worker`、`WorkerLocation`、 `WorkerGlobalScope`、 `ServiceWorkerGlobalScope`
* ウェブワーカーの使用


ウェブアニメーション API - Web API

ウェブアニメーション API
==============

**ウェブアニメーション API** (Web Animation API) を使うことで 、ウェブページの表現を変化させるの同期やタイミング、つまり DOM 要素のアニメーションが可能です。これらはタイミングモデルおよびアニメーションモデルという 2 つのモデルの組み合わせによって実現されます。

概念と利用方法
-------

ウェブアニメーション API は、 DOM 要素のアニメーションを記述する共通言語をブラウザーと開発者に提供します。 API の背景の概念や利用方法についての詳しい情報は、ウェブアニメーション API の使用をご覧ください。

ウェブアニメーションのインターフェイス
-------------------

`Animation`

アニメーションノードやソースの再生制御やタイムラインを提供します。 `KeyframeEffect()` (en-US) コンストラクターで作成されたオブジェクトを取ることができます。

`KeyframeEffect` (en-US)

**キーフレーム**と呼ばれるアニメーション可能なプロパティと値の組み合わせ、およびそのタイミングオプションを記述します。これは `Animation()` コンストラクターを使用して再生することができます。

`AnimationTimeline` (en-US)

アニメーションのタイムラインを表します。このインターフェイスはタイムライン機能（`DocumentTimeline` (en-US) や将来のタイムラインオブジェクトによって継承）を定義するために存在し、これ自体は開発者からはアクセスされません。

`AnimationEvent`

実際には CSS アニメーションの一部です。

`DocumentTimeline` (en-US)

アニメーションのタイムラインを表し、既定の文書のタイムライン（`Document.timeline` プロパティを使用してアクセス）を含みます。

他のインターフェイスへの拡張
--------------

ウェブアニメーション API によって `document` および `element` に新たに追加された機能があります。

### `Document` インターフェイスの拡張

`document.timeline`

既定の文書タイムラインを表す `DocumentTimeline` オブジェクトです。

`document.getAnimations()`

`document` 内で要素に対して現在有効な `Animation` オブジェクトの配列を返します。

### `Element` インターフェイスの拡張

`Element.animate()`

要素のアニメーションを作成して再生するショートカットメソッドです。作成された `Animation` オブジェクトのインスタンスを返します。

`Element.getAnimations()`

`Animation` オブジェクトの配列で、現在その要素に関連し、将来の実行が予定されているものを返します。

仕様書
---

| Specification |
| --- |
| Web Animations  |

関連情報
----

* ウェブアニメーション API の使用
* ウェブアニメーションのデモ
* ポリフィル
* Firefox の現在の実装: AreWeAnimatedYet
* ブラウザーの対応のテスト


TextDecoderStream - Web API

TextDecoderStream
=================

**`TextDecoderStream`** はエンコーディング API のインターフェイスで、UTF-8 などのバイナリーエンコーディングのテキストストリームを文字列ストリームに変換します。
 これは `TextDecoder` と同等のストリームです。

コンストラクター
--------

`TextDecoderStream()`

新しい `TextDecoderStream` オブジェクトを作成します。

インスタンスプロパティ
-----------

`TextDecoderStream.encoding` 読取専用

エンコーディングです。

`TextDecoderStream.fatal` 読取専用

論理値で、エラーモードが fatal であるかどうかを示します。

`TextDecoderStream.ignoreBOM` 読取専用

論理値で、バイトオーダーマークを無視するかどうかを示します。

`TextDecoderStream.readable` 読取専用

このオブジェクトによって制御される `ReadableStream` のインスタンスを返します。

`TextDecoderStream.writable` 読取専用

このオブジェクトによって制御される `WritableStream` のインスタンスを返します。

例
-

* 構造化データと HTML のストリーミングの例
* `TextDecoderStream` を使用したフェッチリクエストストリームの例.
仕様書
---

| Specification |
| --- |
| Encoding Standard # interface-textdecoderstream |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `TextEncoderStream`
* ストリーム API の概念
* Experimenting with the Streams API


OfflineAudioContext - Web API

OfflineAudioContext
===================

`OfflineAudioContext` インターフェイスは `AudioContext` インターフェイスの一種で、 `AudioNode` をつなげて造られる音声処理グラフを表しています。通常の `AudioContext` と異なり、`OfflineAudioContext` で処理された音声はハードウェアから再生されることはありません。処理された結果は `AudioBuffer` に出力されます。

EventTarget

BaseAudioContext

OfflineAudioContextコンストラクター
--------

`OfflineAudioContext()`

新しい `OfflineAudioContext` のインスタンスを作成します。

インスタンスプロパティ
-----------

*親インターフェイスである `BaseAudioContext` からのプロパティも継承しています。*

`OfflineAudioContext.length` 読取専用

サンプルフレーム数で表されるバッファーの大きさの整数値。

インスタンスメソッド
----------

*親インターフェイスである `BaseAudioContext` からのメソッドも継承しています。*

`OfflineAudioContext.suspend()`

指定した時刻に音声コンテキストの時間進行の停止をスケジューリングし、プロミスを返します。

`OfflineAudioContext.startRendering()`

現在の接続と現在の変更予定を考慮して、音声のレンダリングを始めます。このページでは、イベントベース版とプロミス版の両方に応じた説明をします。

### 非推奨のメソッド

`OfflineAudioContext.resume()`

前回中断した音声の時刻の進行を再開します。

**メモ:** `resume()` メソッドはまだ利用できます。これは `BaseAudioContext` インターフェイスで定義されるようになり（`AudioContext.resume` を参照）、従って `AudioContext` および `OfflineAudioContext` インターフェイスの両方でアクセスできます。

イベント
----

これらのイベントを `addEventListener()` で待ち受けするか、イベントハンドラーをこのインターフェイスの `onイベント名` プロパティに代入するかしてください。

`complete`

オフライン音声コンテキストのレンダリングが完了したときに発行されます。

例
-

この例では、`AudioContext` と `OfflineAudioContext` の 2 つのオブジェクトを作っています。`AudioContext` は XHR の (`BaseAudioContext.decodeAudioData`)で音声トラックを読み込むのに使い、`OfflineAudioContext` で`AudioBufferSourceNode` の中に音声をレンダリングし、そしてその音声を再生します。オフライン音声グラフのセットアップが終わった後、`OfflineAudioContext.startRendering` を使って `AudioBuffer` にレンダリングする必要があります。

`startRendering()` のプロミスが解決されるとレンダリングは完了し、出力結果の `AudioBuffer` がプロミスの結果として戻されます。

この時点で、別の音声コンテキストを作成し、その中に `AudioBufferSourceNode` を作成し、そのバッファーをプロミス `AudioBuffer` と等しくなるように設定します。これは単純な標準音声グラフの一部として再生されます。

**メモ:** 動作する例については、 offline-audio-context-promise の GitHub リポジトリーを参照してください（ソースコードも参照してください）。

```js
// オンラインとオフラインのオーディオコンテキストを定義

const audioCtx = new AudioContext();
const offlineCtx = new OfflineAudioContext(2, 44100 \* 40, 44100);

source = offlineCtx.createBufferSource();

// XHRで音声トラックを読み込み、
// decodeAudioData でデコードして OfflineAudioContext で再生する。

function getData() {
  request = new XMLHttpRequest();

  request.open("GET", "viper.ogg", true);

  request.responseType = "arraybuffer";

  request.onload = () => {
    const audioData = request.response;

    audioCtx.decodeAudioData(audioData, (buffer) => {
      myBuffer = buffer;
      source.buffer = myBuffer;
      source.connect(offlineCtx.destination);
      source.start();
      //source.loop = true;
      offlineCtx
        .startRendering()
        .then((renderedBuffer) => {
          console.log("Rendering completed successfully");
          const song = audioCtx.createBufferSource();
          song.buffer = renderedBuffer;

          song.connect(audioCtx.destination);

          play.onclick = () => {
            song.start();
          };
        })
        .catch((err) => {
          console.error(`Rendering failed: ${err}`);
          // 注意: OfflineAudioContext の startRendering が二回以上呼び出されるとプロミスは拒否されます。
        });
    });
  };

  request.send();
}

// getData で処理を開始する。

getData();
```

仕様書
---

| Specification |
| --- |
| Web Audio API # OfflineAudioContext |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* ウェブオーディオ API の使用


UserActivation - Web API

UserActivation
==============

**Experimental:** **これは実験的な機能です。**
本番で使用する前にブラウザー互換性一覧表をチェックしてください。

**`UserActivation`** インターフェイスは、ウインドウのユーザーによる有効化に関する情報の取得を可能にします。

ユーザーによる有効化は､ユーザーが最近ページを操作した､またはページを読み込んでから操作を完了したことを表します｡通常､これはボタンのクリックや他の UI の操作です｡

ウインドウにおけるユーザーによる有効化の状態は、以下の 2 種類があります。

* 一時的な有効化 (ユーザーが現在ページを操作している)
* 粘着的な有効化 (ユーザーがページを読み込んでから少なくとも 1 回ページを操作した)

より詳しい情報と、ユーザーによる一時的もしくは粘着的な有効化を必要とする API の一覧については、ユーザーによる有効化によって制御される機能を参照してください。

この API はウインドウコンテキストでのみ利用可能で、ワーカーには提供されていません。

インスタンスプロパティ
-----------

`UserActivation.hasBeenActive` 読取専用
Experimental

現在のウインドウでユーザーによる粘着的な有効化がされているかを表します。

`UserActivation.isActive` 読取専用
Experimental

現在のウインドウでユーザーによる一時的な有効化がされているかを表します｡

例
-

### 最近ユーザーによる操作が行われたかをチェックする

ユーザーが最近ページを操作したか (一時的な有効化) をチェックするために `UserActivation.isActive` を使用します。

```js
if (navigator.userActivation.isActive) {
  // 例えば、メディアの再生の要求に進む
}
```

### これまでにユーザーによる操作が行われたかをチェックする

ユーザーがこれまでにページを操作したか (粘着的な有効化) をチェックするために `UserActivation.hasBeenActive` を使用します｡

```js
if (navigator.userActivation.hasBeenActive) {
  // 例えば、アニメーションの自動再生に進む
}
```

仕様書
---

| Specification |
| --- |
| HTML Standard # the-useractivation-interface |

ブラウザーの互換性
---------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

関連情報
----

* `navigator.userActivation`
* ユーザーによる有効化によって制御される機能