在JS里，初始化时要提供App ID和App Key
AV.initialize('asdfasdfgrefsrf', 'asdfasdfasdfadsf');可是由于是在web端，所以App ID和App Key都是暴漏给用户的。那么它们起的作用就只是标明应用ID。所以为什么还要提供App Key？不是无谓的暴漏在客户端了吗？
15年7月2日
16年1月4日
所以纯javascript前端应用要去设置域名白名单，防止app id和app key被冒用。
这个是有用处的，appId 是用来明确是哪个应用，appKey 是用来确认权限的。
所以一般来说，一个请求需要这两个参数来控制。
相关安全内容，可以参考 LeanCloud 官方的安全文档。
http://leancloud.cn/docs/data_security.html80
安全文档我是细细看过一遍的，问题也是来源于这里。
每个 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有和没有对安全是没有任何区别的。因此觉得没有意义。
AppKey 是有意义的，LeanCloud 七月底正好会发布新版的 AppKey 策略，这里简单描述下。
正常来说，一个 App 应该有唯一一个 AppId 和多个可自定义的 AppKey 才对，比如 Web 的安全需要通过校验 http request 的 origin 和 Web 安全域名是否匹配，来检查权限的。也就是说 Web 中使用 LeanCloud 的服务，安全策略应该是不同于 Native 的，那如何做到？再比如 iOS、Android 的校验和加密方式可能是不同的，如何做到？
所以，可以通过 AppKey 的隔离来做到，同一个 App 的不同 AppKey 拥有不同的安全等级和校验方式，分别给不同的端来使用，或者不同的安全层级来使用。
这个功能七月底会发布出来，总之，LeanCloud 的安全策略也是在不断加强的一个功能，比如 6 月份，我们已经发布了「安全中心」。
哦，这样啊，谢谢了，期待新的策略更新。
请问，分权的AppKey什么时候能出来啊？
另外，如果没有很好地设置ACL，强烈不建议在web上使用AppId和AppKey。
因为在white list的web网站上，从firebug里调用AV的一切方法都被正常执行了，没有设置好ACL的情况下，相当于“开门揖盗”。
而且ACL要设置好也不是轻而易举的事，比如一条记录中，部分字段是用户输入的，部分字段是计算生成的，那么就无法通过ACL防范利用调试工具的入侵和篡改。
你可能没太理解 ACL，比如我现在可以往这个论坛里面，以我的名义随便的输入数据，那么这些数据是入侵和篡改么？其实不是，是我正常的逻辑。
一个条目的数据，你可以通过 LeanEngine 中的 Hook 来校验权限，比如通过 BeforeSave 这个 hook 在服务器端校验下用户权限即可。
我想说的是，虽然LeanCloud是要让开发者减少后端所花的精力，但不要因为有js api和white list而将业务逻辑全部放在前端来开发，特别是不要以为有white list就安全了。
这个页面是用AV.initialize(...)在前端写的吗？如果是，至少可以用浏览器的调试器如firebug去查看到很多隐藏的信息，或者直接使用AV.Object.extend()去添加些无用的垃圾。因为在调试器控制台直接输入命令会被认为是从white list网站调用的，这时候所有AV的操作均可正常执行。
至于篡改的问题，基于上述原因，举一个极端的栗子：假设有一个交易网站，是先支付再提交的，而提交条件是判断已支付金额是否等于待支付金额，交易条目的Class中有已支付金额的字段，那么用户通过在浏览器调试器控制台里set和save就可以更改已支付金额，从而实现篡改。这个极端栗子中，已支付金额本来是支付网站回调时修改的，但却可以被前端通过调试器进行篡改。
对，这是需要自己通过 Hook 增加权限校验的。
其实和你自己开发东西是一个道理，LeanCloud 提供了所有方法，安全上可以做到非常严密，只是很多用户能力可能还没达到，和不用 LeanCloud 开发是一个道理，很多初级程序员他们就不会意识到安全问题，比如 Cookie 都不设置 HttpOnly、HTML5 跨域可以返回 *（星号）、不会生成 CSRF 防御 Token 等。LeanCloud 提供了全套安全防御设计，你可以再仔细了解下，可以做到非常严密，一样的道理，需要更高开发水平和经验。
另外，我们没有认为增加 white list 就是安全的，这是一个安全上很小白的问题，请相信我们的技术实力和经验。 ：）
安全这块确实还可以做很多事情，我们也都在计划内正在实施。
核心目标是替 LeanCloud 用户发现问题，让他们能够很容易的做到非常安全。
所以，目前 AppKey 隔离、安全检测都在开发中，后续也会更加加强安全。
其实我还想说，既然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隔离，让我们一起期待吧～～～
恩，感谢建议，你的担心我们都理解，这些安全问题也都在我们的安全评估内，请相信我们的技术实力和经验，我们也会不断提高基础安全等级的（当然这样做用户的学习成本就会提高）。
但是强调下，即使 AppId 和 AppKey 泄露，ACL 权限设置中有禁止客户端访问选项，你可以勾选。
之后所有 API 请求都必须传入 MasterKey，你可以将你的服务完全使用 LeanEngine，实现一套自定义的 API，就是非常安全的一种实现了，当然需要开发能力更高，所以其实你说的很多安全问题，其实很多我们的很多高级用户也了解，他们自己也会不断评估的，随着自己的产品成长，也会不断地更深入使用 LeanCloud 的安全相关服务。
安全问题本身是一个平衡问题，在 LeanCloud 你可以做到让你的应用非常安全，但你当然也要付出额外多的成本，需要你自己评估。但基础建设，我们一定会不断地加强。
纯的web应用，如果是别人在firefox直接调试js来访问服务资源，这个怎么避免呢？
这个问题我们可以一起思考另一个问题，比如目前你打开微博，如果有个人在 FireFox 直接调试 JavaScript 来访问微博服务资源，那他能干什么呢？或者怎么避免呢？
其实这个问题就应该回复你的问题了，一个应用的安全，需要设计者不断地增强安全等级，如果他需要这种安全等级，那至少应该通过 AV.User 增加一个账号系统，增加 ACL 权限检测。那么这种调试，也做不了什么。
我也有同样类似的问题，Android端的SDK初始化时也是要这两个东西，那如果代码被反编译了，别人拿到了 App ID 和 App Key，那他不是可以通过 REST API 随便改我应用的所有数据了吗？
通过 ACL 来设置权限管理，相当于服务端做了安全检测。
如何做到呢？ 有没有相关资料？
