前端原始碼安全

今天思考下前端原始碼安全的東西（不是前端安全，只是針對於原始碼部分）。在我看來，原始碼安全有兩點，一是防止抄襲，二是防止被攻破。實際上講，前端的**大多是沒有什麼可抄襲性，安全更是形同虛設的（任何前端輸入都是不能相信的）。但如果還是想防止原始碼被檢視，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壓縮合併混淆

grunt需要配置兩個檔案：

package.json：宣告應用資訊和使用依賴庫的版本

,
"devdependencies":
}

gruntfile.js：宣告壓縮合併的檔案

module.exports = function
(grunt),
uglify : }}
});grunt.loadnpmtasks('grunt-contrib-concat');
grunt.loadnpmtasks('grunt-contrib-uglify');
grunt.registertask('default', ['concat','uglify']);
}

js的混淆我到現在為止還沒用過，原理都是類似的，混淆是把js**變成亂七八糟的字串，然後用eval執行。

ps：uglify本身有一定的混淆作用，但也只是對變數名的混淆，混淆度並不夠。

混淆前：

function
hello()

混淆後：

eval(function(p,a,c,k,e,r)];e=function();c=1};while(c--)if(k[c])p=p.replace(new regexp('\\b'+e(c)+'\\b','g'),k[c]);return p}('1 0()',3,3,'hello|function|alert'.split('|'),0,{}))

不同混淆演算法混淆的結果不一樣，而且混淆後也不是一勞永逸，還是可以被反混淆的。另外混淆會降低程式執行效能，所以是否需要做混淆得做評估。

總結

我覺得做好檔案壓縮合併，簡單的變數名混淆就可以了，並不需要那麼徹底的混淆。即便是前端被人挖得清清楚楚，只要後端強勁也就沒問題了。所以當你想進行**混淆時候，想想是為了什麼，值不值得。

另外我們有時可能會做一些富前端的外包，那我們在交付之前可以對前端指令碼進行加密，供演示使用。

1. 在**裡面設定乙個**過期時間，過期後**就無法使用了。

2. 對js進行壓縮混淆。

分類:

5.前後端安全

前端原始碼安全

前端原始碼安全

閱讀前端專案原始碼的正確姿勢

前端小菜狗看vue原始碼Part One

前端原始碼安全

前端原始碼安全

閱讀前端專案原始碼的正確姿勢

前端小菜狗看vue原始碼Part One

相關推薦