前端js控制步骤（如何保护前端JS代码）

前端js控制步骤（如何保护前端JS代码）JS代码保护的目的已经达到了，不是吗？ 当正真的混淆和加密联合使用，可以实现真正的JS代码安全保护。JS混淆中融入JS加密，JS加密中又嵌入JS混淆。这样保护后的代码，即使在客户端执行环境中被逆向还原，得到的也是大量含义不明的函数、代码、字符串。特别重点是：代码已经经过了重建，这时逆向得到的也是分离后的重建的无意义JS代码、大量的僵尸代码、混淆的字符串、不明含意的变量。可读性与原始代码相比……天壤之别。 固执的人或许还会说：没有破解不了的保护方案，只要我认真、用心、用时的分析，还是能分析出原始代码含意的，确实，可能如此。 但是，原本的代码，可能只需要读10分钟，而从这样保护后的JS代码读取原始含意，可能需要……10个月。而这时候，我们的JS代码可能已经更新到下一版了。

@淘宝攻略 技术分享

淘宝攻略

Web前端JS代码需要保护吗？

这得具体情况具体分析：

1. 如果只是写一段web页面图片轮播，或是跑马灯效果等等之类简单的功能。那不需要保护。
2. 如果是精心设计一个绚丽的特效，如果想要保护这段自己付诸幸苦实现的特效代码不被他人随意拿去使用，那应该保护这段JS代码！
3. 如果页面上有重要的功能是用JS代码管控的，比如交易逻辑、帐号密码信息、个人隐私、甚至有与远程服务器或数据库的通信等等，那么相关的js代码非常应该被保护、应该做JS代码防盗保护！否则可能引起被黑客分析、攻击等严重问题。安全相关的事情，从来都要防患于未然、不可心存侥幸。除非它对你毫不重要。

如何保护Web前端JS代码？

1. 打包&压缩
   有人认为打包、压缩就是对JS代码的保护。确实，打包在一定程度上可以起码些许保护作用，好像看起来是如此。但打包、压缩的目的并不是为了保护JS代码，而是为了使用方便、减小代码体积，方便使用、便于传输。比如模块化的编程可能产生200个JS文件，如果使用时逐一用“script src”进行引用……这是种折磨，不管是对于代发人员，还是网络加载（浏览器也会生气！x_x）。
   类似Webpacket、Gulp进行打包，可以将这些多个JS合成到一个文件，并且可能会进行回车、换行、空格的删除，以实现代码压缩，也有一些简单混淆操作：把长变量名改为统一风格的短变量名等。然后，最终生成的一个文件。代码总量减小了、可读性差了、使用方便了。同时让有些人认为这也实现了JS代码保护。其实、实际上、当然的代码并没有被保护：可读性依旧，只是代码量大了一些而已，只要稍稍耐心的读代码，会发现，代码依然是很易理解的，没有多少安全性可言。
2. 混淆&加密
   前端JS代码的保护，必需要混淆和加密共用。
   单独的JS源代码加密，是行不通的，更不可能有所谓的JS不可逆加密。因为代码在浏览器端执行时，必须转解密还原成原始代码，才能被浏览器的JS引擎识别和运行。在解密后，会存在完整的原始JS代码。这是非常不安全的存在，有多种方法可将原始的JS代码显示出来。

JS代码混淆被不少开发人员认为是不够高端的JS代码保护方式，听起来不如JS源码加密更具安全性。事实上，混淆也有多个级别。比如比较低端的字符搜索和串替换、随机插入伪僵尸代码、字符串十六进制化等等。而也有高端的手法，会先进行语法分析、词法分析，重建语法树，相当于已经实现了一个JS引擎，在引擎中处理代码，那么，就可以在其中任意一步进行自由度极高的操作，比如在语法树中插入新的语法结构、比如可以将字符串全部提取并进行加密、可以对变量进行整体有规则化的重定义使无意义化等等。这样就可以实现真正的代码重建。这样重建的JS代码安全性，将会有一个质的提升。

当正真的混淆和加密联合使用，可以实现真正的JS代码安全保护。JS混淆中融入JS加密，JS加密中又嵌入JS混淆。这样保护后的代码，即使在客户端执行环境中被逆向还原，得到的也是大量含义不明的函数、代码、字符串。特别重点是：代码已经经过了重建，这时逆向得到的也是分离后的重建的无意义JS代码、大量的僵尸代码、混淆的字符串、不明含意的变量。可读性与原始代码相比……天壤之别。

固执的人或许还会说：没有破解不了的保护方案，只要我认真、用心、用时的分析，还是能分析出原始代码含意的，确实，可能如此。

但是，原本的代码，可能只需要读10分钟，而从这样保护后的JS代码读取原始含意，可能需要……10个月。而这时候，我们的JS代码可能已经更新到下一版了。

JS代码保护的目的已经达到了，不是吗？