微信小程序发布成功之后。 用户有没有可能通过一些特殊的处理方式，来获取到当前微信小程序的源码？
对于这种类似的问题，腾讯官方技术方面，有没有做什么相应的应对措施？
由于一直没有找到，微信小程序的官方技术支持的人工联系方式。所以在这里把问题发布出来，希望各位做技术的同仁、以及小程序的官方技术人员，能够帮忙。
谢谢！
收藏
回答
置顶小程序的源码会不会泄露？精选热门
人间无事2018-10-23
| 框架类型 | 问题类型 | 操作系统版本 | 手机型号 | 微信版本 |
|---|---|---|---|---|
| 小程序 | Bug | iOS 11.3 | 1863xxxxxxx | 6.7.3 |
最后一次编辑于 2018-10-23
试试能不能扒自己的源码
https://zhuanlan.zhihu.com/p/37667537
现在有一种操作叫反编译，确实可以拿到小程序源码，一般接口都会加token，这个token来源又是wx.login时得到的，意思就是服务端那边只有原本的小程序能访问，其他的小程序都不行的。反编译得到的源码里没有project.config.json这个配置文件，不用担心appid暴露，所以别人拿到的只是前端代码，有token验证的并不能正常使用。还有一些小程序源码是经过特殊处理的，被反编译后，都不能运行。
谢谢！
如果是反编译的文件里面没有project.config.json这个文件，那么就是说appid不会暴露。
那么，是否存在这种可能：如果拿到除了project.config.json的所有代码文件，那么我是否可以通过其他的任意一个有效的appid把当前的小程序代码，运行起来？
可以的，重新申请一个账号把自己的APPID填进去，然后再在微信后台配置一下requestURL，只要后台接口没有验证，大部分功能都是可以用的（支付除外）
谢谢！
如果后台接口验证的话， 可以采取什么方式来验证呢？
这就要看你反编译的小程序开发者有没有做安全验证，如果异步请求中带上了用token生成的session，那你就无法换个有效appid去请求别人的接口。但是那些没有前后端交互的小程序，特别是单机版的小游戏，反编译一个换个appid就可以了，冷门一点的你甚至可以直接提交审核，说不定还会过
比如所有请求参数先排序，然后拼接成a=xxx&b=xxxc=xxx的形式，再md5加密一下生成一串字符串，后台接口也按照这个规则生成一个字符串，通过判断这两个字符串是否相等来验证
直接仿你的所有页面和功能，提供产品核心竞争力，别人是仿不了的
这种问题好像没有讨论的必要
其实是会有的，其实人家不破解你，也可以模仿你的，但自己的数据接口要做好安全规范
我这么说吧，我前段时间刚刚为了找官方一个api，破了人家的包。所以吧，前端也是无奈。你只能尽可能保证。再说，前端技术大家都看得到。你说百度还有淘宝，人家的前端代码你不是一样能得到。没有绝对安全，做好该做的。服务器也不安全。前端还好了，服务器的安全不是大公司都不怎么懂。
毕竟是前端，说获取不到那是假的，网上大把的文章教程反编译，但是上传的时候会进行加密混淆让可读性不那么高。所以一些安全性，重要的逻辑业务最好在后端处理（也应该说必须在后端处理），后端多加层验证层，来判断客户端传入的是否合法，就算别有用心的人扒了你的小程序源码但是接口还是用不了的。
只要你有js,就能反编译,防不住的,这个论坛里就有人发过破解源码的帖子
对待“薅羊毛”的问题一般都是几个方面综合考虑的：
业务上增加人机交互的方式，尽量避免脚本调用的情况，比如：加验证码（图文、动态、滑块等等）的方式，
技术上在接口请求上增加防重放、防参数串改机制；增加用户属性的识别标准，比如通过对羊毛党手机号的号段黑名单过滤等方式、比如接入一些第三方的工具来判断用户是否存在刷单风险；公司如果有能力的话可以建立自己的风控系统，具体的设计可以参考淘宝的防刷的风控系统和京东的风控系统；
谢谢！
“技术上在接口请求上增加防重放、防参数串改机制；”
如果源码泄露的话，这种规则也就没什么的作用了吧？
你的意思应该是，主要还是在业务流程上来限制吧？
源码泄漏毕竟是对一些高级的羊毛党而言的，这种事就是不断增加羊毛党的薅羊毛成本，从而控制这种比例的。技术上还是有其他限制方式的，这种事一般都是两种思想、发生前的风控预防，发生后的补救措施，比如用户拉黑、限制使用等等，多和公司运营的人员讨论，去寻找羊毛党的共性，然后再去做相应的防护和限制。
研究的方向错了。
客户端（前端）历来没有绝对的安全，只要有人想破解，客户端的安全机制立马就会土甭瓦解。只要代码要在客户端运行，就有能力研究出来程序的运行机制。
所有前端只能简单的设置一道防护机制，防君子不防小人。小程序的包拿到后需要再反编译一下就是这个道理。
现在所有的公司都是在做数据上的安全防护，这一道把好关了，就随便他们折腾。
“导致了某些人使用特殊工具，调用网络接口，批量注册，领取礼品”
后台可以做大量的限制，增加小人们的完成这一流程的成本。比如，限制注册，领取礼品要求，实际得到礼品收益的要求，等等。。。。
“大多数都是僵尸用户。”， “能超过七成的用户都是忠实的用户”
哪个公司都没有办法避免僵尸用户，如果用户量级没有千万级或者更高，或者对服务器产生压力，就不用考虑，可以对每个用户做有效识别，或者打上标签，真要是胆大，半年后对僵尸用户做一次清理，误伤一两个有效用户，也在可以接受的范围内。
以上只是鄙人一些建议，希望帮到楼主
谢谢！
你意思是，这个问题，已经不能从技术层次解决了对吧？而是要考虑在业务逻辑、业务流程上做限制。对吧？
其实当前我这个小程序面向的用户，并不是所有人，而是特定某个行业里面的一些人员。如果是少数“薅羊毛”的存在，我可以接受。按照流程在小程序内部注册，领取礼品等等，这些毕竟是通过正常的流程完成的操作，遵守了“游戏”规则。
但是目前为止这种用户数量，已经远远超过了正常注册人员数量。对于这种通过特殊工具，批量注册来获取礼品的人，我还是希望能够在技术上能够做到一定程度上的限制。
另外，诚挚的感谢你的建议。
哈，只是简单探讨一下，不算是特别有用的建议。
有时候技术也是有局限性的
比如说，游戏的外挂，顶级公司也没有办法，靠谱的做法是频繁更新验证策略，增加外挂的跟随成本。
比如说，微信相关的灰产软件，微信的做法是封号处理。
比如说，前一段时间，比较火的月饼事件，最后开除员工（我是无法接受这样的做法），后台相应修复。
。。。
以上事件，大部分还是在自有平台上发生的，我们使用的小程序是在一个第三方平台托管运行，受制更多。
看吧，类似的问题，最后都不是以技术手段作为终结，这也是没有办法的办法。软件行业只能是先有矛，再有盾，而且是一个时时修复的盾。
所以只能从去他角度去解决问题了。