前端安全即JS代码安全，前端源码安全探讨！

迈不过友情╰ 2022-01-17 15:11 468阅读 0赞

**前端源码安全**

今天思考下前端源码安全的东西，不讲前端安全的大课题，只是针对于源码部分。  
在我看来，源码安全有两点，一是防止抄袭，二是防止被攻破。  
实际上，前端的代码大多是没有什么可抄袭性，安全更是形同虚设的（任何前端输入都是不能相信的）。但如果还是想防止源码被查看，HTML、CSS并不能做什么，最终都会用露出来（创新型的ShareWAF之类WAF类产品，可以做html整体加密，不在本文讨论之列），所以只能针对JS做文件的混淆加密。

**关于抄袭**  
其实就前端来讲，多数代码没有什么好抄袭的，除了一些特效、游戏、前端展示性的类app功能，那么前端源码保护主要可以说为了防分析，防止人们知道其中逻辑，这里有两个案例：一个是之前锤子手机发布时的作弊丑闻，一个是小米手机在英国发布时的作弊事件，巧了，都是手机，都是作弊，都是前端JS代码引起的问题，被分析，曝光...，其实，做一下js混淆加密，这一切就都不会发生了，可惜了，这么大的公司，不注重前端安全，得不偿失啊。  
混淆加密是防止其他人查看代码逻辑，生成的代码比原代码体积大一些，但现在的网速、机器性能、浏览器性能，完全不需要考虑这点性能损失。说了这么多，前端js代码混淆加密怎么做，推荐产品吧，国外有jscrmber，国内有jshaman。（推荐用国内的）！

**关于安全**  
所有的用户输入都是不能相信的，如果后端的检查校验还做得不好，那就可能被攻破。前端代码的逻辑如果还被了解清楚，那就是雪上加霜。后端的问题我们前端管不着，前端的代码安全，就是用混淆加密解决，让别人看不懂。

**HTML压缩**  
很少有人去做HTML的压缩（特指去除空白字符和注释），根据其他资料有几个原因：

1. HTML文档中，多个空白字符等价为一个空白字符。也就是说换行等空白字符的删除是不安全的，可能导致元素的样式产生差异。  
2. HTML元素中，有一个pre, 表示 preformatted text. 里面的任何空白，都不能被删除。  
3. HTML中有可能有 IE 条件注释。这些条件注释是文档逻辑的一部分，不能被删除。

也是鉴于上面几个原因，不提倡压缩HTML，通过服务器的gzip压缩就已经能达到很好的效果。

**JS压缩合并混淆**  
在生产环境上，压缩合并是不必做的。但现在很多人都在做，号称是为了提高加载速度，事实上，不得不说：把多个html、css、js压缩成一个文件，这能快的了？原来一个文件100K，并行加载，是半行同时加载啊！2秒就加载完了。  
压成一个后呢，经常可见的是达到好几MB，不能同时加载了，想想吧，是快了还是慢了，认为压成一个文件加载更快的人们啊，真得去交个智商税了。。。对单个js文件混淆加密就行了，不要压成一个文件，不要压成一个文件。重要的事情说两遍。

[**js代码混淆**][js]**效果怎么样？**

混淆加密前：  
function hello()\{  
   alert('hello');  
\}

用JShaman混淆加密后：  
var  \_0x08e6=\['hello'\];(function(\_0x560c7b,\_0x17e70b)\{var   \_0x56bb8b=function(\_0x4ccb21)\{while(--\_0x4ccb21)\{\_0x560c7b\['\\x70\\x75\\x73\\x68'\](\_0x560c7b\['\\x73\\x68\\x69\\x66\\x74'\]());\}\};\_0x56bb8b(++\_0x17e70b);\}(\_0x08e6,0x77));var  \_0x608e=function(\_0x4d0ca4,\_0x58e301)\{\_0x4d0ca4=\_0x4d0ca4-0x0;var   \_0x50ffc7=\_0x08e6\[\_0x4d0ca4\];return \_0x50ffc7;\};function   hello()\{alert(\_0x608e('0x0'));\}

绝对够用！

**总结**

1、前端安全需要重视，将来会越来越被重视，因为它真重要。

2、不要进行多文件压缩，不要把html、css、js压到一起，很不明智的做法。

3、前端安全，就是js代码安全，对js做混淆加密是正道！

转载于:https://blog.51cto.com/14237227/2364204

[js]: http://www.jshaman.com/