使用CloudFront反向代理API Gateway以防止CORS问题

在本文中，我们将深入探讨如何通过CloudFront反向代理API Gateway来解决CORS（跨源资源共享）问题。我们将简要介绍CORS和反向代理的概念，并展示如何在CloudFront托管的单页应用程序（SPA）中，通过反向代理消除CORS问题。示例代码主要涵盖了公共路由、身份验证路由（使用授权头）以及IAM签名请求的实现，所有配置均通过AWS CDK完成。

什么是CORS？

CORS，全称为跨源资源共享，是一种浏览器安全机制，用于限制在一个源（协议、域名、端口）上运行的Web应用访问另一个源上的资源。为了确保安全性，浏览器在发送实际请求前，会先发起一个预检请求（OPTIONS 请求），以确认目标服务器是否允许该请求。

这种机制虽然提升了安全性，但也带来了性能问题。每个请求都需要额外的预检请求，尤其是在前端与后端位于不同地理位置时，延迟会显著增加。例如，从南非到 AWS 的 us-east-1 区域的往返时间为 400 到 800 毫秒，而预检请求会使延迟翻倍，达到 800 到 1200 毫秒。

解决CORS问题的根本方法是将前端和后端部署在同一个源上。对于传统的单服务器应用程序，这并不是问题，但当前端和后端分离时（如前端通过CloudFront托管，后端使用API Gateway），就需要通过反向代理来解决。

反向代理的作用

反向代理是一种服务器配置，它允许客户端通过当前源访问其他目标源的资源，并将这些资源返回给客户端，使其看起来像是来自当前源。

在我们的案例中，前端代码通过CloudFront的路径（如/backend-api/）发起请求，CloudFront会将这些请求转发到API Gateway。这样，前端无需直接调用API Gateway，从而避免了CORS问题。

配置反向代理的好处

消除CORS预检请求：前端和后端API位于同一源上，减少了约50%的请求延迟。
优化后端资源使用：CloudFront可以终止HTTPS连接，并使用HTTP与后端通信，降低SSL加密解密的计算开销。

实现反向代理的步骤

项目结构

该项目使用AWS CDK进行基础设施配置，主要包括以下组件：

CloudFront：作为CDN和反向代理。
API Gateway：后端服务的入口。
Lambda函数：处理后端逻辑。

完整代码可以在 GitHub 仓库中找到。

配置CloudFront行为

路径转发：将/cf-apigw路径下的所有请求转发到API Gateway域。
自定义域支持：通过/cf-cust-domain路径转发请求到API Gateway的自定义域。

注意事项

路径匹配：CloudFront会将行为路径模式附加到转发路径，因此API资源需要与路径模式保持一致。
缓存设置：将TTL值设置为0，禁用缓存行为，由后端通过适当的缓存头进行控制。
授权头：确保将授权头列入白名单，但不要将Host头列入白名单。

结果验证

通过CloudFront域访问时，可以看到一个基本的HTML页面，用于测试请求的详细信息。在本地主机运行时，由于域名不同，浏览器会发送OPTIONS预检请求。而通过CloudFront域访问时，预检请求被消除，显著降低了延迟。

以下是两种场景下的网络请求对比：

本地主机运行：包含OPTIONS请求，延迟较高。
CloudFront运行：无OPTIONS请求，延迟显著降低。

总结

通过CloudFront反向代理API Gateway，可以有效消除CORS问题，显著降低API请求的延迟。对于同时控制前端和后端的开发者来说，这是一种简单高效的解决方案。无论使用何种技术或框架，反向代理的概念都可以应用于类似场景。

完整项目代码和更多细节，请参考 GitHub 仓库。

原文链接: https://rehanvdm.com/blog/cloudfront-reverse-proxy-api-gateway-to-prevent-cors

使用CloudFront反向代理API Gateway以防止CORS问题

文章目录