recursal/MDN huggingface dataset:
安全なコンテキスト
=========

**安全なコンテキスト** (セキュアコンテキスト) とは、認証と機密性の一定の最低基準を満たしている `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 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
* 安全なコンテキストに制限されている機能
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
脆弱な署名アルゴリズム
===========

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

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

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
========================

**安全なコンテキスト用:** この機能は一部またはすべての対応しているブラウザーにおいて、安全なコンテキスト (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`
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.