CORS，全称为跨源资源共享（Cross-Origin Resource Sharing），是一种基于 HTTP 标头的机制，允许服务器标示哪些外部源（域、协议或端口）可以访问其资源。CORS 可以解决同源策略带来的不便，同源策略是浏览器的一种安全机制，它限制网页从不同的来源加载资源，以防止恶意网站窃取敏感数据。然而，这种限制也阻碍了合法的跨域请求。复杂的应用程序通常会在其客户端代码中引用第三方API和资源，当客户端域与服务器域不匹配时就需要 CORS。通过 CORS，浏览器能够安全地进行跨源数据传输，从而突破同源策略的限制。CORS 允许客户端浏览器在任何数据传输之前,先向第三方服务器检查请求是否被授权。由于 CORS 配置的复杂性，开发人员往往将跨域访问的权限设置得过大，比如在允许访问的标头中使用 “*” 来允许全部访问，这会对应用的安全性造成损害。

Amazon API Gateway 是一项帮助开发人员轻松管理任意规模的 API 的全托管服务，常被用于后端服务的管理与路由。因此，在 API Gateway 上配置 CORS 是一个很常见的需要。在 Amazon API Gateway 中，不同类型的 API 对于 CORS 有不同的配置方式，这增加了 CORS 配置的复杂度。

本文将介绍如何在 Amazon API Gateway 的 REST API 和 HTTP API 中进行跨源资源共享设置，其中将重点介绍 REST API 和 HTTP API 在跨源资源共享配置上的不同之处，以及在开启了授权验证（authorization）的情况下怎么配置跨源资源共享。通过阅读本文，您将掌握 Amazon API Gateway 中跨源资源共享的配置技巧，从而实现满足 最小权限原则 的跨域访问配置。

CORS 原理

CORS 是一种基于 HTTP 标头的机制，服务器通过使用标头信息来限制访问。CORS 的工作主要依赖于以下几个 关键的 HTTP 标头 ：

Origin：指示请求来源。

Access-Control-Allow-Origin：指定哪些源可以访问资源。

Access-Control-Allow-Methods：列出允许访问资源的 HTTP 方法。

Access-Control-Allow-Headers：指示允许使用的自定义请求头。

Access-Control-Allow-Credentials：指示是否允许发送凭据（如 Cookies）。

Access-Control-Max-Age：指示预检请求结果可以被缓存多长时间。

根据请求的复杂程度，CORS 将其分为两类：

简单请求：不需要预检。这类请求使用 GET/POST/HEAD 方法，并且只使用特定的安全头（如 Accept、Content-Type）。

非简单请求：需要预检。除简单请求外的跨域请求都算是非简单请求。在发送实际请求之前，浏览器会先发送一个 OPTIONS 请求，以确认服务器是否允许该实际请求。这种预检机制可以防止未经授权的跨域操作对服务器数据产生副作用。

对于非简单请求，服务器依赖浏览器发送 CORS 预检 或 OPTIONS 请求。一个完整的请求过程如下：

API Gateway 介绍

Amazon API Gateway 是一项完全托管的服务，可以帮助开发人员轻松创建、发布、维护、监控和保护任意规模的 API。在您不需要维护其底层基础设施的情况下，API Gateway 能接受和处理成千上万个并发 API 调用。API Gateway 支持 RESTful 和 WebSocket 两种类型的 API，且支持多种类型的后端集成，如容器化服务、无服务器工作负载、HTTP 端点等。API Gateway 的其他关键功能还包括流量管理、CORS 支持、授权和访问控制、限制、监控，以及 API 版本管理等。

REST API 与 HTTP API 的简介与区别

REST API 和 HTTP API 都是 Amazon API Gateway 的 RESTful API 类型产品。它们的区别如下。

REST API 的特有功能包括：

支持 API 密钥

支持每客户端节流

支持请求验证

可以与 AWS WAF 集成

支持私有 API 端点

HTTP API 的设计初衷是仅保留最简化的功能。其特点包括：

支持 default stage

性能与价格上

由于 HTTP API 的功能更精简，因此它提供跟快的速度和更低的价格。

在 API Gateway 中配置跨域访问

若需要在 Amazon API Gateway 中解决跨域问题，皆需通过 CORS 配置来执行。API Gateway 会自动通过 OPTIONS 方法，并尝试将 CORS 标头添加到现有的方法集成响应中，这将帮助您执行预检请求并进行实际响应。在 Amazon API Gwateway 中，REST API 与 HTTP API 的跨域配置方式会有所不同。

REST APIs 跨域访问配置

以下图为例，REST API 中有一个默认的 / 资源，我们在 / 资源下创建了一个 POST 方法，集成了 Lambda 函数作为后端服务。

不要为 OPTIONS 方法开启授权

HTTP APIs 跨域访问配置

在这一章节中，我们依旧以为 / 资源下的 POST 方法配置跨域访问为例，展示如何为 HTTP API 配置跨域访问。

HTTP API 的 CORS 配置相对简单，因为您一旦为您的 HTTP API 开启跨域访问， API Gateway 会自动响应浏览器发来的 preflight 请求，并且自动为您的后端返回添加 CORS 相关的标头。您无法在您的 API 资源中看到 API Gateway 自动响应 preflight 请求的 OPTIONS 方法的配置，也看不到 POST 方法的响应标头的配置。

以下为开启 HTTP API 跨域访问的详细步骤。

进入 HTTP API 的页面，在左侧导航栏中点击 CORS ，随后在右上角点击 配置 。

附加授权的跨域配置场景

类似于 REST API，HTTP API 支持通过 Lambda ， JWT ， IAM 三种授权方为特定的方法授权。如果您想为集成了授权方的 HTTP API 开启跨域访问，在大多数情况下，HTTP API 会自动为您处理 preflight 请求。因此，您无需进行特殊配置，按照上述步骤即可为集成了授权方的 HTTP API 开启跨域访问。唯一的例外是，当您创建了授权的 ANY 方法时（如下图），则需要注意，这种情况下，preflight 请求也会由 ANY 方法而不会由 HTTP API 处理。而 preflight 请求中不包含授权信息，因此授权的 ANY 方法不会返回正确的状态码和跨域标头，preflight 请求会出现 401 错误。

REST API 可以为 REST API 特定路由配置跨域，具体方法为在该路由下点击右上角 启用 CORS 对跨域访问进行配置。 可以在所配置的路由下看到用于响应 preflight 请求的 OPTIONS 方法及其响应的标头设置。可以在允许跨域访问的方法下看到其响应中跨域标头的设置。 不要为 OPTIONS 方法开启授权。 HTTP API 可以为整个 HTTP API 配置跨域，具体方法点击左侧导航栏的 CORS 进入跨域访问的配置页面。 preflight 请求由 API Gateway 自动响应，在控制台中看不到自动响应的 OPTIONS 方法的配置。跨域访问的标头由 API Gateway 自动添加，在允许跨域访问的方法下也看不到其响应中跨域标头的设置。 尽量避免使用 ANY 方法，如果必须使用，则另外创建一个不需要授权的 OPITONS 方法用于 preflight 请求的响应。

若要为其他亚马逊云科技的资源开启 CORS，可参考：

为 CloudFront 开启 CORS： https://aws.amazon.com/cn/blogs/china/several-solutions-to-cloudfront-cross-domain-problem-cors/

为 Lambda 函数 URL 开启 CORS： https://aws.amazon.com/cn/blogs/china/several-solutions-to-cloudfront-cross-domain-problem-cors/

为托管静态网站的 S3 开启 CORS： https://docs.aws.amazon.com/zh_cn/AmazonS3/latest/userguide/cors.html