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

查看:52
本文介绍了有没有办法保护前端页面上的API密钥?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我的服务允许使用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?

推荐答案

如果您要为经过身份验证的用户提供此子租约,则为他们提供唯一密钥(将其用户ID或会话针对API密钥进行哈希处理的东西)就相当简单了.和初始时间戳,并在访问API之前对其进行检查/对其进行记录/查找是否存在暴力.如果您是在开放的Web上进行的,而没有任何类型的用户身份验证,那么速率限制的确会非常棘手.通常,您需要结合使用会话哈希,IP地址,操作系统和浏览器数据来创建匿名配置文件,该配置文件在前端获得临时密钥.一种相当可靠的方法是在提供临时密钥之前强制用户通过CAPTCHA,该临时密钥允许他们有限次数地使用永久密钥.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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆