initial commit

16 files changed, 1227 insertions, 0 deletions

diff --git a/files/zh-cn/web/security/csp/index.html b/files/zh-cn/web/security/csp/index.html
new file mode 100644
index 0000000000..de5f82e383
--- /dev/null
+++ b/files/zh-cn/web/security/csp/index.html
@@ -0,0 +1,35 @@
+---
+title: 内容安全策略 (CSP)
+slug: Web/Security/CSP
+translation_of: Web/HTTP/CSP
+---
+<div>{{gecko_minversion_header("2.0")}}</div>
+
+<p><b>内容安全策略</b> (CSP, Content Security Policy) 是一个附加的安全层，用于帮助检测和缓解某些类型的攻击，包括跨站脚本 (XSS) 和数据注入等攻击。 这些攻击可用于实现从数据窃取到网站破坏或作为恶意软件分发版本等用途。</p>
+
+<p>尽管内容安全策略在 Firefox 4 中已经包含，使用 <code>X-Content-Security-Policy</code> 头部来实现，但它使用的是过时的 CSP 标准。Firefox 23 包含了更新的 CSP 实现，使用的是 W3C CSP 1.0 标准中描述的没有前缀的 <code>Content-Security-Policy</code> 头部和指令。</p>
+
+<h2 id="内容安全策略主题">内容安全策略主题</h2>
+
+<dl>
+ <dt><a href="/zh-CN/docs/Security/CSP/Introducing_Content_Security_Policy">介绍内容安全策略</a></dt>
+ <dd>概述什么是 CSP，以及它如何让你的网站变得更安全。</dd>
+ <dt><a href="/zh-CN/docs/Security/CSP/CSP_policy_directives">CSP 策略指令</a></dt>
+ <dd>CSP 策略指令参考。</dd>
+ <dt><a href="/zh-CN/docs/Security/CSP/Using_Content_Security_Policy">使用内容安全策略</a></dt>
+ <dd>你可以通过配置策略集调整 CSP 的行为。这让你可以按需对个别类型的资源使用宽松或严格的安全策略。这篇文章讲述了如何建立 CSP 和如何激活你网站的 CSP。</dd>
+ <dt><a href="/zh-CN/docs/Security/CSP/Using_CSP_violation_reports">使用 CSP 违规报告</a></dt>
+ <dd>如何使用 CSP 违规报告来监视攻击你网站的尝试和攻击者。</dd>
+ <dt><a href="/zh-CN/docs/Security/CSP/Default_CSP_restrictions">默认 CSP 限制 </a>{{obsolete_inline("15.0")}}</dt>
+ <dd>CSP 强制实施的默认限制的细节</dd>
+</dl>
+
+<h2 id="另请参阅">另请参阅</h2>
+
+<ul>
+ <li><a href="/zh-CN/docs/Security">Security</a></li>
+ <li><a href="/zh-CN/docs/HTTP_access_control">HTTP access control</a></li>
+ <li><a class="link-https" href="http://www.w3.org/TR/CSP/">CSP 1.0 specification</a></li>
+ <li><a class="link-https" href="https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html">CSP 1.1 specification</a></li>
+ <li><a href="/docs/Apps/CSP">CSP restrictions for Open Web Apps</a></li>
+</ul>
diff --git a/files/zh-cn/web/security/csp/introducing_content_security_policy/index.html b/files/zh-cn/web/security/csp/introducing_content_security_policy/index.html
new file mode 100644
index 0000000000..f730c260c6
--- /dev/null
+++ b/files/zh-cn/web/security/csp/introducing_content_security_policy/index.html
@@ -0,0 +1,55 @@
+---
+title: 内容安全策略介绍
+slug: Web/Security/CSP/Introducing_Content_Security_Policy
+tags:
+  - 介绍
+  - 内容安全策略
+  - 安全
+translation_of: Web/HTTP/CSP
+---
+<p>{{ gecko_minversion_header("2") }}</p>
+
+<p><strong>内容安全策略</strong> (CSP)  是一个附加的安全层，用于帮助检测和缓解某些类型的攻击，包括跨站脚本 (XSS) 和数据注入等攻击。 这些攻击可用于实现从数据窃取到网站破坏或作为恶意软件分发版本等用途。</p>
+
+<p>CSP被设计成向后兼容；不支持的浏览器依然可以运行使用了它的服务器页面，反之亦然。不支持CSP的浏览器会忽略它，像平常一样运行，默认对网页内容使用标准的同源策略。如果网站不提供CSP头部，浏览器同样会使用标准的<a href="/zh-CN/docs/Same_origin_policy_for_JavaScript">同源策略</a>。</p>
+
+<p>开启CSP就如配置您的页面服务来返回<code>Content-Security-Policy</code> HTTP 头部一样简单. (Firefox 23之前的版本使用的是<code>X-Content-Security-Policy</code> ). 查看 <a href="/en/Security/CSP/Using_Content_Security_Policy" title="en/Security/CSP/Using Content Security Policy">Using Content Security Policy</a> 获取如何配置和开启CSP的细节</p>
+
+<div class="note"><strong>提示：</strong> 内容安全策略<a class="link-https" href="https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#meta-http-equiv--x-content-security-policy---html-element" title="https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#meta-http-equiv--x-content-security-policy---html-element">标准特点</a> 是一种能被 {{ HTMLElement("meta") }}元素来配置的一种协议，但这种做法仍未被Firefox支持， 支持这种做法是被添加在<a class="link-https" href="https://bugzilla.mozilla.org/show_bug.cgi?id=663570" title="https://bugzilla.mozilla.org/show_bug.cgi?id=663570">bug 663570</a>.</div>
+
+<h2 id="减少跨域脚本">减少跨域脚本</h2>
+
+<p>CSP的主要目标是减少和报告XSS攻击. XSS攻击利用浏览器对从服务器接受的内容的信任。恶意的脚本在受害的浏览器被执行, 因为浏览器相信内容源，甚至当内容源并不是从它应该来的地方过来的。</p>
+
+<p>CSP使服务器管理员能够通过制定浏览器能够执行的可信赖脚本的域名来减少或者消除由XSS可能出现的矢量。 一个兼容CSP的浏览器将只会执行加载与白名单域名的源文件的脚本，忽略那些其他的脚本（包括内联脚本和事件操控HTML属性）</p>
+
+<p>作为一种最终的保护，想要禁止脚本的站点可以选择全局禁止脚本执行</p>
+
+<h2 id="减少数据包监听攻击">减少数据包监听攻击</h2>
+
+<p>为了重新约束内容被下载的域名, 服务端能够制定那种协议能够被使用；例如（理论上，从安全的立足点来看），一个服务制定所有的内容都通过HTTPS协议来加载</p>
+
+<div class="note"><strong>提示：</strong>一个完整地数据传输安全策略不单单包括通HTTPS加强数据的传输，还可以使所有cookie带上安全标志并且提供从HTTP页面到对应HTTPS页面的自动重定向。</div>
+
+<div class="note"><strong>提示：</strong>站点可能也会使用 <a href="/en/Security/HTTP_Strict_Transport_Security" title="/en/Security/HTTP_Strict_Transport_Security">Strict-Transport-Security</a> HTTP头部来确保浏览器只通过一个加密渠道来连接他们</div>
+
+<h2 id="See_also">See also</h2>
+
+<ul>
+ <li><a href="/en/Security/CSP/Using_Content_Security_Policy" title="en/Security/CSP/Using Content Security Policy">Using Content Security Policy</a></li>
+ <li><a href="/en/Security/CSP/CSP_policy_directives" title="en/Security/CSP/CSP policy directives">CSP policy directives</a></li>
+ <li><a href="/en/Security/CSP/Using_CSP_violation_reports" title="en/Security/CSP/Using CSP violation reports">Using CSP violation reports</a></li>
+</ul>
+
+<h2 id="Specification">Specification</h2>
+
+<ul>
+ <li>{{ spec("https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/latest.html", "Content Security Policy 1.1 (Editor's Draft)") }}</li>
+ <li>{{ spec("http://www.w3.org/TR/CSP/", "Content Security Policy 1.0 (Candidate Recommendation)") }}</li>
+</ul>
+
+<div class="noinclude">
+<p>{{ languages( { "ja": "ja/Introducing_Content_Security_Policy" } ) }}</p>
+</div>
+
+<p> </p>
diff --git a/files/zh-cn/web/security/csp/using_csp_violation_reports/index.html b/files/zh-cn/web/security/csp/using_csp_violation_reports/index.html
new file mode 100644
index 0000000000..decd9db66f
--- /dev/null
+++ b/files/zh-cn/web/security/csp/using_csp_violation_reports/index.html
@@ -0,0 +1,96 @@
+---
+title: Using CSP violation reports
+slug: Web/Security/CSP/Using_CSP_violation_reports
+translation_of: Web/HTTP/CSP
+---
+<p>{{ gecko_minversion_header("2.0") }}{{ draft() }}</p>
+
+<p>CSP其中的一个强大的特性是它为web站点管理员提供了生成和报告详细的站点攻击的描述信息。这些报告通过HTTP的POST请求发送到预先你指定的一个或多个服务器上，这些服务器可以通过 <a href="/en/Security/CSP/CSP_policy_directives#report-uri" title="en/Security/CSP/CSP policy directives#report-uri"><code>report-uri</code></a> 策略来制定。发送的报告是JSON格式的，对于非ASCII字符，其使用了默认的JSON UTF-8编码。本文将向你展示如何在你的站点上配置报告，以及报告的格式。</p>
+
+<p>对于支持CSP的浏览器，只要你制定了合法的 <a href="/en/Security/CSP/CSP_policy_directives#report-uri" style="text-decoration: underline;" title="en/Security/CSP/CSP policy directives#report-uri"><code>report-uri</code></a> 指令，任何违背该策略的攻击操作都会被浏览器所报告。</p>
+
+<h2 id="开启报告">开启报告</h2>
+
+<p>默认情况下，攻击是不会被报告的。要开启报告模式，你要指定 <a href="/en/Security/CSP/CSP_policy_directives#report-uri" title="en/Security/CSP/CSP policy directives#report-uri"><code>report-uri</code></a> 指令，这个指令包含了至少一个用于接收报告的URI:</p>
+
+<pre>Content-Security-Policy: default-src self; report-uri http://reportcollector.example.com/collector.cgi
+</pre>
+
+<p>然后，你要搭建接受报告的服务器；它可以对报告进行存储和并进行适时的处理。</p>
+
+<p>注意：Firefox 23以前的版本所使用的报告头为 X-Content-Security-Policy。这个头在将来将被废弃。</p>
+
+<h2 id="攻击报告的语法">攻击报告的语法</h2>
+
+<p>报告的JSON对象包含了以下的数据:</p>
+
+<dl>
+ <dt><code>document-uri</code></dt>
+ <dd>当前攻击所发生的文档的URI。</dd>
+ <dt><code>referrer</code></dt>
+ <dd>当前攻击所发生的文档的来源页面的URI。</dd>
+ <dt><code>blocked-uri</code></dt>
+ <dd>被CSP策略所拦截的资源的URI。如果被拦截资源的URI属于与当前文档不同的来源，则所拦截的资源URI会被削减至只剩scheme,host和port三部分。</dd>
+ <dt><code>violated-directive</code></dt>
+ <dd>攻击所针对的策略部分的名称</dd>
+ <dt><code>original-policy</code></dt>
+ <dd>由X-Content-Security-Policy头指定的原始策略。</dd>
+</dl>
+
+<h2 id="Sample_violation_report">Sample violation report</h2>
+
+<h2 id="攻击报告的样例">攻击报告的样例</h2>
+
+<div>在CSP规范中，已经有一个样例展示攻击报告。这里我们来看另一个例子。</div>
+
+<div> </div>
+
+<div>假设有一个页面叫做<a class="external" href="http://example.com/signup.html" rel="freelink" style="font-family: Consolas, Monaco, 'Andale Mono', monospace;">http://example.com/signup.html</a>. 它使用了一下的策略，它禁止从除cdn.example.com以外的域加载样式表。</div>
+
+<div>
+<pre>Content-Security-Policy: default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports
+</pre>
+</div>
+
+<div>signup.html的HTML则像下面这样：</div>
+
+<pre class="brush: html">&lt;!DOCTYPE html&gt;
+&lt;html&gt;
+  &lt;head&gt;
+    &lt;title&gt;Sign Up&lt;/title&gt;
+    &lt;link rel="stylesheet" href="css/style.css"&gt;
+  &lt;/head&gt;
+  &lt;body&gt;
+    ... Content ...
+  &lt;/body&gt;
+&lt;/html&gt;
+</pre>
+
+<div><span style="line-height: 22.0080013275147px;">看到问题了么？在策略中指明样式表只能从cdn.example.com加载，而这个页面则试图从它本域（http://example.com）下载样式表. 浏览器基于强制CSP的开启，在这个页面被访问时，将以下的报告通过POST请求发送到 </span><a href="http://example.com/_/csp-reports" rel="freelink" style="font-family: Consolas, Monaco, 'Andale Mono', monospace;">http://example.com/_/csp-reports</a><span style="line-height: 22.0080013275147px;"> 下</span></div>
+
+<pre>{
+  "csp-report": {
+    "document-uri": "http://example.com/signup.html",
+    "referrer": "",
+    "blocked-uri": "http://example.com/css/style.css",
+    "violated-directive": "style-src cdn.example.com",
+    "original-policy": "default-src 'none'; style-src cdn.example.com; report-uri /_/csp-reports"
+  }
+}
+</pre>
+
+<p><span style="line-height: 22.0080013275147px;">我们可以看到，这个报告在blocked-uri中包含了错误资源的整个路径。而这并非总是这样。例如，当signup.html试图从</span><a href="http://anothercdn.example.com/stylesheet.css" style="text-decoration: underline;"><code>http://anothercdn.example.com/stylesheet.css</code></a><span style="line-height: 22.0080013275147px;">加载css的时候，浏览器只会记录来源(http://anothercdn.example.com)而不会记录完整的路径。CSP规范中对这一行为进行了</span><a href="http://www.w3.org/TR/CSP/#violation-reports">解释</a>。总结一下<span style="line-height: 22.0080013275147px;">，CSP的作用是放置跨域信息的泄露。值得注意的是，规范中的</span> <a href="http://www.w3.org/TR/CSP/#sample-violation-report">攻击报告范例</a> 有一处错误(其中blocked-uri应该是"http://evil.example.com")。</p>
+
+<h2 id="更多参考">更多参考</h2>
+
+<ul>
+ <li><a href="/en/Security/CSP/Introducing_Content_Security_Policy" title="en/Security/CSP/Introducing Content Security Policy">Introducing Content Security Policy</a></li>
+ <li><a href="/en/Security/CSP/Using_Content_Security_Policy" title="en/Security/CSP/Using Content Security Policy">Using Content Security Policy</a></li>
+ <li><a href="/en/Security/CSP/CSP_policy_directives" title="en/Security/CSP/CSP policy directives">CSP policy directives</a></li>
+</ul>
+
+<div class="noinclude">
+<p>{{ languages( { "ja": "ja/Security/CSP/Using_CSP_violation_reports" } ) }}</p>
+</div>
+
+<p> </p>
diff --git a/files/zh-cn/web/security/index.html b/files/zh-cn/web/security/index.html
new file mode 100644
index 0000000000..d054db1354
--- /dev/null
+++ b/files/zh-cn/web/security/index.html
@@ -0,0 +1,54 @@
+---
+title: Web 安全
+slug: Web/Security
+tags:
+  - Web
+  - 安全
+translation_of: Web/Security
+---
+<div class="summary">
+<p>确保您的 Web 站点或 Web 应用安全是十分重要的，即使是代码中很小的 bug 也可能导致隐私信息被泄露，黑客会尝试偷窃数据。这些文档提供信息帮助您使代码更安全。<span class="seoSummary">此处列出的面向 Web 安全的文章提供的信息可以帮助您保护站点及其代码免受攻击和数据窃取。</span></p>
+</div>
+
+<div class="row topicpage-table">
+<div class="section">
+<dl>
+ <dt class="landingPageList"><a href="/zh-CN/docs/Web/Security/CSP">CSP (内容安全策略)</a></dt>
+ <dd class="landingPageList"><strong>内容安全策略</strong>（CSP）是一个附加的安全层，有助于探测和减轻某些类型的攻击，包括<a href="/zh-CN/docs/Glossary/Cross-site_scripting">跨站脚本攻击（XSS）</a>和数据注入攻击。这些攻击被广泛使用，从数据窃取到网站污损亦或是恶意软件的分发。</dd>
+ <dt class="landingPageList"><a href="/zh-CN/docs/Web/Security/Information_Security_Basics">信息安全基本原理</a></dt>
+ <dd class="landingPageList">了解安全基本原理会帮助你理解在 web 开发生命周期中安全的角色和重要性。它将帮助你避免使用不必要的、允许攻击者利用缺陷获得经济收益或其他恶意目的非完全软件。以下文章提供了一些基本的 web 安全理论和定义。</dd>
+ <dt class="landingPageList"><a href="/zh-CN/docs/Web/Security/Insecure_passwords">不安全的密码</a></dt>
+ <dd class="landingPageList"><a class="external external-icon" href="https://en.wikipedia.org/wiki/HTTP_Secure" title="https://en.wikipedia.org/wiki/HTTP_Secure">HTTPS</a> 协议旨在保护用户数据在网络上不被窃听（机密性） 和不被篡改（完整性）。处理用户数据的网站应该使用 HTTPS 协议保护他们的用户不受黑客的侵害。如果网站使用 HTTP 协议而不是 HTTPS 协议，窃取用户信息（比如他们的登录凭证）将会轻而易举。这曾经被 <a class="external external-icon" href="https://codebutler.github.io/firesheep/" title="http://codebutler.com/firesheep/">Firesheep</a> 很好地演示过。</dd>
+ <dt class="landingPageList"><a href="/zh-CN/docs/Web/Security/Mixed_content">混合内容</a></dt>
+ <dd class="landingPageList">当用户访问通过 <a class="glossaryLink" href="/zh-CN/docs/Glossary/HTTPS" title="HTTPS: HTTPS (HTTP Secure) is an encrypted version of the HTTP protocol. It usually use SSL or TLS to encrypt all communication between a client and a server. This secure connection allows clients to safly exchange sensitive data with a server, for example for banking activities or online shopping.">HTTPS</a> 协议传输的页面时，他们与 web 服务器的连接被 <a class="glossaryLink" href="/zh-CN/docs/Glossary/TLS" title="TLS: Transport Layer Security (TLS), previously known as Secure Sockets Layer (SSL), is a protocol used by applications to communicate securely across a network, preventing tampering with and eavesdropping on email, web browsing, messaging, and other protocols.">TLS</a> 加密保护，因而免受嗅探器和中间人攻击。如果这个通过 HTTPS 访问的页面包含通过定期的明文 HTTP 获取的内容，那么该连接就只是部分加密；没有加密的内容可以被嗅探器获取、被中间人攻击篡改，因此该连接不受安全保证。当网页表现出这样的行为，就称为混合内容页面。</dd>
+</dl>
+
+<dl>
+</dl>
+</div>
+
+<div class="section">
+<dl>
+ <dt class="landingPageList"><a href="/zh-CN/docs/Web/Security/Public_Key_Pinning">公钥固定</a></dt>
+ <dd class="landingPageList"><strong>HTTP 公钥固定扩展</strong> (HPKP) 是一种安全功能，用来告诉 web 客户端与一些 web 服务器关联特定的加密公钥来阻止 <a class="external external-icon" href="https://en.wikipedia.org/wiki/Man-in-the-middle_attack">MITM</a> 伪造证书攻击。</dd>
+ <dt class="landingPageList"><a href="/zh-CN/docs/Web/Security/Same-origin_policy">同源策略</a></dt>
+ <dd class="landingPageList">同源策略限制了一个源（origin）中加载的文档或脚本与其他源（origin）中的资源交互的方式。这是一种用来隔离潜在恶意文档的关键安全机制。</dd>
+ <dt class="landingPageList"><a href="/zh-CN/docs/Web/Security/Secure_Contexts">安全环境</a></dt>
+ <dd class="landingPageList">当浏览器满足安全的最低要求时将进入一种安全环境。安全环境允许浏览器暴露那些只有在被安全地传输给用户时才被允许的 APIs。</dd>
+ <dt class="landingPageList"><a href="/zh-CN/docs/Web/Security/Securing_your_site">保护你的网站</a></dt>
+ <dd class="landingPageList">有很多你可以做的事情能够保护你的网站安全。本文提出了各种各样的建议，还有其他提供了更多有用信息文章的链接。</dd>
+ <dt class="landingPageList"><a href="/zh-CN/docs/Web/Security/Site_Identity_Button">网站身份按钮</a></dt>
+ <dd class="landingPageList">编辑审核完成。</dd>
+ <dt class="landingPageList"><a href="/zh-CN/docs/Web/Security/Subresource_Integrity">子资源完整性</a></dt>
+ <dd class="landingPageList">子资源完整性 (SRI) 是一种安全功能，允许浏览器验证所获取的文件 (比如，从一个 <a href="/zh-CN/docs/Glossary/CDN">CDN</a> 内容分发网络) 是无意外操作而交付的。它的工作原理是允许你提供一个获取文件必须匹配的加密哈希。</dd>
+ <dt class="landingPageList"><a href="/zh-CN/docs/Web/Security/Transport_Layer_Security">传输层安全协议</a></dt>
+ <dd class="landingPageList">在传输层安全协议中选择合适的密码套件和参数是必要且重要的。它有助于维护客户端和服务器之间通信的机密性和完整性。Mozilla 操作安全团队（OpSec）参考传输层安全协议配置维护着 <a class="external external-icon" href="/Security/Server_Side_TLS">一条 wiki 条目</a>。</dd>
+ <dt class="landingPageList"><a href="/zh-CN/docs/Web/Security/Weak_Signature_Algorithm">弱签名算法</a></dt>
+ <dd class="landingPageList">编辑审核完成。</dd>
+</dl>
+</div>
+</div>
+
+<p>{{LandingPageListSubpages}}</p>
+
+<p>{{QuickLinksWithSubpages}}</p>
diff --git a/files/zh-cn/web/security/information_security_basics/index.html b/files/zh-cn/web/security/information_security_basics/index.html
new file mode 100644
index 0000000000..d9c1f0769f
--- /dev/null
+++ b/files/zh-cn/web/security/information_security_basics/index.html
@@ -0,0 +1,28 @@
+---
+title: 信息安全基础
+slug: Web/Security/Information_Security_Basics
+translation_of: Web/Security/Information_Security_Basics
+---
+<p>了解安全基础知识有助于你了解整个Web开发生命周期中安全性的作用和重要性。 这将帮助你避免不必要的不安全软件，使得攻击者利用漏洞获得经济利益或其他恶意用途。以下的文章提供一些基本的Web安全理论和定义。</p>
+
+<dl>
+ <dt><a href="/en-US/Learn/Confidentiality,_Integrity,_and_Availability">机密性、完整性和可用性</a></dt>
+ <dd>描述了信息安全的基本目标，是理解信息安全的基础。</dd>
+ <dt><a href="https://developer.mozilla.org/en-US/Learn/Vulnerabilities">漏洞</a></dt>
+ <dd>明确主要漏洞策略以及讨论在所有软件中的存在的所有漏洞。</dd>
+ <dt><a href="/en-US/Learn/Threats">威胁 - Threats</a></dt>
+ <dd>对主要威胁概念的简单介绍。</dd>
+ <dt><a href="/en-US/Learn/Security_Controls">安全控制 - Security Controls</a></dt>
+ <dd>明确主要安全控制策略以及它们潜在的缺点。</dd>
+ <dt><a href="/en-US/Learn/TCP_IP_Security">TCP/IP 安全</a></dt>
+ <dd>TCP/IP模型的介绍，还有SSL的教程。</dd>
+</dl>
+
+<h2 id="相关链接">相关链接</h2>
+
+<ul>
+ <li><a href="/zh-CN/docs/Mozilla/%E5%AE%89%E5%85%A8">浏览器安全 - Browser security</a></li>
+ <li><a href="/en-US/docs/Web/Security">网络安全 - Web security</a></li>
+ <li><a href="/en-US/docs/Web/Security/Securing_your_site">让您的网站变得安全 - Securing your site</a></li>
+ <li><a href="/en-US/docs/Security/Firefox_Security_Basics_For_Developers">火狐浏览器安全基础开发者须知 - Firefox Security Basics for Developers</a></li>
+</ul>
diff --git a/files/zh-cn/web/security/information_security_basics/tcp_ip_安全/index.html b/files/zh-cn/web/security/information_security_basics/tcp_ip_安全/index.html
new file mode 100644
index 0000000000..5a8c1a68b0
--- /dev/null
+++ b/files/zh-cn/web/security/information_security_basics/tcp_ip_安全/index.html
@@ -0,0 +1,50 @@
+---
+title: TCP/IP 安全
+slug: Web/Security/Information_Security_Basics/TCP_IP_安全
+translation_of: Archive/Security/TCP_IP
+---
+<p>{{draft}}</p>
+
+<p>TCP/IP 在全世界被广泛应用于提供网络通信。  TCP/IP 通信由四个工作层组成。当用户想要通过网络传输数据时，数据就会从更高层通过中间层逐渐传递到最底层，每层都会添加对应的信息。在每一层, 逻辑单元通常由标头和有效载荷组成。有效载荷由上一层传递下来的信息组成，而头部包含特定于层的信息，例如地址。在应用程序层，有效负载是实际的应用程序数据。最底层通过物理网络发送累积数据;然后，数据通过层向上传递到目的地。基本上，由层生成的数据通过其下面的层封装在更大的容器中。从最高到最低的四个TCP / IP层如下所示。</p>
+
+<ul>
+ <li><strong>应用层</strong> 。 该层发送和接收特定应用程序的数据，例如域名系统（DNS），超文本传输​​协议（HTTP）和简单邮件传输协议（SMTP）。</li>
+ <li><strong>传输层。</strong>  该层提供面向连接或无连接的服务，用于在网络之间传输应用层服务。传输层可以任选地确保通信的可靠性。传输控制协议（TCP）和用户数据报协议（UDP）是常用的传输层协议。</li>
+ <li><strong>网络层。</strong>  该层通过网络根据特定路由发送数据包。 Internet协议（IP）是TCP / IP的基本网络层协议。网络层上的其他常用协议是因特网控制消息协议（ICMP）和因特网组管理协议（IGMP）。</li>
+ <li><strong>数据链路层。</strong> 该层处理物理网络组件上的通信。最着名的数据链路层协议是以太网。</li>
+</ul>
+
+<p>存在用于TCP / IP模型的每一层的网络通信的安全控制。如前所述，数据从最高层传递到最低层，每层添加更多信息。因此，较高层的安全控制不能为较低层提供保护，因为较低层执行较高层不知道的功能。每层可用的安全控制包括：</p>
+
+<ul style="list-style-type: square;">
+ <li><strong>应用层。</strong>  必须为每个应用程序建立单独的控制。例如，如果应用程序需要保护跨网络发送的敏感数据，则可能需要修改应用程序以提供此保护。虽然这为应用程序的安全性提供了非常高的控制和灵活性，但可能需要大量资源投入才能为每个应用程序正确添加和配置控件。设计一个密码健全的应用程序协议是非常困难的，正确实现它更具挑战性，因此创建新的应用程序层安全控制可能会产生漏洞。此外，某些应用程序，尤其是现成的软件，可能无法提供此类保护。虽然应用程序层控件可以保护应用程序数据，但它们无法保护TCP / IP信息（如IP地址），因为此信息存在于较低层。只要有可能，用于保护网络通信的应用层控制应该是基于标准的解决方案，这些解决方案已经使用了一段时间。一个例子是安全的多用途互联网邮件扩展（S / MIME），它通常用于加密电子邮件消息。</li>
+ <li><strong>传输层。</strong>此层的控件可用于保护两台主机之间的单个通信会话中的数据。由于IP信息是在网络层添加的，因此传输层控件无法保护它。传输层协议的最常见用途是保护HTTP流量；通常使用传输层安全性（TLS）协议。 （TLS是SSL版本3的基于标准的版本。有关TLS的更多信息，请参阅RFC 4346，TLS协议版本1.1，可从https://www.ietf.org/rfc/rfc4346.txt 获得。另一个很好的来源信息是NIST SP 800-52，传输层安全的选择和使用指南，可从https://csrc.nist.gov/publications/nistpubs/ ）。TLS的使用通常要求每个应用程序支持TLS；但是，与通常涉及应用程序的广泛定制的应用程序层控件不同，传输层控件（如TLS）的干扰要小得多，因为它们不需要了解应用程序的功能或特性。尽管使用TLS可能需要修改某些应用程序，但TLS是经过充分测试的协议，其中有多个实现已添加到许多应用程序中，因此与在应用程序层添加保护相比，它是一种风险相对较低的选项。传统上，TLS已用于保护基于HTTP的通信，并可与SSL门户VPN一起使用。</li>
+ <li><strong>网络层。</strong>此层的控件可应用于所有应用程序；因此，它们不是特定于应用程序的。例如，可以在该层保护两个主机或网络之间的所有网络通信，而无需修改客户端或服务器上的任何应用程序。在某些环境中，网络层控制（如互联网协议安全性（IPsec））提供了比传输或应用程序层控制更好的解决方案，因为向单个应用程序添加控件存在困难。网络层控制还为网络管理员提供了一种强制执行某些安全策略的方法。网络层控制的另一个优点是，由于在该层添加了IP信息（例如，IP地址），所以控制可以保护分组内的数据和每个分组的IP信息。但是，与传输和应用程序层控制相比，网络层控制提供的保护特定应用程序的控制和灵活性较低SSL隧道VPN提供了保护TCP和UDP通信（包括客户端/服务器和其他网络流量）的能力，因此可用作网络层VPN。</li>
+ <li><strong>数据链路层。</strong> 数据链路层控制应用于特定物理链路上的所有通信，例如两个建筑物之间的专用电路或连接到Internet服务提供商（ISP）的拨号调制解调器连接。专用电路的数据链路层控制通常由称为数据链路加密器的专用硬件设备提供；用于其他类型连接的数据链路层控制，例如拨号调制解调器通信，通常通过软件提供。由于数据链路层位于网络层之下，因此该层的控制可以保护数据和IP信息。与其他层的控件相比，数据链路层控件相对简单，这使得它们更容易实现；此外，它们还支持IP以外的其他网络层协议。由于数据链路层控制特定于特定物理链路，因此它们无法保护与多个链路的连接，例如通过Internet建立VPN。基于互联网的连接通常由链接在一起的若干物理链路组成；保护与数据链路层控制的这种连接将需要为每个链路部署单独的控制，这是不可行的。数据链路层协议已经使用多年，主要是为不应信任的特定物理链路提供额外保护。</li>
+</ul>
+
+<p>由于它们可以同时为许多应用程序提供保护而无需对其进行修改，因此经常使用网络层安全控制来保护通信，尤其是在诸如因特网的共享网络上。网络层安全控制提供单一解决方案，用于保护所有应用程序的数据，以及保护IP信息。然而，在许多情况下，另一层的控制比网络层控制更适合提供保护。例如，如果只有一个或两个应用程序需要保护，则网络层控制可能过多。 SSL等传输层协议最常用于为与各个基于HTTP的应用程序进行通信提供安全性，但它们也用于为其他类型的应用程序（如SMTP，存在点（POP），Internet）的通信会话提供保护。消息访问协议（IMAP）和文件传输协议（FTP）。由于所有主要的Web浏览器都包含对TLS的支持，因此希望使用受TLS保护的基于Web的应用程序的用户通常不需要安装任何客户端软件或重新配置其系统。传输层安全协议的较新应用程序保护HTTP和非HTTP应用程序通信，包括客户端/服务器应用程序和其他网络流量。每一层的控件都提供了其他层控件的优点和功能。</p>
+
+<p>SSL是最常用的传输层安全控制。根据SSL的实现和配置方式，它可以提供以下类型的保护的任意组合：</p>
+
+<ul style="list-style-type: square;">
+ <li><strong>机密性。</strong>  SSL可以确保未授权方无法读取数据。这是通过使用加密算法和秘密密钥加密数据来实现的 - 秘密密钥是仅为双方交换数据所知的值。数据只能由拥有密钥的人解密。</li>
+ <li><strong>完整性。</strong> SSL可以确定数据是否在传输过程中（有意或无意）更改。通过生成消息认证码（MAC）值可以确保数据的完整性，MAC值是数据的密钥加密校验和。如果更改数据并重新计算MAC，则旧MAC和新MAC将不同。</li>
+ <li><strong>对等实体认证。</strong>  每个SSL端点都可以确认其希望与之通信的另一个SSL端点的标识，从而确保从预期的主机发送网络流量和数据。 SSL身份验证通常是单向执行的，向客户端验证服务器，但可以相互执行。</li>
+ <li><strong>重发保护。  </strong>相同的数据不会多次传送，并且数据不会严重无序传送。</li>
+</ul>
+
+
+
+<div class="originaldocinfo">
+<h3 id="Original_Document_Information" name="Original_Document_Information">Original Document Information</h3>
+
+<ul>
+ <li>Author(s): Sheila Frankel, Paul Hoffman, Angela Orebaugh, and Richard Park</li>
+ <li>Title: National Institute of Standards and Technology (NIST) Special Publication 800-113, Guide to SSL VPNs</li>
+ <li>Last Updated Date: July 2008</li>
+ <li>Copyright Information: This document is not subject to copyright.</li>
+</ul>
+</div>
+
+<p>{{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}</p>
diff --git a/files/zh-cn/web/security/information_security_basics/vulnerabilities/index.html b/files/zh-cn/web/security/information_security_basics/vulnerabilities/index.html
new file mode 100644
index 0000000000..e060234976
--- /dev/null
+++ b/files/zh-cn/web/security/information_security_basics/vulnerabilities/index.html
@@ -0,0 +1,47 @@
+---
+title: Vulnerabilities
+slug: Web/Security/Information_Security_Basics/Vulnerabilities
+translation_of: Archive/Security/Vulnerabilities
+---
+<div class="summary">
+<p>本文讨论漏洞，解释它们是什么以及它们在所有系统中的存在方式。</p>
+</div>
+
+<p>漏洞是系统中的一个弱点，可被利用来对机密性，完整性和可用性产生负面影响。 可以通过多种方式对漏洞进行分类。 本文使用三个高级漏洞类别：软件缺陷，安全配置问题和软件功能滥用。 这些类别如下所述。</p>
+
+<h2 id="漏洞级别">漏洞级别</h2>
+
+<p> </p>
+
+<p>软件缺陷是由软件设计或编码中的意外错误引起的。比如输入验证错误，假如用户提供的输入未正确评估恶意字符串和与已知攻击相关的过长值。另一个示例是竞争条件错误，允许攻击者使用提升的权限执行特定操作。</p>
+
+<p>安全配置设置是软件安全性的一个元素，可以通过软件本身进行更改。设置的示例是提供对控制列表的访问的操作系统，该控制列表设置用户对文件的特权，以及提供用于启用或禁用由应用程序存储的敏感数据的加密的设置的应用程序。安全配置问题漏洞涉及使用对软件安全性产生负面影响的安全配置设置。</p>
+
+<p>软件功能是由软件提供的功能功能。软件功能滥用漏洞是一种漏洞，其中该功能还提供了破坏系统安全性的途径。这些漏洞是由软件设计者做出的信任假设允许软件提供有益的功能，同时也引入某人违反信任假设以破坏安全性的可能性引起的。例如，电子邮件客户端软件可能包含在电子邮件消息中呈现HTML内容的功能。攻击者可以制作包含超链接的欺诈性电子邮件，这些超链接在以HTML格式呈现时对收件人来说是良性的，但实际上在收件人点击时会将收件人带到恶意网站。 HTML内容呈现功能设计中的一个信任假设是用户不会收到恶意超链接并点击它们。</p>
+
+<p>在软件设计或软件组件（例如，软件实现的协议）期间引入软件特征滥用漏洞。信任假设可能是明确的 - 例如，设计者意识到安全漏洞并确定单独的安全控制会对其进行补偿。但是，信任假设通常是隐含的，例如创建特征而不首先评估它将引入的风险。威胁也可能在软件的生命周期或软件中使用的协议中发生变化。例如，地址解析协议（ARP）信任ARP回复包含媒体访问控制（MAC）和Internet协议（IP）地址之间的正确映射。 ARP缓存使用该信息提供有用的服务 - 以便在本地网络内的设备之间发送数据。但是，攻击者可能会生成错误的ARP消息来中毒系统的ARP表，从而发起拒绝服务或中间人攻击。 ARP协议在25年前已经标准化，从那时起威胁发生了很大的变化，因此其设计中固有的信任假设今天不太可能合理。</p>
+
+<p>可能很难将软件功能滥用漏洞与其他两个类别区分开来。例如，软件设计过程中的缺陷可能导致软件缺陷和滥用漏洞。但是，软件缺陷纯粹是消极的 - 它们对安全性或功能没有任何积极的好处 - 而软件特性由于提供额外的功能而导致滥用漏洞。</p>
+
+<p>对于可以启用或禁用的功能的滥用漏洞，可能存在混淆 - 在某种程度上，配置与安全配置问题。关键的区别在于，对于滥用漏洞，配置设置启用或禁用整个功能，并不特别改变其安全性;对于安全配置问题漏洞，配置设置仅更改软件的安全性。例如，禁用电子邮件中所有HTML使用的设置会对安全性和功能产生重大影响，因此与此设置相关的漏洞将是滥用漏洞。禁用电子邮件客户端中使用反网络钓鱼功能的设置仅对安全性有重大影响，因此具有该设置的漏洞将被视为安全配置问题漏洞。</p>
+
+<p> </p>
+
+<h2 id="The_Presence_of_Vulnerabilities">The Presence of Vulnerabilities</h2>
+
+<p>No system is 100% secure: every system has vulnerabilities. At any given time, a system may not have any known software flaws, but security configuration issues and software feature misuse vulnerabilities are always present. Misuse vulnerabilities are inherent in software features because each feature must be based on trust assumptions—and those assumptions can be broken, albeit involving significant cost and effort in some cases. Security configuration issues are also unavoidable for two reasons. First, many configuration settings increase security at the expense of reducing functionality, so using the most secure settings could make the software useless or unusable. Second, many security settings have both positive and negative consequences for security. An example is the number of consecutive failed authentication attempts to permit before locking out a user account. Setting this to 1 would be the most secure setting against password guessing attacks, but it would also cause legitimate users to be locked out after mistyping a password once, and it would also permit attackers to perform denial-of-service attacks against users more easily by generating a single failed login attempt for each user account.</p>
+
+<p>Because of the number of vulnerabilities inherent in security configuration settings and software feature misuse possibilities, plus the number of software flaw vulnerabilities on a system at any given time, there may be dozens or hundreds of vulnerabilities on a single system. These vulnerabilities are likely to have a wide variety of characteristics. Some will be very easy to exploit, while others will only be exploitable under a combination of highly unlikely conditions. One vulnerability might provide root-level access to a system, while another vulnerability might only permit read access to an insignificant file. Ultimately, organizations need to know how difficult it is for someone to exploit each vulnerability and, if a vulnerability is exploited, what the possible impact would be.</p>
+
+<div class="originaldocinfo">
+<h3 id="Original_Document_Information" name="Original_Document_Information">Original Document Information</h3>
+
+<ul>
+ <li>Author(s): Elizabeth LeMay, Karen Scarfone, and Peter Mell</li>
+ <li>Title: National Institute of Standards and Technology (NIST) Interagency Report 7864, The Common Misuse Scoring System (CMSS): Metrics for Software Feature Misuse Vulnerabilities</li>
+ <li>Last Updated Date: July 2012</li>
+ <li>Copyright Information: This document is not subject to copyright.</li>
+</ul>
+</div>
+
+<p>{{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}</p>
diff --git a/files/zh-cn/web/security/information_security_basics/机密性、完整性和可用性/index.html b/files/zh-cn/web/security/information_security_basics/机密性、完整性和可用性/index.html
new file mode 100644
index 0000000000..2c415ae3ea
--- /dev/null
+++ b/files/zh-cn/web/security/information_security_basics/机密性、完整性和可用性/index.html
@@ -0,0 +1,35 @@
+---
+title: 机密性、完整性和可用性
+slug: Web/Security/Information_Security_Basics/机密性、完整性和可用性
+translation_of: 'Archive/Security/Confidentiality,_Integrity,_and_Availability'
+---
+<div class="summary" style="margin: 0px 0px 20px; padding: 20px; border: 0px; font-weight: 700; color: rgb(77, 78, 83); font-family: 'Open Sans', sans-serif; font-size: 14px; font-style: normal; font-variant: normal; letter-spacing: normal; line-height: 21px; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; background: rgb(244, 247, 248);">
+<p style="margin: 0px; padding: 0px; border: 0px;">这篇文章讨论Web安全的三个主要目标：机密性、完整性和可用性。</p>
+</div>
+
+<p>传统的关于信息安全的模型定义了三个Web安全的目标：保持机密性、完整性和可用性。每一个目标都阐述了信息安全的不同方面。</p>
+
+<h2 id="机密性">机密性</h2>
+
+<p>机密性指信息指在未验证状态下信息不能被用户获取。也就是说，只有被验证过的用户才能获得敏感数据。联想下你的银行卡，你是授权可以访问的，但是，银行的雇员们也可以访问，其他人不行。机密性不高也就意味着原本不能访问这些信息的人却能够获取到这些信息，不管是有意为之还是由于突发事故。保密失败，也就是通常所说的泄密,通常是很难被根治的。一旦秘密被泄露了，就不能重新加密它。如果你的银行账号被贴到了一个公共的网站上，每一个人就都能知道你的银行账号，收入等，而且这些信息并不会从他们的心里，纸上，电脑或者其他地方清除。今天几乎凡是媒体上报道的安全事故，都涉及到重大的机密损失。</p>
+
+<p>总的来说，机密信息的泄露指的就是本不能访问它的人却获得了这些信息。</p>
+
+<h2 id="完整性">完整性</h2>
+
+<p>完整性表示，经过验证的用户访问数据时，数据没有发生过任何改动，是原生的数据。想象下你有一个网站，并在上面出售商品。这时一个黑客在浏览你的网站，并恶意的修改了你产品的价格，这样一来，他就能够以任意的价格购买任何东西。这就是一个保护完整性的反面案例。因为你的信息--这个场景下，就是商品的价格--被修改了，而且你没有授权这一次变更。另一个反面案例，当你在连接一个网站的时候，攻击者重定向了你的传输到另外一个网站。在这种情况下，你被指向的网站并不是真实可靠的。</p>
+
+<h2 id="可用性">可用性</h2>
+
+<p>可用性指被验证过的用户可以轻易获得信息。</p>
+
+<div class="originaldocinfo">
+<h3 id="Original_Document_Information" name="Original_Document_Information">初始文档信息</h3>
+
+<ul>
+ <li>?作者：Karen Scarfone, Wayne Jansen, and Miles Tracy</li>
+ <li>标题：NIST Special Publication 800-123，《常规服务器安全指南》</li>
+ <li>最后更新日期：2008年7月</li>
+ <li>版权信息： 本文档不受版权保护。</li>
+</ul>
+</div>
diff --git a/files/zh-cn/web/security/same-origin_policy/index.html b/files/zh-cn/web/security/same-origin_policy/index.html
new file mode 100644
index 0000000000..56b8d35992
--- /dev/null
+++ b/files/zh-cn/web/security/same-origin_policy/index.html
@@ -0,0 +1,272 @@
+---
+title: 浏览器的同源策略
+slug: Web/Security/Same-origin_policy
+tags:
+  - AJAX
+  - CORS
+  - JavaScript
+  - Same-origin policy
+  - Security
+  - 同源策略
+translation_of: Web/Security/Same-origin_policy
+---
+<p><strong>同源策略</strong>是一个重要的安全策略，它用于限制一个{{Glossary("origin")}}的文档或者它加载的脚本如何能与另一个源的资源进行交互。它能帮助阻隔恶意文档，减少可能被攻击的媒介。</p>
+
+<h2 id="同源的定义"><strong>同源</strong>的<strong>定义</strong></h2>
+
+<p>如果两个 URL 的 {{Glossary("protocol")}}、{{Glossary("port")}} (如果有指定的话)和 {{Glossary("host")}} 都相同的话，则这两个 URL 是<em>同源</em>。这个方案也被称为“协议/主机/端口元组”，或者直接是 “元组”。（“元组” 是指一组项目构成的整体，双重/三重/四重/五重/等的通用形式）。</p>
+
+<p>下表给出了与 URL <code><span class="nowiki">http://store.company.com/dir/page.html</span></code> 的源进行对比的示例:</p>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th>URL</th>
+   <th>结果</th>
+   <th>原因</th>
+  </tr>
+  <tr>
+   <td><code><span class="nowiki">http://store.company.com/dir2/other.html</span></code></td>
+   <td>同源</td>
+   <td><font face="consolas, Liberation Mono, courier, monospace">只有路径不同</font></td>
+  </tr>
+  <tr>
+   <td><code><span class="nowiki">http://store.company.com/dir/inner/another.html</span></code></td>
+   <td>同源</td>
+   <td><font face="consolas, Liberation Mono, courier, monospace">只有路径不同</font></td>
+  </tr>
+  <tr>
+   <td><code><span class="nowiki">https://store.company.com/secure.html</span></code></td>
+   <td>失败</td>
+   <td>协议不同</td>
+  </tr>
+  <tr>
+   <td><code><span class="nowiki">http://store.company.com:81/dir/etc.html</span></code></td>
+   <td>失败</td>
+   <td>端口不同 ( <code>http://</code> 默认端口是80)</td>
+  </tr>
+  <tr>
+   <td><code><span class="nowiki">http://news.company.com/dir/other.html</span></code></td>
+   <td>失败</td>
+   <td>主机不同</td>
+  </tr>
+ </tbody>
+</table>
+
+<h3 id="源的继承"><strong>源的</strong><strong>继承</strong></h3>
+
+<p>在页面中通过 <code>about:blank</code> 或 <code>javascript:</code> URL 执行的脚本会继承打开该 URL 的文档的源，因为这些类型的 URLs 没有包含源服务器的相关信息。</p>
+
+<div class="blockIndicator note">
+<p>例如，<code>about:blank</code> 通常作为父脚本写入内容的新的空白弹出窗口的 URL（例如，通过  <a href="https://developer.mozilla.org/en-US/docs/Web/API/Window/open">Window.open()</a>  ）。 如果此弹出窗口也包含 JavaScript，则该脚本将从创建它的脚本那里继承对应的源。</p>
+</div>
+
+<div class="note">
+<p>注意：在{{Gecko("6.0")}}之前，如果用户在位置栏中输入 <code>data</code> URLs，<code>data</code> URLs 将继承当前浏览器窗口中网页的安全上下文。</p>
+</div>
+
+<div class="blockIndicator warning">
+<p><code>data</code>：URLs 获得一个新的，空的安全上下文。</p>
+</div>
+
+<h3 id="IE_中的特例"><strong>IE 中的特例</strong></h3>
+
+<p>Internet Explorer 的同源策略有两个主要的差异点：</p>
+
+<ul>
+ <li><strong>授信范围</strong>（Trust Zones）：两个相互之间高度互信的域名，如公司域名（corporate domains），则不受同源策略限制。</li>
+ <li><strong>端口</strong>：IE 未将端口号纳入到同源策略的检查中，因此<span> </span><span><code>https://company.com:81/index.html</code> </span><span>和 </span><span><code>https://company.com/index.html</code>  </span>属于同源并且不受任何限制。</li>
+</ul>
+
+<p>这些差异点是不规范的，其它浏览器也未做出支持，但会助于开发基于window RT IE的应用程序。</p>
+
+<h2 id="源的更改"><strong>源</strong>的更改</h2>
+
+<p>满足某些限制条件的情况下，页面是可以修改它的源。脚本可以将 {{domxref("document.domain")}} 的值设置为其当前域或其当前域的父域。如果将其设置为其当前域的父域，则这个较短的父域将用于后续源检查。</p>
+
+<p>例如：假设 http://store.company.com/dir/other.html 文档中的一个脚本执行以下语句：</p>
+
+<pre class="eval">document.domain = "company.com";
+</pre>
+
+<p>这条语句执行之后，页面将会成功地通过与 <code><span class="nowiki">http://company.com/dir/page.html</span></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>document.domain</code> 为 <code>othercompany.com</code>，因为它不是 <code>company.com</code> 的父域。</p>
+
+<p>端口号是由浏览器另行检查的。任何对document.domain的赋值操作，包括 <code>document.domain = document.domain</code> 都会导致端口号被重写为 <code>null</code> 。因此 <code>company.com:8080</code> <strong>不能</strong>仅通过设置 <code>document.domain = "company.com"</code> 来与<code>company.com</code> 通信。必须在他们双方中都进行赋值，以确保端口号都为 <code>null</code> 。</p>
+
+<div class="note">
+<p>注意：使用 <code>document.domain</code> 来允许子域安全访问其父域时，您需要在父域和子域中设置 document.domain 为相同的值。这是必要的，即使这样做只是将父域设置回其原始值。不这样做可能会导致权限错误。</p>
+</div>
+
+<h2 id="跨源网络访问">跨源网络访问</h2>
+
+<p>同源策略控制不同源之间的交互，例如在使用{{domxref("XMLHttpRequest")}} 或 {{htmlelement("img")}} 标签时则会受到同源策略的约束。这些交互通常分为三类：</p>
+
+<ul>
+ <li>跨域<em><strong>写操作</strong>（Cross-origin writes）</em>一般是被允许的<em>。</em>例如链接（links），重定向以及表单提交。特定少数的HTTP请求需要添加 <a href="https://developer.mozilla.org/zh-CN/docs/HTTP/Access_control_CORS#Preflighted_requests" title="HTTP/Access_control_CORS#Preflighted_requests">preflight</a>。</li>
+ <li>跨域<em><strong>资源嵌入</strong>（Cross-origin embedding）</em>一般是被允许（后面会举例说明）。</li>
+ <li>跨域<em><strong>读操作</strong>（Cross-origin reads）</em>一般是不被允许的<em>，</em>但常可以通过内嵌资源来巧妙的进行读取访问。例如，你可以读取嵌入图片的高度和宽度，调用内嵌脚本的方法，或<a href="https://grepular.com/Abusing_HTTP_Status_Codes_to_Expose_Private_Information" title="https://grepular.com/Abusing_HTTP_Status_Codes_to_Expose_Private_Information">availability of an embedded resource</a>.</li>
+</ul>
+
+<p>以下是可能嵌入跨源的资源的一些示例：</p>
+
+<ul>
+ <li><code>&lt;script src="..."&gt;&lt;/script&gt;</code> 标签嵌入跨域脚本。语法错误信息只能被同源脚本中捕捉到。</li>
+ <li><code>&lt;link rel="stylesheet" href="..."&gt;</code> 标签嵌入CSS。由于CSS的<a href="http://scarybeastsecurity.blogspot.dk/2009/12/generic-cross-browser-cross-domain.html">松散的语法规则</a>，CSS的跨域需要一个设置正确的 HTTP 头部 <code>Content-Type</code> 。不同浏览器有不同的限制：<span> </span><a href="http://msdn.microsoft.com/zh-CN/library/ie/gg622939%28v=vs.85%29.aspx" title="http://msdn.microsoft.com/zh-CN/library/ie/gg622939%28v=vs.85%29.aspx">IE</a><span>, </span><a href="http://www.mozilla.org/security/announce/2010/mfsa2010-46.html" title="http://www.mozilla.org/security/announce/2010/mfsa2010-46.html">Firefox</a><span>, </span><a href="http://code.google.com/p/chromium/issues/detail?id=9877" title="http://code.google.com/p/chromium/issues/detail?id=9877">Chrome</a><span>, </span><a href="http://support.apple.com/kb/HT4070" title="http://support.apple.com/kb/HT4070">Safari</a><span> (跳至CVE-2010-0051)部分 和 </span><a href="http://www.opera.com/support/kb/view/943/" title="http://www.opera.com/support/kb/view/943/">Opera</a>。</li>
+ <li>通过 {{htmlelement("img")}} 展示的图片。支持的图片格式包括PNG,JPEG,GIF,BMP,SVG,...</li>
+ <li>通过 {{htmlelement("video")}} 和 {{htmlelement("audio")}} 播放的多媒体资源。</li>
+ <li>通过 <code><a href="https://developer.mozilla.org/zh-CN/docs/HTML/Element/object" title="HTML/Element/object">&lt;object&gt;</a></code>、 <a href="https://developer.mozilla.org/zh-CN/docs/HTML/Element/embed" title="HTML/Element/embed"><code>&lt;embed&gt;</code></a> 和 <code><a href="https://developer.mozilla.org/zh-CN/docs/HTML/Element/applet" title="HTML/Element/applet">&lt;applet&gt;</a></code> 嵌入的插件。</li>
+ <li>通过 <code><a href="https://developer.mozilla.org/zh-CN/docs/CSS/@font-face" title="CSS/@font-face">@font-face</a></code> 引入的字体。一些浏览器允许跨域字体（ cross-origin fonts），一些需要同源字体（same-origin fonts）。</li>
+ <li><font face="consolas, Liberation Mono, courier, monospace"><span style="background-color: rgba(220, 220, 220, 0.5);">通过</span></font> <code><a href="https://developer.mozilla.org/zh-CN/docs/HTML/Element/iframe" title="HTML/Element/iframe">&lt;iframe&gt;</a></code> 载入的任何资源。站点可以使用 <a href="https://developer.mozilla.org/zh-CN/docs/HTTP/X-Frame-Options" title="HTTP/X-Frame-Options">X-Frame-Options</a> 消息头来阻止这种形式的跨域交互。</li>
+</ul>
+
+<h3 id="如何允许跨源访问"><strong>如何允许跨源访问</strong></h3>
+
+<p>可以使用 <a href="https://developer.mozilla.org/zh-CN/docs/HTTP/Access_control_CORS">CORS</a> 来允许跨源访问。CORS 是 {{Glossary("HTTP")}} 的一部分，它允许服务端来指定哪些主机可以从这个服务端加载资源。</p>
+
+<h3 id="如何阻止跨源访问"><strong>如何阻止跨源访问</strong></h3>
+
+<ul>
+ <li>阻止跨域写操作，只要检测请求中的一个不可推测的标记(CSRF token)即可，这个标记被称为 <a href="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29" title="https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29">Cross-Site Request Forgery (CSRF)</a><span> 标记。你必须使用这个标记来阻止页面的跨站读操作。</span></li>
+ <li><span>阻止资源的跨站读取，需要保证该资源是不可嵌入的。阻止嵌入行为是必须的，因为嵌入资源通常向其暴露信息。</span></li>
+ <li><span>阻止跨站嵌入，需要确保你的资源不能通过以上列出的可嵌入资源格式使用。浏览器可能不会遵守 <code>Content-Type</code> 头部定义的类型。例如，如果您在HTML文档中指定 <code>&lt;script&gt;</code> 标记，则浏览器将尝试将标签内部的 HTML 解析为JavaScript。 当您的资源不是您网站的入口点时，您还可以使用CSRF令牌来防止嵌入。</span></li>
+</ul>
+
+<h2 id="跨源脚本API访问">跨源脚本API访问</h2>
+
+<p>JavaScript 的 API 中，如<span> </span><code><a href="https://developer.mozilla.org/zh-CN/docs/DOM/HTMLIFrameElement" title="DOM/HTMLIFrameElement">iframe.contentWindow</a></code>、<span> {{domxref("window.parent")}}、{{domxref("window.open")}} 和 {{domxref("window.opener")}} 允许文档间直接相互引用。当两个文档的源不同时，这些引用方式将对</span><span> </span><a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#security-window" title="http://www.whatwg.org/specs/web-apps/current-work/multipage/browsers.html#security-window">Window</a><span> 和 </span><a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#security-location" title="http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#security-location">Location</a>对象的访问添加限制，如下两节所述。</p>
+
+<p>为了能让不同源中文档进行交流，可以使用 {{domxref("window.postMessage")}}。</p>
+
+<p>规范: <a href="https://html.spec.whatwg.org/multipage/browsers.html#cross-origin-objects">HTML Living Standard § Cross-origin objects</a> 。</p>
+
+<h3 id="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">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="跨源数据存储访问">跨源数据存储访问</h2>
+
+<p>访问存储在浏览器中的数据，如 <a href="https://developer.mozilla.org/zh-CN/docs/Web/Guide/API/DOM/Storage">localStorage</a> 和 <a href="https://developer.mozilla.org/zh-CN/docs/IndexedDB">IndexedDB</a>，是以源进行分割。每个源都拥有自己单独的存储空间，一个源中的 JavaScript 脚本不能对属于其它源的数据进行读写操作。</p>
+
+<p>{{glossary("Cookie", "Cookies")}}  使用不同的源定义方式。一个页面可以为本域和其父域设置 cookie，只要是父域不是公共后缀（public suffix）即可。Firefox 和 Chrome 使用 <a href="http://publicsuffix.org/">Public Suffix List</a> 检测一个域是否是公共后缀（public suffix）。Internet Explorer 使用其内部的方法来检测域是否是公共后缀。不管使用哪个协议（HTTP/HTTPS）或端口号，浏览器都允许给定的域以及其任何子域名(sub-domains) 访问 cookie。当你设置 cookie 时，你可以使用 <code>Domain</code>、<code>Path</code>、<code>Secure</code>、和 <code>HttpOnly</code> 标记来限定其可访问性。当你读取 cookie 时，你无法知道它是在哪里被设置的。 即使您只使用安全的 https 连接，您看到的任何 cookie 都有可能是使用不安全的连接进行设置的。</p>
+
+<h2 id="参见">参见</h2>
+
+<ul>
+ <li><a href="http://www.w3.org/Security/wiki/Same_Origin_Policy" title="http://www.w3.org/Security/wiki/Same_Origin_Policy">Same-Origin Policy at W3C</a></li>
+ <li><a href="http://web.dev/secure/same-origin-policy">http://web.dev/secure/same-origin-policy</a></li>
+</ul>
+
+<div class="originaldocinfo">
+<h2 id="Original_Document_Information" name="Original_Document_Information">原始文件资料</h2>
+
+<ul>
+ <li>Author(s): Jesse Ruderman</li>
+</ul>
+</div>
+
+<div class="noinclude"></div>
diff --git a/files/zh-cn/web/security/secure_contexts/index.html b/files/zh-cn/web/security/secure_contexts/index.html
new file mode 100644
index 0000000000..d658bbb4a0
--- /dev/null
+++ b/files/zh-cn/web/security/secure_contexts/index.html
@@ -0,0 +1,72 @@
+---
+title: Secure contexts
+slug: Web/Security/Secure_Contexts
+translation_of: Web/Security/Secure_Contexts
+---
+<p><span class="seoSummary"><strong>安全上下文</strong>是 <code>Window</code> 与 <code>Worker</code> 中的概念</span>满足了最低标准的身份验证和机密性<span class="seoSummary">.</span> 许多Web APIs的访问仅能在安全上下文中. 安全上下文的主要目标是防止 {{interwiki("wikipedia", "man-in-the-middle attack", "MITM attackers")}} 强大的APIs被坏人利用.</p>
+
+<h2 id="为什么要限制某些功能">为什么要限制某些功能?</h2>
+
+<p>有些APIs是非常强大的, 能给攻击者更强的能力以及更多的操作:</p>
+
+<ul>
+ <li>侵犯用户隐私.</li>
+ <li>获得对用户计算机的低级访问权限.</li>
+ <li>获得对数据的访问权限，例如用户凭证.</li>
+</ul>
+
+<h2 id="When_is_a_context_considered_secure">When is a context considered secure?</h2>
+
+<p>A context is considered secure when it meets certain minimum standards of authentication and confidentiality defined in the <a href="https://w3c.github.io/webappsec-secure-contexts/">Secure Contexts</a> specification. A particular document is considered to be in a secure context when it is the <a href="https://html.spec.whatwg.org/multipage/browsers.html#active-document">active document</a> of a <a href="https://html.spec.whatwg.org/multipage/browsers.html#top-level-browsing-context">top-level browsing context</a> (basically, a containing window or tab) that is a secure context.</p>
+
+<p>For example, even for a document delivered over TLS within an {{HTMLElement("iframe")}}, its context is <strong>not</strong> considered secure if it has an ancestor that was not also delivered over TLS.</p>
+
+<p>However, it’s important to note that if a non-secure context causes a new window to be created (with or without specifying <a href="/en-US/docs/Web/API/Window/open#noopener">noopener</a>), then the fact that the opener was insecure has no effect on whether the new window is considered secure. That’s because the determination of whether or not a particular document is in a secure context is based only on considering it within the top-level browsing context with which it is associated — and not whether a non-secure context happened to be used to create it.</p>
+
+<p>Locally-delivered resources such as those with <em>http://127.0.0.1</em> URLs, <em>http://localhost</em> URLs (under certain conditions), and <em>file://</em> URLs are also considered to have been delivered securely.</p>
+
+<p>Resources that are not local, to be considered secure, must meet the following criteria:</p>
+
+<ul>
+ <li>must be served over <em>https://</em> or <em>wss://</em> URLs</li>
+ <li>the security properties of the network channel used to deliver the resource must not be considered deprecated</li>
+</ul>
+
+<h2 id="Feature_detection">Feature detection</h2>
+
+<p>Pages can use feature detection to check whether they are in a secure context or not by using the {{domxref("WindowOrWorkerGlobalScope.isSecureContext", "isSecureContext")}} boolean, which is exposed on the global scope.</p>
+
+<pre class="brush: js notranslate">if (window.isSecureContext) {
+  // Page is a secure context so service workers are now available
+  navigator.serviceWorker.register("/offline-worker.js").then(function () {
+    ...
+  });
+}</pre>
+
+<h2 id="Specifications">Specifications</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <td>Specification</td>
+   <td>Status</td>
+   <td>Comment</td>
+  </tr>
+  <tr>
+   <td>{{SpecName('Secure Contexts')}}</td>
+   <td>{{Spec2('Secure Contexts')}}</td>
+   <td>Editor’s Draft</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="See_also">See also</h2>
+
+<ul>
+ <li><a href="/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts">Platform features restricted to secure contexts</a> — a list of the features available only in secure contexts</li>
+ <li>{{domxref("Window.isSecureContext")}}</li>
+ <li><a href="https://permission.site">https://permission.site</a> — A site that allows you to check what API permission checks your browser employs, over HTTP and HTTPS</li>
+ <li><a href="/en-US/docs/Web/HTTP/Headers/Strict-Transport-Security">Strict-Transport-Security</a> HTTP header</li>
+</ul>
+
+<div>{{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}</div>
diff --git a/files/zh-cn/web/security/securing_your_site/configuring_server_mime_types/index.html b/files/zh-cn/web/security/securing_your_site/configuring_server_mime_types/index.html
new file mode 100644
index 0000000000..577aacfb08
--- /dev/null
+++ b/files/zh-cn/web/security/securing_your_site/configuring_server_mime_types/index.html
@@ -0,0 +1,118 @@
+---
+title: Properly Configuring Server MIME Types
+slug: Web/Security/Securing_your_site/Configuring_server_MIME_types
+tags:
+  - HTTP
+translation_of: Learn/Server-side/Configuring_server_MIME_types
+---
+<h2 id="Background" name="Background">Background</h2>
+
+<p>默认情况下，许多web服务器会为那些未知内容类型的文件配置一个默认MIME类型<code>text/plain</code> 或者<code>application/octet-stream</code> 。当一种新的内容类型被创造或者被添加到web服务器上，web管理者在添加它到web服务器配置中可能会失败。主要原因是用户使用Gecko-based 的浏览器，而这种浏览器只相信由web服务器和web应用所发布的MIME类型</p>
+
+<h3 id="What_are_MIME_types.3F" name="What_are_MIME_types.3F">What are MIME types?</h3>
+
+<p>MIME类型描述了邮件或者web服务器或者web应用中的媒体内容的类型，其目的是为了指导web浏览器对媒体内容的处理和表现。MIME类型的示例如下：</p>
+
+<ul>
+ <li><code>text/html</code>  对于一般网页</li>
+ <li><code>text/plain</code> 对于一般文本</li>
+ <li><code>text/css</code> 对于级联样式表</li>
+ <li><code>text/javascript</code> 对于脚本</li>
+ <li><code>application/octet-stream</code> 意味着“下载这个文件”</li>
+ <li><code>application/x-java-applet</code> 对于 Java applets</li>
+ <li><code>application/pdf</code> 对于 PDF 文档</li>
+</ul>
+
+<h3 id="Technical_Background" name="Technical_Background">Technical Background</h3>
+
+<p>完整的MIME类型列表可在 <a class="external" href="http://www.iana.org/assignments/media-types/index.html">IANA | MIME Media Types</a> 查看.</p>
+
+<p>在<a class="external" href="http://www.w3.org/Protocols/HTTP/1.1/spec.html">HTTP specification</a> 中定义了能够描述在web中使用的媒体类型的MIME超集。</p>
+
+<h3 id="Why_are_correct_MIME_types_important.3F" name="Why_are_correct_MIME_types_important.3F">Why are correct MIME types important?</h3>
+
+<p><img alt="Example of an incorrect MIME type result" class="internal" src="/@api/deki/files/729/=Incorrect-mime-screen.jpg" style="float: right;"> 假如web服务器或者应用报告内容的MIME类型不正确，根据HTTP规范，或许发起人想要处理和显示内容通过他所规定的MIME类型，因此web浏览器无法采取任何措施。</p>
+
+<p>对于某些浏览器，例如IE，它尝试允许web服务器对于错误配置通过其源码猜测它可能的正确MIME类型。</p>
+
+<p>这种做法将会避免许多由web管理员他们的错误。因为当内容的MIME类型错误，IE将会用可能正确的MIME类型来继续处理内容。例如你设置一个<code>img</code>的类型为<code>text/plain</code> ,IE可能会设置它为正确的MIME类型<code>images/*</code></p>
+
+<p>出于安全原因，使用正确的MIME类型的服务内容也是重要的； 恶意内容可能会影响用户的计算机，假装它是一个安全类型文档，实际上不是。</p>
+
+<div class="note">
+<p><strong>注意:</strong> 从历史角度, 只要HTML文档请求处理CSS文件 ，Firefox 能够正常加载CSS即使它设置了错误的MIME类型。处于安全原因, {{ gecko("2.0") }} 对于从请求文档不同来源加载的样式表，将不再这样做。如果CSS来自于不同来源，你必须设置它的正确MIME类型 (<code>text/css</code>).</p>
+
+<p>Gecko 1.9.1.11 (Firefox 3.5.11) 和 Gecko 1.9.2.5 (Firefox 3.6.5) 同样实施这种安全措施，但是提高它的实用性。如果样式表中的第一行看起来是一个很好的CSS构造，则存在允许加载的临时启发式算法。在Firefox 4中已经删除了启发式，您必须正确设置<code>text/css</code> 的MIME类型，才能够识别CSS。</p>
+</div>
+
+<h2 id="Why_browsers_should_not_guess_MIME_types" name="Why_browsers_should_not_guess_MIME_types">为何浏览器不应该猜测 MIME 类型</h2>
+
+<p>除了违返了HTTP规范，让浏览器去猜测正确的MIME类型是一个差劲的策略。原因如下</p>
+
+<h4 id="Loss_of_control" name="Loss_of_control">失去控制</h4>
+
+<p>假如浏览器忽略报告的MIME类型，web管理员和用户不在对内容如何进行处理有发言权了。</p>
+
+<p>例如，面对web开发员的网址可能希望发送某些实例HTML文档，同时通希望能够以 <code>text/html</code>或者 <code>text/plain</code> 的MIME类型进行数据的处理和显示 或者 作为一个源代码。如果浏览器猜测它的正确MIME类型为 <code>text/html</code> 那么开发员不在有权利进行选择了。</p>
+
+<h4 id="Security" name="Security">安全性</h4>
+
+<p>一些内容类型，例如可执行程序，本质上是不安全的。原因是经过规范化的MIME类型都有经过严格规定浏览器如何对这类类型的文件进行操作。一个可执行程序不能够在用户的电脑浏览器上执行，但可以通过弹出会话询问是否下载这个文件</p>
+
+<p>MIME类型猜测导致IE浏览器的安全漏洞（通过利用IE能够将错误的MIME类型 修改为正确的类型）。这绕过了正常的下载对话框，导致InternetExplorer猜测内容是可执行程序，然后在用户的计算机上运行。</p>
+
+<h2 id="如何确定服务器发送内容的_MIME_类型">如何确定服务器发送内容的 MIME 类型</h2>
+
+<p>通过开发者工具的 ContentType 查看MIME类型。</p>
+
+<p>根据标准，通过一个 <code>meta</code> 标签来设置MIME类型 例如 <code><span class="nowiki">&lt;meta http-equiv="Content-Type" content="text/html"&gt;</span></code><span class="nowiki"> 当包含</span>{{HTTPHeader("Content-Type")}} 时则忽略 <code>meta</code> 标签</p>
+
+
+
+<h2 id="如何为你的内容确定正确的_MIME_类型">如何为你的内容确定正确的 MIME 类型</h2>
+
+<p>这里有几种方法来确定文件的正确MIME类型</p>
+
+<ol>
+ <li>如果你的内容是通过供应商软件应用创建的，那么你可以阅读供应商文档确认不同媒体文件的MIME值</li>
+ <li>通过查看完整的MIME类型表 <a class="external" href="http://www.iana.org/assignments/media-types/index.html">IANA | MIME Media Types registry</a> </li>
+ <li>如果使用插件netscape gecko显示媒体类型，请安装插件，然后查看“帮助”&gt;“关于插件”菜单，以查看哪些MIME类型与媒体类型相关联。</li>
+ <li>搜索文件扩展名 <a class="external" href="http://filext.com/">FILExt</a> 或者<a class="external" href="http://www.file-extensions.org/">File extensions reference</a> ，确认扩展名和哪种类型的MIME相关联</li>
+</ol>
+
+<h2 id="如何设置服务器以发送正确的MIME类型">如何设置服务器以发送正确的MIME类型</h2>
+
+<p>基本的方法是配置你的服务器发送正确的HTTP <code>ContentType</code>类型给每个文档</p>
+
+<ul>
+ <li>如果您正在使用Apache Web服务器，只需将此示例.htaccess文件复制到包含要使用正确MIME类型发送的文件的目录中。 如果你有一个完整的文件子目录，只需将文件放在父目录中；您不需要将它放在每个子目录中。</li>
+ <li>如果您使用的是Microsoft IIS, 请参阅<a href="http://www.iana.org/assignments/media-types/index.html">IANA | MIME Media Types registry</a>这篇文章。</li>
+ <li>如果您使用服务器端脚本生成内容，通常可以在脚本顶部附近添加一行。 您可以从Perl，PHP，ASP或Java提供HTML以外的内容 - 只需相应地更改MIME类型即可。
+  <ul>
+   <li>对于 Perl CGI，你应该在文档其他行之前输出 <code>print "Content-Type: text/html\n\n";</code>。如果您正在使用CGI模块, 你可以使用 <code>print $cgi-&gt;header('text/html');</code>  代替, 其中 <code>$cgi</code> 是对CGI实例的引用。</li>
+   <li>对于 PHP，你应该在文档其他行之前输出 <code>header('Content-Type: text/html');</code>。</li>
+   <li>对于 ASP, 你应该在文档其他行之前输出<code>response.ContentType = "text/html";</code>。</li>
+   <li>对于 Java servlet, 你需要在<code>doGet</code> 或 <code>doPost</code> 方法之前输出<code>response.setContentType("text/html");</code> ，其中 <code>response</code> 是对 <code>HttpServletResponse</code>的引用。</li>
+  </ul>
+ </li>
+</ul>
+
+<h3 id="Related_Links" name="Related_Links">Related Links</h3>
+
+<ul>
+ <li><a href="/en/Incorrect_MIME_Type_for_CSS_Files" title="en/Incorrect_MIME_Type_for_CSS_Files">Incorrect MIME Type for CSS Files</a></li>
+ <li><a class="external" href="http://www.iana.org/assignments/media-types/index.html">IANA | MIME Media Types</a></li>
+ <li><a class="external" href="http://www.w3.org/Protocols/HTTP/1.1/spec.html">Hypertext Transfer Protocol — HTTP/1.1</a></li>
+ <li><a class="external" href="http://support.microsoft.com/default.aspx?sd=msdn&amp;scid=kb;en-us;293336">Microsoft - 293336 - INFO: WebCast: MIME Type Handling in Microsoft Internet Explorer</a></li>
+ <li><a class="external" href="http://msdn.microsoft.com/workshop/networking/moniker/overview/appendix_a.asp">Microsoft - Appendix A: MIME Type Detection in Internet Explorer</a></li>
+ <li><a class="external" href="http://www.microsoft.com/windows/ie/downloads/critical/q290108/">Microsoft - Security Update, March 29, 2001</a></li>
+ <li><a class="external" href="http://www.microsoft.com/windows/ie/downloads/critical/Q313675/">Microsoft - Security Update, December 13, 2001</a></li>
+</ul>
+
+<div class="originaldocinfo">
+<h3 id="Original_Document_Information" name="Original_Document_Information">Original Document Information</h3>
+
+<ul>
+ <li>Author: Bob Clary, date: 20 Feb 2003</li>
+</ul>
+</div>
diff --git a/files/zh-cn/web/security/securing_your_site/index.html b/files/zh-cn/web/security/securing_your_site/index.html
new file mode 100644
index 0000000000..be94236abd
--- /dev/null
+++ b/files/zh-cn/web/security/securing_your_site/index.html
@@ -0,0 +1,48 @@
+---
+title: 确保你的站点安全
+slug: Web/Security/Securing_your_site
+tags:
+  - HTTP
+  - NeedsTranslation
+  - Security
+  - TopicStub
+  - Web Development
+translation_of: Web/Security/Securing_your_site
+---
+<p>{{ draft() }}</p>
+
+<p>你可以采取一些措施来确保你的网站安全。本文提供了各种建议，以及提供更多有用信息的其他文章的链接。</p>
+
+<div class="note"><strong>Note:</strong> This article is a work in progress, and is neither complete nor does following its suggestions guarantee your site will be fully secure.</div>
+
+<h2 id="用户信息安全">用户信息安全</h2>
+
+<dl>
+ <dt><a href="/en/How_to_Turn_Off_Form_Autocompletion" title="en/How to Turn Off Form Autocompletion">如何关闭表单的自动完成功能</a></dt>
+ <dd>在Gecko中表单字段支持自动完成功能; 因此他们的值可以被记住，并且在下一次用户访问你的网站时自动被填充. 对于某些特定类型的数据, 你可能希望禁止这个功能.</dd>
+ <dt><a href="/en/CSS/Privacy_and_the_:visited_selector" title="en/CSS/Privacy and the :visited selector">隐私和:visited选择器</a></dt>
+ <dd>这篇文章讨论对于<code>getComputedStyle()</code>方法的改动, 消除恶意站点获取用户浏览历史的能力.</dd>
+</dl>
+
+<h2 id="内容安全">内容安全</h2>
+
+<dl>
+ <dt><a href="/en/Properly_Configuring_Server_MIME_Types" title="en/Properly Configuring Server MIME Types">正确配置服务器的 MIME 类型</a></dt>
+ <dd>不正确的 MIME 类型有几种方式可以对您的站点造成潜在的安全问题. 这篇文章解释了其中的几种方式, 并且向您展示如何配置您的服务器，以让它使用正确的 MIME 类型提供文件服务.</dd>
+ <dt><a href="/en/Security/HTTP_Strict_Transport_Security" title="en/Security/HTTP Strict Transport Security">HTTP Strict Transport Security</a></dt>
+ <dd><code>Strict-Transport-Security:</code>  这个HTTP头允许站点只能使用 HTTPS。</dd>
+ <dt><a href="/En/HTTP_access_control" title="En/HTTP access control">HTTP 访问控制</a></dt>
+ <dd><span class="tlid-translation translation" lang="zh-CN"><span title="">跨源资源共享标准提供了一种指定可从其他域加载的内容的方法。</span> <span title="">您可以使用它来防止您的网站被不正当地使用;</span> <span title="">此外，您可以使用它来建立明确允许其他站点使用的资源。</span></span></dd>
+ <dt><a href="/en/Security/CSP" title="en/Security/CSP">内容安全策略</a></dt>
+ <dd>一种附加的安全层，有助于检测和减轻某些类型的攻击，包括跨站脚本(XSS) 以及数据注入攻击。 <span class="tlid-translation translation" lang="zh-CN"><span title="">这些攻击用于从数据窃取到站点破坏或恶意软件分发的所有内容。</span></span></dd>
+ <dt><a href="/en-US/docs/Web/HTTP/X-Frame-Options" title="en/The X-FRAME-OPTIONS response header">X-Frame-Options 响应头</a></dt>
+ <dd>
+ <p><code>X-Frame-Options:</code>该<a href="/en/HTTP" title="en/HTTP">HTTP</a> <span class="tlid-translation translation" lang="zh-CN">响应头可用于指示是否应允许浏览器在{{HTMLElement("frame")}}中呈现页面。站点可以通过确保其内容未嵌入到其他站点中来避免点击劫持攻击。</span></p>
+ </dd>
+</dl>
+
+<h2 id="另外参考">另外参考</h2>
+
+<ul>
+ <li><a class="external" href="http://www.owasp.org/">开放Web应用程序安全项目 (OWASP)</a></li>
+</ul>
diff --git a/files/zh-cn/web/security/securing_your_site/turning_off_form_autocompletion/index.html b/files/zh-cn/web/security/securing_your_site/turning_off_form_autocompletion/index.html
new file mode 100644
index 0000000000..fe8e97cdef
--- /dev/null
+++ b/files/zh-cn/web/security/securing_your_site/turning_off_form_autocompletion/index.html
@@ -0,0 +1,73 @@
+---
+title: 如何关闭表单自动填充
+slug: Web/Security/Securing_your_site/Turning_off_form_autocompletion
+tags:
+  - Autocompletion
+  - Forms
+  - 安全
+  - 指南
+  - 自动填充
+  - 表单
+translation_of: Web/Security/Securing_your_site/Turning_off_form_autocompletion
+---
+<p>本文介绍了网站如何禁用表单字段的自动完成功能。</p>
+
+<p>默认情况下，浏览器会记录用户网页上提交的<a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input">输入</a>框的信息。这使得浏览器能够提供自动补全（在用户开始输入的时候给用户提供可能的内容）和自动填充（在加载的时候预先填充某些字段）功能。</p>
+
+<p>这些功能通常是默认启用的，但可能涉及用户的隐私，因此浏览器允许用户禁用这些功能。然而，一些数据可能会在将来失效（例如一次性密码）或包含敏感信息（例如唯一的政府身份识别码或信用卡安全码）。作为网站作者，你可能更希望浏览器不去记住这些字段的值，即使浏览器的自动填充功能已开启。</p>
+
+<p>重要的是，如果你关闭了自动填充，你就违反了这一条规则，<a href="https://www.w3.org/WAI/WCAG21/Understanding/identify-input-purpose.html">1.3.5: Identify Input Purpose in WCAG 2.1</a>。如果你制作的网站应该遵守WCAG，你就应该使用自动填充和自动补全。</p>
+
+<h2 id="禁用自动填充">禁用自动填充</h2>
+
+<p>要禁用的表单自动填充，你可以将 {{htmlattrxref("autocomplete", "input")}} 的属性设置为 "off"：</p>
+
+<pre class="brush: html notranslate">autocomplete="off"</pre>
+
+<p>可以为整个表单设置或为表单中某个输入元素单独设置：</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> 会有两种效果：</p>
+
+<ul>
+ <li>这会告诉浏览器，不要为了以后在类似表单上自动填充而保存用户输入的数据。但浏览器不一定遵守。</li>
+ <li>这会阻止浏览器缓存会话历史记录中的数据。若表单数据缓存于会话历史记录，用户提交表单后，再点击返回按钮返回之前的表单页面，则会显示用户之前输入的数据。</li>
+</ul>
+
+<p>如果即使在 autocomplete 已经设置为 off 时，浏览器仍继续提供输入建议，那么你需要更改输入元素的 name 属性。</p>
+
+<h2 id="自动填充属性和登录">自动填充属性和登录</h2>
+
+<p>现代浏览器实现了内建的密码管理功能：当用户在一个网站上输入了用户名和密码，浏览器会为用户提供记忆功能。当用户再次访问这个网站时，浏览器使用保存的值自动填写登录字段。</p>
+
+<p>另外，浏览器可让用户指定一个主密码用来加密存储的登录信息。</p>
+
+<p>即使没有主密码，浏览器内置的密码管理对安全也有益无害。由于用户不需要记住已被浏览器存储的密码，因此他们可以放心选择更强的密码。</p>
+
+<p>由于这个原因，许多现代浏览器都不支持在登录字段中设置 <code>autocomplete="off"</code> ：</p>
+
+<ul>
+ <li>如果一个网站为<a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/form">表单</a>设置了<code>autocomplete="off"</code>，表单中包含用户名和密码字段，浏览器仍会为这次登录提供记忆功能，并且如果用户同意，用户在下一次访问网站时，浏览器会自动填写这些字段。</li>
+ <li>如果网站给用户名和密码的<a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input">输入</a>框设置了 <code>autocomplete="off"</code>，浏览器仍会为这次登录提供记忆功能，并且如果用户同意，用户在下一次访问网站时，浏览器会自动填写这些字段。</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>autocomplete="new-password"</code> 的 <code>&lt;input&gt;</code> 元素上使用自动填充。例如，Firefox 67 版（见 {{bug(1119063)}}）在这种情况下会停止自动填充；而 Firefox 70版（见 {{bug(1565407)}}）则可以建议一个安全生成的密码，而不自动填充已保存的密码。更多细节参见  <a href="https://wiki.developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete#Browser_compatibility"><code>autocomplete</code> compat table</a>。</p>
+
+<p>{{QuickLinksWithSubpages("/en-US/docs/Web/Security")}}</p>
diff --git a/files/zh-cn/web/security/site_identity_button/index.html b/files/zh-cn/web/security/site_identity_button/index.html
new file mode 100644
index 0000000000..fff6661ffd
--- /dev/null
+++ b/files/zh-cn/web/security/site_identity_button/index.html
@@ -0,0 +1,27 @@
+---
+title: Site Identity Button
+slug: Web/Security/Site_Identity_Button
+tags:
+  - 安全
+  - 火狐
+translation_of: Mozilla/Firefox/Site_identity_button
+---
+<p> <a href="https://support.mozilla.org/kb/how-do-i-tell-if-my-connection-is-secure">Site Identity Button</a> 是火狐的一个特性，用于向用户提示更多他们已经访问过的网站的信息。</p>
+
+<p>这个特性的使用取决于你网站的配置，按钮会显示许多不同的图标。</p>
+
+<p>如果站点身份按钮没有按照您的配置显示出来的话（如你想要看到一个绿色的锁却显示一个橙色的三角图标），你可以打开<a href="/en-US/docs/Tools/Web_Console">火狐开发者工具的控制台</a>，在控制台里能找到一些原因：</p>
+
+<ol>
+ <li>确定您的控制台在'security'目录下显示信息。</li>
+ <li>强制刷新有问题的站点</li>
+ <li>耐心等待可能会出现的一些安全信息</li>
+</ol>
+
+<p>由于以下的原因之一，UI的安全等级将会降低：</p>
+
+<ul>
+ <li>mixed content - 页面是经过TLS传输，但是页面没有经过subresources加载；这种情况下，在控制台里会看到‘mixed content’的信息提示。</li>
+ <li>Use of a weak cipher - 当使用TLS时而强密码是不可用的，会显示一些关于弱密码的信息提示（如RC4）</li>
+ <li>Insecure renegotation - 老版本的TLS在设计上有一个缺陷；如果您的服务在使用低版本的TLS，UI的等级将会降低且控制台不会有任何信息提示。</li>
+</ul>
diff --git a/files/zh-cn/web/security/传输层安全协议/index.html b/files/zh-cn/web/security/传输层安全协议/index.html
new file mode 100644
index 0000000000..ed6e6bb128
--- /dev/null
+++ b/files/zh-cn/web/security/传输层安全协议/index.html
@@ -0,0 +1,18 @@
+---
+title: 传输层安全协议
+slug: Web/Security/传输层安全协议
+tags:
+  - 传输层安全协议
+  - 安全
+  - 密码学
+translation_of: Web/Security/Transport_Layer_Security
+---
+<p><span class="seoSummary">使用传输层安全性协议（TLS）进行的任何连接的安全性在很大程度上取决于密码套件和所选的安全性参数。 本文的目的是帮助您确保客户端和服务器之间的机密性和完整性通信。</span>Mozilla运营安全团队（OpSec）维护了 <a href="https://wiki.mozilla.org/Security/Server_Side_TLS">服务器端TLS参考配置的Wiki条目</a>。</p>
+
+<p class="summary">传输层安全性协议（Transport Layer Security protocol，TLS）是使两个联网应用程序或设备能够安全可靠地交换信息的标准。使用TLS的应用程序可以自行选择安全性参数，这可能会对数据的安全性和可靠性产生重大影响。本文对TLS进行了概述，并提供了多种在保护内容时需要做出的决策。</p>
+
+<h3 id="另请参阅">另请参阅</h3>
+
+<ul>
+ <li><a href="https://cipherli.st/">Cipherli.st's</a> 此网站为各种各样的软件产品列出了强大的TLS配置信息供参考。</li>
+</ul>
diff --git a/files/zh-cn/web/security/子资源完整性/index.html b/files/zh-cn/web/security/子资源完整性/index.html
new file mode 100644
index 0000000000..86c80188c0
--- /dev/null
+++ b/files/zh-cn/web/security/子资源完整性/index.html
@@ -0,0 +1,199 @@
+---
+title: Subresource Integrity
+slug: Web/Security/子资源完整性
+tags:
+  - CORS
+  - SRI
+  - Security
+  - Subresource Integrity
+  - 子资源完整性
+translation_of: Web/Security/Subresource_Integrity
+---
+<p><strong>子资源完整性</strong>(SRI)是允许浏览器检查其获得的资源（例如从 <a href="/en-US/docs/Glossary/CDN">CDN</a> 获得的）是否被篡改的一项安全特性。它通过验证获取文件的哈希值是否和你提供的哈希值一样来判断资源是否被篡改。</p>
+
+<h2 id="SRI_如何工作">SRI 如何工作</h2>
+
+<p>使用 {{Glossary("CDN", "内容分发网络 (CDNs)")}} 在多个站点之间共享脚本和样式表等文件可以提高站点性能并节省带宽。然而，使用CDN也存在风险，如果攻击者获得对 CDN 的控制权，则可以将任意恶意内容注入到 CDN 上的文件中 （或完全替换掉文件)<br>
+ ），因此可能潜在地攻击所有从该 CDN 获取文件的站点。</p>
+
+<p>子资源完整性通过确保 Web 应用程序获得的文件未经第三方注入或其他任何形式的修改来降低这种攻击的风险。</p>
+
+
+
+<div class="note">
+<p><strong>Note</strong>: SRI并不能规避所有的风险。第三方库经常会自己请求额外的信息，这就有可能会携带用户的账号密码等关键信息。这些经常需要js功能的支持，比如一个地图库会需要取&lt;svg&gt;数据来渲染，但是包含点击事件。</p>
+</div>
+
+<h2 id="如何使用_SRI">如何使用 SRI</h2>
+
+<p>将使用 base64 编码过后的文件哈希值写入你所引用的 {{HTMLElement("script")}} 或 {{HTMLElement("link")}} 标签的 <strong>integrity</strong> 属性值中即可启用子资源完整性功能。</p>
+
+<p>integrity 值分成两个部分，第一部分指定哈希值的生成算法（目前支持 sha256、sha384 及 sha512），第二部分是经过 base64 编码的实际哈希值，两者之间通过一个短横（-）分割。</p>
+
+<div class="note">
+<p><strong>integrity</strong> 值可以包含多个由空格分隔的哈希值，只要文件匹配其中任意一个哈希值，就可以通过校验并加载该资源。</p>
+</div>
+
+<p>使用 base64 编码 sha384 算法计算出摘要后的 <strong>integrity</strong> 值的例子：</p>
+
+<pre>sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC
+</pre>
+
+<p><code>oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC</code> 即哈希值部分，<code>sha384</code> 前缀说明使用的是 sha384 哈希方法。</p>
+
+<div class="note">
+<p><strong>integrity</strong> 中的“hash”部分，严格来说，是一种经过特定的哈希函数转换之后的密码学摘要。但是更一般的叫法就是<strong>哈希</strong>，本文用的也是这种叫法。</p>
+</div>
+
+<h3 id="生成_SRI_哈希的工具">生成 SRI 哈希的工具</h3>
+
+<p>你可以用 <strong>openssl</strong> 在命令行中执行如下命令来生成 SRI 哈希值：</p>
+
+<pre>cat <strong>FILENAME.js</strong> | openssl dgst -sha384 -binary | openssl enc -base64 -A         </pre>
+
+<p>或者用 <strong>shasum</strong> 在命令行中执行：</p>
+
+<pre><code>shasum -b -a 384 FILENAME.js | xxd -r -p | base64</code></pre>
+
+<p><code>另外，</code><a href="https://srihash.org/">SRI Hash Generator</a> 是一个在线生成 SRI 哈希值的工具。</p>
+
+<h2 id="内容安全策略及子资源完整性">内容安全策略及子资源完整性</h2>
+
+<p>你可以根据<a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP">内容安全策略</a>来配置你的服务器使得指定类型的文件遵守 SRI。这是通过在 CSP 头部添加 {{CSP("require-sri-for")}} 指令实现的：</p>
+
+<pre><code>Content-Security-Policy: require-sri-for script;</code></pre>
+
+<p><code>这条指令规定了所有 JavaScript 都要有 <strong>integrity</strong> 属性，且通过验证才能被加载。</code></p>
+
+<p>你也可以指定所有样式表也要通过 SRI 验证：</p>
+
+<pre><code>Content-Security-Policy: require-sri-for style;</code></pre>
+
+<p><code>你也可以对两者都加上验证。</code></p>
+
+<h2 id="范例">范例</h2>
+
+<p>在这个例子中，我们已知 <code id="sriSnippet">oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/uxy9rx7HNQlGYl1kPzQho1wx4JwY8wC 是一个指定文件，比如 </code><code>example-framework.js，经过 SHA-384</code> 算法得出的摘要，同时在 <code>https://example.com/example-framework.js 上有其一份拷贝。</code></p>
+
+<h3 id="在_script_标签中增加_SRI">在 script 标签中增加 SRI</h3>
+
+<p>你可以使用以下的 {{HTMLElement("script")}} 元素告诉浏览器在执行 https://example.com/example-framework.js 中的内容之前，必须先比较该文件的哈希值是否和预期的一致，只有一致才能执行。</p>
+
+<pre class="brush: html">&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>crossorigin </strong>属性的更多信息，见 <a href="/en-US/docs/Web/HTML/CORS_settings_attributes">CORS settings attributes</a>.</p>
+</div>
+
+<h2 id="浏览器如何处理_SRI">浏览器如何处理 SRI</h2>
+
+<p>浏览器根据以下步骤处理 SRI：</p>
+
+<ol>
+ <li>当浏览器在  {{HTMLElement("script")}} 或者 {{HTMLElement("link")}}  标签中遇到 <strong>integrity</strong> 属性之后，会在执行脚本或者应用样式表之前对比所加载文件的哈希值和期望的哈希值。</li>
+ <li>当脚本或者样式表的哈希值和期望的不一致时，浏览器必须拒绝执行脚本或者应用样式表，并且必须返回一个网络错误说明获得脚本或样式表失败。</li>
+</ol>
+
+<h2 id="规范">规范</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">规范</th>
+   <th scope="col">状态</th>
+   <th scope="col">注释</th>
+  </tr>
+  <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="浏览器兼容性">浏览器兼容性</h2>
+
+<p>{{CompatibilityTable}}</p>
+
+<div id="compat-desktop">
+<table class="compat-table">
+ <tbody>
+  <tr>
+   <th>Feature</th>
+   <th>Chrome</th>
+   <th>Firefox (Gecko)</th>
+   <th>Internet Explorer</th>
+   <th>Opera</th>
+   <th>Safari</th>
+  </tr>
+  <tr>
+   <td>The integrity attribute for <code>&lt;script&gt;</code> and <code>&lt;link&gt;</code></td>
+   <td>{{ CompatChrome("45.0") }}</td>
+   <td>{{ CompatGeckoDesktop("43") }}</td>
+   <td>{{CompatNo}}</td>
+   <td>{{CompatOpera("32")}}</td>
+   <td>{{CompatNo}} [1]</td>
+  </tr>
+  <tr>
+   <td>The CSP {{CSP("require-sri-for")}} directive</td>
+   <td>{{CompatUnknown}}</td>
+   <td>{{ CompatGeckoDesktop("49") }}</td>
+   <td>{{CompatUnknown}}</td>
+   <td>{{CompatUnknown}}</td>
+   <td>{{CompatUnknown}}</td>
+  </tr>
+ </tbody>
+</table>
+</div>
+
+<div id="compat-mobile">
+<table class="compat-table">
+ <tbody>
+  <tr>
+   <th>Feature</th>
+   <th>Chrome for Android</th>
+   <th>Firefox Mobile (Gecko)</th>
+   <th>IE Mobile</th>
+   <th>Opera Mobile</th>
+   <th>Safari Mobile</th>
+  </tr>
+  <tr>
+   <td>The integrity attribute for <code>&lt;script&gt;</code> and <code>&lt;link&gt;</code></td>
+   <td>{{ CompatChrome("45.0") }}</td>
+   <td>{{CompatGeckoMobile("43")}}</td>
+   <td>{{CompatNo}}</td>
+   <td>{{CompatNo}}</td>
+   <td>{{CompatNo}} [1]</td>
+  </tr>
+  <tr>
+   <td>The CSP {{CSP("require-sri-for")}} directive</td>
+   <td>{{CompatUnknown}}</td>
+   <td>{{CompatGeckoMobile("49")}}</td>
+   <td>{{CompatUnknown}}</td>
+   <td>{{CompatUnknown}}</td>
+   <td>{{CompatUnknown}}</td>
+  </tr>
+ </tbody>
+</table>
+</div>
+
+<p>[1] {{WebKitBug(148363)}}</p>
+
+<p>[2] 位于 <code>security.csp.experimentalEnabled</code> 之后的是: config preference。</p>
+
+<h2 id="相关资料">相关资料</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>
+</ul>
+
+<p>{{QuickLinksWithSubpages("/zh-CN/docs/Web/Security")}}</p>