今天思考下前端源码安全的东西（不是前端安全，只是针对于源码部分）。在我看来，源码安全有两点，一是防止抄袭，二是防止被攻破。实际上讲，前端的代码大多是没有什么可抄袭性，安全更是形同虚设的（任何前端输入都是不能相信的）。但如果还是想防止源码被查看，HTML、CSS并不能做什么，最终都会用露出来（最简单用Chrome开发者工具就可以看到），所以只能针对JS做文件的压缩合并和混淆。
关于抄袭
其实就前端来讲，代码没有什么好抄袭的，大多人都是抄UI设计（这个是躲不了），还有一些富前端的控件和算法，重要之处还是在于后端，而后端是抄不了的。所以前端文件压缩合并，目的并不是防止抄袭，而是为了减少文件体积、加快载入速度，提高程序的执行性能，当然压缩也有混淆的功能。文件混淆是防止其他人查看代码逻辑，但是生成的代码比原代码体积大得多，所以文件如果做了混淆，加载速度和执行速度都会有所下降。
关于安全
所有的用户输入都是不能相信的，如果后端的检查校验还做得不好，那就可能被攻破。前端代码的逻辑如果还被了解清楚，那就是雪上加霜。后端的问题我们前端管不着，前端的代码安全，简单的可以用压缩解决、再进一步就去混淆，让别人看不懂。
HTML压缩
很少有人去做HTML的压缩（特指去除空白字符和注释），根据其他资料有几个原因：
1. HTML文档中，多个空白字符等价为一个空白字符。也就是说换行等空白字符的删除是不安全的，可能导致元素的样式产生差异。
2. HTML元素中，有一个pre, 表示 preformatted text. 里面的任何空白，都不能被删除。
3. HTML中有可能有 IE 条件注释。这些条件注释是文档逻辑的一部分，不能被删除。
也是鉴于上面几个原因，不提倡压缩HTML，通过gzip压缩就已经能达到很好的效果。
CSS压缩合并
CSS压缩合并很常见，或者说是必做的，可以由后端动态生成或工具提前生成。目的也只是为了提高加载速度，CSS即便的压缩之后，代码也是清晰可见，没有混淆说法。CSS压缩合并的工具很多，一般是用sass、less直接生成压缩后的CSS，如果是直接压缩，用grunt还不错。
JS压缩合并混淆
在生产环境上，压缩合并是必做的。就如上面说的，目的不是为了防止暴露业务逻辑，是为了提高载入速度。在上一篇文章《AngularJS结合RequireJS做文件合并压缩的那些坑》，说了一点JS压缩合并要注意的东西。除了用RequireJS，直接使用grunt来做发布是不错的方式，开发后一键调用grunt。
grunt需要配置两个文件：
package.json：声明应用信息和使用依赖库的版本
{
"name":"BingoTouch",
"version":"3.0.0",
"engines":{
"node":">= 0.8.0"
},
"devDependencies":{
"grunt":"~0.4.0",
"grunt-contrib-concat":"~0.3.0",
"grunt-contrib-copy" : "~0.4.1",
"grunt-contrib-cssmin" : "~0.6.0",
"grunt-contrib-uglify":"~0.2.0",
"express":""
}
}
Gruntfile.js：声明压缩合并的文件
module.exports = function(grunt){
grunt.initConfig({
pkg : grunt.file.readJSON(‘package.json‘),
concat : {
‘dist/bingotouch.js‘ :
[ ‘demo/js/ui.js‘,
‘demo/js/module/ui.GarbageCollection.js‘,
‘demo/js/module/ui.plugins.js‘]
},
uglify : {
target : {
files : {
‘dist/bingotouch.min.js‘: ‘dist/bingotouch.js‘
}
}
}
});
grunt.loadNpmTasks(‘grunt-contrib-concat‘);
grunt.loadNpmTasks(‘grunt-contrib-uglify‘);
grunt.registerTask(‘default‘, [‘concat‘,‘uglify‘]);
}
JS的混淆我到现在为止还没用过，原理都是类似的，混淆是把JS代码变成乱七八糟的字符串，然后用eval执行。
PS：uglify本身有一定的混淆作用，但也只是对变量名的混淆，混淆度并不够。
混淆前：
function hello(){
alert(‘hello‘);
}
混淆后：
eval(function(p,a,c,k,e,r){e=String;if(!‘‘.replace(/^/,String)){while(c--)r[c]=k[c]||c;k=[function(e){return r[e]}];e=function(){return‘\\w+‘};c=1};while(c--)if(k[c])p=p.replace(new RegExp(‘\\b‘+e(c)+‘\\b‘,‘g‘),k[c]);return p}(‘1 0(){2(\‘0\‘)}‘,3,3,‘hello|function|alert‘.split(‘|‘),0,{}))
不同混淆算法混淆的结果不一样，而且混淆后也不是一劳永逸，还是可以被反混淆的。另外混淆会降低程序执行性能，所以是否需要做混淆得做评估。
总结
我觉得做好文件压缩合并，简单的变量名混淆就可以了，并不需要那么彻底的混淆。即便是前端被人挖得清清楚楚，只要后端强劲也就没问题了。所以当你想进行代码混淆时候，想想是为了什么，值不值得。
本文为原创文章，转载请保留原出处，方便溯源，如有错误地方，谢谢指正。
本文地址 ：http://www.cnblogs.com/lovesong/p/5185543.html