可以使用 Cloudflare 缓存和保护 REST API 吗？

Question

我正在设计一个旨在供单页应用程序和本机移动应用程序使用的 RESTful API。此 API 的某些调用会返回可以缓存一段时间的公共结果。此外，还需要速率保护来保护 API 免受未经授权的用户（蜘蛛）的攻击

我可以使用 Cloudflare 为我的 RESTful API 实施缓存和速率限制/DDOS 保护吗？

缓存： Cloudflare supports HTTP cache control headers，因此 API 可以决定通过 GET 请求的每个实体是否是公共的以及可以缓存多长时间。

• 但是不清楚缓存控制头是否也被下游传递给客户端，所以也会触发浏览器缓存响应？这可能是不可取的，因为它可能会使故障排除更加困难
• Akamai 有一个Edge-Control header 以确保内容缓存在 CDN 中，而不是浏览器中。 可以用 Cloudflare 做类似的事情吗？

DDOS 保护： Cloudflare 支持有一篇文章 recommending that DDOS protection be disabled for backend APIs，但这不适用于我的用例，即每个客户端都应该向 API 发出少量请求。原生 DDOS 保护实际上符合我保护 API 免受机器人攻击的要求。

• 我需要知道如何以编程方式检测 Cloudflare 何时提供 Captcha / 我受到攻击 等页面然后，这将允许 SPA / 移动应用程序智能地做出反应，并将用户重定向到一个网络视图，在那里她可以展示她的“人性”。

• 从 Cloudflare 文档中，当出现 DDOS 质询时发送什么 HTTP 状态代码并不明显。绕过 Cloudflare DDOS 保护的开源 cloudscraper 似乎表明 Captcha 和质询页面以 HTTP 状态 200 传递。有没有比解析请求正文更好的方法来确定 DDOS 保护是否启动？

• Cloudflare apparently uses cookies 记录谁成功解决了验证码。这显然会给原生应用程序带来一些额外的复杂性。 在挑战解决后，有没有将 Cloudflare 会话 cookie 传输回本机应用程序的好方法？

这可能是一个高级 Cloudflare 用例 - 但我认为它很有希望，并且很高兴听到是否有人有类似的经验（在 Cloudflare 或其他 CDN 上）。

Answer 1

Cloudflare 已发布 a list of best practices 以将其与 API 结合使用。

TL;DR，他们建议设置一个修补所有 API 请求的页面规则并在其上放置以下设置：

1. 缓存级别：绕过
2. 始终在线：关闭
3. Web 应用程序防火墙： 关闭
4. 安全级别：除了“我受到攻击”之外的任何内容
5. 浏览器完整性检查：关闭

Answer 2

是的，CloudFlare 可以帮助进行 DDOS 保护，不，它不会为您的 API 实现缓存和速率限制。您将自己实现这些，或者您使用一个框架来实现。

您可以使用 CloudFlare 作为代理来保护您的 API 端点。 CloudFlare 保护整个 URL 位，您可以使用页面规则来调整您的 api 端点的设置。

Example: https://api.example.com/*

• 将此规则的安全性降低到低或中之间，以便 不显示验证码。
• API 并不是为了显示验证码，您使用授权和访问代码保护它们。
• 您可以在标头上实施 HTTP 严格传输安全和访问控制标头。
• 云托管服务提供商（例如 DigitalOcean、Vultr 等）提供免费或付费的 DDoS 保护。您可以仅在面向公众的 VM 上订阅它。这将是一大优势，因为现在您拥有双重 DDOS 保护。

对于缓存 API

Create a page rule like https://api.example.com/*.json

• 为该规则设置缓存级别，以便 CloudFlare 将其缓存在其服务器上一段特定的时间。

还有很多其他方法可以保护 API。希望这个答案对您有所帮助？

Answer 3

这是来自@flexresponsive 的一个 5 年前的问题，最近的答案是 3 年前写的，并在 2 年前发表了评论。虽然我确信 OP 现在已经找到了解决方案，无论是在 CloudFlare 中还是在其他地方，我都会更新以现代（2020 年）方式给出的解决方案并留在 CloudFlare 中。详细的页面规则对任何人来说都是一个好主意；但是对于 OP 的特定需求，这个特定的集合与“CloudFlare Workers”脚本相结合将是有益的：

1. Edge Cache TTL: (n)time 设置为 CloudFlare 沿/在其“边缘”中缓存您的 API 内容所需的时间（来自边缘节点/服务器场位置的路由取决于一个人的帐户计划，“免费" 优先级最低，因此更有可能从延迟较高的位置向您的消费者提供内容。

2. 但是 Edge Cache TTL > 0（基本上完全使用它）这将不允许设置以下内容，这可能对您的 API 很重要，也可能不重要：

3. Cache Deception Armor:ON

4. Origin Cache Control:ON如果使用 #3 并且您想要执行以下操作：

5. 将 Cache Level: Cache Everything 与在调用 API 期间运行的工作程序结合使用。紧扣主题，我将展示两个特定于您的 API 的路由/地址的标头。

  addEventListener("fetch", event => {
  event.respondWith(fetchAndReplace(event.request));
    });
    async function fetchAndReplace(request) {
    const response = await fetch(request);
      let type = response.headers.get("Content-Type") || "";
      if (!type.startsWith("application/*")) {
      return response;
        }
      let newHeaders = new Headers(response.headers);
         'Cache-Control', 's-maxage=86400';
         'Clear-Site-Data', '"cache"';
    return new Response(response.body, {
    status: response.status,
    statusText: response.statusText,
    headers: newHeaders
    });
   }

在设置两个特定于缓存的标头时，您是在说“只有共享代理才能缓存它”。但是，不可能完全控制任何共享代理的实际行为，因此取决于 API 有效负载，如果这是一个问题，no-transform 值可能是有价值的，例如如果 only JSON 在起作用，那么没有它你会很好，除非行为不端的缓存决定一路破坏它，但如果说，你将提供任何需要完整性哈希或nonce 然后使用 no-transform 是必须确保有效负载根本不被更改并且在被更改时无法验证为来自您的 API 的文件。设置了 Cache 值的 Clear-Site-Data 标头指示消费者的浏览器在接收有效负载时从本质上清除缓存。 “缓存”需要在 HTTP 标头中的双引号内才能发挥作用。

只要运行检查以确保您的消费者没有遇到无法将 API 负载直接传输给他们并且 hCaptcha 启动的阻塞情况，检查包含 cf 字符串的查询字符串的最终目的地（我不记得确切的布局，但它肯定会有 CloudFlare cf 并且绝对不是您希望您的消费者登陆的地方。除此之外，CloudFlare 使用的“正常”DDoS 保护不会由 与 API 的正常交互。我还建议不要遵循 CloudFlare 的具体建议来使用除“我受到攻击”之外的任何安全级别；在这一点上，我必须指出，即使 5-第二次重定向不会在每个请求上发生，hCaptchas 将在安全级别低、中和高时触发。将安全级别设置为“基本上关闭”并不意味着安全级别为空；此外，WAF 将捕获标准违规和 th at 当然可以根据您的 API 提供的内容进行调整。

希望这是有用的，如果不是对 OP 至少对其他潜在的访问者来说。