15-07-2

所以纯javascript前端应用要去设置域名白名单，防止app id和app key被冒用。

15-07-4
zhaoxin

是的，应该通过安全域名和ACL来保证安全。但我的问题是，有App ID，安全域名和ACL。要App Key的意义是什么。因为它是暴漏给任何人的，所以完全没有意义呀。

15-07-4
wangxiao

安全文档我是细细看过一遍的，问题也是来源于这里。

每个 App 中有个 AppId，服务器都是通过这个唯一 id 来调用服务器端资源的，当然这个 AppId 理论上是保密的，但是太容易泄露了。Native 中可能成本要高些，但是在 Web 中你一定会把这个 AppId 写在页面里，其他人非常简单就可以查看到。所以我们来想一下我们需要做哪些防御？关键点是，我们要能够保证其他人把你的 AppId 偷过去之后，他也无法直接使用你的服务器资源。Web 端可以通过 Web 安全域名 来对请求来源做限制，可以简单的防御住 Web 的服务器资源盗取。但是安全域名对 Native 类的应用又是无效的，所以如果你是使用 Native App 的 SDK，那么设置安全域名就不够，这个时候就要考虑ACL 权限控制。

我非常同意App ID，安全域名加ACL来控制。我的问题是App Key的存在意义。连文档里都没有提到App Key对于安全的意义。

我不认同您说的App Key是用来确认权限的。因为它是暴漏出来的，所以有什么样的权限是要通过App Key来确认的呢？如果有，那么任何人都可以得到它来获得响应权限。

因此，我认为，在使用了App ID，安全域名和ACL以后，App Key有和没有对安全是没有任何区别的。因此觉得没有意义。

15-07-4

AppKey 是有意义的，LeanCloud 七月底正好会发布新版的 AppKey 策略，这里简单描述下。

正常来说，一个 App 应该有唯一一个 AppId 和多个可自定义的 AppKey 才对，比如 Web 的安全需要通过校验 http request 的 origin 和 Web 安全域名是否匹配，来检查权限的。也就是说 Web 中使用 LeanCloud 的服务，安全策略应该是不同于 Native 的，那如何做到？再比如 iOS、Android 的校验和加密方式可能是不同的，如何做到？

所以，可以通过 AppKey 的隔离来做到，同一个 App 的不同 AppKey 拥有不同的安全等级和校验方式，分别给不同的端来使用，或者不同的安全层级来使用。

这个功能七月底会发布出来，总之，LeanCloud 的安全策略也是在不断加强的一个功能，比如 6 月份，我们已经发布了「安全中心」。

1 人赞了这个帖子.
15-07-5

哦，这样啊，谢谢了，期待新的策略更新。

15-08-5
wangxiao

另外，如果没有很好地设置ACL，强烈不建议在web上使用AppId和AppKey。
因为在white list的web网站上，从firebug里调用AV的一切方法都被正常执行了，没有设置好ACL的情况下，相当于“开门揖盗”。
而且ACL要设置好也不是轻而易举的事，比如一条记录中，部分字段是用户输入的，部分字段是计算生成的，那么就无法通过ACL防范利用调试工具的入侵和篡改。

15-08-6

你可能没太理解 ACL，比如我现在可以往这个论坛里面，以我的名义随便的输入数据，那么这些数据是入侵和篡改么？其实不是，是我正常的逻辑。

一个条目的数据，你可以通过 LeanEngine 中的 Hook 来校验权限，比如通过 BeforeSave 这个 hook 在服务器端校验下用户权限即可。

15-08-6

我想说的是，虽然LeanCloud是要让开发者减少后端所花的精力，但不要因为有js api和white list而将业务逻辑全部放在前端来开发，特别是不要以为有white list就安全了。

这个页面是用AV.initialize(...)在前端写的吗？如果是，至少可以用浏览器的调试器如firebug去查看到很多隐藏的信息，或者直接使用AV.Object.extend()去添加些无用的垃圾。因为在调试器控制台直接输入命令会被认为是从white list网站调用的，这时候所有AV的操作均可正常执行。

至于篡改的问题，基于上述原因，举一个极端的栗子：假设有一个交易网站，是先支付再提交的，而提交条件是判断已支付金额是否等于待支付金额，交易条目的Class中有已支付金额的字段，那么用户通过在浏览器调试器控制台里set和save就可以更改已支付金额，从而实现篡改。这个极端栗子中，已支付金额本来是支付网站回调时修改的，但却可以被前端通过调试器进行篡改。

15-08-7
1

对，这是需要自己通过 Hook 增加权限校验的。

其实和你自己开发东西是一个道理，LeanCloud 提供了所有方法，安全上可以做到非常严密，只是很多用户能力可能还没达到，和不用 LeanCloud 开发是一个道理，很多初级程序员他们就不会意识到安全问题，比如 Cookie 都不设置 HttpOnly、HTML5 跨域可以返回 *（星号）、不会生成 CSRF 防御 Token 等。LeanCloud 提供了全套安全防御设计，你可以再仔细了解下，可以做到非常严密，一样的道理，需要更高开发水平和经验。

另外，我们没有认为增加 white list 就是安全的，这是一个安全上很小白的问题，请相信我们的技术实力和经验。 ：）

15-08-7

安全这块确实还可以做很多事情，我们也都在计划内正在实施。
核心目标是替 LeanCloud 用户发现问题，让他们能够很容易的做到非常安全。
所以，目前 AppKey 隔离、安全检测都在开发中，后续也会更加加强安全。

15-08-7

其实我还想说，既然app id + app key + white list其实并不安全，那还不如只使用app id + white list，避免无谓的app key的暴露。

别人有了你的app id 和 app key之后，就可以开发 android 或者 ios 或者 nodejs的应用来做一些坏事。
安全问题不可能固若金汤，app key的暴露比其他的诸如 Cookie 不设置 HttpOnly、HTML5 跨域可以返回 *（星号）、不会生成 CSRF 防御 Token 等问题严重多了。

这个想法在另一个帖子里提到过。不过既然你们在开发key隔离，让我们一起期待吧～～～

15-08-7
1

恩，感谢建议，你的担心我们都理解，这些安全问题也都在我们的安全评估内，请相信我们的技术实力和经验，我们也会不断提高基础安全等级的（当然这样做用户的学习成本就会提高）。

但是强调下，即使 AppId 和 AppKey 泄露，ACL 权限设置中有禁止客户端访问选项，你可以勾选。
之后所有 API 请求都必须传入 MasterKey，你可以将你的服务完全使用 LeanEngine，实现一套自定义的 API，就是非常安全的一种实现了，当然需要开发能力更高，所以其实你说的很多安全问题，其实很多我们的很多高级用户也了解，他们自己也会不断评估的，随着自己的产品成长，也会不断地更深入使用 LeanCloud 的安全相关服务。

安全问题本身是一个平衡问题，在 LeanCloud 你可以做到让你的应用非常安全，但你当然也要付出额外多的成本，需要你自己评估。但基础建设，我们一定会不断地加强。

1 人赞了这个帖子.
15-08-12

纯的web应用，如果是别人在firefox直接调试js来访问服务资源，这个怎么避免呢？

15-08-13

这个问题我们可以一起思考另一个问题，比如目前你打开微博，如果有个人在 FireFox 直接调试 JavaScript 来访问微博服务资源，那他能干什么呢？或者怎么避免呢？

其实这个问题就应该回复你的问题了，一个应用的安全，需要设计者不断地增强安全等级，如果他需要这种安全等级，那至少应该通过 AV.User 增加一个账号系统，增加 ACL 权限检测。那么这种调试，也做不了什么。

15-09-23

我也有同样类似的问题，Android端的SDK初始化时也是要这两个东西，那如果代码被反编译了，别人拿到了 App ID 和 App Key，那他不是可以通过 REST API 随便改我应用的所有数据了吗？

16-01-3

通过 ACL 来设置权限管理，相当于服务端做了安全检测。

16-01-4

如何做到呢？ 有没有相关资料？

16-01-4

我先简单描述下，appId 和 appKey 是用来标记和识别 App 的，也就是这个 App 可以访问哪个服务器资源包括数据。然后，什么是 ACL 权限管理呢？举个例子：在你的 App 逻辑中，A 用户只能访问他自己的资源，必须得 A 登录以后才可以，否则服务器拒绝。也就是，B 用户，没法在没有授权的情况下，访问到 A 用户的隐私数据，包括相关设置接口。

那么，现在其实一个道理，我即便知道了你的 AppId 和 AppKey，但是我没有登录，也就是我没有任何权限，那我怎么能够修改或者非法访问你的数据呢？除非你的数据都没有设置权限。

这个权限设置，就是通过 ACL 权限设置来管理的。

相关文档 https://leancloud.cn/docs/data_security.html21