前端源碼安全
今天思考下前端源碼安全的東西，不講前端安全的大課題，只是針對於源碼部分。
在我看來，源碼安全有兩點，一是防止抄襲，二是防止被攻破。
實際上，前端的代碼大多是沒有什麼可抄襲性，安全更是形同虛設的（任何前端輸入都是不能相信的）。但如果還是想防止源碼被查看，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代碼混淆效果怎麼樣？
混淆加密前：
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做混淆加密是正道！