initial commit

author: Peter Bengtsson <mail@peterbe.com> 2020-12-08 14:40:17 -0500
committer: Peter Bengtsson <mail@peterbe.com> 2020-12-08 14:40:17 -0500
commit: 33058f2b292b3a581333bdfb21b8f671898c5060 (patch)
tree: 51c3e392513ec574331b2d3f85c394445ea803c6 /files/ja/web/security
parent: 8b66d724f7caf0157093fb09cfec8fbd0c6ad50a (diff)
download: translated-content-33058f2b292b3a581333bdfb21b8f671898c5060.tar.gz
translated-content-33058f2b292b3a581333bdfb21b8f671898c5060.tar.bz2
translated-content-33058f2b292b3a581333bdfb21b8f671898c5060.zip
19 files changed, 1897 insertions, 0 deletions
diff --git a/files/ja/web/security/certificate_transparency/index.html b/files/ja/web/security/certificate_transparency/index.html
new file mode 100644
index 0000000000..a3efbd98a6
--- /dev/null
+++ b/files/ja/web/security/certificate_transparency/index.html
@@ -0,0 +1,62 @@
+---
+title: 証明書の透明性
+slug: Web/Security/Certificate_Transparency
+tags:
+  - Security
+  - Web
+translation_of: Web/Security/Certificate_Transparency
+---
+<p><span class="seoSummary"><strong>Certificate Transparency</strong> は、証明書の誤発行を防止し、監視するために設計されたオープンなフレームワークです。新しく発行された証明書は、公開されている、多くの場合独立した CT ログに「記録」され、発行された TLS 証明書の追加のみの暗号的に保証された記録を維持します。</span></p>
+
+<p>このようにして、証明書局 (CA) は、はるかに大きな監視と監督を受けることができます。CA/B フォーラムの<em>ベースライン要件</em>に違反するような、潜在的に悪意のある証明書は、より迅速に検出され、失効される可能性があります。また、ブラウザベンダーやルートストアのメンテナは、不信に繋がるかもしれない問題がある CA について、より多くの情報に基づいた決定を下すことができるようになります。</p>
+
+<h2 id="背景">背景</h2>
+
+<p>CT ログは <em>Merkle</em> ツリーのデータ構造をベースに構築されています。ノードには子ノードの<em>暗号化ハッシュ</em>がラベル付けされています。リーフノードには実際のデータのハッシュが含まれています。したがって、ルートノードのラベルは、ツリー内の他のすべてのノードに依存します。</p>
+
+<p>Certificate Transparency のコンテキストでは、リーフノードによってハッシュ化されたデータは、現在運営されている様々な異なる CA によって発行された証明書です。証明書の組み込みは、対数的な O(log n) 時間で効率的に生成・検証できる<em>監査証明</em>を介して検証することができます。</p>
+
+<p>Certificate Transparency は、認証局の危殆化 (2011 年の DigiNotar の違反)、疑わしい決定 (2012 年の Trustwave の下位ルート事件)、技術的な発行問題 (マレーシアの Digicert Sdn Bhd による 512 ビットの脆弱な証明書の発行) を背景に、2013 年に初めて実現しました。</p>
+
+<h2 id="実装">実装</h2>
+
+<p>証明書が CT ログに送信されると、<em>署名付き証明書のタイムスタンプ</em> (SCT) が生成されて返されます。これは、証明書が提出され、ログに追加されることを証明する役割を果たします。</p>
+
+<p>仕様では、準拠サーバは接続時にこれらの SCT を TLS クライアントに提供<em>しなければならない</em>とされています。これは、いくつかの異なるメカニズムを介して実現することができます。</p>
+
+<ul>
+ <li>署名付き証明書のタイムスタンプを直接リーフ証明書に埋め込む X.509 v3 証明書拡張機能</li>
+ <li>ハンドシェイク中に送信される <code>signed_certificate_timestamp</code> 型の TLS 拡張</li>
+ <li>OCSP のステープリング (つまり、<code>status_request</code> TLS 拡張) と、1つ以上の SCT を持つ <code>SignedCertificateTimestampList</code> の提供</li>
+</ul>
+
+<p>X.509 証明書の拡張では、含まれる SCT は発行 CA が決定します。このメカニズムを使用する場合、Web サーバを変更する必要はありません。</p>
+
+<p>後者の方法では、必要なデータを送信するためにサーバを更新する必要があります。利点は、サーバオペレータが TLS 拡張/stapled OCSP レスポンスを介して送信される SCT を提供する CT ログソースをカスタマイズできることです。</p>
+
+<h2 id="ブラウザの要件">ブラウザの要件</h2>
+
+<p>Google Chrome では、2018年4月30日以降の notBefore 日付を持つすべての証明書の問題に対して、CT ログのインクルードを要求しています。これにより、ユーザーは非準拠の TLS 証明書を使用したサイトを訪問できなくなります。これまで Chrome では、<em>Extended Validation</em> (EV) や Symantec が発行した証明書に対して CT のインクルードが義務付けられていました。</p>
+
+<p>Apple は、Safari や他のサーバがサーバ証明書を信頼するために、さまざまな数の SCT を<a href="https://support.apple.com/ja-jp/HT205280">必要としています</a>。</p>
+
+<p>Firefox は現在、ユーザーが訪問したサイトの CT ログを確認したり、使用を義務付けたり<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1281469">していません</a>。</p>
+
+<p><a href="/ja/docs/Web/HTTP/Headers/Expect-CT">Expect-CT ヘッダ</a>を使用して、ブラウザが証明書の透過性の要件を常に実施するように要求することができます (Chrome などでは、証明書の発行日が4月以前の notBefore であっても)。</p>
+
+<h2 id="仕様">仕様</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">仕様書</th>
+   <th scope="col">ステータス</th>
+   <th scope="col">コメント</th>
+  </tr>
+  <tr>
+   <td><a class="external external-icon" href="https://tools.ietf.org/html/rfc6962" hreflang="en" lang="en" rel="noopener">Certificate Transparency</a></td>
+   <td><span class="spec-RFC">IETF RFC</span></td>
+   <td></td>
+  </tr>
+ </tbody>
+</table>
diff --git a/files/ja/web/security/index.html b/files/ja/web/security/index.html
new file mode 100644
index 0000000000..4db17fb313
--- /dev/null
+++ b/files/ja/web/security/index.html
@@ -0,0 +1,237 @@
+---
+title: Web セキュリティ
+slug: Web/Security
+tags:
+  - Landing
+  - Security
+  - Web
+  - セキュリティ
+translation_of: Web/Security
+---
+<div class="summary">
+<p>Web サイトや公開 Web アプリケーションが安全であることを保証するのは重要なことです。コードの中の単純なバグが、個人情報の漏洩という結果を招くことがありますし、データを盗む方法を見つけようとしている悪い輩があちこちにいます。<span class="seoSummary">以下に紹介するセキュリティ方面の記事では、コードの安全性を確保する際に助けとなる情報を提供しています。</span></p>
+</div>
+
+<h2 id="Content_security" name="Content_security">コンテンツセキュリティ</h2>
+
+<dl>
+ <dt><a href="/ja/docs/Web/HTTP/CSP">コンテンツセキュリティポリシー (CSP)</a></dt>
+ <dd><strong>コンテンツセキュリティポリシー</strong> ({{Glossary("CSP")}}) は、クロスサイトスクリプティング ({{Glossary("XSS")}}) やデータインジェクション攻撃などのような、特定の種類の攻撃を検知し、影響を軽減するために追加できるセキュリティレイヤーです。これらの攻撃はデータの窃取からサイトの改ざん、マルウェアの拡散に至るまで、様々な目的に用いられます。</dd>
+</dl>
+
+<h2 id="Connection_security" name="Connection_security">コネクションセキュリティ</h2>
+
+<dl>
+ <dt><a href="/ja/docs/Web/Security/Transport_Layer_Security">Transport security layer (TLS)</a></dt>
+ <dd>Transport Layer Security ({{Glossary("TLS")}}) プロトコルは、ネットワークで結ばれた二つのアプリケーションや端末が、私的にかつ強固に情報交換するための標準です。 TLS を使用するアプリケーションは、セキュリティ引数を選択することができ、これは、データのセキュリティと信頼性に大きな影響を与える可能性があります。この記事では、 TLS の概要と、コンテンツを保護するために必要な決定の種類について説明します。</dd>
+ <dt>HTTPS</dt>
+ <dd><strong>HTTPS</strong> (<strong><em>HyperText Transfer Protocol Secure</em></strong>) は、 {{Glossary("HTTP")}} プロトコルの暗号化バージョンです。 {{Glossary("SSL")}} または {{Glossary("TLS")}} を使用して、クライアントとサーバー間のすべての通信を暗号化します。この安全な接続により、クライアントは意図したサーバーに接続されていることを確認し、機密データを交換することができます。</dd>
+ <dt><a href="/ja/docs/Web/HTTP/Headers/Strict-Transport-Security">HTTP Strict-Transport-Security</a></dt>
+ <dd><code>Strict-Transport-Security:</code> は <a href="/en/HTTP" title="en/HTTP">HTTP</a> のヘッダーで、Web サイトを HTTPS を使用してのみアクセスできるようにするものです。</dd>
+ <dt><a href="/ja/docs/Web/Security/Certificate_Transparency">電子証明書の透明性</a></dt>
+ <dd><strong>電子証明書の透明性</strong>は、証明書の誤発行を防止し、監視するために設計されたオープンなフレームワークです。新しく発行された証明書は、公開されている、多くの場合独立した CT ログに「記録」され、発行された TLS 証明書の追加のみの暗号的に保証された記録を維持します。</dd>
+ <dt><a href="/ja/docs/Web/Security/Mixed_content">混在コンテンツ</a></dt>
+ <dd>HTTPS のページの中に通常の平文の HTTP で送られてくるコンテンツが含まれている場合、<strong>混在コンテンツ</strong>と呼ばれます。このようなページは部分的にしか暗号化されておらず、盗聴者や中間者攻撃者が暗号化されていないコンテンツにアクセスできてしまいます。</dd>
+ <dt><a href="/ja/docs/Web/Security/Mixed_content/How_to_fix_website_with_mixed_content">混在コンテンツでブロックされるWeb サイトを修正するには</a></dt>
+ <dd>Web サイトを HTTPS で配信している場合、ページ上にある <a href="/ja/docs/Web/Security/Mixed_content#Mixed_active_content">能動的な混在コンテンツ</a>はすべて既定でブロックされます。結果として、ユーザーからはその Web サイトが壊れているように見えるかもしれません (iframe やプラグインが読み込まれないなど)。一方、<a href="/ja/docs/Web/Security/Mixed_content/#Mixed_passivedisplay_content">受動的な混在コンテンツ</a>は既定で表示されますが、このようなコンテンツをブロックするようにユーザーが設定することも可能です。このページでは、Web 開発者として知っておくべきことを説明します。</dd>
+ <dt><a href="/ja/docs/Web/Security/Secure_Contexts">安全なコンテキスト</a></dt>
+ <dd><strong>安全なコンテキスト (Secure Context)</strong> とは、(HTTPS/TLS を介して) コンテンツが安全に配信され、安全<strong>ではない</strong>コンテキストとの通信の可能性が限られているという合理的な確信がある <code>Window</code>、または <code>Worker</code> のことです。多くの Web API が安全なコンテキストでのみ利用可能です。安全なコンテキストの主目的は、{{interwiki("wikipedia", "中間者攻撃", "中間者攻撃者")}}が被害者に更なる危険にさらす可能性がある強力な API にアクセスするのを防ぐことにあります。</dd>
+ <dt><a href="/ja/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts">安全なコンテキストに制限されている機能</a></dt>
+ <dd>このリファレンスは、安全なコンテキストでのみ使用できるWeb プラットフォーム機能の一覧です。</dd>
+ <dt><a href="/ja/docs/Web/Security/Weak_Signature_Algorithm">脆弱な署名アルゴリズム</a></dt>
+ <dd>{{Glossary("Digital certificate", "ディジタル証明書")}}の{{Glossary("Signature/Security", "電子署名")}}に用いられるハッシュアルゴリズムの強度は、証明書のセキュリティにおいて核心的な要素です。この記事では、脆弱になったため、可能であれば避けるものと知られている署名アルゴリズムについて、いくらかの情報を提供します。</dd>
+ <dt>301 および 302 レスポンスコードによるリダイレクト</dt>
+ <dd>執筆予定</dd>
+</dl>
+
+<h2 id="Data_security" name="Data_security">データセキュリティ</h2>
+
+<dl>
+ <dt><a href="/ja/docs/Web/HTTP/Cookies">HTTP Cookie の使用</a></dt>
+ <dd><dfn>HTTP Cookie</dfn> (ウェブ Cookie、ブラウザ Cookie) は、サーバーがユーザーのWeb ブラウザに送信する小さなデータであり、ブラウザに保存されて次のリクエストと共に同じサーバーへ返送されます。一般的には、二つのリクエストが同じブラウザから送信されたものであるかを知るために使用されます。例えば、ユーザーのログイン状態を維持することができます。</dd>
+ <dt><a href="/ja/docs/Web/API/Window/localStorage">ローカルストレージ</a></dt>
+ <dd><code>Window</code> オブジェクトの {{domxref("Window.localStorage")}} プロパティは、サーバーがクライアントにセッションを通して存在するデータを格納する一つの手段です。</dd>
+</dl>
+
+<h2 id="Information_leakage" name="Information_leakage">情報漏洩</h2>
+
+<dl>
+ <dt><a href="/ja/docs/Web/Security/Referer_header:_privacy_and_security_concerns">Referer ヘッダーのプライバシーとセキュリティの考慮事項</a></dt>
+ <dd><a href="/ja/docs/Web/HTTP/Headers/Referer">HTTP の Referer ヘッダー</a>にまつわるプライバシーとセキュリティのリスクがあります。この記事ではこれらを説明し、これらのリスクを回避するためのアドバイスを提案します。</dd>
+ <dt>Robots.txt</dt>
+ <dd>執筆予定</dd>
+ <dt>Site maps</dt>
+ <dd>執筆予定</dd>
+</dl>
+
+<h2 id="Integrity" name="Integrity">完全性</h2>
+
+<dl>
+ <dt><a href="/ja/docs/Web/Security/Same-origin_policy">同一オリジンポリシー</a></dt>
+ <dd><strong>同一オリジンポリシー</strong>とは、あるオリジンから読み込まれた文書やスクリプトについて、そのリソースから他の{{Glossary("origin", "オリジン")}}のリソースにアクセスできないように制限するものです。同一オリジンポリシーは Web のセキュリティにおける重要な仕組みであり、悪意ある行動を起こしかねないリソースの分離を目的としています。</dd>
+ <dt><a href="/ja/docs/Web/Security/Subresource_Integrity">サブリソース完全性</a></dt>
+ <dd><ruby><strong>サブリソース完全性</strong><rp> (</rp><rt>Subresource Integrity</rt><rp>)</rp></ruby> (SRI) は、 ({{Glossary("CDN")}} などから) 取得したリソースが意図せず改ざんされていないかをブラウザが検証するセキュリティ機能です。 SRI を利用する際には、取得したリソースのハッシュ値と一致すべきハッシュ値を指定します。</dd>
+ <dt><a href="/ja/docs/Web/HTTP/Headers/Access-Control-Allow-Origin">HTTP の Access-Control-Allow-Origin</a></dt>
+ <dd><code><strong>Access-Control-Allow-Origin</strong></code> レスポンスヘッダーは、指定された{{glossary("origin", "オリジン")}}からのリクエストを行うコードでレスポンスが共有できるかどうかを示します。</dd>
+ <dt><a href="/ja/docs/Web/HTTP/Headers/X-Content-Type-Options">HTTP X-Content-Type-Options</a></dt>
+ <dd>
+ <p><code><strong>X-Content-Type-Options</strong></code> は HTTP のレスポンスヘッダーで、 {{HTTPHeader("Content-Type")}} ヘッダーで示された <a href="/ja/docs/Web/HTTP/Basics_of_HTTP/MIME_types">MIME タイプ</a>を変更せに従うべきであることを示すために、サーバーによって使用されるマーカーです。これにより、<a href="/ja/docs/Web/HTTP/Basics_of_HTTP/MIME_types#MIME_sniffing">MIME タイプのスニッフィング</a>を抑止することができます。すなわち、Web マスターが自分が何をしているかを分かっていると言う手段です。</p>
+ </dd>
+</dl>
+
+<h2 id="Clickjacking_protection" name="Clickjacking_protection">クリックジャックからの保護</h2>
+
+<p id="sect1">クリックジャッキングでは、ユーザーがだまされて、ユーザーが期待するもの以外のアクションを実行するUI要素をクリックします。 </p>
+
+<dl>
+ <dt><a href="/ja/docs/Web/HTTP/Headers/X-Frame-Options">HTTP X-Frame-Options</a></dt>
+ <dd><strong><code>X-Frame-Options</code></strong> <a href="/ja/docs/Web/HTTP">HTTP</a> レスポンスヘッダーを使用して、ブラウザが <a href="/ja/docs/Web/HTML/Element/frame" title="&lt;frame> is an HTML element which defines a particular area in which another HTML document can be displayed. A frame should be used within a &lt;frameset>."><code>&lt;frame&gt;</code></a>, <a href="/ja/docs/Web/HTML/Element/iframe" title="The HTML Inline Frame element (&lt;iframe>) represents a nested browsing context, embedding another HTML page into the current one."><code>&lt;iframe&gt;</code></a>, <a href="/ja/docs/Web/HTML/Element/embed" title="The HTML &lt;embed> element embeds external content at the specified point in the document. This content is provided by an external application or other source of interactive content such as a browser plug-in."><code>&lt;embed&gt;</code></a> または <a href="/ja/docs/Web/HTML/Element/object" title="The HTML &lt;object> element represents an external resource, which can be treated as an image, a nested browsing context, or a resource to be handled by a plugin."><code>&lt;object&gt;</code></a> でページをレンダリングできるかどうかを示すことができます。サイトはこれを使用してコンテンツが他のサイトに埋め込まれないようにすることで、クリックジャッキング攻撃を回避できます。</dd>
+ <dt><a href="/ja/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors">CSP: frame-ancestors</a></dt>
+ <dd>HTTP {{HTTPHeader("Content-Security-Policy")}} (CSP) <code><strong>frame-ancestors</strong></code> ディレクティブは、 {{HTMLElement("frame")}}, {{HTMLElement("iframe")}}, {{HTMLElement("object")}}, {{HTMLElement("embed")}}, または {{HTMLElement("applet")}} を使用して、ページを埋め込むことができる有効な親を指定します。</dd>
+</dl>
+
+<h2 id="User_information_security" name="User_information_security">ユーザー情報セキュリティ</h2>
+
+<dl>
+ <dt><a href="/ja/docs/Web/Security/Insecure_passwords">安全でないパスワード</a></dt>
+ <dd>HTTP 経由でログインフォームを送信することは、ユーザのパスワードを抽出するために使用できる様々な攻撃があるため、特に危険です。ネットワーク盗聴者は、ネットワークを盗聴したり、転送中に提供されたページを変更したりすることで、ユーザのパスワードを盗むことができます。</dd>
+ <dt><a href="/ja/docs/Web/CSS/Privacy_and_the_:visited_selector">プライバシーと :visited セレクタ</a></dt>
+ <dd>2010年頃までは、<a href="/ja/docs/Web/CSS">CSS</a> {{cssxref(":visited")}} セレクタにより、Web サイトがユーザーの閲覧履歴を明らかにし、そのユーザーがどのサイトを訪問したかを把握することができました。この問題を軽減するために、ブラウザは訪問したリンクから取得できる情報量を制限しています。</dd>
+</dl>
+
+<h2 id="Security-related_glossary_terms" name="Security-related_glossary_terms">セキュリティに関する用語集の用語</h2>
+
+<div class="twocolumns">
+<ul>
+ <li>
+  <p>{{Glossary("Block cipher mode of operation")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("Certificate authority")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("challenge", "Challenge-response authentication")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("Cipher")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("Cipher suite")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("Ciphertext")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("CORS")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("CORS-safelisted request header")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("CORS-safelisted response header")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("Cross-site scripting")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("Cryptanalysis")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("Cryptographic hash function")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("Cryptography")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("CSP")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("CSRF")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("Decryption")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("Digital certificate")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("DTLS")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("Encryption")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("Forbidden header name")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("Forbidden response header name")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("Hash")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("HMAC")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("HPKP")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("HSTS")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("HTTPS")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("Key")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("MitM")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("OWASP")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("Preflight request")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("Public-key cryptography")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("Reporting directive")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("Robots.txt")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("Same-origin policy")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("Session hijacking")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("SQL injection")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("Symmetric-key cryptography")}}</p>
+ </li>
+ <li>
+  <p>{{Glossary("TOFU")}}</p>
+ </li>
+</ul>
+
+<ul>
+ <li>
+  <p>{{Glossary("TLS")}}</p>
+ </li>
+</ul>
+</div>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li><a href="https://lists.mozilla.org/listinfo/dev-security">Mozilla メーリングリスト</a></li>
+ <li><a href="https://blog.mozilla.com/security/">ブログ</a></li>
+ <li><a href="https://twitter.com/mozsec">@mozsec (Twitter)</a></li>
+</ul>
+
+<p>{{QuickLinksWithSubpages}}</p>
diff --git a/files/ja/web/security/information_security_basics/index.html b/files/ja/web/security/information_security_basics/index.html
new file mode 100644
index 0000000000..4eaeff0350
--- /dev/null
+++ b/files/ja/web/security/information_security_basics/index.html
@@ -0,0 +1,39 @@
+---
+title: 情報セキュリティの基本
+slug: Web/Security/Information_Security_Basics
+tags:
+  - Beginner
+  - Landing
+  - Security
+  - セキュリティ
+translation_of: Web/Security/Information_Security_Basics
+---
+<p><span class="seoSummary">情報セキュリティを基本的に理解しておくことは、ソフトウェアやサイトが危険で脆弱なままで、資産を奪ったりその他の悪意の理由のために弱点を悪用されるのを防ぐのに役立ちます。これらの記事は知るべきことを学ぶのに役立ちます。</span> この情報から、ウェブ開発を通じて、またそれ以外のコンテンツのデプロイにおいても、セキュリティの役割と重要性に気づくでしょう。</p>
+
+<dl>
+ <dt><a href="/ja/docs/Web/Security/Information_Security_Basics/Confidentiality,_Integrity,_and_Availability">機密性、完全性、可用性</a></dt>
+ <dd>セキュリティを理解する上で絶対的な基礎となる、セキュリティの第一の目的を説明します。</dd>
+ <dt><a href="/ja/docs/Web/Security/Information_Security_Basics/Security_Controls">セキュリティの制御</a></dt>
+ <dd>セキュリティ制御の主要なカテゴリを定義し、潜在的な欠点を議論します。</dd>
+ <dt><a href="/ja/docs/Web/Security/Information_Security_Basics/TCP_IP_Security">TCP/IP セキュリティ</a></dt>
+ <dd>SSL のセキュリティの考慮事項に焦点を当てた TCP/IP モデルの概要です。</dd>
+ <dt><a href="/ja/docs/Web/Security/Information_Security_Basics/Threats">脅威</a></dt>
+ <dd>主要な脅威の概念を簡単に案内します。</dd>
+</dl>
+
+<dl>
+ <dt><a href="/ja/docs/Web/Security/Information_Security_Basics/Vulnerabilities">脆弱性</a></dt>
+ <dd>主要な分野の脆弱性を定義し、すべてのソフトウェアの脆弱性の存在を議論します。</dd>
+</dl>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li><a href="/ja/docs/Mozilla/Security">ブラウザーセキュリティ</a></li>
+ <li><a href="/ja/docs/Web/Security">ウェブセキュリティ</a></li>
+ <li><a href="/ja/docs/Web/Security/Securing_your_site">サイトを安全にする</a></li>
+ <li><a href="/ja/docs/Security/Firefox_Security_Basics_For_Developers">開発者向け Firefox セキュリティの基本</a></li>
+ <li><a href="/ja/docs/Web/Privacy">プライバシー、アクセス制限、情報セキュリティ</a></li>
+</ul>
+
+<p>{{QuickLinksWithSubpages("/ja/docs/Web/Security")}}</p>
diff --git a/files/ja/web/security/insecure_passwords/index.html b/files/ja/web/security/insecure_passwords/index.html
new file mode 100644
index 0000000000..ede48de515
--- /dev/null
+++ b/files/ja/web/security/insecure_passwords/index.html
@@ -0,0 +1,31 @@
+---
+title: 安全でないパスワード
+slug: Web/Security/Insecure_passwords
+tags:
+  - Insecure
+  - Intermediate
+  - Security
+  - Web
+  - password
+  - passwords
+translation_of: Web/Security/Insecure_passwords
+---
+<p class="summary">HTTP を通じてログインフォームを提供することは、ユーザーのパスワードを暴くための広範にわたる攻撃に対して特に危険です。ネットワークの盗聴者は、ネットワークを覗き見たり、転送によって提供されたページを変更したりしてユーザーのパスワードを盗むことができます。</p>
+
+<p>{{glossary("HTTPS")}} プロトコルは、ネットワーク上での盗聴 (機密性) や改ざん (完全性) といった脅威から、ユーザーのデータを保護できるように設計されています。ユーザーのデータを扱うウェブサイトは、ユーザーを攻撃者から守るために HTTPS を使用してください。 HTTPS を使わなければ、ユーザーの情報 (ログインの資格情報など) が盗まれるのは当たり前になってしまいます。このことを <a href="https://codebutler.github.io/firesheep/">Firesheep</a> が証明したのは有名です。</p>
+
+<p>この問題を修正するためには、 SSL/{{glossary("TLS")}} 証明書をサーバーにインストールし構成してください。様々なベンダーが無料または有料の証明書を提供しています。クラウドプラットフォームを使用しているのであれば、 HTTPS を有効にする方法を独自に持っているかもしれません。</p>
+
+<h2 id="Note_on_password_reuse" name="Note_on_password_reuse">パスワードの使い回しに関するメモ</h2>
+
+<p>ウェブサイトがユーザー名とパスワードを求めても、実際には微妙なデータを保存しないことがあります。例えば、あるニュースサイトがユーザーが読み返したい記事を保存しても、ユーザーに関する他のデータを保存しない場合などです。ニュースサイトのウェブ開発者は、サイトやユーザーの資格情報を安全にする必要があるとはあまり考えないかもしれません。</p>
+
+<p>残念ながら、<a href="https://www.lightbluetouchpaper.org/2011/02/09/measuring-password-re-use-empirically/">パスワードの使い回しは大きな問題</a>です。ユーザーは複数のサイト (ニュースサイト、SNS、メールサービス、銀行) で同じパスワードを使用します。つまり、サイトが管理するユーザー名とパスワードに何者かがアクセスしたところで、自分たちに大きなリスクがあると思えなくとも、銀行のウェブサイトでも同じパスワードでログインしているユーザーーにとっては非常に大きなリスクなのです。攻撃者はより賢くなっており、一つのサイトでユーザ名とパスワードの組を盗んだ後には、より金目のあるサイトに同じ組でログインできないか試しているのです。</p>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li class="entry-title"><a href="https://blog.mozilla.org/tanvi/2016/01/28/no-more-passwords-over-http-please/">No More Passwords over HTTP, Please!</a> — detailed blog post with more information, and FAQ.</li>
+</ul>
+
+<p class="entry-title">{{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}</p>
diff --git a/files/ja/web/security/mixed_content/how_to_fix_website_with_mixed_content/index.html b/files/ja/web/security/mixed_content/how_to_fix_website_with_mixed_content/index.html
new file mode 100644
index 0000000000..7a03322393
--- /dev/null
+++ b/files/ja/web/security/mixed_content/how_to_fix_website_with_mixed_content/index.html
@@ -0,0 +1,31 @@
+---
+title: 混在コンテンツでブロックされるウェブサイトを修正するには
+slug: Web/Security/Mixed_content/How_to_fix_website_with_mixed_content
+tags:
+  - HTTPS
+  - Security
+translation_of: Web/Security/Mixed_content/How_to_fix_website_with_mixed_content
+---
+<p><a href="/ja/docs/Mozilla/Firefox/Releases/23">Firefox 23</a> より、 Firefox は<a href="/ja/docs/Security/MixedContent#Mixed_active_content">能動的な混在コンテンツ</a>を既定でブロックします。この機能は Internet Explorer (<a href="http://blogs.msdn.com/b/ie/archive/2011/06/23/internet-explorer-9-security-part-4-protecting-consumers-from-malicious-mixed-content.aspx">バージョン 9 以降</a>) や <a href="https://security.googleblog.com/2011/06/trying-to-end-mixed-scripting.html?m=1">Chrome</a> でも採用されています。</p>
+
+<p>このページでは、ウェブ開発者として知っておくべきことを説明します。</p>
+
+<h2 id="Your_website_may_break" name="Your_website_may_break">ウェブサイトが壊れることも</h2>
+
+<p>ウェブサイトを HTTPS で配信している場合、ページ上にある <a href="/ja/docs/Security/MixedContent#Mixed_active_content">能動的な混在コンテンツ</a>はすべて既定でブロックされます。結果として、ユーザーからはそのウェブサイトが壊れているように見えるかもしれません (iframe やプラグインが読み込まれないなど)。一方、<a href="/ja/docs/Security/MixedContent#Mixed_passive.2Fdisplay_content">受動的な混在コンテンツ</a>は既定で表示されますが、このようなコンテンツをブロックするようにユーザーが設定することも可能です。</p>
+
+<p>混在コンテンツは Chrome と Internet Explorer でもブロックされるため、ウェブサイトがこの２つのブラウザーで正常に動作していれば、混在コンテンツをブロックする Firefox でも正常に動作する可能性が高いと言えます。</p>
+
+<p>いずれにしても、ウェブサイトが Firefox で動作しない原因を特定するには、<a href="https://www.mozilla.org/ja/firefox">最新の Firefox</a> を利用すると良いでしょう。ウェブサイトを開いた上で、開発ツールの<a href="/ja/docs/Tools/Web_Console">ウェブコンソール</a>を開き、「セキュリティ」のメッセージを有効にします。そうすると、混在コンテンツを引き起こしている原因が表示されます。また、 <a href="http://www.jitbit.com/sslcheck/">SSL-check</a> や <a href="https://www.missingpadlock.com">Missing Padlock</a> などの無料のオンライン型クローラーや、 <a href="https://httpschecker.net/how-it-works">HTTPSChecker</a> といったデスクトップ型のクローラー、または <a href="https://github.com/agis/mcdetect">mcdetect</a> などの CLI ツールを使用して、安全ではないコンテンツを指すリンクがないかどうか、ウェブサイトを再帰的に検索することが出来ます。もし混在コンテンツに関する警告が出なければ、ウェブサイトの品質は保たれていると言えます。今後も維持し続けてください。</p>
+
+<h2 id="How_to_fix_your_website" name="How_to_fix_your_website">ウェブサイトを修正する方法</h2>
+
+<p>混合コンテンツが原因でブロックされないためには、すべてのコンテンツを (HTTP ではなく) HTTPS で提供することが重要です。</p>
+
+<p><strong>自分が保有するドメインの場合</strong>、すべてのコンテンツが HTTPS で配信されるようにリンクを修正します。多くの場合、既にコンテンツは HTTPS として配信できるようになっているため、単に "s" を追加してリンクの http:// を https:// に変更するだけで対応できます。</p>
+
+<p>しかし、場合によっては、問題のメディアに対してパスが正しくない可能性があります。 これを解決するためには、 <a href="https://linkchecker.github.io/linkchecker/">linkchecker</a> のようなオンラインツールとオフラインツール (オペレーティングシステムに依存します) があります。</p>
+
+<p><strong>他者が保有するドメインの場合</strong>、可能であれば HTTPS でウェブサイトに接続します。 HTTPS でアクセスできない場合は、 HTTPS を介してコンテンツを配信してもらえるよう、ドメインの管理者に連絡してみてください。</p>
+
+<p>{{QuickLinksWithSubpages("/ja/docs/Web/Security")}}</p>
diff --git a/files/ja/web/security/mixed_content/index.html b/files/ja/web/security/mixed_content/index.html
new file mode 100644
index 0000000000..02f276986b
--- /dev/null
+++ b/files/ja/web/security/mixed_content/index.html
@@ -0,0 +1,83 @@
+---
+title: 混在コンテンツ
+slug: Web/Security/Mixed_content
+tags:
+  - HTTP
+  - HTTPS
+  - Security
+  - Web
+  - console
+translation_of: Web/Security/Mixed_content
+---
+<p>ユーザが {{Glossary("HTTPS")}} を通じてページにアクセスすると、ユーザとウェブサーバとの接続は {{Glossary("TLS")}} で暗号化され、盗聴や中間者攻撃から保護されます。<span class="seoSummary">HTTPS のページの中に通常の平文の HTTP で送られてくるコンテンツが含まれている場合、<strong>混在コンテンツ</strong>と呼ばれます。このようなページは部分的にしか暗号化されておらず、盗聴者や中間者攻撃者が暗号化されていないコンテンツにアクセスできてしまいます。</span>つまり、ページは安全ではありません。</p>
+
+<h2 id="Types_of_mixed_content" name="Types_of_mixed_content">混在コンテンツの種類</h2>
+
+<p>混在コンテンツには <strong>受動的な混在コンテンツ</strong> と <strong>能動的な混在コンテンツ</strong> の 2 種類があります。この 2 つは、中間者攻撃によってコンテンツが改ざんされた場合に、最悪のケースとして脅威が影響を与える度合いで区別されます。受動的な混在コンテンツにおける脅威は低いものとなります (誤解を招くコンテンツが含まれているか、ユーザのクッキーが盗まれている可能性があります)。能動的な混在コンテンツの場合、その脅威としてフィッシングや機密情報の漏えい、悪意あるサイトへのリダイレクトなどが想定されます。</p>
+
+<h3 id="Mixed_passivedisplay_content" name="Mixed_passivedisplay_content">受動的な混在コンテンツ</h3>
+
+<p>受動的な混在コンテンツは、 HTTPS のウェブページの中で HTTP 経由で送信されるコンテンツです。しかし、そのウェブページの他の要素を混在コンテンツから変更することは出来ません。 例えば、HTTP で送信された画像に対して、攻撃者は別の不適切な画像やメッセージへと差し替えてユーザに表示させることが出来ます。 また、攻撃者はユーザへ送信される画像を盗聴することで、ユーザの行動に関する情報を推測することが可能です。 なぜなら、画像ファイルの置かれている場所がウェブサイト中のある特定のページに固定されていることがままあるからです。もし攻撃者が特定の画像に対する HTTP リクエストを覗き見れば、ユーザが閲覧しているウェブページを特定することが出来るでしょう。</p>
+
+<h4 id="Passive_content_list" name="Passive_content_list">受動的なコンテンツの一覧</h4>
+
+<p>受動的なコンテンツとされる HTTP リクエストは以下の通りです。</p>
+
+<ul>
+ <li>{{HTMLElement("img")}} (<code>src</code> 属性)</li>
+ <li>{{HTMLElement("audio")}} (<code>src</code> 属性)</li>
+ <li>{{HTMLElement("video")}} (<code>src</code> 属性)</li>
+ <li>{{HTMLElement("object")}} サブリソース (<code>&lt;object&gt;</code> が HTTP リクエストを送信したとき)</li>
+</ul>
+
+<h3 id="Mixed_active_content" name="Mixed_active_content">能動的な混在コンテンツ</h3>
+
+<p><strong>能動的な混在コンテンツ</strong>は、その HTTPS ページのすべて、ないしは DOM の一部にアクセスできるコンテンツです。このタイプの混在コンテンツは HTTPS ページの動作を変更することができ、ユーザから機密情報を窃取することも可能です。従って、先程説明した受動的な混在コンテンツによる脅威に加え、能動的な混在コンテンツには他の攻撃ベクタへ向けた脆弱性が存在します。</p>
+
+<p>能動的な混在コンテンツの場合、中間者攻撃の攻撃者はまず HTTP のコンテンツへのリクエストを横取りすることが出来ます。 その後、攻撃者はレスポンスを改ざんして悪意ある JavaScript コードを含めることも可能です。悪意ある能動的なコンテンツは、ユーザーのログイン情報を窃取したり、ユーザーに関する機密情報を取得したり、ユーザのマシンにマルウェアのインストールを試みることが出来ます (例えば、ブラウザーやそのプラグインの脆弱性を利用することが考えられます)。</p>
+
+<p>混在コンテンツに関係するリスクは、ユーザが閲覧しているウェブサイトの種類と、そのサイトにどれだけ機微な情報が含まれているかに依存します。そのウェブページには世界中に公開されているデータもあれば、認証された時のみアクセスできる機密情報もあるでしょう。 もしウェブページが公開されていて機微なデータは何もなかった場合でも、攻撃者は能動的な混在コンテンツを利用することにより、ユーザを他の HTTP ページへリダイレクトさせたり、 HTTP cookie をサイトから窃取したりできてしまうのです。</p>
+
+<h4 id="Active_content_examples" name="Active_content_examples">能動的な混在コンテンツの例</h4>
+
+<p>能動的なコンテンツとされる HTTP リクエストのうち、代表的なものは以下の通りです。</p>
+
+<ul>
+ <li>{{HTMLElement("script")}} (<code>src</code> 属性)</li>
+ <li>{{HTMLElement("link")}} (<code>href</code> 属性) (CSS スタイルシートも含む)</li>
+ <li>{{HTMLElement("iframe")}} (<code>src</code> 属性)</li>
+ <li>{{domxref("XMLHttpRequest")}} リクエスト</li>
+ <li>{{domxref("GlobalFetch.fetch","fetch()")}} リクエスト</li>
+ <li>{{cssxref("url")}} 値を用いる CSS すべて ({{cssxref("@font-face")}} /  {{cssxref("cursor")}} / {{cssxref("background-image")}} など)</li>
+ <li>{{HTMLElement("object")}} (<code>data</code> 属性)</li>
+ <li>{{domxref("Navigator.sendBeacon")}} (<code>url</code> 属性)</li>
+</ul>
+
+<p>Chrome と同様に、ウェブフォントやワーカーのようなリソースタイプも能動的なコンテンツとみなされます。</p>
+
+<h2 id="Warnings_in_Web_Console" name="Warnings_in_Web_Console">ウェブコンソール内の警告</h2>
+
+<p>閲覧しているページに混在コンテンツが含まれていた場合、Firefox のウェブコンソールには警告が表示されます。 HTTP 経由で読み込まれた混在コンテンツのリソースは赤色で表示され、このページへのリンクである「混在コンテンツ」の文字列が併記されます。</p>
+
+<p><a class="internal" href="/files/12545/Mixed_content_-_Net_pane.png"><img alt="Screen shot of the web console displaying a mixed content warning." src="https://mdn.mozillademos.org/files/12545/Mixed_content_-_Net_pane.png" style="border-style: solid; border-width: 1px; height: 286px; width: 720px;"></a></p>
+
+<p>これらの警告をウェブコンソールで見つけるのと同様に、 <a href="/ja/docs/Web/HTTP/CSP">Content Security Policy (CSP)</a> を使用して問題を報告することができます。 <a href="http://www.jitbit.com/sslcheck/" rel="noopener">SSL-check</a> や <a href="https://www.missingpadlock.com/" rel="noopener">Missing Padlock</a> のようなオンラインクローラーと使用すると、ウェブサイトを再帰的にチェックし、安全ではないコンテンツのリンクを探すことができます。</p>
+
+<p>Firefox 23 以降より、能動的な混在コンテンツはデフォルトでブロックされるようになりました (受動的な混在コンテンツは設定によりブロック可能です)。ウェブ開発者が混在コンテンツのエラーに気付きやすくなるよう、ブロックされた混在コンテンツへのリクエストはウェブコンソールのセキュリティペインにすべて記録されます。</p>
+
+<p><a href="/files/5261/blocked-mixed-content-errors.png"><img alt="A screenshot of blocked mixed content errors in the Security Pane of the Web Console" src="https://mdn.mozillademos.org/files/12543/mixed_content_webconsole.png" style="border-style: solid; border-width: 1px; height: 285px; width: 720px;"></a></p>
+
+<p>このエラーを修正するには、 HTTP コンテンツへのリクエストをすべて HTTPS コンテンツへのリクエストに差し替えてください。よくある混在コンテンツには JavaScript ファイルやスタイルシート、画像、動画、その他のメディアファイルなどがあります。</p>
+
+<div class="note">
+<p><strong>注</strong>: Firefox 55 以降、 http://127.0.0.1/ で混在コンテンツの読み込みが許可されました ({{bug(903966)}} を参照)。 Chrome は http://127.0.0.1/ 及び http://localhost/ で混在コンテンツを許可しています。 Safari は混在コンテンツを許可しません。</p>
+</div>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li><a href="https://w3c.github.io/webappsec/specs/mixedcontent/" title="https://w3c.github.io/webappsec/specs/mixedcontent/">Mixed Content - W3C Editor's Draft</a></li>
+ <li><a href="/ja/docs/Security/%E6%B7%B7%E5%9C%A8%E3%82%B3%E3%83%B3%E3%83%86%E3%83%B3%E3%83%84/How_to_fix_website_with_mixed_content">混在コンテンツでブロックされるウェブサイトを修正するには</a></li>
+</ul>
+
+<p>{{QuickLinksWithSubpages("/ja/docs/Web/Security")}}</p>
diff --git a/files/ja/web/security/public_key_pinning/index.html b/files/ja/web/security/public_key_pinning/index.html
new file mode 100644
index 0000000000..4741133a6b
--- /dev/null
+++ b/files/ja/web/security/public_key_pinning/index.html
@@ -0,0 +1,163 @@
+---
+title: HTTP Public Key Pinning (HPKP)
+slug: Web/Security/Public_Key_Pinning
+tags:
+  - Deprecated
+  - Guide
+  - HPKP
+  - HTTP
+  - Obsolete
+  - Security
+translation_of: Web/HTTP/Public_Key_Pinning
+---
+<p>{{HTTPSidebar}}{{deprecated_header}}</p>
+
+<div class="blockIndicator note"><strong>注:</strong> Public Key Pinning の仕組みは <a href="/ja/docs/Web/Security/Certificate_Transparency">Certificate Transparency</a> および {{HTTPHeader("Expect-CT")}} ヘッダーに置き換えられ、非推奨になりました。</div>
+
+<p class="summary"><strong>HTTP Public Key Pinning</strong> ({{Glossary("HPKP")}}) は、ウェブクライアントに特定の公開鍵をあるウェブサーバーに関連付けさせることで、偽造された証明書による{{Glossary("MITM", "中間者攻撃")}}のリスクを減少させるためのセキュリティ機能でした。これは最近のブラウザーでは削除され、対応がなくなりました。</p>
+
+<p>{{Glossary("TLS")}} セッションで用いられるサーバーの公開鍵の真正性を担保するため、通常その公開鍵は認証局 ({{GLossary("CA")}}) の証明書でラップされます。ブラウザーなどのウェブクライアントがこれらの認証局を信頼することで、認証局は任意のドメイン名に対する証明書を作成できます。攻撃者が1つの認証局を危殆化させることができれば、様々な TLS コネクションで中間者攻撃を仕掛けることが可能になってしまいます。 HPKP はこの {{Glossary("HTTPS")}} プロトコルへの脅威を、そのウェブサーバーにどの公開鍵が所属するのかをクライアントに伝えることで回避することができます。</p>
+
+<p>HPKP は <em>Trust on First Use</em> ({{Glossary("TOFU")}}) 技術の1つです。 HPKP の HTTP ヘッダーがウェブサーバーからクライアントへ最初に送信されて以降、そのウェブサーバーに紐付く公開鍵はクライアントで一定期間記憶されます。クライアントが再びそのサーバーを訪れた際は、既に HPKP で記憶したフィンガープリントと一致する公開鍵が、証明書チェインにおいて最低 1 つの証明書に含まれていることを確認します。そのサーバーから送信されてきた公開鍵が不明なものだった場合、クライアントはユーザーに警告を表示します。</p>
+
+<p class="note">Firefox および Chrome は、認証された証明書チェーンが (内蔵の証明書ではなく) <strong>ユーザー定義の証明書</strong>であった場合、<strong>ピン留めによる認証を無効化します</strong>。つまり、独自のルート証明書をインポートしたユーザーに対しては、ピン留めによる警告が表示されません。</p>
+
+<h2 id="Enabling_HPKP" name="Enabling_HPKP">HPKP の有効化</h2>
+
+<p>サイトでこの機能を有効化するには、サイトに HTTPS でアクセスされたとに、 HTTP の {{HTTPHeader("Public-Key-Pins")}} ヘッダーを返す必要があります。</p>
+
+<pre class="notranslate">Public-Key-Pins: pin-sha256="base64=="; max-age=<em>expireTime</em> [; includeSubDomains][; report-uri="<em>reportURI"</em>]</pre>
+
+<dl>
+ <dt><code>pin-sha256</code></dt>
+ <dd>二重引用符で囲まれた文字列で、 Base64 符号化された <em>Subject Public Key Information</em> ({{Glossary("SPKI")}}) のフィンガープリントです。異なる公開鍵に対する複数のピンを指定することが出来ます。将来のブラウザーでは SHA-256 以外のハッシュアルゴリズムが許容されるかもしれません。証明書や鍵ファイルからこの情報を抽出する方法は次の項で説明します。</dd>
+ <dt><code>max-age</code></dt>
+ <dd>このサイトへのアクセス時に必要となる（唯一ピン留めされた）鍵について、この鍵をブラウザーが記憶するべき時間を指定します。この値は秒単位で表現します。</dd>
+ <dt><code>includeSubDomains</code> {{optional_inline}}</dt>
+ <dd>このパラメータは省略可能です。サイトにおけるすべてのサブドメインにもこのルールが適用されます。</dd>
+ <dt><code>report-uri</code> {{optional_inline}}</dt>
+ <dd>このパラメータは省略可能です。ピンの検証に失敗した際に、失敗した旨を報告する URL を指定します。</dd>
+</dl>
+
+<div class="note">
+<p><strong>注</strong>: 現在の仕様では、本番系で運用されていないバックアップ用の第2のピンを指定することが必須になっています。これにより、既にピンを持っているクライアントからのアクセス性を損なうことなく、サーバの公開鍵を変更することが可能になります。例えば、本番系の鍵が危殆化したときなどに重要となります。</p>
+</div>
+
+<h3 id="Extracting_the_Base64_encoded_public_key_information" name="Extracting_the_Base64_encoded_public_key_information">Base64 エンコードされた公開鍵情報を抽出するには</h3>
+
+<div class="note">
+<p><strong>注:</strong> 以下の例ではサーバ証明書をピン留めする方法を説明していますが、証明書の更新やローテーションを容易にするため、サーバ証明書を発行した CA の中間証明書もピン留めすることを推奨します。</p>
+</div>
+
+<p>まずは証明書や鍵ファイルから公開鍵情報を抽出し、それを Base64 でエンコードする必要があります。</p>
+
+<p>次に示す便利なコマンドで、鍵ファイルや証明書署名要求 (CSR)、または証明書から Base64 エンコードされた情報を抽出できます。</p>
+
+<pre class="notranslate">openssl rsa -in my-rsa-key-file.key -outform der -pubout | openssl dgst -sha256 -binary | openssl enc -base64</pre>
+
+<pre class="notranslate">openssl ec -in my-ecc-key-file.key -outform der -pubout | openssl dgst -sha256 -binary | openssl enc -base64</pre>
+
+<pre class="notranslate">openssl req -in my-signing-request.csr -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64</pre>
+
+<pre class="notranslate">openssl x509 -in my-certificate.crt -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64</pre>
+
+<p>以下のコマンドを用いると、ウェブサイト向けに情報を抽出することができます。</p>
+
+<pre class="notranslate">openssl s_client -servername www.example.com -connect www.example.com:443 | openssl x509 -pubkey -noout | openssl pkey -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64</pre>
+
+<h3 id="Example_HPKP_Header" name="Example_HPKP_Header">HPKP ヘッダーの例</h3>
+
+<pre class="notranslate">Public-Key-Pins:
+  pin-sha256="cUPcTAZWKaASuYWhhneDttWpY3oBAkE3h2+soZS7sWs=";
+  pin-sha256="M8HztCzM3elUxkcjR2S5P4hhyBNf6lHkmjAHKhpGPWE=";
+  max-age=5184000; includeSubDomains;
+  report-uri="<em>https://www.example.org/hpkp-report"</em></pre>
+
+<p>この例では、 <strong>pin-sha256="cUPcTAZWKaASuYWhhneDttWpY3oBAkE3h2+soZS7sWs="</strong> で本番系で使用されるサーバーの公開鍵をピン止めします。２番目のピン宣言である <strong>pin-sha256="M8HztCzM3elUxkcjR2S5P4hhyBNf6lHkmjAHKhpGPWE="</strong> も、バックアップキーをピン止めします。 <strong>max-age=5184000</strong> はクライアントにこの情報を２か月間保存するように伝え、これは IETF RFC によれば合理的な期間です。このキーのピン止めは、 <strong>includeSubDomains</strong> 宣言で指示されているように、すべてのサブドメインでも有効です。最後に、 <strong>report-uri="https://www.example.net/hpkp-report"</strong> はピンの検証の失敗を報告する場所を説明します。</p>
+
+<h3 id="Report-Only_header" name="Report-Only_header">Report-Only ヘッダー</h3>
+
+<p>{{HTTPHeader("Public-Key-Pins")}} ヘッダーを用いる代わりに、 {{HTTPHeader("Public-Key-Pins-Report-Only")}} ヘッダーを利用することも可能です。このヘッダーを用いた場合、ピン留めの認証に失敗した場合でも指定した report-uri にレポートが送信されるのみで、ブラウザーがウェブサーバーへ接続することは可能となります。</p>
+
+<h3 id="Setting_up_your_webserver_to_include_the_HPKP_header" name="Setting_up_your_webserver_to_include_the_HPKP_header">HPKP ヘッダーを送信するためのウェブサーバーの設定</h3>
+
+<p>HPKP ヘッダーを送信するのに必要な具体的な手順はウェブサーバーによって異なります。</p>
+
+<div class="note">
+<p><strong>注:</strong> 以下の例では、2か月間の max-age と includeSubDomains を指定しています。自身のサーバに合った適切な設定をしてください。</p>
+</div>
+
+<div class="warning">
+<p id="HPKP_has_the_potential_to_lock_out_users_for_a_long_time_if_used_incorrectly!_The_use_of_backup_certificates_andor_pinning_the_CA_certificate_is_recommend.">HPKP の設定を間違えると、ユーザーが長期間接続できなくなってしまう可能性があります！バックアップの証明書を用意したり、CA の証明書をピン留めすることを推奨します。</p>
+</div>
+
+<h4 id="Apache">Apache</h4>
+
+<p>次のような行をウェブサーバーの config に追加すると Apache で HPKP が有効になります。 <code>mod_headers</code> モジュールがインストールされている必要があります。</p>
+
+<pre class="notranslate">Header always set Public-Key-Pins "pin-sha256=\"base64+primary==\"; pin-sha256=\"base64+backup==\"; max-age=5184000; includeSubDomains"</pre>
+
+<h4 id="Nginx">Nginx</h4>
+
+<p>次のような行を追加し、適切な <code>pin-sha256="..."</code> の値を設定すると nginx で HPKP が有効になります。 <code>ngx_http_headers_module</code> がインストールされている必要があります。</p>
+
+<pre class="notranslate">add_header Public-Key-Pins 'pin-sha256="base64+primary=="; pin-sha256="base64+backup=="; max-age=5184000; includeSubDomains' always;</pre>
+
+<h4 id="Lighttpd">Lighttpd</h4>
+
+<p>鍵に関する次のような情報 (pin-sha256="..." フィールド) を含む行を追加すると、 lighttpd で HPKP が有効になります。</p>
+
+<pre class="notranslate">setenv.add-response-header  = ( "Public-Key-Pins" =&gt; "pin-sha256=\"base64+primary==\"; pin-sha256=\"base64+backup==\"; max-age=5184000; includeSubDomains")</pre>
+
+<p><strong>注:</strong> 以下のように server.module で <code>mod_setenv</code> をあらかじめ読み込んでおく必要があります。</p>
+
+<pre class="notranslate">server.modules += ( "mod_setenv" )</pre>
+
+<h4 id="IIS">IIS</h4>
+
+<p>IIS から <code>Public-Key-Pins</code> ヘッダーを送信するには、以下のような数行を Web.config ファイルに追加してください。</p>
+
+<pre class="brush: xml notranslate">&lt;system.webServer&gt;
+  ...
+
+  &lt;httpProtocol&gt;
+    &lt;customHeaders&gt;
+      &lt;add name="Public-Key-Pins" value="pin-sha256=&amp;quot;base64+primary==&amp;quot;; pin-sha256=&amp;quot;base64+backup==&amp;quot;; max-age=5184000; includeSubDomains" /&gt;
+    &lt;/customHeaders&gt;
+  &lt;/httpProtocol&gt;
+
+  ...
+&lt;/system.webServer&gt;
+</pre>
+
+<h2 id="Specifications" name="Specifications">仕様書</h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">仕様書</th>
+   <th scope="col">題名</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{RFC("7469", "Public-Key-Pins", "2.1")}}</td>
+   <td>Public Key Pinning Extension for HTTP</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser_compatibility" name="Browser_compatibility">ブラウザーの互換性</h2>
+
+<div class="hidden">このページの互換性一覧表は構造化データから生成されています。データに協力したいのであれば、 <a href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> をチェックアウトしてプルリクエストを送信してください。</div>
+
+<p>{{Compat("http.headers.Public-Key-Pins")}}</p>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li>{{HTTPHeader("Public-Key-Pins")}}</li>
+ <li>{{HTTPHeader("Public-Key-Pins-Report-Only")}}</li>
+ <li>Browser test site: <a href="https://projects.dm.id.lv/Public-Key-Pins_test">HSTS and HPKP test</a></li>
+ <li>{{HTTPHeader("Expect-CT")}}</li>
+</ul>
diff --git a/files/ja/web/security/referer_header_colon__privacy_and_security_concerns/index.html b/files/ja/web/security/referer_header_colon__privacy_and_security_concerns/index.html
new file mode 100644
index 0000000000..051493d501
--- /dev/null
+++ b/files/ja/web/security/referer_header_colon__privacy_and_security_concerns/index.html
@@ -0,0 +1,58 @@
+---
+title: Referer ヘッダーのプライバシーとセキュリティの考慮事項
+slug: 'Web/Security/Referer_header:_privacy_and_security_concerns'
+tags:
+  - Privacy
+  - Referrer Policy
+  - Security
+  - referer
+  - referrer
+  - セキュリティ
+  - プライバシー
+translation_of: 'Web/Security/Referer_header:_privacy_and_security_concerns'
+---
+<p class="summary"><a href="/ja/docs/Web/HTTP/Headers/Referer">HTTP の Referer ヘッダー</a>にまつわるプライバシーとセキュリティのリスクがあります。この記事ではこれらを説明し、これらのリスクを回避するためのアドバイスを提案します。</p>
+
+<h2 id="The_referrer_problem" name="The_referrer_problem">リファラー問題</h2>
+
+<p>{{httpheader("Referer")}} (綴りに注意) ヘッダーには現在リクエストされているページへのリンクをたどる元のウェブページのアドレスが含まれています。これには、分析、ログ、キャッシュの最適化など、問題のない用途がかなりあります。しかし、情報の追跡や盗用など、もっと問題になる用途や、誤って機密情報を漏らすなどの副作用もあります。</p>
+
+<p>例えば、フッターにソーシャルメディアへのリンクがある「パスワードリセット」ページを想像してみてください。リンクをクリックすると、情報を共有する方法によっては、ソーシャルメディアサイトがパスワードをリセットする URL を受け取り、共有された情報が使用されると、ユーザーのセキュリティを侵害する恐れがあります。</p>
+
+<p>同じ論理で、サードパーティ側でホストされている画像がページに埋め込まれている場合、機密情報がサードパーティに漏洩する可能性があります。たとえセキュリティが損なわれていなくても、その情報はユーザーが共有してほしくないものかもしれません。</p>
+
+<h2 id="How_can_we_fix_this" name="How_can_we_fix_this">どのように対処できるか</h2>
+
+<p>このリスクの多くは、アプリケーションの賢明な設計によって軽減することができます。賢明なアプリケーションは、パスワードリセット URL を一度だけの使用、または一意のユーザートークンと組み合わせた場合にのみ使用可能にし、機密データを異なる方法で送信することで、このようなリスクを取り除くことができます。</p>
+
+<p>URL 経由で他の場所に機密データを渡すことを避けるために、可能な限り {{HTTPMethod("GET")}} ではなく {{HTTPMethod("POST")}} を使用すべきです。</p>
+
+<p>サイトには常に {{glossary("HTTPS")}} を使用してください。これには多くのセキュリティ上の利点がありますが、HTTPS サイトは参照元情報を HTTPS 以外のサイトには決して送信しないという事実もあります。Web のほとんどが HTTPS を使用するようになった現在では、これはあまり意味をなさなくなってきていますが、それでも検討する価値はあります。</p>
+
+<p>さらに、パスワードリセットページ、支払いフォーム、ログインエリアなど、Web サイトの安全な領域からサードパーティのコンテンツ ({{htmlelement("iframe")}} に埋め込まれたソーシャルネットワーキングウィジェットなど) を削除することを検討する必要があります。</p>
+
+<p>また、このようなリスクを軽減するには、次のような方法があります。</p>
+
+<ul>
+ <li>サーバ上の {{httpheader("Referrerer-Policy")}} ヘッダで、<code>Referer</code> ヘッダを通してどのような情報を送るかを制御します。繰り返しになりますが、<code>no-referrer</code> ディレクティブは Referer ヘッダを完全に省略します</li>
+ <li>そのような情報が漏れる危険性のある HTML 要素 ({{HTMLElement("img")}} や {{HTMLElement("a")}} など) 上の <code>referrerpolicy</code> 属性。これは、例えば、<code>Referer</code> ヘッダーが完全に送信されないようにするために、<code>no-referrer</code> に設定することができます</li>
+ <li>そのような情報が漏れる危険性のある HTML 要素 ({{HTMLElement("img")}} や {{HTMLElement("a")}} など) で <code>no-referrer</code> に設定されている <code>rel</code> 属性。詳細については、<a href="/ja/docs/Web/HTML/Link_types">リンク種別</a>と <code>no-referrer</code> の検索を参照してください</li>
+ <li>技術的な<a href="https://geekthis.net/post/hide-http-referer-headers/#exit-page-redirect">終了ページ</a></li>
+</ul>
+
+<p>セキュリティを意識したサーバーサイドのフレームワークは、例えば、このような問題を緩和するための機能が組み込まれていることが多いです。</p>
+
+<ul>
+ <li><a href="https://docs.djangoproject.com/ja/3.1/topics/security/">Django におけるセキュリティ</a> (特に <a href="https://docs.djangoproject.com/ja/3.1/topics/security/#cross-site-request-forgery-csrf-protection">クロス・サイト・リクエスト・フォージェリ(CSRF)の防御</a> を参照してください)</li>
+ <li><a href="https://github.com/helmetjs/helmet/tree/d75632db7dece10210e3a1db1a36d6dec686697d/middlewares/referrer-policy">helmetjs referrer-policy </a>— Node.js/Express アプリで Referrerer-Policy を設定するためのミドルウェアです (セキュリティ規定の詳細については <a href="https://github.com/helmetjs">helmetjs</a> も参照してください)</li>
+</ul>
+
+<h2 id="ポリシーと要件">ポリシーと要件</h2>
+
+<p>プロジェクトチームのために、関連するリスクを軽減するために、そのような機能の使用方法を指定したセキュリティとプライバシーの要件を書くことは理にかなっているでしょう。これらの要件を書くためには、ウェブセキュリティの専門家の助けを借りて、ユーザーのニーズと福祉の両方を考慮し、<a href="https://ec.europa.eu/commission/priorities/justice-and-fundamental-rights/data-protection/2018-reform-eu-data-protection-rules_en">EU 一般データ保護規則 (GDPR)</a> のような法律で施行されているポリシーや規制のような他の問題も考慮する必要があります。</p>
+
+<h2 id="あわせて参照">あわせて参照</h2>
+
+<ul>
+ <li><a href="https://infosec.mozilla.org/guidelines/web_security.html#referrer-policy">Mozilla security team guidelines on Referrer-Policy</a></li>
+</ul>
diff --git a/files/ja/web/security/same-origin_policy/index.html b/files/ja/web/security/same-origin_policy/index.html
new file mode 100644
index 0000000000..42ebea014a
--- /dev/null
+++ b/files/ja/web/security/same-origin_policy/index.html
@@ -0,0 +1,272 @@
+---
+title: 同一オリジンポリシー
+slug: Web/Security/Same-origin_policy
+tags:
+  - CORS
+  - Host
+  - JavaScript
+  - Same-origin policy
+  - Security
+  - URL
+  - origin
+  - secure
+translation_of: Web/Security/Same-origin_policy
+---
+<div>{{QuickLinksWithSubpages("/ja/docs/Web/Security")}}</div>
+
+<p><span class="seoSummary"><strong>同一オリジンポリシー</strong>とは、あるオリジンから読み込まれた文書やスクリプトについて、そのリソースから他のオリジンのリソースにアクセスできないように制限するものです。</span>同一オリジンポリシーはウェブのセキュリティにおける重要な仕組みであり、悪意ある行動を起こしかねないリソースの分離を目的としています。</p>
+
+<h2 id="Definition_of_an_origin" name="Definition_of_an_origin">オリジンの定義</h2>
+
+<p>二つのページの{{Glossary("protocol", "プロトコル")}}、{{Glossary("port", "ポート番号")}} (もしあれば)、{{Glossary("host", "ホスト")}}が等しい場合、両者のページは同じオリジンです。これは「スキーム/ホスト/ポート番号のタプル」または時に単に「タプル」として参照されます (「タプル」は共に全体を構成する三つの部分の組み合わせを表します)。</p>
+
+<p>以下の表は、各行の URL が <code>http://store.company.com/dir/page.html</code> と同じオリジンであるかを比較したものです。</p>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th>URL</th>
+   <th>結果</th>
+   <th>理由</th>
+  </tr>
+  <tr>
+   <td><code>http://store.company.com/dir2/other.html</code></td>
+   <td>同一オリジン</td>
+   <td>パスだけが異なる</td>
+  </tr>
+  <tr>
+   <td><code>http://store.company.com/dir/inner/another.html</code></td>
+   <td>同一オリジン</td>
+   <td>パスだけが異なる</td>
+  </tr>
+  <tr>
+   <td><code>https://store.company.com/page.html</code></td>
+   <td>不一致</td>
+   <td>プロトコルが異なる</td>
+  </tr>
+  <tr>
+   <td><code>http://store.company.com:81/dir/page.html</code></td>
+   <td>不一致</td>
+   <td>ポート番号が異なる (<code>http://</code> は既定で80番ポート)</td>
+  </tr>
+  <tr>
+   <td><code>http://news.company.com/dir/page.html</code></td>
+   <td>不一致</td>
+   <td>ホストが異なる</td>
+  </tr>
+ </tbody>
+</table>
+
+<h3 id="Inherited_origins" name="Inherited_origins">オリジンの継承</h3>
+
+<p> <code>about:blank</code> や <code>javascript:</code> の URL のページから実行されたスクリプトは、その URL にオリジンのサーバーについての情報が明示的に含まれていないため、その URL を開いた文書のオリジンを継承します。</p>
+
+<div class="note">
+<p>例えば、 <code>about:blank</code> は (例えば {{domxref("Window.open()")}} メカニズムを使用して) 新しい空のポップアップウィンドウを生成し、その中に親スクリプトがコンテンツを書き込むために使用されます。ポップアップウィンドウにもコードが含まれた場合、そのコードはそれを生成したスクリプトと同じオリジンを継承します。
+</p></div>
+
+<div class="warning">
+<p><code>data:</code> の URL は新しく、空のセキュリティコンテキストを生成します。</p>
+</div>
+
+<h3 id="Exceptions_in_Internet_Explorer" name="Exceptions_in_Internet_Explorer">IE における例外事項</h3>
+
+<p>Internet Explorer では、同一オリジンポリシーについて二つの大きな例外があります。</p>
+
+<dl>
+ <dt>信頼済みゾーン</dt>
+ <dd>双方のドメインが<em>高く信頼されたゾーン</em> (企業のドメインなど) である場合は、同一オリジンの制限が適用されません。</dd>
+ <dt>ポート番号</dt>
+ <dd>IE は同一オリジンの確認要素にポート番号を含みません。従って、 <code>http://company.com:81/index.html</code> と <code>http://company.com/index.html</code> は同一オリジンとみなされ、制限は適用されません。</dd>
+</dl>
+
+<p>これらの例外事項は標準外であり、他のブラウザーはこのような挙動に対応していません。</p>
+
+<h2 id="Changing_origin" name="Changing_origin">オリジンの変更</h2>
+
+<p>ページのオリジンは、いくつかの制限の下で変更されることがあります。スクリプトを用いると、 {{domxref("document.domain")}} の値を現在のドメインまたは上位ドメインに変更できます。スクリプトによって現在のドメインの上位ドメインへオリジンが変更された場合、より短くなったドメイン名は次回のオリジン検査時に用いられます。</p>
+
+<p>例えば、 <code>http://store.company.com/dir/other.html</code> にあるドキュメント内のスクリプトが以下のコードを実行したと仮定します。</p>
+
+<pre class="brush: js notranslate">document.domain = "company.com";
+</pre>
+
+<p>このコードが実行された後、そのページは <code>http://company.com/dir/page.html</code> におけるオリジンの検査を通過できます (許可を明示するために <code>http://company.com/dir/page.html</code> が自身の <code>document.domain</code> を "<code>company.com</code>" に変更したと仮定します。詳しくは {{domxref("document.domain")}} を参照してください)。しかし、 <code>company.com</code> <code>が自身の</code><code>document.domain</code> を <code>othercompany.com</code> に変更することは<strong>できません</strong>。なぜなら <code>company.com</code> の上位ドメインではないためです。</p>
+
+<p>ブラウザーはポート番号を個別に検査します。 <code>document.domain</code> を呼び出すと、 <code>document.domain = document.domain</code> の場合も含め、ポート番号が <code>null</code> で上書きされます。従って、スクリプトの最初に <code>document.domain = "company.com"</code> を設定しただけでは、 <code>company.com:8080</code> と <code>company.com</code> とは互いにアクセス<strong>できません</strong>。双方のポートが <code>null</code> になるように、双方で設定しなければなりません。</p>
+
+<div class="note">
+<p><strong>注:</strong> サブドメインから安全に親ドメインへアクセスさせるために <code>document.domain</code> を使用する際は、親ドメインとサブドメインの双方で同じ値を <code>document.domain</code> に設定することが必要です。この作業は、単に親ドメインを元の値に戻す際にも必要です。これを怠ると権限エラーが発生します。</p>
+</div>
+
+<h2 id="Cross-origin_network_access" name="Cross-origin_network_access">異なるオリジンへのネットワークアクセス</h2>
+
+<p>{{domxref("XMLHttpRequest")}} や {{htmlelement("img")}} 要素を使用する場合など、 同一オリジンポリシーは 2 つのオリジン間における通信を制御します。一般にこれらの通信は 3 つのカテゴリに分類されます。</p>
+
+<ul>
+ <li>異なるオリジンへの<em>書き込み</em>は、概して許可されます。例えばリンクやリダイレクト、フォームの送信などがあります。まれに使用される HTTP リクエストの際は<a href="/ja/docs/Web/HTTP/CORS#Preflighted_requests">プリフライト</a>が必要です。</li>
+ <li>異なるオリジンの<em>埋め込み</em>は、概して許可されます。例は後述します。</li>
+ <li>異なるオリジンからの<em>読み込み</em>は一般に許可されませんが、埋め込みによって読み取り権限がしばしば漏れてしまいます。例えば埋め込み画像の幅や高さ、埋め込みスクリプトの動作内容、あるいは<a class="external" href="https://bugzilla.mozilla.org/show_bug.cgi?id=629094">埋め込みリソースでアクセス可能なもの</a>を読み取ることができます。</li>
+</ul>
+
+<p>以下に挙げるのは、異なるオリジンに埋め込むことができるリソースの例です。</p>
+
+<ul>
+ <li>JavaScript を <code>&lt;script src="..."&gt;&lt;/script&gt;</code> で使用する場合。構文に関するエラーメッセージは、同一オリジンのスクリプトについてのみ読み取り可能です。</li>
+ <li>CSS を <code>&lt;link rel="stylesheet" href="..."&gt;</code> で使用する場合。 CSS は<a class="external" href="https://scarybeastsecurity.blogspot.com/2009/12/generic-cross-browser-cross-domain.html">緩い構文規則</a>を持っているため、オリジンをまたぐ CSS には適切な <code>Content-Type</code> ヘッダーを付加することが必要です。制約はブラウザーにより異なり、ブラウザーごとの詳細は <a class="external" href="https://docs.microsoft.com/en-us/previous-versions/windows/internet-explorer/ie-developer/compatibility/gg622939(v=vs.85)?redirectedfrom=MSDN">Internet Explorer</a>, <a class="external" href="https://www.mozilla.org/en-US/security/advisories/mfsa2010-46/">Firefox</a>, <a class="external" href="https://bugs.chromium.org/p/chromium/issues/detail?id=9877">Chrome</a>, <a class="external" href="https://support.apple.com/kb/HT4070">Safari</a> (<a class="external" href="http://support.apple.com/kb/HT4070?viewlocale=ja_JP">日本語訳</a>) (CVE-2010-0051 までスクロールしてください), <a class="external" href="https://security.opera.com/cross-domain-data-theft-with-css-load-opera-security-advisories/">Opera</a> の各項目を参照してください。</li>
+ <li>画像を {{htmlelement("img")}} で使用する場合。サポートされる画像形式は PNG、JPEG、GIF、BMP、SVG などです。</li>
+ <li>メディアファイルを {{htmlelement("video")}} および {{htmlelement("audio")}} で使用する場合。</li>
+ <li>外部リソースを {{htmlelement("object")}} または {{htmlelement("embed")}} で埋め込む場合。</li>
+ <li>フォントを {{cssxref("@font-face")}} で指定する場合。異なるオリジンのフォントを許可するブラウザーもありますが、フォントにも同一オリジンを要求するブラウザーもあります。</li>
+ <li>{{htmlelement("iframe")}} に関連するあらゆること。このような形のオリジン間のやりとりを防ぐため、サイトに {{HTTPHeader("X-Frame-Options")}} ヘッダーを使用することができます。</li>
+</ul>
+
+<h3 id="How_to_allow_cross-origin_access" name="How_to_allow_cross-origin_access">異なるオリジンへのアクセスを許可する方法</h3>
+
+<p>異なるオリジンへのアクセスを許可するには、 <a href="/ja/docs/Web/HTTP/CORS">CORS</a> を使用してください。 CORS は {{Glossary("HTTP")}} の一部で、サーバーがクライアントに、どのホストがそのサーバーからコンテンツを読み込むことが許可されているかを共有する機能です。</p>
+
+<h3 id="How_to_block_cross-origin_access" name="How_to_block_cross-origin_access">異なるオリジンへのアクセスをブロックする方法</h3>
+
+<ul>
+ <li>異なるオリジンへの書き込みを防ぐには、リクエスト内の a class="external" href="https://owasp.org/www-community/attacks/csrf"&gt;Cross-Site Request Forgery (CSRF) トークンと呼ばれる推測できないトークンをチェックしてください。このトークンを知っているページのオリジンをまたがった読み込みを防ぎます。</li>
+ <li>異なるオリジンからのリソースの読み込みを防ぐには、そのリソースが埋め込まれないようにします。リソースの埋め込まれると情報が漏えいする場合があるため、多くの場合は埋め込みの抑止が必要になります。</li>
+ <li>異なるオリジンによる埋め込みを防ぐには、リソースの形式が先ほど述べたような埋め込み可能な形式だと思われないようにします。ほとんどの場合、ブラウザーは <code>Content-Type</code> を尊重しません。例えば <code>&lt;script&gt;</code> タグで HTML 文書を指した場合、ブラウザーは HTML を JavaScript としてパースしようとします。リソースがサイトの入口ではない場合は、埋め込みを抑止するため CSRF トークンも使用するとよいでしょう。</li>
+</ul>
+
+<h2 id="Cross-origin_script_API_access" name="Cross-origin_script_API_access">異なるオリジンへのスクリプトからの API によるアクセス</h2>
+
+<p>{{domxref("HTMLIFrameElement.contentWindow", "iframe.contentWindow")}}, {{domxref("window.parent")}}, {{domxref("window.open")}}, {{domxref("window.opener")}} といった JavaScript API を用いると、ドキュメントが直接互いに参照することができます。2 つのドキュメントが同一のオリジンではない場合、 {{domxref("Window")}} オブジェクトや {{domxref("Location")}} オブジェクトなど、限られたオブジェクトにのみアクセスすることができます。詳しくは次の 2 つのセクションで説明します。</p>
+
+<p>{{domxref("window.postMessage")}} を使用すると、異なるオリジンの文書間における通信がさらに可能となります。</p>
+
+<p>仕様書: <a class="external" href="https://html.spec.whatwg.org/multipage/browsers.html#cross-origin-objects">HTML Living Standard § Cross-origin objects</a>.</p>
+
+<h3 id="Window" name="Window">Window</h3>
+
+<p>以下に示した <code>Window</code> のプロパティは、異なるオリジンからのアクセスが許可されています。</p>
+
+<table class="fullwidth-table standard-table">
+ <thead>
+  <tr>
+   <th scope="col">メソッド</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{domxref("window.blur")}}</td>
+  </tr>
+  <tr>
+   <td>{{domxref("window.close")}}</td>
+  </tr>
+  <tr>
+   <td>{{domxref("window.focus")}}</td>
+  </tr>
+  <tr>
+   <td>{{domxref("window.postMessage")}}</td>
+  </tr>
+ </tbody>
+</table>
+
+<table class="fullwidth-table standard-table">
+ <thead>
+  <tr>
+   <th scope="col">属性</th>
+   <th scope="col"></th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{domxref("window.closed")}}</td>
+   <td>読み取り専用</td>
+  </tr>
+  <tr>
+   <td>{{domxref("window.frames")}}</td>
+   <td>読み取り専用</td>
+  </tr>
+  <tr>
+   <td>{{domxref("window.length")}}</td>
+   <td>読み取り専用</td>
+  </tr>
+  <tr>
+   <td>{{domxref("window.location")}}</td>
+   <td>読み取り/書き込み</td>
+  </tr>
+  <tr>
+   <td>{{domxref("window.opener")}}</td>
+   <td>読み取り専用</td>
+  </tr>
+  <tr>
+   <td>{{domxref("window.parent")}}</td>
+   <td>読み取り専用</td>
+  </tr>
+  <tr>
+   <td>{{domxref("window.self")}}</td>
+   <td>読み取り専用</td>
+  </tr>
+  <tr>
+   <td>{{domxref("window.top")}}</td>
+   <td>読み取り専用</td>
+  </tr>
+  <tr>
+   <td>{{domxref("window.window")}}</td>
+   <td>読み取り専用</td>
+  </tr>
+ </tbody>
+</table>
+
+<p>一部のブラウザーでは、仕様書で定められたものより多くのプロパティでアクセスが許可されています。</p>
+
+<h3 id="Location" name="Location">Location</h3>
+
+<p>以下に示した <code>Location</code> のプロパティは、異なるオリジンからのアクセスが許可されています。</p>
+
+<table class="fullwidth-table standard-table">
+ <thead>
+  <tr>
+   <th scope="col">メソッド</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{domxref("location.replace")}}</td>
+  </tr>
+ </tbody>
+</table>
+
+<table class="fullwidth-table standard-table">
+ <thead>
+  <tr>
+   <th scope="col">属性</th>
+   <th scope="col"></th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{domxref("URLUtils.href")}}</td>
+   <td>書き込みのみ</td>
+  </tr>
+ </tbody>
+</table>
+
+<p>一部のブラウザーでは、仕様書で定められたものより多くのプロパティでアクセスが許可されています。</p>
+
+<h2 id="Cross-origin_data_storage_access" name="Cross-origin_data_storage_access">オリジンをまたいだデータストレージアクセス</h2>
+
+<p><a href="/ja/docs/Web/API/Web_Storage_API">ウェブストレージ</a>や <a href="/ja/docs/Web/API/IndexedDB_API">IndexedDB</a> など、ブラウザー内部に保存されるデータへのアクセスは、オリジンによって権限が分かれています。それぞれのオリジンが個別にストレージを持ち、あるオリジンの JavaScript から別のオリジンに属するストレージを読み書きすることはできません。</p>
+
+<p>{{glossary("Cookie", "Cookie")}} におけるオリジンの定義は異なります。ページは自身のドメインまたは任意の親ドメイン (親ドメインが public suffix ではない場合に限る) 用の Cookie を設定できます。 ドメインが public suffix であるかを判断する際、Firefox と Chrome は <a class="external" href="https://publicsuffix.org/">Public Suffix List</a> を使用します。 Internet Explorer は独自の方法で public suffix であるかを判断します。使用しているスキーム (HTTP/HTTPS) やポートに関係なく、ブラウザーはサブドメインも含めて Cookie を使用可能にします。Cookie の設定時に <code>Domain</code>, <code>Path</code>, <code>Secure</code>, <code>HttpOnly</code> の各フラグを用いることで、その Cookie の利用範囲を制限できます。Cookie を読み取るとき、Cookie を設定した場所から知ることはできません。安全な https 接続のみ使用していたとしても、参照している Cookie は安全でない接続を通じて設定された可能性があります。</p>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li><a href="https://www.w3.org/Security/wiki/Same_Origin_Policy">Same Origin Policy at W3C</a></li>
+ <li><a href="https://web.dev/secure/same-origin-policy">Same-origin policy at web.dev</a></li>
+</ul>
+
+<div class="originaldocinfo">
+<h2 id="Original_Document_Information" name="Original_Document_Information">出典情報</h2>
+
+<ul>
+ <li>著者: Jesse Ruderman</li>
+</ul>
+</div>
diff --git a/files/ja/web/security/secure_contexts/features_restricted_to_secure_contexts/index.html b/files/ja/web/security/secure_contexts/features_restricted_to_secure_contexts/index.html
new file mode 100644
index 0000000000..8eb04d2a59
--- /dev/null
+++ b/files/ja/web/security/secure_contexts/features_restricted_to_secure_contexts/index.html
@@ -0,0 +1,236 @@
+---
+title: 安全なコンテキストに制限されている機能
+slug: Web/Security/Secure_Contexts/features_restricted_to_secure_contexts
+tags:
+  - API
+  - Browsers
+  - Reference
+  - Secure contexts
+  - Security
+  - Web
+  - features
+  - support
+  - セキュリティ
+  - ブラウザー
+  - 安全なコンテキスト
+translation_of: Web/Security/Secure_Contexts/features_restricted_to_secure_contexts
+---
+<p>このリファレンスは、安全なコンテキストでのみ使用できるウェブプラットフォーム機能の一覧です — 定義や詳細については、<a href="/ja/docs/Web/Security/Secure_Contexts">安全なコンテキスト</a>を参照してください。</p>
+
+<h2 id="Current_features_available_only_in_secure_contexts" name="Current_features_available_only_in_secure_contexts">安全なコンテキストでのみ使用できる現在の機能</h2>
+
+<p>この節では、安全なコンテキストでのみ利用できる API の一覧を、制限が導入されたブラウザーのバージョンと共に示します。</p>
+
+<div class="note">
+<p><strong>メモ</strong>: 実際に安全なコンテキストに対応しているブラウザーのみ表示しています。安全なコンテキストの対応の詳細は<a href="/ja/docs/Web/Security/Secure_Contexts#Browser_compatibility">こちらをご覧ください</a>。</p>
+</div>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">API</th>
+   <th scope="col">Chrome/Opera</th>
+   <th scope="col">Edge</th>
+   <th scope="col">Safari</th>
+   <th scope="col">Firefox</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td><a href="/ja/docs/Web/API/Clipboard">Async Clipboard API</a></td>
+   <td>66</td>
+   <td>対応なし</td>
+   <td>対応なし</td>
+   <td>63</td>
+  </tr>
+  <tr>
+   <td><a href="https://wicg.github.io/BackgroundSync/spec/">Background Sync</a> (例えば {{domxref("SyncManager")}} を参照)</td>
+   <td>49</td>
+   <td>対応なし</td>
+   <td>対応なし</td>
+   <td>対応なし</td>
+  </tr>
+  <tr>
+   <td><a href="/ja/docs/Web/HTTP/Headers/Cache-Control"><code>Cache-Control: immutable</code></a></td>
+   <td>対応なし</td>
+   <td>15</td>
+   <td>11</td>
+   <td>49</td>
+  </tr>
+  <tr>
+   <td><a href="/ja/docs/Web/API/Credential_Management_API">Credential Management API</a></td>
+   <td>51</td>
+   <td>対応なし</td>
+   <td>対応なし</td>
+   <td>対応なし</td>
+  </tr>
+  <tr>
+   <td><a href="https://w3c.github.io/sensors/">Generic Sensor API</a></td>
+   <td>67</td>
+   <td>対応なし</td>
+   <td>対応なし</td>
+   <td>対応なし</td>
+  </tr>
+  <tr>
+   <td><a href="/ja/docs/Web/API/Payment_Request_API">Payment Request API</a> (および <a href="https://w3c.github.io/payment-method-basic-card/">Basic Card Payment</a>)</td>
+   <td>61</td>
+   <td><a href="https://blogs.windows.com/msedgedev/2017/04/11/introducing-edgehtml-15/">15</a></td>
+   <td><a href="https://webkit.org/blog/8182/introducing-the-payment-request-api-for-apple-pay/">11.1</a></td>
+   <td>開発中 (<code>dom.payments.request.enabled</code> の設定で隠蔽)。</td>
+  </tr>
+  <tr>
+   <td><a href="/ja/docs/Web/API/Push_API">プッシュ API</a></td>
+   <td>42</td>
+   <td><a href="https://blogs.windows.com/msedgedev/2017/12/19/service-workers-going-beyond-page/">17</a></td>
+   <td>対応なし</td>
+   <td>44</td>
+  </tr>
+  <tr>
+   <td><a href="/ja/docs/Web/API/Reporting_API">Reporting API</a></td>
+   <td>対応あり</td>
+   <td>対応なし</td>
+   <td>対応なし</td>
+   <td>Firefox 65 以降はフラグで隠ぺい</td>
+  </tr>
+  <tr>
+   <td><a href="/ja/docs/Web/API/Service_Worker_API">サービスワーカー</a></td>
+   <td>40</td>
+   <td><a href="https://blogs.windows.com/msedgedev/2017/12/19/service-workers-going-beyond-page/">17</a></td>
+   <td><a href="https://webkit.org/blog/8216/new-webkit-features-in-safari-11-1/">11.1</a></td>
+   <td>44</td>
+  </tr>
+  <tr>
+   <td><a href="/ja/docs/Web/API/Storage_API">Storage API</a></td>
+   <td>55</td>
+   <td>対応なし</td>
+   <td>対応なし</td>
+   <td>51</td>
+  </tr>
+  <tr>
+   <td><a href="/ja/docs/Web/API/Web_Authentication_API">Web Authentication API</a></td>
+   <td>65</td>
+   <td><a href="https://blogs.windows.com/msedgedev/2018/07/30/introducing-web-authentication-microsoft-edge/">In preview (17)</a></td>
+   <td><a href="https://bugs.webkit.org/show_bug.cgi?id=181943">開発中</a></td>
+   <td>60</td>
+  </tr>
+  <tr>
+   <td><a href="/ja/docs/Web/API/Web_Bluetooth_API">Web Bluetooth</a></td>
+   <td>56</td>
+   <td>対応なし</td>
+   <td>対応なし</td>
+   <td>対応なし</td>
+  </tr>
+  <tr>
+   <td><a href="https://webaudio.github.io/web-midi-api/">Web MIDI</a> (たとえば、 {{domxref("MIDIAccess")}} を参照)</td>
+   <td>43</td>
+   <td>対応なし</td>
+   <td>対応なし</td>
+   <td>対応なし</td>
+  </tr>
+  <tr>
+   <td><a href="/ja/docs/Web/API/Web_Crypto_API">Web Crypto API </a></td>
+   <td>60</td>
+   <td>79</td>
+   <td>対応なし</td>
+   <td>75</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Secure_context_restrictions_that_vary_by_browser" name="Secure_context_restrictions_that_vary_by_browser">ブラウザー独自の安全なコンテキストの制限</h2>
+
+<p>ブラウザーによっては、仕様書の要件になくても、特定の API を安全ではないコンテキストでは無効にしたり、その他の制限やセキュリティ要件を課したりしていることがあります。この節では、ブラウザーによって違いがあるものの一覧を示しています。</p>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th>API</th>
+   <th>Chrome</th>
+   <th>Edge</th>
+   <th>Safari</th>
+   <th>Firefox</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td><a href="/ja/docs/Web/HTML/Using_the_application_cache">Application Cache</a></td>
+   <td><a href="https://bugs.chromium.org/p/chromium/issues/detail?id=588931#c19">Chrome 70 で安全なコンテキストに限定することを計画中</a></td>
+   <td><a href="https://twitter.com/patrickkettner/status/961999450016239616">2018年2月に非推奨化の検討が開始</a></td>
+   <td><a href="https://twitter.com/johnwilander/status/959423900470800384">非推奨化に対する一般の関心</a> {{webkitbug(182442)}}</td>
+   <td><a href="https://www.fxsitecompat.com/en-CA/docs/2018/application-cache-can-no-longer-be-used-on-insecure-sites/">Firefox 62 で安全なコンテキストに限定</a></td>
+  </tr>
+  <tr>
+   <td>{{domxref("Geolocation")}}</td>
+   <td><a href="https://developers.google.com/web/updates/2016/04/geolocation-on-secure-contexts-only">50で安全なコンテキストに限定</a></td>
+   <td></td>
+   <td>10で安全なコンテキストに限定</td>
+   <td><a href="https://www.fxsitecompat.com/en-CA/docs/2017/use-of-geolocation-api-is-now-limited-to-secure-sites/">55で安全なコンテキストに限定</a></td>
+  </tr>
+  <tr>
+   <td><a href="/ja/docs/Web/API/Detecting_device_orientation">Device Orientaion / Device Motion</a></td>
+   <td>非推奨の警告</td>
+   <td></td>
+   <td></td>
+   <td><a href="https://www.fxsitecompat.com/en-CA/docs/2018/various-device-sensor-apis-are-now-deprecated/">60から非推奨の警告</a>。なお、これは安全なコンテキストでも同様に適用されます。</td>
+  </tr>
+  <tr>
+   <td><a href="/ja/docs/Web/API/Encrypted_Media_Extensions_API">Encrypted Media Extensions</a></td>
+   <td><a href="https://developers.google.com/web/updates/2017/03/chrome-58-deprecations#remove_eme_from_non-secure_contexts">58で安全なコンテキストに限定</a></td>
+   <td></td>
+   <td></td>
+   <td><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1322517">計画中</a>。</td>
+  </tr>
+  <tr>
+   <td><a href="/ja/docs/Web/API/MediaDevices/getUserMedia">getUserMedia()</a></td>
+   <td><a href="https://codereview.chromium.org/1336633002">Chrome 47 以降、安全なコンテキストに限定</a></td>
+   <td></td>
+   <td></td>
+   <td>一時的なアクセスのみ可能 (ユーザーは許可ダイアログで "この設定を記憶する" を選べない)。</td>
+  </tr>
+  <tr>
+   <td><a href="/ja/docs/Web/API/Notifications_API">Notifications</a></td>
+   <td><a href="https://developers.google.com/web/updates/2017/09/chrome-62-deprecations#remove_usage_of_notifications_from_insecure_iframes">Chrome 62 で安全なコンテキストに限定</a></td>
+   <td></td>
+   <td></td>
+   <td><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1429432">Firefox 67 で安全なコンテキストに限定</a></td>
+  </tr>
+  <tr>
+   <td><a href="/ja/docs/Web/HTML/Element/a#attr-ping">&lt;a ping&gt; 属性</a></td>
+   <td></td>
+   <td>安全でないコンテキストでは無効</td>
+   <td></td>
+   <td>Firefox 3 で対応が追加、但し既定では有効化されていない (<code>browser.send_pings</code> の設定で隠蔽)。</td>
+  </tr>
+  <tr>
+   <td><a href="/ja/docs/Web/API/Presentation_API">Presentation</a></td>
+   <td><a href="https://developers.google.com/web/updates/2017/08/chrome-61-deprecations#deprecate_and_remove_presentation_api_on_insecure_contexts">61 で非推奨の警告</a></td>
+   <td></td>
+   <td></td>
+   <td></td>
+  </tr>
+  <tr>
+   <td><a href="/ja/docs/Web/API/Web_Crypto_API">Web Crypto API</a></td>
+   <td>早期から HTTPS に限定 (API は HTTP で見えたが、操作には失敗した)。 <a href="https://developers.google.com/web/updates/2017/06/chrome-60-deprecations#cryptosubtle_now_requires_a_secure_origin">Chrome 60 で安全なコンテキストに限定</a> (API は安全ではないコンテキストから見えなくなった).</td>
+   <td></td>
+   <td></td>
+   <td><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1333140">計画中</a>。</td>
+  </tr>
+  <tr>
+   <td><a href="/ja/docs/Web/API/Navigator/registerProtocolHandler">registerProtocolHandler()</a></td>
+   <td></td>
+   <td></td>
+   <td></td>
+   <td><a href="https://www.fxsitecompat.com/en-CA/docs/2018/navigator-registerprotocolhandler-can-no-longer-be-used-on-insecure-sites/">Firefox 62 で安全なコンテキストに限定</a>。</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li><a href="/ja/docs/Web/Security/Secure_Contexts">安全なコンテキスト</a></li>
+ <li><a href="https://www.fxsitecompat.dev/en-CA/categories/privacy-security/">Privacy &amp; Security section on Firefox Site Compatibility</a></li>
+ <li><a href="https://www.chromestatus.com/features#secure%20context">"secure context" query on Chrome Platform Status</a></li>
+</ul>
+
+<div>{{QuickLinksWithSubpages("/ja/docs/Web/Security")}}</div>
diff --git a/files/ja/web/security/secure_contexts/index.html b/files/ja/web/security/secure_contexts/index.html
new file mode 100644
index 0000000000..8c6576066a
--- /dev/null
+++ b/files/ja/web/security/secure_contexts/index.html
@@ -0,0 +1,77 @@
+---
+title: 安全なコンテキスト
+slug: Web/Security/Secure_Contexts
+tags:
+  - Secure contexts
+  - Security
+  - セキュリティ
+  - 安全なコンテキスト
+translation_of: Web/Security/Secure_Contexts
+---
+<p><span class="seoSummary"><strong>セキュアコンテキスト</strong>とは、認証と機密性の一定の最低基準を満たしている <code>Window</code> や <code>Worker</code> のことです。</span>多くの Web API や機能は安全なコンテキストでのみアクセス可能です。セキュアコンテキストの主な目的は、{{interwiki("wikipedia", "中間者攻撃", "中間者攻撃")}} が攻撃の犠牲者をさらに危険にさらす可能性のある強力な API にアクセスすることを防ぐことです。</p>
+
+<h2 id="Why_should_some_features_be_restricted" name="Why_should_some_features_be_restricted">機能をアクセス制限すべき理由</h2>
+
+<p>Web の API には強力なものもあり、攻撃者に対して以下のような (それよりも多くの) 能力を与えてしまう可能性があります。</p>
+
+<ul>
+ <li>ユーザーのプライバシーを侵害する</li>
+ <li>ユーザーのコンピューターに対して低水準のアクセス権限を得る</li>
+ <li>ユーザーの認証情報のようなデータへのアクセス権限を得る</li>
+</ul>
+
+<h2 id="When_is_a_context_considered_secure" name="When_is_a_context_considered_secure">コンテキストが安全とみなされるのはいつですか？</h2>
+
+<p>コンテキストは、<a href="https://w3c.github.io/webappsec-secure-contexts/">Secure Contexts</a> 仕様で定義されている認証および機密性の一定の最低基準を満たしている場合に、セキュアなコンテキストとみなされます。特定の文書がセキュアコンテキストである<a href="https://html.spec.whatwg.org/multipage/browsers.html#top-level-browsing-context">トップレベルのブラウジングコンテキスト</a> (基本的には、セキュアコンテキストであるウィンドウやタブを含むコンテキスト) の<a href="https://html.spec.whatwg.org/multipage/browsers.html#active-document">アクティブな文書</a>である場合、その文書はセキュアコンテキストにあるとみなされます。</p>
+
+<p>例えば、{{HTMLElement("iframe")}} 内で TLS 上で配信された文書であっても、TLS 上で配信されなかった祖先がある場合には、そのコンテキストは安全であるとは見なされ<strong>ません</strong>。</p>
+
+<p>しかし、安全ではないコンテキストによって (<a href="/ja/docs/Web/API/Window/open#noopener">noopener</a> を指定してもしなくても) 新しいウィンドウが作成された場合、 オープナーが安全ではないという事実は、新しいウィンドウが安全であるとみなされるかどうかに影響を与えないことに注意してください。これは、特定の文書が安全なコンテキストにあるかどうかの判断は、それが関連付けられているトップレベルのブラウジングコンテキスト内でそれを考慮することにのみ基づいており、安全でないコンテキストがたまたまその文書を作成するために使用されたかどうかではないからです。</p>
+
+<p><em>http://127.0.0.1</em> の URL、<em>http://localhost</em> の URL (一定の条件の下で)、<em>file://</em> の URL など、ローカルに配信されたリソースも安全に配信されていると考えられます。</p>
+
+<p>ローカルではないリソースが安全であるとみなされるためには、以下の基準を満たす必要があります。</p>
+
+<ul>
+ <li><em>https://</em> または <em>wss://</em> URL で提供されなければなりません</li>
+ <li>リソースを配信するために使用されるネットワークチャネルのセキュリティプロパティは、非推奨と見なされてはなりません</li>
+</ul>
+
+<h2 id="Feature_detection" name="Feature_detection">機能の判別</h2>
+
+<p>グローバルスコープで利用できる {{domxref("WindowOrWorkerGlobalScope.isSecureContext", "isSecureContext")}} の真偽値を用いることで、そのページ自身が安全なコンテキストの中にいるかどうか確かめることができます。</p>
+
+<pre class="brush: js notranslate">if (window.isSecureContext) {
+  // Service Worker が実行されているので、このページは安全なコンテキストです
+  navigator.serviceWorker.register("/offline-worker.js").then(function () {
+    ...
+  });
+}</pre>
+
+<h2 id="Specifications" name="Specifications">仕様</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">仕様書</th>
+   <th scope="col">状態</th>
+   <th scope="col">備考</th>
+  </tr>
+  <tr>
+   <td>{{SpecName('Secure Contexts')}}</td>
+   <td>{{Spec2('Secure Contexts')}}</td>
+   <td>編集者による草稿</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li><a href="/ja/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts">安全なコンテキストに制限されたプラットフォーム機能</a> — 安全なコンテキストでのみ使用できる機能のリスト</li>
+ <li>{{domxref("Window.isSecureContext")}}</li>
+ <li><a href="https://permission.site">https://permission.site</a> — HTTP と HTTPS を使用して、ブラウザーが使用している API のアクセス許可チェックを確認できるサイト。</li>
+ <li><a href="/ja/docs/Web/HTTP/Headers/Strict-Transport-Security">Strict-Transport-Security</a> HTTP ヘッダー</li>
+</ul>
+
+<div>{{QuickLinksWithSubpages("/ja/docs/Web/Security")}}</div>
diff --git a/files/ja/web/security/securing_your_site/index.html b/files/ja/web/security/securing_your_site/index.html
new file mode 100644
index 0000000000..8d375d18b7
--- /dev/null
+++ b/files/ja/web/security/securing_your_site/index.html
@@ -0,0 +1,54 @@
+---
+title: サイトの安全化
+slug: Web/Security/Securing_your_site
+tags:
+  - HTTP
+  - Security
+  - Web Development
+  - Website Security
+translation_of: Web/Security/Securing_your_site
+---
+<div>{{ draft() }}</div>
+
+<p>サイトをより安全にする方法はいくつもあります。この記事はその方法を紹介するとともに他のより有益な記事へのリンクを掲載しています。</p>
+
+<div class="note"><strong>メモ:</strong> この記事は作成途中であり、以下の事項に従うことによりあなたのサイトが完全にセキュアになることを保証するものではありません。</div>
+
+<h2 id="User_information_security" name="User_information_security">ユーザー情報のセキュリティ</h2>
+
+<dl>
+ <dt><a href="/ja/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion">フォームオートコンプリートを無効にするには</a></dt>
+ <dd>Geckoではフォームのオートコンプリートがサポートされています。つまり、ユーザがフォームに入力した値を記憶し、次回訪問時には自動的にその値が入力されることになります。ある特定のデータに関しては、この機能を無効にしたほうが適切かもしれません。</dd>
+ <dt><a href="/ja/CSS/Privacy_and_the_:visited_selector" title="ja/CSS/Privacy and the :visited selector">プライバシーと :visited セレクター</a></dt>
+ <dd>この記事では悪質なサイトがユーザーの閲覧履歴を取得できないようにするために <code>getComputedStyle()</code> メソッドに加えられた変更について議論しています。</dd>
+ <dt><a href="https://www.owasp.org/index.php/Password_Storage_Cheat_Sheet">安全なアルゴリズムを使用したパスワードのハッシュ</a> (OWASP)</dt>
+ <dd>プレーンテキストでパスワードを格納すると、攻撃者がサイトのユーザーの正確なパスワードを知り、漏洩させることにつながり、ユーザーを危険にさらすことになります。古く安全ではないハッシュアルゴリズム (md5 など) を使用すると、同じ問題が浮上します。メッセージダイジェストアルゴリズム (md5 や sha) ではなくパスワード専用のハッシュアルゴリズム (Argon2, PBKDF2, scrypt, bcrypt など) を使用するようにしてください。この記事はパスワードを格納するときに使用することができるベストプラクティスのショーケースです。</dd>
+</dl>
+
+<h2 id="コンテンツセキュリティ">コンテンツセキュリティ</h2>
+
+<dl>
+ <dt><a href="/ja/docs/Web/Security/Securing_your_site/Configuring_server_MIME_types" title="ja/docs/Web/Security/Securing_your_site/Configuring_server_MIME_types">サーバーの MIME タイプを正しく設定する</a></dt>
+ <dd>MIME タイプを正しく設定しないと、幾つかの潜在的なセキュリティ上の問題が発生します。この記事ではそのうちのいくつかを紹介し、サーバーで MIME タイプを正しく設定する方法を示します。</dd>
+ <dt><a href="/ja/docs/Web/Security/HTTP_Strict_Transport_Security">HTTP Strict Transport Security</a></dt>
+ <dd><code>Strict-Transport-Security:</code> <a href="/ja/HTTP" title="ja/HTTP">HTTP</a> ヘッダーを使うと、そのサイトが HTTPS でのみアクセスされるべきであるということを示すことができます。</dd>
+ <dt><a href="/ja/docs/Web/HTTP/CORS">HTTP アクセス制御</a></dt>
+ <dd>Cross-Origin Resource Sharing 標準はどのコンテンツが他のドメインから読み込まれるかを示す方法を提供します。この仕組みによりあなたのサイトが意図せず使われることを防いだり、明示的に使用を許可できます。</dd>
+ <dt><a href="/ja/docs/Web/Security/CSP">Content Security Policy</a></dt>
+ <dd>{{Glossary("Cross-site_scripting", "クロスサイトスクリプティング (XSS)")}} やデータインジェクション攻撃を含む、特定の攻撃を検知したり軽減したりすることができる追加のセキュリティレイヤーです。これらの攻撃は、データの窃盗からサイトの改ざんやマルウェアの配布まで、あらゆることに利用されます。コードは被害者によって実行され、攻撃者がアクセス制御をバイパスしたり、成りすまししたりすることができるようになります。 Open Web Application Security Project によれば、 XSS は2017年に<a class="external external-icon" href="https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf" rel="noopener">よくあるウェブアプリの脆弱性の第7位</a>でした。</dd>
+ <dt><a href="/ja/docs/Web/HTTP/X-Frame-Options">X-Frame-Options レスポンスヘッダー</a></dt>
+ <dd>
+ <p><code>X-Frame-Options:</code> <a href="/ja/HTTP">HTTP</a> レスポンスヘッダーはページを {{ HTMLElement("frame") }} 内に描画して良いかどうかを示すために使われます。これを使うことにより、自身のサイトが他のサイトに埋め込まれていないことを保証できるため、クリックジャッキングを防ぐことができます。</p>
+ </dd>
+ <dt>ウェブサイトの構成によるアクセス制御</dt>
+ <dd>これはサイトを安全にするのに最良の方法です。 IP アドレスのブラックリスト、ウェブサイトの特定の領域へのアクセス制御、様々なファイルの保護、画像のホットリンクの防止、その他多数です。例えば、 <a href="https://httpd.apache.org/">Apache HTTP Server</a> でホスティングされているウェブサイトでは .htaccess ファイルが使用されます。</dd>
+</dl>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li><a class="external" href="https://www.owasp.org/">Open Web Application Security Project (OWASP)</a></li>
+ <li><a href="https://infosec.mozilla.org/guidelines/web_security/en-US/docs/">Mozilla Web Security Cheat Sheet</a></li>
+</ul>
+
+<div>{{QuickLinksWithSubpages("/ja/docs/Web/Security")}}</div>
diff --git a/files/ja/web/security/securing_your_site/turning_off_form_autocompletion/index.html b/files/ja/web/security/securing_your_site/turning_off_form_autocompletion/index.html
new file mode 100644
index 0000000000..642f8b3317
--- /dev/null
+++ b/files/ja/web/security/securing_your_site/turning_off_form_autocompletion/index.html
@@ -0,0 +1,74 @@
+---
+title: フォームの自動補完を無効にするには
+slug: Web/Security/Securing_your_site/Turning_off_form_autocompletion
+tags:
+  - Forms
+  - Guide
+  - Security
+  - Web Development
+  - ウェブ開発
+  - セキュリティ
+  - フォーム
+translation_of: Web/Security/Securing_your_site/Turning_off_form_autocompletion
+---
+<p><span class="seoSummary">この記事では、フォーム入力欄の自動補完をウェブサイト側から無効にする方法を説明します。</span></p>
+
+<p>既定では、ウェブサイト上の {{HTMLElement("input")}} 欄を通じてユーザーが送信した情報はブラウザーによって記憶されます。これよってブラウザーは、自動補完 (入力を受けた入力欄の補完候補をユーザーに提示する機能) や、オートフィル (読み込まれた入力欄をあらかじめブラウザーが補完する機能) を実現しています。</p>
+
+<p>これらの機能は通常は既定で有効ですが、ユーザーのプライバシーにかかわる可能性があるため、ブラウザーは無効にすることができます。しかしながら、フォームで送信される情報の中には将来利用する価値のないもの (ワンタイムパスワードなど) や、機微な情報 (公的な識別番号やクレジットカード番号など) があります。ブラウザーの自動補完機能が有効であっても、ウェブサイトの作者としては、そのような入力欄の値をブラウザーに記憶させないほうが適切かもしれません。</p>
+
+<p>自動補完を無効にすると、 <a href="https://www.w3.org/WAI/WCAG21/Understanding/identify-input-purpose.html">WCAG 2.1 の 1.3.5: Identify Input Purpose</a> の規則を<strong>破る</strong>ことになることを知っておくことが重要です。 WCAG に従うウェブサイトを制作するのであれば、自動的に記入する自動補完を使用するべきです。</p>
+
+<h2 id="Disabling_autocompletion" name="Disabling_autocompletion">自動補完の無効化</h2>
+
+<p>フォームにおける自動補完を無効にするには、 <code><a href="/ja/docs/Web/HTML/Attributes/autocomplete">autocomplete</a></code> 属性に "off" を指定することで実現できます。</p>
+
+<pre class="brush: html notranslate">autocomplete="off"</pre>
+
+<p>上記の設定はフォーム全体に適用することも、特定の input 要素に指定することも可能です。</p>
+
+<pre class="brush: html notranslate">&lt;form method="post" action="/form" autocomplete="off"&gt;
+[…]
+&lt;/form&gt;</pre>
+
+<pre class="brush: html notranslate">&lt;form method="post" action="/form"&gt;
+  […]
+  &lt;div&gt;
+    &lt;label for="cc"&gt;クレジットカード番号:&lt;/label&gt;
+    &lt;input type="text" id="cc" name="cc" autocomplete="off"&gt;
+  &lt;/div&gt;
+&lt;/form&gt;</pre>
+
+<p>入力欄に <code>autocomplete="off"</code> を指定すると、以下の 2 つの効果が生じます。</p>
+
+<ul>
+ <li>ブラウザーに対して、同様のフォームで自動補完を行うために、ユーザーが入力したデータを保存しないよう指示しますが、実際の動作はブラウザーによって異なります。</li>
+ <li>ブラウザーがフォームデータをセッション履歴にキャッシュしないようにします。フォームデータがセッション履歴にキャッシュされた後で、フォームの送信後に「戻る」ボタンで元のページに戻った際にユーザーの入力データが表示されます。</li>
+</ul>
+
+<p>autocomplete を off に設定してもブラウザーがサジェスト値を表示し続ける場合は、 input 要素の name 属性を変更する必要があります。</p>
+
+<h2 id="The_autocomplete_attribute_and_login_fields" name="The_autocomplete_attribute_and_login_fields">autocomplete 属性とログイン欄</h2>
+
+<p>現代的なブラウザーでは、パスワードを一括管理する機能が実装されています。ユーザーがウェブサイトでユーザー名とパスワードを入力した際、ブラウザーはその値を記憶するかユーザーに尋ねます。ユーザーがそのウェブサイトを再び訪れた際には、ログイン欄がブラウザーに保存された値で自動入力されます。</p>
+
+<p>加えて、ユーザーがマスターパスワードを設定すると、ログイン情報をマスターパスワードで暗号化した状態でブラウザーに保存することができます。</p>
+
+<p>マスターパスワードが用いられない場合でも、ブラウザーのパスワード管理機能は純粋にセキュリティの向上につながります。パスワードをブラウザーが保存すればユーザーは覚えなくてもよいため、覚えなければならない場合よりも強固なパスワードをユーザーが設定できるようになります。</p>
+
+<p>このような理由から、現代的なブラウザーの多くはログイン欄における <code>autocomplete="off"</code> に対応していません。</p>
+
+<ul>
+ <li>ウェブサイトが <code>autocomplete="off"</code> を {{HTMLElement("form")}} に設定しており、かつそのフォーム内にユーザー名とパスワードの入力欄が含まれていた場合、ブラウザーはログイン情報を記憶するか尋ねてきて、ユーザーが同意すれば、次回の訪問時にログイン欄を自動入力します。</li>
+ <li>ウェブサイトが <code>autocomplete="off"</code> をユーザー名とパスワードの {{HTMLElement("input")}} 欄に設定していた場合でも、ブラウザーはログイン情報を記憶するか尋ねてきて、ユーザーが同意すれば、次回の訪問時にログイン欄を自動入力します。</li>
+</ul>
+
+<p>この挙動は Firefox 38 以降、 Google Chrome 34 以降、 Internet Explorer 11 以降で共通です。</p>
+
+<h3 id="autocompletenew-password_による自動入力を抑止">autocomplete="new-password" による自動入力を抑止</h3>
+
+<p>他人のパスワードを指定するようなユーザー管理ページを定義していて、パスワード欄の自動入力を抑止したい場合は、 <code>autocomplete="new-password"</code> を使用することができます。</p>
+
+<p>これはヒントであり、ブラウザーは守る必要はありません。しかし、最近のブラウザーは <code>&lt;input&gt;</code> 要素に <code>autocomplete="new-password"</code> を設定すると自動入力を停止します。例えば、 Firefox バージョン 67 ({{bug(1119063)}} を参照) はこの場合に自動入力を停止していましたが、 Firefox 70 ({{bug(1565407)}} を参照) は安全に生成されたパスワードを提案することができるものの、保存されたパスワードを自動入力しません。詳しくは <a href="/ja/docs/Web/HTML/Attributes/autocomplete#Browser_compatibility"><code>autocomplete</code> 互換性テーブル</a>を参照してください。</p>
+
+<p>{{QuickLinksWithSubpages("/ja/docs/Web/Security")}}</p>
diff --git a/files/ja/web/security/site_identity_button/index.html b/files/ja/web/security/site_identity_button/index.html
new file mode 100644
index 0000000000..5f28d27ac4
--- /dev/null
+++ b/files/ja/web/security/site_identity_button/index.html
@@ -0,0 +1,29 @@
+---
+title: サイト認証ボタン
+slug: Web/Security/Site_Identity_Button
+tags:
+  - Security
+  - Web
+translation_of: Mozilla/Firefox/Site_identity_button
+---
+<p><span class="seoSummary">Firefox における機能の一つに<a href="https://support.mozilla.org/kb/how-do-i-tell-if-my-connection-is-secure">サイト認証ボタン</a>があります。このボタンによって、ユーザーは自分が閲覧しているウェブサイトに関する詳しい情報を知ることができます。</span></p>
+
+<p>ウェブサイトの設定によって、このボタンは何種類ものアイコンで表示されることがあります。</p>
+
+<p>サイト認証ボタンの表示が期待と異なる場合 (緑色の錠前を期待したのに、黄色の警告の三角形が表示されるなど)、Firefox の開発ツール内にある<a href="/ja/docs/Tools/Web_Console">ウェブコンソール</a>を確認すれば、問題の原因を探ることができます。</p>
+
+<ol>
+ <li>ウェブコンソールで「セキュリティ」カテゴリの出力が有効になっていることを確認します。</li>
+ <li>問題が生じているウェブページを再読み込みします。</li>
+ <li>セキュリティに関係するメッセージが表示されます。</li>
+</ol>
+
+<p>サイト認証ボタンが低評価を示す場合、以下の 3 つが原因として考えられます。</p>
+
+<ul>
+ <li>混在コンテンツ - ウェブページが TLS で提供れているにもかかわらず、いくつかのサブリソースが TLS で読み込まれていない状態です。この場合、ウェブコンソールには「混在コンテンツ」と表示されるはずです。</li>
+ <li>弱い暗号方式の使用 - TLS は利用しているものの、十分な強度を持つ暗号が使用されていない状態です。弱い暗号 (例 RC4) についてのメッセージを探してください。</li>
+ <li>安全ではない再ネゴシエーション - 古いバージョンの TLS には仕様自体に欠陥が存在します。運用しているサーバーが該当するバージョンの TLS を利用していた場合、サイト認証ボタンによる評価は下がりますが、ウェブコンソールにメッセージは表示されません。</li>
+</ul>
+
+<p>{{QuickLinksWithSubpages("/ja/docs/Web/Security")}}</p>
diff --git a/files/ja/web/security/subdomain_takeovers/index.html b/files/ja/web/security/subdomain_takeovers/index.html
new file mode 100644
index 0000000000..be1c1e9b66
--- /dev/null
+++ b/files/ja/web/security/subdomain_takeovers/index.html
@@ -0,0 +1,60 @@
+---
+title: Subdomain takeovers
+slug: Web/Security/Subdomain_takeovers
+translation_of: Web/Security/Subdomain_takeovers
+---
+<p>subdomain takeover は、攻撃者がターゲットドメインのサブドメインの制御権を獲得したときに発生します。一般的には、サブドメインがドメインネームシステム (<a href="https://wiki.developer.mozilla.org/en-US/docs/Glossary/DNS">DNS</a>) に正規名 (<a href="https://en.wikipedia.org/wiki/CNAME_record">CNAME</a>) を持っているが、そのサブドメインにコンテンツを提供しているホストがいない場合に発生します。これは、バーチャルホストがまだ公開されていないか、バーチャルホストが削除されているために起こる可能性があります。攻撃者は、自分のバーチャルホストを提供して、そのサブドメインのコンテンツをホストすることで、そのサブドメインを乗っ取ることができます。</p>
+
+<p>攻撃者がこれを行うことができれば、メインドメインから設定された<a href="/ja/docs/Web/HTTP/Cookies">クッキー</a>を読み取ったり、<a href="/ja/docs/Web/Security/Types_of_attacks#Cross-site_scripting_XSS">クロスサイトスクリプティング</a>を行ったり、<a href="/ja/docs/Web/HTTP/CSP">コンテンツセキュリティポリシー</a>を回避したりすることが可能となり、保護された情報 (ログインを含む) を取得したり、不審なユーザーに悪意のあるコンテンツを送信したりすることが可能となります。</p>
+
+<p>サブドメインはコンセントのようなものです。自分のアプライアンス (ホスト) をコンセントに差し込んでおけば、すべてが問題ありません。しかし、あなたがコンセントから自分のアプライアンスを取り外すと (またはまだコンセントを差し込んでいない場合)、誰かが別のアプライアンスを差し込んでしまう可能性があります。コンセントが他の人に使われるのを防ぐためには、ブレーカーやヒューズボックス (DNS) で電源を切る必要があります。</p>
+
+<h2 id="どのようにして起こるのでしょうか？">どのようにして起こるのでしょうか？</h2>
+
+<p>バーチャルホストのプロビジョニングやデプロビジョニング (削除) のプロセスが適切に処理されていない場合、攻撃者がサブドメインを乗っ取る機会がある可能性があります。</p>
+
+<h3 id="プロビジョニング時">プロビジョニング時</h3>
+
+<p>攻撃者は、ホスティングプロバイダで購入したサブドメイン名の仮想ホストを先に設定します。</p>
+
+<p>あなたがドメイン example.com を管理しているとします。あなたは blog.example.com にブログを追加したいと思っていて、あなたはブログプラットフォームを維持しているホスティングプロバイダを使用することにしました。(「ブログ」は、「電子商取引プラットフォーム」や「顧客サービスプラットフォーム」、あるいは他の「クラウドベース」の仮想ホスティング・シナリオでも代用可能です)。あなたが通過するプロセスは、次のように見えるかもしれません。</p>
+
+<ol>
+ <li>ドメインレジストラに "blog.example.com" という名前を登録します</li>
+ <li>blog.example.com にアクセスしたいブラウザをバーチャルホストに誘導するために DNS レコードを設定します</li>
+ <li>ホスティングプロバイダでバーチャルホストを作成します</li>
+</ol>
+
+<p>ホスティングプロバイダが、バーチャルホストを設定したエンティティが実際にサブドメイン名の所有者であることを確認するように細心の注意を払わない限り、あなたよりも手っ取り早い攻撃者が、あなたのサブドメイン名を使って、同じホスティングプロバイダでバーチャルホストを作成することができます。このような場合、ステップ2で DNS を設定するとすぐに、攻撃者はあなたのサブドメイン上でコンテンツをホストすることができます。</p>
+
+<h3 id="デプロビジョニング時">デプロビジョニング時</h3>
+
+<p>あなたはバーチャルホストを削除したが、攻撃者は同じ名前とホスティングプロバイダを使用して新しいバーチャルホストをセットアップすることがあります。</p>
+
+<p>あなた (またはあなたの会社) はもうブログを維持したくないと判断したので、ホスティングプロバイダからバーチャルホストを削除します。しかし、ホスティングプロバイダを指す DNS エントリを削除しなければ、攻撃者はそのプロバイダで独自のバーチャルホストを作成し、あなたのサブドメインを主張し、そのサブドメインの下で独自のコンテンツをホストすることができるようになります。</p>
+
+<h2 id="どうすれば防げるのでしょうか？">どうすれば防げるのでしょうか？</h2>
+
+<p>サブドメインの乗っ取りを防ぐことは、バーチャルホストや DNS のライフサイクル管理における業務の順序の問題です。組織の規模にもよりますが、これには複数の部署間でのコミュニケーションと調整が必要となり、脆弱性のある誤設定の可能性が高まるだけです。</p>
+
+<ul>
+ <li>ホストのプロビジョニングとデプロビジョニングの標準プロセスを定義します。すべての手順を可能な限り密接に行います
+  <ul>
+   <li>バーチャルホストを主張してプロビジョニングを開始し、<em>最後に</em> DNS レコードを作成します</li>
+   <li><em>最初に</em> DNS レコードを削除してデプロビジョニングを開始します</li>
+  </ul>
+ </li>
+ <li>組織のすべてのドメインとそのホスティングプロバイダのインベントリを作成し、変化に応じて更新することで、何もぶら下がったままにならないようにします</li>
+ <li>バーチャルホストを主張する人が実際にドメイン名への正当な主張を持っていることをどのように検証するのかを尋ねてください。あなたの組織内での作業は、ベンダーの資格プロセスの一部にするためです</li>
+</ul>
+
+<h2 id="サブドメインが乗っ取られてしまいました。どうすればいいですか？">サブドメインが乗っ取られてしまいました。どうすればいいですか？</h2>
+
+<p>ドメインのサブドメインが乗っ取られているのを発見した場合、可能であれば、最初のステップは、サブドメインの DNS エントリを削除して「電力をカット」することです。サイトに仮想化の複数のレイヤー (例えば、仮想ホスティングに加えて <a href="/ja/docs/Glossary/CDN">CDN</a>) がある場合、攻撃者がどこで仮想ホストの主張を主張してドメインを乗っ取ったのかを確認するために、各レイヤーを調べる必要があるかもしれません。</p>
+
+<h2 id="詳細はこちら">詳細はこちら</h2>
+
+<ul>
+ <li><a href="https://blog.rubidus.com/2017/02/03/deep-thoughts-on-subdomain-takeovers/">'Deep Thoughts' on Subdomain Takeover Vulnerabilities</a></li>
+ <li><a href="https://0xpatrik.com/subdomain-takeover-basics/">Subdomain Takeover: Basics</a></li>
+</ul>
diff --git a/files/ja/web/security/subresource_integrity/index.html b/files/ja/web/security/subresource_integrity/index.html
new file mode 100644
index 0000000000..e16794fea6
--- /dev/null
+++ b/files/ja/web/security/subresource_integrity/index.html
@@ -0,0 +1,150 @@
+---
+title: サブリソース完全性
+slug: Web/Security/Subresource_Integrity
+tags:
+  - HTML
+  - HTTP
+  - Intro
+  - Networking
+  - セキュリティ
+translation_of: Web/Security/Subresource_Integrity
+---
+<p><span class="seoSummary"><ruby><strong>サブリソース完全性</strong><rp> (</rp><rt>Subresource Integrity</rt><rp>)</rp></ruby> (SRI) は、 ({{Glossary("CDN")}} などから) 取得したリソースが意図せず改ざんされていないかをブラウザーが検証するセキュリティ機能です。 SRI を利用する際には、取得したリソースのハッシュ値と一致すべきハッシュ値を指定します。</span></p>
+
+<div class="note">
+<p><strong>メモ</strong>: サブリソース完全性の検証において、サブリソースが埋め込まれる文書のオリジン以外から提供されたリソースについては、ブラウザーは<a href="/ja/docs/Web/HTTP/CORS">オリジン間リソース共有 (CORS)</a> を使用してリソースに追加のチェックを行い、オリジンがリソースがリクエストしたオリジンに共有されることを許可しているかどうかを確認します。</p>
+</div>
+
+<h2 id="How_Subresource_Integrity_helps" name="How_Subresource_Integrity_helps">サブリソース完全性の必要性</h2>
+
+<p>複数のサイトで使われるスクリプトやスタイルシートなどのファイルを{{Glossary("CDN", "コンテンツ配信ネットワーク (CDN)")}} にホストすることにより、読み込みに必要な時間や通信帯域を減らすことができます。しかし、 CDN はリスクにもなり得ます。仮に攻撃者が CDN を掌握できれば、攻撃者は CDN 上のファイルに悪意あるコンテンツを挿入することにより (あるいは完全に置き換えることにより)、その CDN からファイルを読み込む全てのサイトを攻撃対象とすることができます。</p>
+
+<p>サブリソース完全性は、ウェブアプリケーションやウェブ文書が (CDN など任意の場所から) 取得したファイルについて、第三者によってファイルの中に別のものが挿入されていないか、そして、それらのファイルに対してその他の改ざんが行われていないかを検証することにより、先程のような攻撃のリスクを軽減します。</p>
+
+<h2 id="Using_Subresource_Integrity" name="Using_Subresource_Integrity">サブリソース完全性の使い方</h2>
+
+<p>サブリソース完全性の機能は、ブラウザーが取得するリソース (ファイル) のハッシュ値を base64 エンコードし、その値を {{HTMLElement("script")}} や {{HTMLElement("link")}} 要素の <code>integrity</code> 属性に指定することによって使用します。</p>
+
+<p><code>integrity</code> 属性の値は、ハッシュアルゴリズムを示す接頭辞 (現在利用できる接頭辞は <code>sha256</code>, <code>sha384</code>, <code>sha512</code> です) と、 base64 でエンコードされたハッシュ値をダッシュで繋いだ文字列です。</p>
+
+<div class="note">
+<p><strong>メモ</strong>: <code>integrity</code> 属性値には、ホワイトスペースで区切って複数のハッシュ値を含めることができます。リソースはこれらのハッシュ値のいずれかに一致した場合に読み込まれます。</p>
+</div>
+
+<p>base64 でエンコードされた sha384 ハッシュを含む <code>integrity</code> 文字列の例</p>
+
+<pre class="notranslate">sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC
+</pre>
+
+<p>従って、 <code>oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC</code> がハッシュ値の部分であり、接頭辞の <code>sha384</code> が sha384 ハッシュであることを示します。</p>
+
+<div class="note">
+<p><strong>メモ</strong>: 厳密に言うと、 <code>integrity</code> 属性値におけるハッシュ値の部分は、あるハッシュ関数にデータを入力 (スクリプトやスタイルシートファイル) して生成された<strong>暗号学的ダイジェスト値</strong>です。しかし、一般的には短く「ハッシュ」と言えば<em>暗号学的ダイジェスト値</em>を意味するので、本記事でもそのように呼んでいます。</p>
+</div>
+
+<h3 id="Tools_for_generating_SRI_hashes" name="Tools_for_generating_SRI_hashes">SRI ハッシュを生成するツール</h3>
+
+<p>次の <strong>openssl</strong> コマンドにより SRI ハッシュを生成することができます。</p>
+
+<pre class="brush: bash notranslate">cat <strong>FILENAME.js</strong> | openssl dgst -sha384 -binary | openssl base64 -A</pre>
+
+<p>または、次のような <strong>shasum</strong> コマンドの呼び出しでも実現できます。</p>
+
+<pre class="brush: bash notranslate">shasum -b -a 384 <strong>FILENAME.js</strong> | awk '{ print $1 }' | xxd -r -p | base64
+</pre>
+
+<div class="note">
+<p><strong>メモ</strong>:</p>
+
+<ul>
+ <li>パイプで <code>xxd</code> を通る過程で、 <code>shasum</code> からの出力を取り、バイナリへ変換します。</li>
+ <li>パイプで <code>awk</code> を通る過程は、 <code>shasum</code> がハッシュ化されたファイル名を <code>xxd</code> へ渡すために必要です。ファイル名が有効な16進数の文字を持っている場合に有害な影響を与える可能性があるからです。 <code>xxd</code> はそれを復号して、 <code>base64</code> に渡す可能性があるからです。</li>
+</ul>
+</div>
+
+<p>また、<strong>SRI Hash Generator</strong> (<a href="https://www.srihash.org/">https://www.srihash.org/</a>) によりオンラインで SRI ハッシュを生成することもできます。</p>
+
+<h3 id="Cross-Origin_Resource_Sharing_and_Subresource_Integrity" name="Cross-Origin_Resource_Sharing_and_Subresource_Integrity">オリジン間リソース共有とサブリソース完全性</h3>
+
+<p>サブリソース完全性の検証において、サブリソースが埋め込まれる文書のオリジン以外から提供されたリソースについては、ブラウザーは<a href="/ja/docs/Web/HTTP/CORS">オリジン間リソース共有 (CORS)</a> を使用してリソースに追加のチェックを行い、オリジンがリソースがリクエストしたオリジンに共有されることを許可しているかどうかを確認します。従って、次の例のように、リソースが要求されたオリジンに共有できるよう {{httpheader("Access-Control-Allow-Origin")}} ヘッダーを付けて提供する必要があります。</p>
+
+<pre class="notranslate">Access-Control-Allow-Origin: *</pre>
+
+<h2 id="Examples" name="Examples">例</h2>
+
+<p>以下の例では、 <code id="sriSnippet">oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC</code> が特定のスクリプト <code>example-framework.js</code> の期待される SHA-384 ハッシュ値としてすでに知られており、スクリプトのコピーが <code>https://example.com/example-framework.js</code> にホストされているものとします。</p>
+
+<h3 id="Subresource_Integrity_with_the_&lt;script>_element" name="Subresource_Integrity_with_the_&lt;script>_element">&lt;script&gt; 要素のサブリソース完全性</h3>
+
+<p>次の {{HTMLElement("script")}} 要素により、ブラウザーが <code>https://example.com/example-framework.js</code> を実行する前に、まず想定されるハッシュ値とスクリプトのハッシュ値が一致することをブラウザーに確認させることができます。</p>
+
+<pre class="brush: html notranslate">&lt;script src="https://example.com/example-framework.js"
+        integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC"
+        crossorigin="anonymous"&gt;&lt;/script&gt;</pre>
+
+<div class="note">
+<p><strong>メモ</strong>: <strong>crossorigin</strong> 属性については <a href="/ja/docs/Web/HTML/CORS_settings_attributes">CORS 設定属性</a>を参照してください。</p>
+</div>
+
+<h2 id="How_browsers_handle_Subresource_Integrity" name="How_browsers_handle_Subresource_Integrity">サブリソース完全性のブラウザーでの扱い</h2>
+
+<p>ブラウザは SRI を以下のように処理します。</p>
+
+<p class="note"><strong>メモ</strong>: サブリソース完全性の検証において、サブリソースが埋め込まれる文書のオリジン以外から提供されたリソースについては、ブラウザーは<a href="/ja/docs/Web/HTTP/CORS">オリジン間リソース共有 (CORS)</a> を使用してリソースに追加のチェックを行い、オリジンがリソースがリクエストしたオリジンに共有されることを許可しているかどうかを確認します。</p>
+
+<ol>
+ <li>
+  <p>ブラウザは <code>integrity</code> 属性を持った {{HTMLElement("script")}} または {{HTMLElement("link")}} 属性を見つけると、スクリプトや {{HTMLElement("link")}} 属性で指定された任意のスタイルシートを適用する前に、<code>integrity</code> 属性のハッシュ値とスクリプトやスタイルシートのハッシュ値を比較しなくてはなりません。</p>
+ </li>
+ <li>スクリプトやスタイルシートが対応する <code>integrity</code> 属性値と一致しない場合、ブラウザーはスクリプトを実行したりスタイルシートを適用してはいけません。その代わりに、スクリプトやスタイルシートの取得が失敗したというネットワークエラーを返さなくてはなりません。</li>
+</ol>
+
+<h2 id="Specifications" name="Specifications">仕様</h2>
+
+<table class="standard-table">
+ <thead>
+  <tr>
+   <th scope="col">仕様書</th>
+   <th scope="col">状態</th>
+   <th scope="col">備考</th>
+  </tr>
+ </thead>
+ <tbody>
+  <tr>
+   <td>{{SpecName('Subresource Integrity')}}</td>
+   <td>{{Spec2('Subresource Integrity')}}</td>
+   <td></td>
+  </tr>
+  <tr>
+   <td>{{SpecName('Fetch')}}</td>
+   <td>{{Spec2('Fetch')}}</td>
+   <td></td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser_compatibility" name="Browser_compatibility">ブラウザの互換性</h2>
+
+<h3 id="&lt;script_integrity>">&lt;script integrity&gt;</h3>
+
+<p class="hidden">このページの互換性一覧表は構造化データから生成されています。データに協力していただけるのであれば、 <a class="external" href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> をチェックアウトしてプルリクエストを送信してください。</p>
+
+<p>{{Compat("html.elements.script.integrity")}}</p>
+
+<h3 id="CSP_require-sri-for">CSP: require-sri-for</h3>
+
+<p class="hidden">このページの互換性一覧表は構造化データから生成されています。データに協力していただけるのであれば、 <a class="external" href="https://github.com/mdn/browser-compat-data">https://github.com/mdn/browser-compat-data</a> をチェックアウトしてプルリクエストを送信してください。</p>
+
+<p>{{Compat("http.headers.csp.require-sri-for")}}</p>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li>Content Security Policy</li>
+ <li>{{httpheader("Content-Security-Policy")}}</li>
+ <li><a href="https://frederik-braun.com/using-subresource-integrity.html" id="page-title">A CDN that can not XSS you: Using Subresource Integrity</a></li>
+ <li><a href="https://w3c-test.org/subresource-integrity/subresource-integrity.html" id="w3c-test">Subresource Integrity test from W3C</a></li>
+ <li><a href="https://www.srihash.org/">SRI Hash Generator</a></li>
+</ul>
+
+<p>{{QuickLinksWithSubpages("/ja/docs/Web/Security")}}</p>
diff --git a/files/ja/web/security/transport_layer_security/index.html b/files/ja/web/security/transport_layer_security/index.html
new file mode 100644
index 0000000000..ee6b578afa
--- /dev/null
+++ b/files/ja/web/security/transport_layer_security/index.html
@@ -0,0 +1,124 @@
+---
+title: Transport Layer Security
+slug: Web/Security/Transport_Layer_Security
+tags:
+  - Cryptography
+  - Guide
+  - SSL
+  - Security
+  - TLS
+  - セキュリティ
+  - 暗号化
+  - 認証
+translation_of: Web/Security/Transport_Layer_Security
+---
+<p><span class="seoSummary">Transport Layer Security (TLS) を使用した接続のセキュリティは、選択されている暗号スイートとセキュリティ引数に強く依存します。この記事の目的は、クライアントとサーバの間の機密性と完全性の通信を確実にするために、選択の参考になることです。</span> Mozilla Operations Security (OpSec) チームは、サーバの設定項目のリファレンスが付いた<a href="https://wiki.mozilla.org/Security/Server_Side_TLS">ウィキ記事を管理しています</a>。</p>
+
+<p class="summary">Transport Layer Security (TLS) プロトコルは、ネットワークで結ばれた二つのアプリケーションや端末が、私的にかつ強固に情報交換するための標準です。 TLS を使用するアプリケーションは、セキュリティ引数を選択することができ、これは、データのセキュリティと信頼性に大きな影響を与える可能性があります。この記事では、 TLS の概要と、コンテンツを保護するために必要な決定の種類について説明します。</p>
+
+<h2 id="History" name="History">歴史</h2>
+
+<p>HTTPS が導入されたときは Secure Sockets Layer (SSL) 2.0 という、 Netscape がもたらした技術に基づいていました。その後で間もなく SSL 3.0 に更新され、用途が拡大し、Web ブラウザーとサーバの間の相互運用性を保証するために、共通で標準化された暗号化技術を規定することが必要になりました。 <a href="https://www.ietf.org/">Internet Engineering Task Force</a> (IETF) は TLS 1.0 を {{RFC(2246)}} で1999年1月に規定しました。 TLS の現在のバージョンは 1.3 ({{RFC(8446)}}) です。</p>
+
+<div class="note">
+<p>Web では暗号化に TLS を使用するようになったという事実に関わらず、多くの人々はまだ習慣的に "SSL" と呼んでいます。</p>
+</div>
+
+<p>TLS はどのような低水準のトランスポートプロトコルの上でも使用することができますが、このプロトコルの本来の目標は HTTP トラフィックを暗号化することでした。 HTTP を TLS で暗号化することは、一般に {{Glossary("HTTPS")}} と呼ばれています。暗号化されていない HTTP が既定で80番ポートを使用するのに対し、 TLS で暗号化されたWeb トラフィックは、慣習として既定で443番ポートで交わされます。 HTTPS は引き続き、 TLS の重要な用途です。</p>
+
+<h2 id="HTTP_over_TLS">HTTP over TLS</h2>
+
+<p>TLS は、それと交換されるデータの安全性とセキュリティを確保するための3つの主要なサービスを提供しています。</p>
+
+<dl>
+ <dt>認証</dt>
+ <dd>認証は、通信の各当事者が相手が自分の主張する人物であることを確認することを可能にします。</dd>
+ <dt>暗号化</dt>
+ <dd>データは、ユーザーエージェントとサーバの間で送信されている間は暗号化されており、権限のない者によって読み取られたり解釈されたりすることを防ぐことができます。</dd>
+ <dt>完全性</dt>
+ <dd>TLS は、データの暗号化から送信、復号化までの間に、情報の紛失、破損、改ざん、偽造がないことを保証します。</dd>
+</dl>
+
+<p>TLS 接続は、クライアントとサーバが共有シークレットに合意し、暗号スイートのような重要なパラメータがネゴシエートされるハンドシェイクフェーズから始まります。一旦、パラメータと HTTP などのアプリケーションデータが交換されるデータ交換モードになります。</p>
+
+<h3 id="Cipher_suites" name="Cipher_suites">暗号スイート</h3>
+
+<p>TLS のハンドシェイクがネゴシエートする主なパラメータは {{interwiki("wikipedia", "cipher suite")}} です。</p>
+
+<p>TLS 1.2 およびそれ以前のバージョンでは、ネゴシエートされた暗号スイートには、共有秘密のネゴシエート、サーバの認証手段、データの暗号化に使用される方法を提供する一連の暗号アルゴリズムが含まれています。</p>
+
+<p>TLS 1.3 の暗号化スイートは主にデータの暗号化を管理し、鍵の合意と認証には個別のネゴシエーション方法が使用されます。</p>
+
+<p>異なるソフトウェアでは、同じ暗号スイートに対して異なる名前を使用している場合があります。例えば、OpenSSL や GnuTLS で使われている名前は TLS 標準のものとは異なります。Mozilla OpSec チームの TLS 設定に関する記事の<a href="https://wiki.mozilla.org/Security/Server_Side_TLS#Cipher_names_correspondence_table">暗号名対応表</a>には、これらの名前と互換性やセキュリティレベルに関する情報が記載されています。</p>
+
+<h3 id="Configuring_your_server" name="Configuring_your_server">サーバの構築</h3>
+
+<p>サーバを正しく設定することは非常に重要です。一般的には、サイトに接続できるようにしたいブラウザと互換性のある、可能な限り最新の暗号をサポートするようにしてください。<a href="https://wiki.mozilla.org/Security/Server_Side_TLS">Mozilla OpSec ガイドの TLS 設定</a>では、推奨される設定についての詳細な情報を提供しています。</p>
+
+<p>サイトの設定を支援するために、Mozilla は以下の Web サーバ用の設定ファイルを生成する便利な <a href="https://mozilla.github.io/server-side-tls/ssl-config-generator/">TLS 設定ジェネレータ</a>を提供しています。</p>
+
+<ul>
+ <li>Apache</li>
+ <li>Nginx</li>
+ <li>Lighttpd</li>
+ <li>HAProxy</li>
+ <li>Amazon Web Services CloudFormation Elastic Load Balancer</li>
+</ul>
+
+<p>必要に応じて設定を作成するには、<a href="https://mozilla.github.io/server-side-tls/ssl-config-generator/">コンフィグレータ</a>を使用することをお勧めします。設定ファイルをコピーしてサーバ上の適切なファイルに貼り付け、サーバを再起動して変更を反映させます。設定ファイルにはカスタム設定を含めるための調整が必要な場合がありますので、使用する前に生成された設定を確認してください。ドメイン名などの参照が正しいことを確認せずに設定ファイルをインストールすると、サーバが動作しなくなります。</p>
+
+<h2 id="TLS_1.3">TLS 1.3</h2>
+
+<p>{{RFC("8446", "TLS 1.3")}} は、TLS のメジャーリビジョンです。TLS 1.3 には、セキュリティとパフォーマンスを向上させる多数の変更が含まれています。TLS 1.3 の目標は以下の通りです。</p>
+
+<ul>
+ <li>TLS 1.2 の未使用で安全でない機能を削除します</li>
+ <li>強力なセキュリティ分析を設計に含めます</li>
+ <li>プロトコルをより多く暗号化することで、プライバシーを向上させます</li>
+ <li>ハンドシェイクを完了するまでの時間を短縮します</li>
+</ul>
+
+<p>TLS 1.3 はプロトコルの基本的な部分の多くを変更していますが、以前のバージョンの TLS と同様に基本的な機能のほとんどすべてを保持しています。Web では、TLS 1.3 はいくつかのまれな例外を除いて、互換性に影響を与えることなく有効にすることができます (以下を参照)。</p>
+
+<p>TLS 1.3 の主な変更点は以下の通りです。</p>
+
+<ul>
+ <li>TLS 1.3 のハンドシェイクは、ほとんどの場合 1 回のラウンドトリップで完了し、ハンドシェイクの待ち時間を短縮します</li>
+ <li>サーバーは 0-RTT (ゼロラウンドトリップタイム) ハンドシェイクを有効にすることができます。サーバに再接続したクライアントはすぐにリクエストを送ることができ、TLS ハンドシェイクの待ち時間を完全に排除できます。0-RTT によるパフォーマンスの向上は大きなものですが、リプレイ攻撃のリスクもありますので、この機能を有効にする前には注意が必要です</li>
+ <li>TLS 1.3 は、接続が再開されるか、事前に共有された鍵を使用しない限り、フォワードセキュアモードのみをサポートしています</li>
+ <li>TLS 1.3 は、TLS 1.3 専用の新しい暗号スイートを定義しています。これらの暗号化スイートはすべて最新の Authenticated Encryption with Associated Data (AEAD) アルゴリズムを使用しています</li>
+ <li>TLS 1.3 のハンドシェイクは、共有シークレットを確立するために必要なメッセージを除き、暗号化されています。特に、これはサーバ証明書とクライアント証明書が暗号化されていることを意味します。ただし、クライアントがサーバに送信するサーバ ID (サーバ名または SNI 拡張子) は暗号化されないことに注意してください</li>
+ <li>数多くのメカニズムが無効化されています: リネゴシエーション、一般的なデータ圧縮、{{interwiki("wikipedia", "デジタル署名アルゴリズム")}}。(DSA) 証明書、静的 RSA 鍵交換、カスタム Diffie-Hellman (DH) グループとの鍵交換</li>
+</ul>
+
+<p>TLS 1.3 のドラフト版の実装が公開されています。TLS 1.3  は 0-RTT モードを含むいくつかのブラウザで有効になっています。TLS 1.3 を有効にしている Web サーバでは、TLS 1.3 が正常に動作するように設定を調整する必要があるかもしれません。</p>
+
+<p>TLS 1.3 では、重要な新しいユースケースが 1 つだけ追加されました。0-RTT ハンドシェイクは、Web のようなレイテンシに敏感なアプリケーションに大きなパフォーマンスの向上をもたらします。0-RTT を有効にするには、導入を確実に成功させ、リプレイ攻撃のリスクを管理するための追加のステップが必要です。</p>
+
+<p>TLS 1.3 でリネゴシエーションが削除されたことは、証明書を使ったクライアント認証に依存する一部の Web サーバに影響を与える可能性があります。一部の Web サーバは、クライアント証明書が暗号化されていることを確実にするため、あるいは特定のリソースが要求されたときにのみクライアント証明書を要求するために、リネゴシエーションを使用しています。クライアント証明書のプライバシーを守るために、TLS 1.3 ハンドシェイクの暗号化によってクライアント証明書の暗号化が確実に行われますが、これにはソフトウェアの変更が必要になるかもしれません。証明書を使ったリアクティブなクライアント認証は TLS 1.3 でサポートされていますが、広くは実装されていません。代替のメカニズムは現在開発中で、HTTP/2 もサポートする予定です。</p>
+
+<h2 id="Retiring_old_TLS_versions" name="Retiring_old_TLS_versions">古いバージョンの TLS の引退</h2>
+
+<p>よりモダンで安全な Web に向けての取り組みにより、2020 年第 1 四半期に TLS 1.0 および 1.1 のサポートがすべての主要ブラウザーから削除されます。 Web サーバが今後 TLS 1.2 または 1.3 をサポートすることを確認する必要があります。</p>
+
+<p>Firefox はバージョン 74 以降、古い TLS バージョンを使用してサーバに接続すると <a href="https://support.mozilla.org/en-US/kb/secure-connection-failed-firefox-did-not-connect">Secure Connection Failed</a> エラーを返します ({{bug(1606734)}}) 。</p>
+
+<h2 id="TLS_handshake_timeout_values" name="TLS_handshake_timeout_values">TLS ハンドシェイクタイムアウト値</h2>
+
+<p>何らかの理由で TLS ハンドシェイクが遅くなったり、反応しなくなったりすると、ユーザーの体験に大きな影響を与える可能性があります。この問題を軽減するために、最近のブラウザはハンドシェイクのタイムアウトを実装しています。</p>
+
+<ul>
+ <li>バージョン 58 以降、Firefox は TLS ハンドシェイクのタイムアウトをデフォルト値の 30 秒で実装しています。タイムアウトの値は、about:config の <code>network.http.tls-handshake-timeout</code> 設定値を編集することで変更できます</li>
+</ul>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li><a href="https://ssl-config.mozilla.org">Mozilla SSL Configuration Generator</a> および <a href="https://cipherli.st/">Cipherli.st</a> は、サーバがサイトの安全を確保するための構成ファイルを生成するのに役立つかもしれません。</li>
+ <li>Mozilla Operations Security (OpSec) チームは、 <a href="https://wiki.mozilla.org/Security/Server_Side_TLS">reference TLS configurations</a> の wiki ページを保守しています。</li>
+ <li><a href="https://observatory.mozilla.org/">Mozilla Observatory</a>, <a href="https://www.ssllabs.com/ssltest/">SSL Labs</a>, <a href="https://github.com/mozilla/cipherscan">Cipherscan</a> はサイトの TLS 構成がどれだけア年かを確認するテストに役立ちます。</li>
+ <li><a href="/ja/docs/Web/Security/Secure_Contexts">安全なコンテキスト</a></li>
+ <li><a href="/ja/docs/Web/HTTP/Headers/Strict-Transport-Security">Strict-Transport-Security</a> HTTP ヘッダー</li>
+</ul>
+
+<p>{{QuickLinksWithSubpages("/ja/docs/Web/Security")}}</p>
diff --git a/files/ja/web/security/types_of_attacks/index.html b/files/ja/web/security/types_of_attacks/index.html
new file mode 100644
index 0000000000..45edd24b04
--- /dev/null
+++ b/files/ja/web/security/types_of_attacks/index.html
@@ -0,0 +1,88 @@
+---
+title: 攻撃の種類
+slug: Web/Security/Types_of_attacks
+translation_of: Web/Security/Types_of_attacks
+---
+<p>{{draft}}</p>
+
+<p>この記事では、様々な種類のセキュリティ攻撃とそれを軽減するためのテクニックについて解説しています。</p>
+
+<h2 id="クリックジャッキング">クリックジャッキング</h2>
+
+<p>クリックジャッキングとは、ユーザーを騙して、ユーザーが思っているものとは別のリンクやボタンなどをクリックさせることです。これは、例えば、ログイン認証情報を盗んだり、マルウェアの一部をインストールするためにユーザーの無意識のうちに許可を得るために使用することができます。(クリックジャッキングは、「ユーザーインターフェースのリドレス」と呼ばれることもありますが、これは「リドレス」という用語の誤用です)。</p>
+
+<h2 id="クロスサイトリクエストフォージェリ_CSRF">クロスサイトリクエストフォージェリ (CSRF)</h2>
+
+<h2 id="クロスサイトスクリプティング_XSS">クロスサイトスクリプティング (XSS)</h2>
+
+<p>クロスサイトスクリプティング（XSS）は、攻撃者が悪意のあるクライアント側のコードをウェブサイトに注入することができるセキュリティエクスプロイトです。このコードは被害者によって実行され、攻撃者はアクセス制御を迂回したり、ユーザーになりすましたりすることができます。Open Web Application Security Project によると、XSS は2017年に<a href="https://owasp.org/images/7/72/OWASP_Top_10-2017_(en).pdf">7番目に多いWebアプリの脆弱性</a>だったという。</p>
+
+<p>これらの攻撃は、Web アプリが十分な検証やエンコーディングを採用していない場合に成功します。ユーザーのブラウザは、悪意のあるスクリプトが信頼できないものであることを検出できないため、クッキー、セッション トークン、またはその他のサイト固有の機密情報へのアクセスを許可したり、悪意のあるスクリプトに {{glossary("HTML")}} コンテンツを書き換えさせたりします。</p>
+
+<p>クロスサイトスクリプティング攻撃は、通常、1) 信頼されていないソース (多くの場合、Web リクエスト) を介して Web アプリにデータが入力されたり、2) 悪意のあるコンテンツが検証されずに動的なコンテンツが Web ユーザーに送信されたりした場合に発生します。</p>
+
+<p>悪意のあるコンテンツには、{{glossary("JavaScript")}} が含まれていることが多いですが、HTML、Flash、またはブラウザが実行できるその他のコードが含まれていることもあります。XSS に基づく攻撃の種類はほぼ無限にありますが、一般的には、クッキーなどのセッション情報などのプライベートデータを攻撃者に送信したり、攻撃者が管理するウェブページに被害者をリダイレクトさせたり、脆弱性のあるサイトを装ってユーザーのマシンに悪意のある操作を行ったりすることが多いです。</p>
+
+<p>XSS 攻撃は、蓄積型 (パーシステントとも呼ばれる)、反映型 (非パーシステントとも呼ばれる)、DOM ベースの3つに分類されます。</p>
+
+<dl>
+ <dt>格納された XSS 攻撃</dt>
+ <dd>注入されたスクリプトは、ターゲットのサーバーに永久に保存されます。そして、被害者は、ブラウザがデータの要求を送信すると、この悪意のあるスクリプトをサーバーから取得します。</dd>
+ <dt>反映された XSS 攻撃</dt>
+ <dd>ユーザーがだまされて悪意のあるリンクをクリックしたり、特別に細工されたフォームを送信したり、悪意のあるサイトを閲覧したりすると、注入されたコードは脆弱性のある Web サイトに移動します。Web サーバは、注入されたスクリプトを、エラーメッセージ、検索結果、またはリクエストの一部としてサーバに送信されたデータを含むその他の応答など、ユーザのブラウザに反映させます。ブラウザは、レスポンスがユーザーが既にやり取りしたことのある「信頼できる」サーバからのものであると想定しているため、コードを実行します。</dd>
+ <dt>DOM ベースの XSS 攻撃</dt>
+ <dd>ペイロードは、元のクライアントサイドスクリプトが使用していた DOM 環境 (被害者のブラウザ内) を変更した結果、実行されます。つまり、ページ自体は変わりませんが、DOM 環境を悪意を持って改変した結果、ページに含まれるクライアント側のコードが予期せぬ形で実行される。</dd>
+</dl>
+
+<p>Wikipedia には、CSRF の良い例が記載されています。この状況では、誰かが (例えば、フィルタリングされていないチャットやフォーラムで) 実際には画像ではない画像を含むが、その代わりに、それは本当にお金を引き出すためにあなたの銀行のサーバーへのリクエストです。</p>
+
+<pre class="brush: html notranslate">&lt;img src="https://bank.example.com/withdraw?account=bob&amp;amount=1000000&amp;for=mallory"&gt;</pre>
+
+<p>さて、あなたが銀行口座にログインしていて、クッキーがまだ有効であれば (他の検証はありません)、この画像を含む HTML を読み込むとすぐに送金されます。POST リクエストを必要とするエンドポイントでは、ページが読み込まれたときにプログラム的に &lt;form&gt; の送信をトリガーすることができます (おそらく不可視の &lt;iframe&gt; で)。</p>
+
+<pre class="brush: html notranslate">&lt;form action="https://bank.example.com/withdraw" method="POST"&gt;
+  &lt;input type="hidden" name="account" value="bob"&gt;
+  &lt;input type="hidden" name="amount" value="1000000"&gt;
+  &lt;input type="hidden" name="for" value="mallory"&gt;
+&lt;/form&gt;
+&lt;script&gt;window.addEventListener('DOMContentLoaded', (e) =&gt; { document.querySelector('form').submit(); }&lt;/script&gt;</pre>
+
+<p><br>
+ これを防ぐためには、いくつかのテクニックがあります。</p>
+
+<ul>
+ <li>GET エンドポイントは、変更を実行するアクションであって、単にデータを取得するだけのものではなく、POST (または他の HTTP メソッド) リクエストの送信を必要とするものでなければなりません。POST エンドポイントは、クエリ文字列内のパラメータを持つ GET リクエストを相互に受け入れてはいけません</li>
+ <li>CSRF トークンは、非表示の入力フィールドを経由して &lt;form&gt; 要素に含まれなければなりません。このトークンはユーザーごとに一意で、リクエストが送られたときにサーバーが期待値を調べることができるように、(たとえばクッキーに) 保存されるべきです。アクションを実行する可能性のあるすべての非 GET リクエストに対して、 この入力フィールドは期待値と比較されるべきです。不一致があった場合、リクエストは中止されるべきです</li>
+ <li>CSRF トークンを予測できないことに依存しています。トークンはサインイン時に再生成されなければなりません</li>
+ <li>機密性の高い動作 (セッションクッキーなど) に使用されるクッキーは、SameSite 属性を Strict または Lax に設定して、有効期限を短くする必要があります (上記の SameSite cookies を参照)。サポートしているブラウザでは、これはクロスサイトリクエストと一緒にセッションクッキーが送信されないようにする効果があり、そのリクエストはアプリケーションサーバに対して事実上認証されません</li>
+ <li>CSRF トークンと SameSite Cookie の両方を導入する必要があります。これにより、すべてのブラウザが保護され、SameSite のクッキーでは対応できない場合 (別のサブドメインからの攻撃など) にも保護されます</li>
+</ul>
+
+<p>より多くの予防のヒントについては、OWASP CSRF prevention チートシートを参照してください。</p>
+
+<h2 id="中間者攻撃_MitM">中間者攻撃 (MitM)</h2>
+
+<p>第三者がウェブサーバーとクライアント（ブラウザ）間のトラフィックを傍受し、ウェブサーバーになりすましてデータ（ログイン情報やクレジットカード情報など）を取得します。トラフィックは、場合によっては変更された状態で通過します。オープン WiFi ネットワークは、この攻撃を実行する一般的な手段です。</p>
+
+<h2 id="セッションハイジャック">セッションハイジャック</h2>
+
+<p>セッションハイジャックは、ユーザの認証されたセッションにアクセスして悪用することです。これは、既存のセッションのクッキーを盗んだり、ユーザ (またはブラウザ) を騙して、あらかじめ設定されたセッション ID のクッキーを設定させることで起こる可能性があります。</p>
+
+<p>厳密な Content-Security-Policy を展開することで、侵入経路を制限することができます。</p>
+
+<h3 id="セッションの固定">セッションの固定</h3>
+
+<p>第三者は、ユーザーのセッション識別子を判断することができ（つまり、読み取ったり、設定したりすることで）、そのユーザーとしてサーバーとやりとりをすることができます。クッキーを盗むことは、これを行う一つの方法です。</p>
+
+<p>application.example.com のようなサブドメインは、<code>Domain</code> 属性を設定することで、example.com や他のサブドメインへのリクエストと一緒に送信されるクッキーを設定できることを思い出してください。</p>
+
+<pre class="notranslate">Set-Cookie: CSRF=e8b667; Secure; Domain=example.com</pre>
+
+<p>脆弱性のあるアプリケーションがサブドメイン上で利用可能な場合、このメカニズムはセッション固定化攻撃で悪用される可能性があります。ユーザが親ドメイン(または別のサブドメイン)のページを訪問したとき、アプリケーションはユーザのクッキーで送られた既存の値を信頼するかもしれません。これにより、攻撃者は CSRF 保護を迂回したり、ユーザがログインした後にセッションを乗っ取ったりすることができます。<br>
+ あるいは、親ドメインが <code>includeSubdomains</code> が設定された <a href="/ja/docs/Glossary/HSTS">HTTP Strict-Transport-Security</a> を使用しない場合、アクティブな MitM の対象となるユーザ (おそらくオープンなWiFi ネットワークに接続されている) は、存在しないサブドメインからの Set-Cookie ヘッダを持つレスポンスを提供される可能性があります。ブラウザは違法なクッキーを保存し、example.com の下の他のすべてのページにそれを送信します。</p>
+
+<p>セッションの固定化は主に、ユーザが認証するときに (たとえクッキーがすでに存在していても) セッションクッキーの値を再生成し、 CSRF トークンをユーザに結びつけることによって緩和されるべきです。</p>
+
+<h3 id="セッションのサイドジャッキング">セッションのサイドジャッキング</h3>
+
+<h3 id="ブラウザハイジャックマルウェア">ブラウザハイジャックマルウェア</h3>
diff --git a/files/ja/web/security/weak_signature_algorithm/index.html b/files/ja/web/security/weak_signature_algorithm/index.html
new file mode 100644
index 0000000000..c66d35c30f
--- /dev/null
+++ b/files/ja/web/security/weak_signature_algorithm/index.html
@@ -0,0 +1,29 @@
+---
+title: 脆弱な署名アルゴリズム
+slug: Web/Security/Weak_Signature_Algorithm
+tags:
+  - Cryptography
+  - ウェブ
+  - ガイド
+  - セキュリティ
+translation_of: Web/Security/Weak_Signature_Algorithm
+---
+<p><span class="seoSummary">{{Glossary("Digital certificate", "ディジタル証明書")}}の{{Glossary("Signature/Security", "電子署名")}}に用いられるハッシュアルゴリズムの強度は、証明書のセキュリティにおいて核心的な要素です。この記事では、脆弱になったため、可能であれば避けるものと知られている署名アルゴリズムについて、いくらかの情報を提供します。</span></p>
+
+<p>ハッシュアルゴリズムの脆弱性は、攻撃者が偽の証明書を作成または取得してしまうような事態を招きます。新しい攻撃手法が発見や、利用可能な攻撃技術の進歩などのため、古いアルゴリズムを使用することは避けるべきであり、いつかは対応が削除されます。</p>
+
+<h2 id="SHA-1">SHA-1</h2>
+
+<p>SHA-1 の証明書は、2017年の初めから、多くのブラウザーの開発者が安全であるとはみなさなくなりました。より安全なハッシュアルゴリズム (SHA-256 や SHA-512 など) を代わりに使用してください。</p>
+
+<h2 id="MD5">MD5</h2>
+
+<p>MD5 による署名への対応は、2012年初めに削除されました。</p>
+
+<h2 id="See_also" name="See_also">関連情報</h2>
+
+<ul>
+ <li>SHA-1 の廃止に関する <a class="external" href="https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/">Mozilla Security Blog の記事</a> (参考: <a href="http://mozsec-jp.hatenablog.jp/entry/2015/10/22/111053">日本語訳</a>)</li>
+</ul>
+
+<p>{{QuickLinksWithSubpages("/ja/docs/Web/Security")}}</p>
author	Peter Bengtsson <mail@peterbe.com>	2020-12-08 14:40:17 -0500
committer	Peter Bengtsson <mail@peterbe.com>	2020-12-08 14:40:17 -0500
commit	33058f2b292b3a581333bdfb21b8f671898c5060 (patch)
tree	51c3e392513ec574331b2d3f85c394445ea803c6 /files/ja/web/security
parent	8b66d724f7caf0157093fb09cfec8fbd0c6ad50a (diff)
download	translated-content-33058f2b292b3a581333bdfb21b8f671898c5060.tar.gz translated-content-33058f2b292b3a581333bdfb21b8f671898c5060.tar.bz2 translated-content-33058f2b292b3a581333bdfb21b8f671898c5060.zip