有没有办法保护前端页面上的 API 密钥? [英] Is there a way to secure an API key on a frontend page?

问题描述

我的服务允许使用 POST 请求将任何 HTML 文档转换为 PDF.它主要用于我的客户端服务器的后端，因此用于通信的 API 密钥是保密的.

My service allow any HTML documents to be converted to PDF using a POST request. It is mostly used on the backend of my client's server and thus, the API key used for the communication is kept private.

现在，我正在考虑一种方法，让我的客户的访问者能够代表我的客户 API 密钥调用我的服务，而不会暴露这个安全的 API 密钥.

Now, I'm thinking of a way to let my client's visitors be able to call my service on behalf of my client API key, without exposing this secure API Key.

我的主要问题是安全性.如果我的客户添加了一个包含 API 密钥的 XHR POST 请求，那么有人可以获取该 API 密钥并将其用于自己的目的并滥用我客户的帐户.

My main issue here is security. If my client add an XHR POST requests that contains the API key, someone can take that API key and use it for their own purpose and abusing my client's account.

我可以按域进行过滤，但是这很容易被欺骗，所以这是不可能的.

I could filter by domain, but this is easily spoofed so it's not possible.

我想知道是否有一种方法可以从客户端(的客户端)调用私人服务并在不冒其身份被盗的风险的情况下进行识别?

I was wondering if there was a way to call a private service and be identified without risking its identity to be stolen, from the client ('s client) side?

推荐答案

如果您为经过身份验证的用户提供此 sublet，那么为他们提供唯一密钥(将他们的用户 ID 或会话与 API 密钥进行哈希处理的东西)相当简单和一个初始时间戳，并在访问 API 之前检查它/记录它/寻找蛮力).如果你在开放的网络上进行，没有任何类型的用户身份验证，那么速率限制确实会变得非常棘手.通常，您希望使用会话哈希、IP 地址、操作系统和浏览器数据的组合来创建一个匿名配置文件，该配置文件在前端获取一个临时密钥.一种相当可靠的方法是在提供临时密钥之前强制用户通过验证码，从而允许他们有限次数地使用永久密钥.任何其 ip/浏览器/会话与已知客户端密钥的现有属性匹配的用户都会被分流到那个用户(并跳过验证码)；任何与现有个人资料不匹配的人都会获得验证码.这使您成为欺骗目标的吸引力降低.最重要的是，您应该始终根据您期望(或负担得起)的流量类型，将整个事情的速率限制在合理的每天点击次数内，这样您就不会有任何意外.如果每次使用他们的 API 密钥时客户的钱都在线，这是您想要的最低限度的安全性.它将需要一个简单的数据库来存储这些配置文件"、跟踪使用情况、检查暴力并维护当前有效的客户端密钥.客户端密钥应始终定期过期 - 与创建它们的时间不同，或定期 cron 进程，或最大使用次数等.

If you're providing this sublet for authenticated users, then it's fairly trivial to give them unique keys (something that hashes their user ID or session against the API key and an initial timestamp, and checks it / logs it / looks for brutes before accessing the API). If you're doing it on the open web, without any kind of user authentication, then rate limiting gets very tricky indeed. Generally you'd want to use a combination of session hashes, IP address, operating system and browser data to create an anonymous profile that gets a temporary key on the frontend. One fairly solid way to do this is to force users through a CAPTCHA before serving a temporary key that allows them a limited number of uses of the permanent key. Any user whose ip/browser/session matches the existing attributes of a known client key is shunted to that one (and gets to skip the CAPTCHA); anyone who doesn't match an existing profile gets the CAPTCHA. That makes you a less attractive target for spoofing. On top of that, you should always rate-limit the entire thing, within a reasonable number of hits per day based on what kind of traffic you expect (or can afford), just so you don't have any surprises. This is the minimal security you'd want if your client's money is on the line every time their API key is used. It will require a simple database to store these "profiles", track usage, check for brutes and maintain the currently valid client keys. Client keys should always be expired regularly - either with a time diff against when they were created, or a regular cron process, or a maximum number of uses, etc.

我经常做的另一件事是基于曲线的速率限制.例如，如果我认为每分钟 5 次使用是合理的，那么在会话的一分钟内使用 5 次后，每次使用都会增加几分之一秒的延迟 * 最后一分钟的使用次数，平方，在数据之前已送达.

One other thing I frequently do is rate-limit based on a curve. If I think 5 uses per minute is reasonable, for example, then after 5 uses in a minute from a session, each usage adds a delay of a fraction of a second * the number of uses in the last minute, squared, before the data is served.

最好的答案是把这一切都放在一个登录系统后面并保护那个.

The best answer would be to put this all behind a login system and secure that.

这篇关于有没有办法保护前端页面上的 API 密钥?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！