在客户端应用程序中保护 YouTube v3 API 密钥

Posted 2023-02-24

【中文标题】在客户端应用程序中保护 YouTube v3 API 密钥

【英文标题】：Protecting YouTube v3 API key in a client-side application

【发布时间】：2014-10-28 17:01:14

【问题描述】：

我正在查看以下指南：https://developers.google.com/youtube/v3/getting-started

与 YouTube 的 API 交互的第一步是：

您需要一个 Google 帐户才能访问 Google Developers Console， 请求 API 密钥，然后注册您的应用程序。

他们继续展示他们使用密钥的示例：

网址： https://www.googleapis.com/youtube/v3/videos?id=7lCDEYXw3mM&key=YOUR_API_KEY &part=sn-p,contentDetails,statistics,status

我有一个被很多人使用的客户端应用程序。该应用程序向 YouTube 的 API 发出搜索请求。 YouTube 的 API 的请求限制为每天 5000 万次请求。

因为它是一个客户端应用程序，所以我的 API 密钥被嵌入到代码中。

今天，一个恶意用户编写了一些脚本来最大化请求：

我想知道我有什么办法可以抵御这种活动。我唯一的选择是托管服务器，通过我的服务器路由对 YouTube API 的所有需求，并在请求过于频繁时拒绝请求？

我对实施这样的事情有真正的担忧。它会有效地将每个 API 请求的等待时间加倍，并且还会对服务器造成看似不必要的负担，但也许是需要的。

我还有其他选择吗？

谢谢

【问题讨论】：

是“客户端应用程序”==“网络应用程序”吗？或者它是一个移动应用程序？

它是一个浏览器扩展，所以它是一个不被服务器隐式支持的网络应用程序。

【参考方案1】：

不要认为它是恶意用户。我认为 YouTube 方面出了点问题，因为我看到从我的应用发出的 API 请求完全相同的问题

【讨论】：

哇！！真的吗？废话！

是的。还有其他人看到同样的问题：***.com/questions/25657245/… 和 ***.com/questions/25670351/…

现在似乎每 1 个请求都“计数”为 150

【参考方案2】：

您可以使用限制来保护您的 API 密钥。

使用公共 API 密钥的 REFERERS 属性。在console developers -> API&Auth -> Credentials 中转到您的项目

如果您将 Key 用于浏览器应用程序，REFERERS 是对 一个域。 如果您使用服务器密钥，REFERERS 是对 IP 的引用。 （例如您的服务器的 IP）

例如，如果您使用 github.io 进行应用程序的现场演示，REFERERS 将指向http://user.github.io/*

您可以阅读更多register your application

如果您的应用程序在服务器上运行，请使用服务器密钥。不要使用这个 服务器代码之外的密钥。例如，不要将其嵌入网络中 页。为防止配额被盗，请限制您的密钥，以便请求 仅允许来自您服务器的源 IP 地址。

使用浏览器密钥 如果您的应用程序在客户端（例如 Web 浏览器）上运行。到 防止您的密钥在未经授权的网站上使用，只允许 来自您管理的域的推荐。

帮助您的屏幕：

【讨论】：

浏览器扩展默认没有referrer，实际上可以通过chrome.webRequest.onBeforeSendHeaders拦截请求头来修改他们的referrer。 :( 与基于 IP 地址限制每个用户相同 - 他们可以修改 IP 地址，因为它是从客户端发送的。

【参考方案3】：

这是由于配额成本增加所致，已暂时恢复。今后，我们将在 http://apiblog.youtube.com/ 和 https://developers.google.com/youtube/v3/revision_history 中公布费用变化。

【讨论】：

嘿，我在错误报告中也说过，但我也会在这里回复。您能否澄清一下您所说的暂时恢复是什么意思？ YouTube 是否有意将成本提高 150 倍？这似乎太离谱了。我的申请目前每天会产生8-1000万积分的费用。将该成本乘以 150 会有效地削弱我的应用程序。

【参考方案4】：

这似乎是一个重大错误。同样的问题 - 从 9 月 3 日开始，配额使用率飙升，现在请求的成本比 documentation states 高得多。

有人将其报告为他们的错误跟踪系统中的一个缺陷。我建议所有受影响的人都去那里为缺陷加注星标以帮助引起人们的注意：

https://code.google.com/p/gdata-issues/issues/detail?id=6623&q=label%3AAPI-YouTube&sort=-id&colspec=API%20ID%20Type%20Status%20Priority%20Stars%20Summary

【参考方案5】：

我提出以下想法：

您可以确保访问您页面的用户是人类（使用验证码等） 将您的 API 调用隐藏在由您的前端触发的 AJAX 调用后面（如 GET /callgoogleapi）； AJAX 调用的处理程序可以设置频率阈值，即每秒 2 个请求。如果太快，API 调用不会进行，AJAX 会回复类似“用户操作太快”的消息。

【讨论】：

我在帖子中提到了这一点，以及我对将请求隐藏在代理后面的担忧。试图让我的服务器每天处理 1000 万个 API 请求，同时有效地将响应时间加倍似乎是一个糟糕的决定，但对我来说这是唯一明显的决定。

【参考方案6】：

没错。当您制作您的钥匙时，请确保您使用了 REFERERS，这样即使他们得到了您的钥匙，它也不会为他们工作！

【讨论】：

不幸的是，我的问题是针对没有引荐来源的 chrome 扩展。

【参考方案7】：

我们也看到了这个错误，看来是偏差太大了。结果概述为 813.844，但 API 在今天的 50,000,000 个请求中使用了 49,379,348 个