内容安全策略 (CSP) Header：在每个文件上还是仅在实际的 HTML 页面上？
Content Security Policy (CSP) Header: Onto each file or only the actual HTML pages?
我目前正在将内容安全策略 (CSP) header 添加到我们的应用程序中。我想知道 header 必须附加到哪些文件。经过一番研究，我没有找到明确的答案。
推特，例如仅将其添加到实际的 HTML 文档中。然而，Facebook 将它添加到几乎所有资源和 HTML 文档（HTML、JS、CSS 等）。
那么，是否需要将内容安全策略 header 添加到每个服务的资源文件或仅添加到 HTML 文档？它如何处理 Ajax（JSON 内容）请求？它如何与 SPA 一起使用（仅 index.html 文件或所有资源）？如果从安全角度来看没有必要，我不想通过向每个文件添加长 CSP headers 来减慢页面速度。
编辑：
澄清一下：当图像或其他 non-document 资源附带 CSP header 时，浏览器会以不同的方式对待它们吗？
CSP 并不是针对内容注入漏洞的第一道防线。
...
新答案二
问题：
To clarify: Do browser treat images or other non-document resources differently when they come with a CSP header attached?
我的回答：
首先定义'non-document'？ W3（设定互联网实际运作方式的人）有一个 definition of "document"，我假设你的定义是相同的。
如果不是，请相应说明。
W3 内容安全策略规则（截至 2018 年 10 月）规定 the goals of CSP 是：
Mitigate the risk of content-injection attacks by giving developers fairly granular control over:
The resources which can be requested (and subsequently embedded or executed) on behalf of a specific Document or Worker
The execution of inline script
Dynamic code execution (via eval() and similar constructs)
The application of inline style
Mitigate the risk of attacks which require a resource to be embedded in a malicious context (the "Pixel Perfect" attack described
in [TIMING], for example) by giving developers granular control over
the origins which can embed a given resource.
Provide a policy framework which allows developers to reduce the privilege of their applications.
Provide a reporting mechanism which allows developers to detect flaws being exploited in the wild.
注意点 1(i);
"The resources which can be requested (and subsequently embedded or executed) on behalf of a specific Document or Worker"
文档的定义如上，作品的定义 - 本质上 - 是使用 JavaScript DOM 模型的东西（这可能不正确 ).
因此 CSP 预计适用于 documents（给定的）和 workers.
Are other (MP3, PDF, etc.) files documents or workers?
它们不是文档，但它们在浏览器中的处理方式 确实暗示它们包含在文档结构中。
请看这个old Chrome Bug report。由于网站 CSP 设置，PDF 无法加载内容，而 PDF 实际上是由浏览器插件（所有现代浏览器的原生插件）加载的，因此受到 object-src CSP 的影响。
这是 CSP 版本 1，我没有理由认为浏览器处理 non-document 文件的方式或 CSP 集成的方式自提交该错误以来发生了重大变化。
因此：浏览器 不需要 将 CSP 应用于 non-document 和 non-worker objects，但由于浏览器的操作方式，它们可能会将 CSP headers 应用到 non-document 和 non-worker objects，事实上这些 objects 将被包装在文档模型中以便于浏览器处理文件在它自己里面。
但是这是由浏览器自行决定的编码，预计到 2018 年 10 月不会出现这种情况。
较早的答案 2：
问题：
To clarify: Do browser treat images or other non-document resources differently when they come with a CSP header attached?
没有
CSP makes it possible for server administrators to reduce or eliminate the vectors by which XSS can occur by specifying the domains that **the browser** should consider to be valid sources of **executable scripts**. A CSP compatible browser will then **only execute scripts** loaded in **source files received from those whitelisted domains**, ignoring all other script (including inline scripts and event-handling HTML attributes).
我的突出显示。资料来源：MDN Content Security Policy (CSP)
进一步解释：
CSP 仅 在以下情况下工作：
- 在数据内容
之前发送了正确的 CSP HTTP header
- 浏览器收到header
- 浏览器可以理解 header。
- 内容（
data）由浏览器接收并在浏览器中打开。
一个例子是 www.cspexample.com，在这个 Apache 驱动的网站上，Apache httpd.conf 设置了正确的 CSP headers 以阻止来自 google.com 的所有脚本
该网站托管一个文件：https://www.cspexample.com/document.pdf；这个文件以某种方式编写来打开一个 PDF，它调用一个 google 脚本来监视客户端机器上的按键（假设...）。
如果 PDF 在浏览器中打开，CSP header 会阻止这种情况发生并阻止此脚本。如果将 PDF 文件保存到计算机，然后在 Adobe PDF 文件查看器中打开，则不再启用此特定的 CSP 保护。 （其他缓解措施可能存在于 Adobe 程序中）。
当一个文件被下载到客户端机器上时（比如将恶意图像文件保存到磁盘上），CSP 不会在浏览器之外进行任何保护。
Why does it work this way?
CSP 是浏览器接收的一组 HTTP headers，是无状态的。将 HTTP 视为包裹的包装。有些包裹用不同的东西包装，例如新鲜水果的包装方式与游戏机的包装方式不同，但包装纸永远不知道里面到底是什么 - 如果您将游戏机包装成新鲜水果，它仍然会送达。
按照这个类比，包裹上有一个标签，上面写着“警告”和一些标准，它很脆弱等等。现在邮政服务的收件人看到了这一点并尊重它，因为那是她的工作。这是浏览器。然而，包裹可能会被随意扔给某个人（无论是 USB 驱动器、磁盘驱动器还是非常非常旧的浏览器），他们不会阅读警告标签并且会忽略警告 - 因为警告仅适用于邮政服务工人 - 从而允许内容连接到它想要的任何东西。
旧答案 1：
理想情况下，您应该在尽可能早的级别添加 CSP，例如在您的 Apache httpd.conf 文件或等效文件中——这样每次从您的网站调用任何内容时都会自动加载它, 因此它适用于每个资源。
一些资源，例如 JPEG 图像，可以很容易地 reference/call 以愚蠢的方式获取外部信息；不要仅仅因为它看起来良性就相信任何东西。一个主要（但可能无害）的例子是 Facebook 使用的 JPEG 图像，如下所述（见旁注）。
重新加载服务器：httpd.conf 信息保存在服务器内存中，因此没有 read/write 延迟等。
Ajax 与浏览器加载一样，只是一个调用o the/a 服务器上的脚本。
“从安全角度来看，什么是必要的”完全取决于您的系统面临哪些风险，您计划在 CSP 之外缓解这些风险，以及您想要投入多少时间和精力在 micro-seconds 的服务器加载时间或替代系统之间进行权衡。
CSP 完全是可选的。如果您想 micro-optimise 到您认为使用 CSP 对您的用户体验征税，这很公平......但您需要了解该选择和设置（几乎肯定会耗时) 替代方案，例如防火墙黑名单...
旁注：
Facebook 资源并不总是“真正的”资源 -- 它是一个 PHP 文件，加载数据（比如图像）并写入数据库并输出数据，就好像它只是图像一样适当的 PHP header.
旁注 2：
在 PHP 系统（以及许多其他系统）上，可以加载页面和资源并将其输出给最终用户，而该用户不会意识到访问正在通过代码库传递。例如：
<?php
///
/// Send data to a cURL request off site
///
/// Call image from a 3rd party provider.
///
/// Display image to end user as image.jpeg
///
你认为这只是一个图像，但在引擎盖下任何事情都可能发生。
此外，恶意的 JPEG 图像长期以来一直能够通过其元数据集访问第 3 方资源。
支持 HTTP Content Security Policy response header will prevent images (and other content) from loading for any page where the response header or a meta tag contains Content Security Policy directives that limit the domains considered as valid content sources, require all content to be loaded via HTTPS, etc. Most widely used modern browsers support Content Security Policy 并应用它来控制与任何 HTTP 请求关联的大部分内容资源（包括图像）的浏览器（除了 Web Worker 资源控制在 Safari 和 IE 中不受支持，并且可能不会在 Edge 或 Opera 中得到支持）。
您可以在您的内容安全策略中专门包含 img-src 策略指令，以限制被视为有效图像来源的域以及要求 HTTPS 方案等。还有特定指令可用于各种其他资源，包括字体、框架、媒体（音频、视频等）、脚本、样式表、网络工作者等。
您需要将您的内容安全策略作为 HTTP 响应的一部分包含在 header 中，该响应作为每个 HTTP 请求的一部分从您的 Web 服务器返回，您希望限制有效的内容源或确保请求的页面包含内容安全策略元标记，例如...
<meta http-equiv="Content-Security-Policy" content="default-src 'self';">
请注意，IE 10+ 浏览器支持内容安全策略响应 header 但不支持元标记（如果您想支持 IE，还需要注意一些具体的实施细节）。
slow down the page by adding long CSP headers to each file
据推测，304 未修改 状态 - CSP headers 未发送
- 仅在初始加载时
我的问题的正确答案是 另一个人的答案，
类似问题。它指的是 CSP 规范，该规范明确指出，该策略仅影响创建新“执行上下文”的资源。这意味着，没有必要将 CSP 添加到 REST API 响应中，这些响应不打算由浏览器打开。请参阅 or directly to the specification of W3，其中还包括如何处理不同资源（例如脚本、图像等）的 table。
我目前正在将内容安全策略 (CSP) header 添加到我们的应用程序中。我想知道 header 必须附加到哪些文件。经过一番研究，我没有找到明确的答案。
推特，例如仅将其添加到实际的 HTML 文档中。然而，Facebook 将它添加到几乎所有资源和 HTML 文档（HTML、JS、CSS 等）。
那么，是否需要将内容安全策略 header 添加到每个服务的资源文件或仅添加到 HTML 文档？它如何处理 Ajax（JSON 内容）请求？它如何与 SPA 一起使用（仅 index.html 文件或所有资源）？如果从安全角度来看没有必要，我不想通过向每个文件添加长 CSP headers 来减慢页面速度。
编辑：
澄清一下：当图像或其他 non-document 资源附带 CSP header 时，浏览器会以不同的方式对待它们吗？
CSP 并不是针对内容注入漏洞的第一道防线。
...
新答案二
问题：
To clarify: Do browser treat images or other non-document resources differently when they come with a CSP header attached?
我的回答：
首先定义'non-document'？ W3（设定互联网实际运作方式的人）有一个 definition of "document"，我假设你的定义是相同的。
如果不是，请相应说明。
W3 内容安全策略规则（截至 2018 年 10 月）规定 the goals of CSP 是：
Mitigate the risk of content-injection attacks by giving developers fairly granular control over:
The resources which can be requested (and subsequently embedded or executed) on behalf of a specific Document or Worker
The execution of inline script
Dynamic code execution (via eval() and similar constructs)
The application of inline style
Mitigate the risk of attacks which require a resource to be embedded in a malicious context (the "Pixel Perfect" attack described in [TIMING], for example) by giving developers granular control over the origins which can embed a given resource.
Provide a policy framework which allows developers to reduce the privilege of their applications.
Provide a reporting mechanism which allows developers to detect flaws being exploited in the wild.
注意点 1(i);
"The resources which can be requested (and subsequently embedded or executed) on behalf of a specific Document or Worker"
文档的定义如上，作品的定义 - 本质上 - 是使用 JavaScript DOM 模型的东西（这可能不正确 ).
因此 CSP 预计适用于 documents（给定的）和 workers.
Are other (MP3, PDF, etc.) files documents or workers?
它们不是文档，但它们在浏览器中的处理方式 确实暗示它们包含在文档结构中。
请看这个old Chrome Bug report。由于网站 CSP 设置，PDF 无法加载内容，而 PDF 实际上是由浏览器插件（所有现代浏览器的原生插件）加载的，因此受到 object-src CSP 的影响。
这是 CSP 版本 1，我没有理由认为浏览器处理 non-document 文件的方式或 CSP 集成的方式自提交该错误以来发生了重大变化。
因此：浏览器 不需要 将 CSP 应用于 non-document 和 non-worker objects，但由于浏览器的操作方式，它们可能会将 CSP headers 应用到 non-document 和 non-worker objects，事实上这些 objects 将被包装在文档模型中以便于浏览器处理文件在它自己里面。
但是这是由浏览器自行决定的编码，预计到 2018 年 10 月不会出现这种情况。
较早的答案 2：
问题：
To clarify: Do browser treat images or other non-document resources differently when they come with a CSP header attached?
没有
CSP makes it possible for server administrators to reduce or eliminate the vectors by which XSS can occur by specifying the domains that **the browser** should consider to be valid sources of **executable scripts**. A CSP compatible browser will then **only execute scripts** loaded in **source files received from those whitelisted domains**, ignoring all other script (including inline scripts and event-handling HTML attributes).
我的突出显示。资料来源：MDN Content Security Policy (CSP)
进一步解释：
CSP 仅 在以下情况下工作：
- 在数据内容 之前发送了正确的 CSP HTTP header
- 浏览器收到header
- 浏览器可以理解 header。
- 内容（
data）由浏览器接收并在浏览器中打开。
一个例子是 www.cspexample.com，在这个 Apache 驱动的网站上，Apache httpd.conf 设置了正确的 CSP headers 以阻止来自 google.com 的所有脚本
该网站托管一个文件：https://www.cspexample.com/document.pdf；这个文件以某种方式编写来打开一个 PDF，它调用一个 google 脚本来监视客户端机器上的按键（假设...）。
如果 PDF 在浏览器中打开，CSP header 会阻止这种情况发生并阻止此脚本。如果将 PDF 文件保存到计算机，然后在 Adobe PDF 文件查看器中打开，则不再启用此特定的 CSP 保护。 （其他缓解措施可能存在于 Adobe 程序中）。
当一个文件被下载到客户端机器上时（比如将恶意图像文件保存到磁盘上），CSP 不会在浏览器之外进行任何保护。
Why does it work this way?
CSP 是浏览器接收的一组 HTTP headers，是无状态的。将 HTTP 视为包裹的包装。有些包裹用不同的东西包装，例如新鲜水果的包装方式与游戏机的包装方式不同，但包装纸永远不知道里面到底是什么 - 如果您将游戏机包装成新鲜水果，它仍然会送达。
按照这个类比，包裹上有一个标签，上面写着“警告”和一些标准，它很脆弱等等。现在邮政服务的收件人看到了这一点并尊重它，因为那是她的工作。这是浏览器。然而，包裹可能会被随意扔给某个人（无论是 USB 驱动器、磁盘驱动器还是非常非常旧的浏览器），他们不会阅读警告标签并且会忽略警告 - 因为警告仅适用于邮政服务工人 - 从而允许内容连接到它想要的任何东西。
旧答案 1：
理想情况下，您应该在尽可能早的级别添加 CSP，例如在您的 Apache httpd.conf 文件或等效文件中——这样每次从您的网站调用任何内容时都会自动加载它, 因此它适用于每个资源。
一些资源，例如 JPEG 图像，可以很容易地 reference/call 以愚蠢的方式获取外部信息；不要仅仅因为它看起来良性就相信任何东西。一个主要（但可能无害）的例子是 Facebook 使用的 JPEG 图像，如下所述（见旁注）。
重新加载服务器：httpd.conf 信息保存在服务器内存中，因此没有 read/write 延迟等。
Ajax 与浏览器加载一样，只是一个调用o the/a 服务器上的脚本。
“从安全角度来看，什么是必要的”完全取决于您的系统面临哪些风险，您计划在 CSP 之外缓解这些风险，以及您想要投入多少时间和精力在 micro-seconds 的服务器加载时间或替代系统之间进行权衡。
CSP 完全是可选的。如果您想 micro-optimise 到您认为使用 CSP 对您的用户体验征税，这很公平......但您需要了解该选择和设置（几乎肯定会耗时) 替代方案，例如防火墙黑名单...
旁注：
Facebook 资源并不总是“真正的”资源 -- 它是一个 PHP 文件，加载数据（比如图像）并写入数据库并输出数据，就好像它只是图像一样适当的 PHP header.
旁注 2：
在 PHP 系统（以及许多其他系统）上，可以加载页面和资源并将其输出给最终用户，而该用户不会意识到访问正在通过代码库传递。例如：
<?php
///
/// Send data to a cURL request off site
///
/// Call image from a 3rd party provider.
///
/// Display image to end user as image.jpeg
///
你认为这只是一个图像，但在引擎盖下任何事情都可能发生。
此外，恶意的 JPEG 图像长期以来一直能够通过其元数据集访问第 3 方资源。
支持 HTTP Content Security Policy response header will prevent images (and other content) from loading for any page where the response header or a meta tag contains Content Security Policy directives that limit the domains considered as valid content sources, require all content to be loaded via HTTPS, etc. Most widely used modern browsers support Content Security Policy 并应用它来控制与任何 HTTP 请求关联的大部分内容资源（包括图像）的浏览器（除了 Web Worker 资源控制在 Safari 和 IE 中不受支持，并且可能不会在 Edge 或 Opera 中得到支持）。
您可以在您的内容安全策略中专门包含 img-src 策略指令，以限制被视为有效图像来源的域以及要求 HTTPS 方案等。还有特定指令可用于各种其他资源，包括字体、框架、媒体（音频、视频等）、脚本、样式表、网络工作者等。
您需要将您的内容安全策略作为 HTTP 响应的一部分包含在 header 中，该响应作为每个 HTTP 请求的一部分从您的 Web 服务器返回，您希望限制有效的内容源或确保请求的页面包含内容安全策略元标记，例如...
<meta http-equiv="Content-Security-Policy" content="default-src 'self';">
请注意，IE 10+ 浏览器支持内容安全策略响应 header 但不支持元标记（如果您想支持 IE，还需要注意一些具体的实施细节）。
slow down the page by adding long CSP headers to each file
据推测，304 未修改 状态 - CSP headers 未发送
- 仅在初始加载时
我的问题的正确答案是 另一个人的答案，
类似问题。它指的是 CSP 规范，该规范明确指出，该策略仅影响创建新“执行上下文”的资源。这意味着，没有必要将 CSP 添加到 REST API 响应中，这些响应不打算由浏览器打开。请参阅