这可能是一个通用的安全问题，但我想我应该在我正在开发的领域提出问题。
场景是:一个 Web 服务(WCF Web Api)，使用 API key 来验证并告诉我用户是谁，以及前端的 jQuery 和应用程序的组合。
一方面，流量可以是 https，因此无法检查，但如果我对每个用户使用相同的 key (例如 guid)，并且我在两者中都使用它，那么就有可能会被采取并且有人可以冒充用户。
如果我实现类似于 OAuth 的功能，则会生成一个用户和每个应用程序 key ，这可以工作 - 但对于 jQuery 端，我仍然需要 javascript 中的应用程序 API key 。
只有当有人在实际计算机上查看源代码时，这才会成为问题。
我应该做什么？
- md5 或以某种方式加密 key ？
- 将 key 放入 session 变量中，然后在使用 ajax 时检索它？
- 克服它，这不是什么大问题。
我确信这可能是一个常见问题 - 因此欢迎任何指点。
为了让这一点更清楚 - 这是我编写的 API，我正在查询，而不是 google 等。所以我可以执行每个 session token 等，我只是想找出保护我将使用的客户端 token / key 的最佳方法。
我在这里有点过于谨慎，但只是用它来学习。
最佳答案
(我建议将这篇文章标记为“安全”。)
首先，您应该清楚您要防范的是什么。你能完全信任客户吗？狡猾的用户可以在您的页面上粘贴 Greasemonkey 脚本，并准确调用您的 UI 发送请求所调用的代码。将所有内容隐藏在 Javascript 闭包中只意味着您需要一个调试器；这并不意味着攻击变得不可能。 Firebug 可以跟踪 HTTPS 请求。还要考虑受感染的客户端:是否安装了键盘记录器？整个系统是否 secret 运行虚拟化，以便攻击者可以在闲暇时随时检查内存的任何部分？当您像网络应用一样暴露时，安全性确实很棘手。
尽管如此，您还是需要考虑以下几点:
考虑不实际使用 key ，而是使用 HMAC 哈希值，例如您在身份验证后立即提供的 token 。
DOM 存储可能比 Cookie 更难破解。
看看Google's implementation of OAuth 2举一个安全模型的例子。基本上，您使用的 token 仅在有限的时间内有效(可能对于单个 IP 地址)。这样，即使 token 被拦截或克隆，它也只能在很短的时间内有效。当然，当代币用完时，你需要小心你的行为；攻击者是否可以执行与您的代码相同的操作并获得新的有效 token ？
不要忽视服务器端安全性:即使您的客户端应该在提交请求之前进行检查，也要在服务器上再次检查用户是否确实有权执行他们所要求的操作。事实上，这个建议可能会消除上述大部分内容。
关于javascript - Web 服务 API key 和 Ajax - 保护 key ，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/6302341/