有没有办法在前端页面上保护 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，那么为他们提供唯一的密钥(根据 API 密钥散列他们的用户 ID 或会话的东西)是相当简单的和一个初始时间戳，并在访问 API 之前检查它/记录它/寻找野蛮人).如果您是在开放网络上进行操作，而没有任何类型的用户身份验证，那么速率限制确实会变得非常棘手.通常，您希望使用会话哈希、IP 地址、操作系统和浏览器数据的组合来创建匿名配置文件，该配置文件在前端获取临时密钥.一种相当可靠的方法是在提供临时密钥之前强制用户通过验证码，允许他们有限次数地使用永久密钥.任何 ip/浏览器/会话与已知客户端密钥的现有属性匹配的用户都会被分流到那个用户(并且可以跳过 CAPTCHA)；任何与现有配置文件不匹配的人都会获得 CAPTCHA.这使您成为欺骗目标的吸引力较小.最重要的是，您应该始终对整个事情进行速率限制，根据您期望(或能够承受)的流量类型，在每天合理的点击次数内，这样您就不会感到意外.如果每次使用他们的 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屋！