recursal/MDN huggingface dataset:
CSP: default-src
================

在 HTTP 协议中，`Content-Security-Policy` (CSP) 首部字段中的 **`default-src`** 指令可以为其他 CSP 拉取指令（fetch directives）提供备选项。对于以下列出的指令，假如不存在的话，那么用户代理会查找并应用 default-src 指令的值。

* `child-src`
* `connect-src`
* `font-src`
* `frame-src` (en-US)
* `img-src` (en-US)
* `manifest-src` (en-US)
* `media-src` (en-US)
* `object-src` (en-US)
* `script-src` (en-US)
* `style-src` (en-US)
* `worker-src`

| CSP 版本 | 1 |
| --- | --- |
| 指令类型 | Fetch directive |

语法
--

`default-src` 策略允许指定一个或多个源：
```

Content-Security-Policy: default-src <source>;
Content-Security-Policy: default-src <source> <source>;
```

### 源

<source> 可以是以下之一：

<host-source>

 以域名或者 IP 地址表示的主机名，外加可选的 URL 协议名（URL scheme）以及端口号。站点地址中可能会包含一个可选的前置通配符（星号 '\*'），同时也可以将通配符（也是'\*'）应用于端口号，表示在这个源中可以使用任意合法的端口号。
 举例说明：\_ `http://_.example.com:` 匹配从使用 http: 的 example.com 的任意子域的资源加载。


* `mail.example.com:443:`匹配对 mail.example.com 上的 443 端口号的访问。
* `https://store.example.com`: 匹配对使用了 https: 的 store.example.com 的访问。

<scheme-source>

协议名如'http:' 或者 'https:'。**必须带有冒号，不要有单引号**。同时你还可以指定数据协议（data schema）（不推荐使用）。

* `data:` 允许 `data:` URIs 作为内容的源。这是不安全的。攻击者可以注入任意 data: URI。不要轻易使用这种形式的源，尤其是脚本，绝对不要使用。
* `mediastream:` 允许 `mediastream:` URIs (en-US) 作为内容的源。
* `blob:` 允许 `blob:` URIs 作为内容的源。
* `filesystem:` 允许 `filesystem:` URIs 作为内容的源。

`'self'`

指向与要保护的文件所在的源，包括相同的 URL scheme 与端口号。必须有单引号。一些浏览器会特意排除 blob 与 filesystem。需要设定这两种内容类型的站点可以在 Data 属性中进行设定。

`'unsafe-inline'`

允许使用内联资源，例如内联 `<script>` 元素（javascript: URL）、内联事件处理器以及内联 `<style>` 元素。必须有单引号。

`'unsafe-eval'`

允许使用 eval() 以及相似的函数来从字符串创建代码。必须有单引号。

`'none'`

不允许任何内容。必须有单引号。

'nonce-<base64 值>'

特定使用一次性加密内联脚本的白名单。服务器必须在每一次传输政策时生成唯一的一次性值。否则将存在绕过资源政策的可能。请参见不安全的内联脚本 (en-US)查看示例。

<hash-source>

使用 sha256、sha384 或 sha512 编码过的内联脚本或样式。其由用短划线分隔的两部分组成：用于创建哈希的加密算法，以及脚本或样式 base64 编码的哈希值。当生成哈希值的时候，不要包含 <script> 或 <style> 标签，同时注意字母大小写与空格——包括首尾空格——都是会影响生成的结果的。请参见不安全的内联脚本 (en-US)。

'strict-dynamic'

strict-dynamic 指定对于含有标记脚本 (通过附加一个随机数或散列) 的信任，应该传播到由该脚本加载的所有脚本。与此同时，任何白名单以及源表达式例如 'self' 或者 'unsafe-inline' 都会被忽略。参见 script-src (en-US) 。

示例
--

### `不继承 default-src 的情况`

假如设定了其他指令，那么 `default-src` 不会对它们起作用。这个首部


```bash
Content-Security-Policy: default-src 'self'; script-src https://example.com
```


与下列代码等价：


```bash
Content-Security-Policy: connect-src 'self';
                         font-src 'self';
                         frame-src 'self';
                         img-src 'self';
                         manifest-src 'self';
                         media-src 'self';
                         object-src 'self';
                         script-src https://example.com;
                         style-src 'self';
                         worker-src 'self'
```

规范
--

| Specification |
| --- |
| Content Security Policy Level 3 # directive-default-src |

浏览器兼容性
------

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

参见
--

* `Content-Security-Policy`
* `connect-src`
* `font-src`
* `frame-src` (en-US)
* `img-src` (en-US)
* `manifest-src` (en-US)
* `media-src` (en-US)
* `object-src` (en-US)
* `script-src` (en-US)
* `style-src` (en-US)
* `worker-src`
report-to
=========

`Report-To` HTTP 响应头部指示客户端存储特定域名的报告端点。
```

Content-Security-Policy: ...; report-to groupname
```


该指令本身没有任何影响，仅与其他指令结合起来才有意义。

|  |  |
| --- | --- |
| CSP version | 1 |
| 指令类型 | Reporting directive (en-US) |
| `<meta>` 元素并不支持该指令 |

Syntax
------
```

Content-Security-Policy: report-to <json-field-value>;
```

Examples
--------

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

可以查看`Content-Security-Policy-Report-Only`获取更多信息和示例。
```

Report-To: { "group": "csp-endpoint",
             "max-age": 10886400,
             "endpoints": [
               { "url": "https://example.com/csp-reports" }
             ] },
           { "group": "hpkp-endpoint",
             "max-age": 10886400,
             "endpoints": [
               { "url": "https://example.com/hpkp-reports" }
             ] }
Content-Security-Policy: ...; report-to csp-endpoint
```


```
Report-To: { "group": "endpoint-1",
             "max-age": 10886400,
             "endpoints": [
               { "url": "https://example.com/reports" },
               { "url": "https://backup.com/reports" }
             ] }

Content-Security-Policy: ...; report-to endpoint-1
```


Browser compatibility

The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out https://github.com/mdn/browser-compat-data and send us a pull request.

See also
--------

* `Content-Security-Policy`
* `Content-Security-Policy-Report-Only`
CSP: form-action
================

HTTP `Content-Security-Policy` (CSP) 的 **`form-action`** 指令能够限定当前页面中表单的提交地址。

**警告：** 在表单提交之后， `form-action` 指令是否应该阻止重定向仍有待讨论，各个浏览器对于此行为的实现也不尽相同（例如，Chrome 63 会阻止重定向，而 Firefox 57 则不会）。


| CSP version | 2 |
| --- | --- |
| Directive type | Navigation directive |
| `default-src` fallback | No. 未设定时允许任何值。 |

语法
--

`form-action` 策略允许设定一个或多个源：
```

Content-Security-Policy: form-action <source>;
Content-Security-Policy: form-action <source> <source>;
```

示例
--

### meta 标签配置


```html
<meta http-equiv="Content-Security-Policy" content="form-action 'none'" />
```

### Apache 服务器配置


```bash
<IfModule mod_headers.c>
Header set Content-Security-Policy "form-action 'none';
</IfModule>
```

### Nginx 配置


```bash
add_header Content-Security-Policy "form-action 'none';"
```

### 反例

将 `<form>` 元素的 action 设置为内联 JavaScript 会违反 CSP 规则。


```html
<meta http-equiv="Content-Security-Policy" content="form-action 'none'" />

<form action="javascript:alert('Foo')" id="form1" method="post">
  <input type="text" name="fieldName" value="fieldValue" />
  <input type="submit" id="submit" value="submit" />
</form>

<!-- Error: Refused to send form data because it violates the following Content Security Policy directive: "form-action 'none'". -->
```

规范
--

| Specification |
| --- |
| Content Security Policy Level 3 # directive-form-action |

浏览器兼容性
------

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

参见
--

* `Content-Security-Policy`
* `<form>`
CSP: base-uri
=============

HTTP `Content-Security-Policy`（内容安全策略）中的 **`base-uri`** 指令限制了可以应用于一个文档的 `<base>` 元素的 URL。假如指令值为空，那么任何 URL 都是允许的。如果指令不存在，那么用户代理会使用 `<base>` 元素中的值。

|  |  |
| --- | --- |
| CSP 版本 | 2 |
| 指令类型 | 文档指令 |
| `default-src` 回落 | 无。没有设置则允许任何 URL。 |

语法
--

base-uri 安全策略可以设置一个或多个源：
```

Content-Security-Policy: base-uri <source>;
Content-Security-Policy: base-uri <source> <source>;
```

### 源

此指令与其他 CSP 指令一样，使用大部分与参数相同的源值：CSP 源值 (en-US)。

然而，请注意，一些值对 `base-uri` 没有意义，例如关键字 `'unsafe-inline'` 和 `'strict-dynamic'`。

示例
--

### Meta tag 配置


```html
<meta http-equiv="Content-Security-Policy" content="base-uri 'self'" />
```

### Apache 配置


```bash
<IfModule mod_headers.c>
Header set Content-Security-Policy "base-uri 'self';
</IfModule>
```

### Nginx 配置


```bash
add_header Content-Security-Policy "base-uri 'self';"
```

### 违规的案列

假如你的域名不是 `example.com`，那么将 `<base>` 元素的 `href` 属性值设置成 `https://example.com` 会违反 CSP 策略。


```html
<meta http-equiv="Content-Security-Policy" content="base-uri 'self'" />
<base href="http://example.com/" />

<!-- Error: Refused to set the document's base URI to 'http://example.com/' because it violates the following Content Security Policy directive: "base-uri 'self'" -->
```

规范
--

| Specification |
| --- |
| Content Security Policy Level 3 # directive-base-uri |

浏览器兼容性
------

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

相关内容
----

* `Content-Security-Policy`
* `<base>`
* `Node.baseURI`
CSP: connect-src
================

HTTP `Content-Security-Policy`（内容安全策略，CSP）中的 **`connect-src`** 指令用于限制通过使用脚本接口加载的 URL。其中受限制的 API 如下：

* `<a>` `ping`
* `fetch()`
* `XMLHttpRequest`
* `WebSocket`
* `EventSource`
* `Navigator.sendBeacon()`

**备注：** 并不是所有浏览器都能将 `connect-src 'self'` 解析为 websocket 协议，更多信息，请查看这个 issue。


|  |  |
| --- | --- |
| CSP 版本 | 1 |
| 指令类型 | Fetch 指令 |
| `default-src` 回落 | 是。如果没有此指令，用户代理将查找 `default-src` 指令。 |

语法
--

connect-src 策略可以允许一个或多个源：


```http
Content-Security-Policy: connect-src <source>;
Content-Security-Policy: connect-src <source> <source>;
```

### 源

`<source>` 可以是 CSP 源值 (en-US)列出来的任意一个。

注意，这套相同的值可以用于所有 fetch 指令（以及许多其他指令 (en-US)）。

示例
--

### 违规的案例

给定此 CSP 标头：


```http
Content-Security-Policy: connect-src https://example.com/
```


以下连接被禁止并且将不会加载：


```html
<a ping="https://not-example.com">
  <script>
 const xhr = new XMLHttpRequest();
 xhr.open("GET", "https://not-example.com/");
 xhr.send();

 const ws = new WebSocket("https://not-example.com/");

 const es = new EventSource("https://not-example.com/");

 navigator.sendBeacon("https://not-example.com/", {
 /\* … \*/
 });
 </script></a
>
```

规范
--

| Specification |
| --- |
| Content Security Policy Level 3 # directive-connect-src |

浏览器兼容性
------

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

### 兼容性备注

* Firefox 23 之前，`xhr-src` 被用来代替 `connect-src` 指令，并且只用于限制 `XMLHttpRequest` 的使用。
参见
--

* `Content-Security-Policy`
* `<a>` `ping`
* `fetch()`
* `XMLHttpRequest`
* `WebSocket`
* `EventSource`
CSP：frame-ancestors
===================

HTTP 标头 `Content-Security-Policy`（CSP）中的 `frame-ancestors` 指令指定了一个可以包含 `<frame>`、`<iframe>`、`<object>` 或 `<embed>` 等元素的有效父级。

当该指令设置为 `'none'` 时，其作用类似于 `X-Frame-Options``: DENY`（该标头被一些老版本浏览器所支持）。

|  |  |
| --- | --- |
| CSP 版本（CSP version） | 2 |
| 指令类型（Directive type） | Navigation directive |
| 是否后备使用`default-src` | 否。如未设置则允许所有可能值。 |
| 
 该指令不支持通过`<meta>` 元素或通过
 `Content-Security-policy-Report-Only`
 头域所指定。
  |

Syntax
------

`frame-ancestors`策略可以设置一个或多个源<source>：
```

Content-Security-Policy: frame-ancestors <source>;
Content-Security-Policy: frame-ancestors <source> <source>;
```

### Sources

<source> 可以是如下内容：

**备注：** `frame-ancestors` 指令的语法类似于其他指令的源列表（source list，如`default-src`），但不允许 `'unsafe-eval'` 或`'unsafe-inline'` 。它也不会回退使用 `default-src` 的值。仅有如下的源列表是可用的：

<host-source>

 一个 Internet 主机的名称或 IP 地址，以及一个可选的URL scheme和／或端口号。这些站点的地址可以包含一个可选的引导通配符（星号， `'*'），或者你可以使用通配符`（同样还是， `'*'）作为端口地址`，以示这个源的所有合法端口地址都是有效的。
 例子：\_ `http://_.example.com`: 匹配所有使用 http:URL scheme 并来对于 example.com 及其子域名的加载意图。


* `mail.example.com:443`: 匹配所有对于 mail.example.com 在 443 端口的访问意图。
* `https://store.example.com`: 匹配所有使用 https:访问 store.example.com 的意图。

<scheme-source>

一个 schema 配置，比如'http:'或'https:'。注意，冒号是必要的。你同样也可以指定一个 data schema（但并不推荐）。

* '`data:`' 允许 `data:` URIs 作为内容源。*这是不安全的，攻击者可以用此来注入恶意代码。请谨慎使用，并不要令其作用于脚本。*
* `'mediastream:'` 允许 `mediastream:` URIs (en-US) 作为内容源。
* `'blob:'` 允许 `blob:` URIs 作为内容源。
* `'filesystem:'` 允许 `filesystem:` URIs 作为内容源。

`'self'`

指向一个该受保护文档所在的源，包含同样的 URL schema 和端口号。必须用单引号设置。有些浏览器会从源指令中排`除 blob`和`filesystem`。需要允许这些内容类型的站点可以通过 Data 属性指定它们。

`'none'`

指向一个空集，意味着没有 URL 会被匹配。也需要单引号包裹设置。

Examples
--------


```bash
Content-Security-Policy: frame-ancestors 'none';
```

Specifications
--------------

| Specification |
| --- |
| Content Security Policy Level 3 # directive-frame-ancestors |

Browser compatibility
---------------------

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

See also
--------

* `Content-Security-Policy`
* `X-Frame-Options`
CSP: child-src
==============

HTTP `Content-Security-Policy`（CSP 内容安全策略）中的 **`child-src`** 指令定义了使用如 `<frame>` 和 `<iframe>` 等元素在加载 web worker 和嵌套浏览上下文时的有效来源。对于 worker 来说，不合规的请求会被用户代理当作致命的网络错误处理。

|  |  |
| --- | --- |
| CSP 版本 | 2 |
| 指令类型 | fetch 指令 |
| `default-src` 回落 | 是。如果该指令不存在，用户代理将查找 `default-src` 指令。 |

Syntax
------

`child-src` 策略可以允许一个或者多个源：


```http
Content-Security-Policy: child-src <source>;
Content-Security-Policy: child-src <source> <source>;
```

### 源

`<source>` 可以是 CSP 源值 (en-US)中的任意一个。

请注意，这套相同的值可以用于所有 fetch 指令（以及许多其他的指令 (en-US)）。

示例
--

### 违规的策略

给定此 CSP 标头：


```http
Content-Security-Policy: child-src https://example.com/
```


这个 `<iframe>` 和 worker 被禁止并且不会加载：


```html
<iframe src="https://not-example.com"></iframe>

<script>
 const blockedWorker = new Worker("data:application/javascript,…");
</script>
```

规范
--

| Specification |
| --- |
| Content Security Policy Level 3 # directive-child-src |

浏览器兼容性
------

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

参见
--

* `Content-Security-Policy`（内容安全策略）
* `<frame>` 和 `<iframe>`
* `Worker`、`SharedWorker`、`ServiceWorker`
CSP: block-all-mixed-content
============================

HTTP 协议首部字段 `Content-Security-Policy` (CSP) 中的 **`block-all-mixed-content`** 指令在当前页面为通过 HTTPS 协议加载的情况下禁止通过 HTTP 渠道加载任何资源。

任何混合类型 (en-US)的资源请求都是被禁止的，包括混合活动内容和混合被动内容。这一条也适用于 `<iframe>` 中的文档，确保整体页面都不包含混合内容。

`upgrade-insecure-requests` 指令会在 `block-all-mixed-content` 之前执行；如果前者执行成功，后者就不再发挥任何作用。推荐的做法是设置二者之一，而不是全部。

语法
--
```

Content-Security-Policy: block-all-mixed-content;
```

示例
--
```

Content-Security-Policy: block-all-mixed-content;

<meta http-equiv="Content-Security-Policy" content="block-all-mixed-content">
```


为了在更细粒度上限制对 http 资源的访问，你可以将个别指令的值设置为 "https:"。例如，为了限制对不安全的走 http 协议的图片的访问，可以这么做：
```

Content-Security-Policy: img-src https:
```

规范
--

不属于任何现行的规范，曾在过时的 Mixed Content Level 1 规范中定义。

浏览器兼容性
------

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

相关内容
----

* `Content-Security-Policy`
* `upgrade-insecure-requests`
* Mixed content (en-US)
CSP: upgrade-insecure-requests
==============================

HTTP `Content-Security-Policy` (CSP) \*\*`upgrade-insecure-requests`\*\*指令指示客户端将该站点的所有不安全 URL（通过 HTTP 提供的 URL）视为已被替换为安全 URL（通过 HTTPS 提供的 URL）。该指令适用于需要重写大量不安全的旧版 URL 的网站。

`upgrade-insecure-requests`指令在 `block-all-mixed-content` 之前被执行，如果其被设置，后者实际上是空操作。可以设置其中一个，但不能同时设置。

The `upgrade-insecure-requests` directive will not ensure that users visiting your site via links on third-party sites will be upgraded to HTTPS for the top-level navigation and thus does not replace the `Strict-Transport-Security` (HSTS) header, which should still be set with an appropriate `max-age` to ensure that users are not subject to SSL stripping attacks.

Syntax
------
```

Content-Security-Policy: upgrade-insecure-requests;
```

Examples
--------
```

// header
Content-Security-Policy: upgrade-insecure-requests;

// meta tag
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">
```


一旦将上述头部设置在计划从 HTTP 迁移到 HTTPS 的 example.com 域名上，非跳转 (non-navigational) 的不安全资源请求会自动升级到 HTTPS（包括第当前域名以及第三方请求）。


```html
<img src="http://example.com/image.png" />
<img src="http://not-example.com/image.png" />
```


这些 URL 在请求发送之前都会被改写成 HTTPS，也就意味着不安全的请求都不会发送出去。注意，如果请求的资源在 HTTPS 情况下不可用，则该请求将失败，其也不能回退到 HTTP。


```html
<img src="https://example.com/image.png" />
<img src="https://not-example.com/image.png" />
```


Navigational upgrades to third-party resources brings a significantly higher potential for breakage, these are not upgraded:


```html
<a href="https://example.com/">Home</a>
<a href="http://not-example.com/">Home</a>
```

### Finding insecure requests

通过 `Content-Security-Policy-Report-Only` HTTP 头部和 `report-uri` (en-US) 指令，你可以设置执行策略和报告策略，如下所示：
```

Content-Security-Policy: upgrade-insecure-requests; default-src https:
Content-Security-Policy-Report-Only: default-src https:; report-uri /endpoint
```


That way, you still upgrade insecure requests on your secure site, but the only monitoring policy is violated and reports insecure resources to your endpoint.

Specifications
--------------

| Specification |
| --- |
| Upgrade Insecure Requests # delivery |

Browser compatibility
---------------------

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

See also
--------

* `Content-Security-Policy`
* `Upgrade-Insecure-Requests` header
* `Strict-Transport-Security` (HSTS) header
* `block-all-mixed-content`
* Mixed content (en-US)
Permissions-Policy: camera
==========================

HTTP `Permissions-Policy` 标头当中的 `camera` 指令控制着当前的文档是否允许使用视频输入设备。当该策略被开启时，由 `MediaDevices.getUserMedia()` 返回的 `Promise` 将会以一个 `NotAllowedError` `DOMException` 拒绝。

语法
--
```

Permissions-Policy: camera <allowlist>;
```


<allowlist>

允许使用此特性的来源（origin）列表。参见 `Permissions-Policy`。

默认策略
----

默认允许的 `camera` 列表为 `'self'`。

规范
--

| Specification |
| --- |
| Media Capture and Streams # permissions-policy-integration |

浏览器兼容性
------

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

参见
--

* `Permissions-Policy` 标头
* Feature Policy
* 使用 Feature Policy
Permissions-Policy: picture-in-picture
======================================

**实验性:** **这是一项实验性技术**  
在将其用于生产之前，请仔细检查浏览器兼容性表格。

HTTP 标头 `Permissions-Policy` 的 `picture-in-picture` 指令表示是否允许当前的文档通过相应的 API 以画中画模式播放视频。

语法
--
```

Permissions-Policy: picture-in-picture <allowlist>;
```


<allowlist>

允许使用该功能的来源列表。参见 `Permissions-Policy`。

默认策略
----

截至 2019 年 6 月，规范草案 和 Google Chrome 将允许列表默认设置为 `*`。

规范
--

| Specification |
| --- |
| Picture-in-Picture # permissions-policy |

浏览器兼容性
------

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

参见
--

* `Permissions-Policy` 标头
* Permission Policy
* Using Permission Policy
Permissions-Policy: autoplay
============================

**实验性:** **这是一项实验性技术**  
在将其用于生产之前，请仔细检查浏览器兼容性表格。

The HTTP `Permissions-Policy` header `autoplay` directive controls whether the current document is allowed to autoplay media requested through the `HTMLMediaElement` interface. When this policy is enabled and there were no user gestures, the `Promise` (en-US) returned by `HTMLMediaElement.play()` will reject with a `DOMException`. The `autoplay` attribute on `<audio>` and `<video>` elements will be ignored.

For more details on autoplay and autoplay blocking, see the article Autoplay guide for media and Web Audio APIs.

语法
--
```

Permissions-Policy: autoplay <allowlist>;
```


<allowlist>

允许使用此特性的来源（origin）列表。参见 `Permissions-Policy`。

默认策略
----

Google Chrome 的默认值是 `'self'`。

规范
--

| Specification |
| --- |
| HTML Standard # autoplay-feature |

浏览器兼容性
------

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

参见
--

* `Permissions-Policy` 标头
* Permission Policy
* 使用 Permission Policy
CORS 错误
=======

跨源资源分享（CORS）是一种允许服务器放宽同源策略的标准。这用于明确允许一些跨源请求，同时拒绝其他请求。例如，如果站点提供外界嵌入的服务，则可能需要放宽同源策略。设置这样的 CORS 配置并不一定容易，并且可能存在一些挑战。在这些页面中，我们将研究一些常见的 CORS 错误消息以及如何解决它们。

如果未正确设置 CORS 配置，浏览器控制台将显示错误，例如 `"Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at $somesite"` 表示请求因违反 CORS 安全规则而被阻止。但这可能不一定是设置错误。因为用户的 Web 应用程序和远程外部服务可能故意禁止该请求。如果要使端点可用，则需要进行一些调试才能成功。

确定问题
----

要了解 CORS 配置的基本问题，你需要找出哪个请求有问题以及原因。步骤如下：

1. 打开有问题的网站并打开开发者工具。
2. 尝试重现失败的事务并检查控制台是否看到 CORS 违规错误消息。它可能看起来像这样：

![Firefox 控制台展示 CORS 错误](/zh-CN/docs/Web/HTTP/CORS/Errors/cors-error2.png)

错误消息的文本将类似于以下内容：
```

Cross-Origin Request Blocked: The Same Origin Policy disallows
reading the remote resource at https://some-url-here. (Reason:
additional information here).
```


**备注：** 出于安全原因，*JavaScript 代码无法给出*有关 CORS 请求出错的详细信息。所有代码都知道发生了错误。确定具体问题的唯一方法是查看浏览器的控制台以获取详细信息。

CORS 错误信息
---------

当请求因 CORS 失败时，Firefox 的控制台会在其控制台中显示消息。错误文本的一部分是“原因”消息，它提供了对出错的更深入的了解。下面列出了原因的消息；点击消息以打开一篇文章，更详细地阐述了错误以及提供可能的解决方案。

* 原因：CORS disabled
* 原因：CORS request did not succeed
* 原因：CORS header 'Origin' cannot be added
* 原因：CORS request external redirect not allowed
* 原因：CORS request not http
* 原因：CORS header 'Access-Control-Allow-Origin' missing
* 原因：CORS header 'Access-Control-Allow-Origin' does not match 'xyz'
* 原因：Credential is not supported if the CORS header 'Access-Control-Allow-Origin' is '\*'
* 原因：Did not find method in CORS header 'Access-Control-Allow-Methods'
* 原因：expected 'true' in CORS header 'Access-Control-Allow-Credentials'
* 原因：CORS preflight channel did not succeed
* 原因：invalid token 'xyz' in CORS header 'Access-Control-Allow-Methods'
* 原因：invalid token 'xyz' in CORS header 'Access-Control-Allow-Headers'
* 原因：missing token 'xyz' in CORS header 'Access-Control-Allow-Headers' from CORS preflight channel
* 原因：Multiple CORS header 'Access-Control-Allow-Origin' not allowed
参见
--

* 术语：CORS
* CORS 介绍
* 服务端 CORS 设置 (en-US)
* 允许图片跨源请求
* CORS 设置属性
* https://www.test-cors.org——用于测试 CORS 请求的页面
原因：CORS preflight channel did not succeed
=========================================

原因
--
```

原因：CORS preflight channel did not succeed
```

哪里错了？
-----

CORS 请求需要预校验，但是不能执行预校验。可能是由于下列几种原因导致：

* 一个跨站请求在先前已经进行过预校验，进行重复的校验是不被允许的。请确保你的代码每次连接只进行一次预校验。
* 预校验请求碰到了通常情况下不应该发生的网络问题。
参见
--

* CORS 错误
* 术语：CORS
* CORS 介绍
原因：Credential is not supported if the CORS header 'Access-Control-Allow-Origin' is '\*'
=======================================================================================

原因
--
```

原因：Credential is not supported if the CORS header 'Access-Control-Allow-Origin' is '*'
```

出了什么问题？
-------

CORS 请求是在设置了凭证标志的情况下尝试的，但服务端使用通配符（`"*"`）配置 `Access-Control-Allow-Origin` 的值，这样是不允许使用凭证的。

要在客户端改正这个问题，只需要确保发出 CORS 请求时将凭证标志设置为 `false`。

* 如果使用 `XMLHttpRequest` 发出请求，确保未将 `withCredentials` 设置为 `true`。
* 如果使用服务器发送事件，确保 `EventSource.withCredentials` (en-US) 的值为 `false`（false 为默认值）。
* 如果使用 Fetch API，确保 `Request.credentials` 的值为 `"omit"`。

如果还不成功，则需要修改服务端的行为，可能需要修改 `Access-Control-Allow-Origin` 的值，来为客户端所能够加载资源的源予以授权。

参见
--

* CORS 错误
* 术语：CORS
* CORS 介绍
原因：CORS request did not succeed
===============================

原因
--
```

原因：CORS request did not succeed
```

哪里错了？
-----

使用 CORS 的 HTTP 请求失败，因为 HTTP 连接在网络或协议级别失败。该错误与 CORS 没有直接关系，而是某种基本的网络错误。

很多情况下，它是某个浏览器插件（比如广告拦截或隐私保护插件）阻止了请求而引起的。

其他可能包括的原因：

* 尝试访问拥有无效凭证的 `https` 资源将导致此错误。
* 尝试从 `https` 源页面访问 `http` 资源将也会导致此错误。
* 从 Firefox 68 开始，`https` 页面不允许去访问 `http://localhost`，尽管这可能随着 Bug 1488740 而改变。
* 服务器不能响应真实的请求（即使它响应了预检请求）。一种情况是正在开发的 HTTP 服务器发生异常停止，而且没有返回任何数据。
参见
--

* CORS 错误
* 术语：CORS
* CORS 介绍
原因：CORS header 'Access-Control-Allow-Origin' missing
====================================================

原因
--
```

原因：CORS header 'Access-Control-Allow-Origin' missing
```

哪里出错了？
------

对 CORS 请求的响应缺少必需的 `Access-Control-Allow-Origin` 标头，该标头用于确定在当前源中的操作是否可以访问资源。

如果服务器在你的控制之下，请将请求站点的源添加到允许访问的域集，方法是将其添加到 `Access-Control-Allow-Origin` 标头的值。

例如，要允许 `https://amazing.site` 上的站点使用 CORS 访问资源，这个标头应该是：


```http
Access-Control-Allow-Origin: https://amazing.site
```


你还可以使用 `*` 通配符配置站点，这样可以允许任何站点访问它。这样的处理应该只用于公共的 API。私有 API 永远不应使用 `*`，而应设置特定的域（可以不止一个）。此外，通配符仅适用于将 `crossorigin` 属性设置为 `anonymous` 的请求，并且它阻止在请求中发送诸如 cookie 之类的凭据。


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


**警告：** 使用通配符允许所有站点访问私有 API 是显而易见的坏主意。

如果要在*不使用* `*` 通配符的情况下让任意站点发出 CORS 请求（例如，为了启用凭证），你的服务器必须读取请求的 `Origin` 标头，将那个值设置为 `Access-Control-Allow-Origin` 的值，且必须一并设置 `Vary: Origin` 标头，表明一部分标头由源动态决定。

设置标头的命令取决于你的 Web 服务器。例如，在 Apache 服务器中，将下面一行添加到服务器的配置中（在相应的 `<Directory>`、`<Location>`、`<Files>` 或 `<VirtualHost>` 部分中）。配置通常位于 `.conf` 文件中（`httpd.conf` 和 `apache.conf` 是这些文件的通用名称）或者位于 `.htaccess` 文件中。
```

Header set Access-Control-Allow-Origin 'origin-list'
```


对于 Nginx，设置此标头的命令是：
```

add_header 'Access-Control-Allow-Origin' 'origin-list';
```

参见
--

* CORS 错误
* 术语：CORS
* CORS 介绍
原因：invalid token 'xyz' in CORS header 'Access-Control-Allow-Methods'
====================================================================

原因
--
```

原因：invalid token 'xyz' in CORS header 'Access-Control-Allow-Methods'
```

哪里错了？
-----

服务器发送的对 CORS 请求的响应包含 `Access-Control-Allow-Methods` 标头信息，并且含有至少一个无效的方法名称。

服务器发送 `Access-Control-Allow-Methods` 标头信息，让客户端知道它对 CORS 请求支持哪些 HTTP 请求方法。`Access-Control-Allow-Methods` 的值是以逗号分隔的 HTTP 方法，例如 `GET`、`POST` 或 `HEAD`。如果客户端用户代理无法识别返回的值，则会发生此错误。

这很有可能只能在服务端解决，方法是修改服务器的配置以不再发送带有 `Access-Control-Allow-Methods` 标头的无效或未知方法名称。检查你的用户代理或者你使用的浏览器中的 HTTP 库是最新的。

参见
--

* CORS 错误
* 术语：CORS
* CORS 介绍
* HTTP 请求方法
原因：Multiple CORS header 'Access-Control-Allow-Origin' not allowed
=================================================================

原因
--
```

原因：Multiple CORS header 'Access-Control-Allow-Origin' not allowed
```

哪里错了？
-----

服务器返回了多个 `Access-Control-Allow-Origin` 标头。这是不允许的。

如果你有权访问该该服务器，请更改你的实现以在 `Access-Control-Allow-Origin` 标头返回该源。你不能发回源列表，因为浏览器仅接受单一的源或者空值。

参见
--

* CORS 错误
* 术语：CORS
* CORS 介绍
* 启用 CORS：我想让自己的服务支持 CORS