1. 前端安全到底在防什么前端安全這個詞剛入行的同學聽起來容易覺得虛。頁面能跑、按鈕能點、接口能通不就完了嗎但真正做過線上項目的人都知道前端是離用戶最近的一層也是最容易被當成突破口的一層。用戶輸入的數(shù)據(jù)在這里落地第三方資源在這里加載瀏覽器各種存儲機制在這里被調用稍有不慎一個看似不起眼的細節(jié)就能變成整個系統(tǒng)的軟肋。我做了十多年前端從最早寫jQuery插件到現(xiàn)在搞微前端架構踩過的安全坑不算少。最典型的一次是某次大促前夜運營同學在后臺配置了一個帶特殊字符的商品標題結果整個列表頁的DOM結構被撐爆樣式全亂排查到凌晨三點才發(fā)現(xiàn)是拼接HTML時沒做轉義。這件事讓我徹底意識到前端安全不是“有空再優(yōu)化”的選項而是從第一行代碼開始就要刻在腦子里的習慣。這篇文章想聊的就是把前端常見的安全問題一次性捋清楚。我會按攻擊類型、觸發(fā)原理、實際代碼場景、防御手段這個順序來講每個點都配上能直接抄的代碼片段和配置示例。不管你是剛學完HTML CSS的新手還是已經能獨立帶項目的資深開發(fā)都能從中找到能立刻用上的東西。核心關鍵詞就一個前端安全。圍繞它展開的XSS、CSRF、點擊劫持、依賴鏈攻擊、敏感信息泄露等問題咱們一個一個拆。2. XSS跨站腳本攻擊前端安全的第一大敵人2.1 XSS到底是怎么發(fā)生的XSS的全稱是Cross-Site Scripting翻譯過來叫跨站腳本攻擊。名字聽著繞原理其實特別簡單攻擊者想辦法把一段可執(zhí)行的腳本代碼塞進你的頁面里當其他用戶訪問這個頁面時這段代碼就在他們的瀏覽器里跑起來了。因為瀏覽器分不清這段代碼是你寫的還是攻擊者寫的所以它會老老實實執(zhí)行。舉個最樸素的例子。假設你有個搜索頁面用戶輸入關鍵詞后頁面顯示“您搜索的是xxx”。如果代碼寫成這樣const keyword new URLSearchParams(location.search).get(q); document.getElementById(result).innerHTML 您搜索的是 keyword;正常用戶輸入“前端安全”頁面顯示“您搜索的是前端安全”沒問題。但如果攻擊者構造了這樣一個鏈接https://example.com/search?qimg srcx onerroralert(document.cookie)用戶點開這個鏈接innerHTML會把這段字符串當成HTML解析img標簽的onerror事件觸發(fā)alert(document.cookie)就執(zhí)行了。攻擊者可以把alert換成任何惡意代碼比如偷偷把cookie發(fā)到自己的服務器。這就是最典型的反射型XSS。還有存儲型XSS惡意代碼被存進數(shù)據(jù)庫所有訪問該頁面的用戶都會中招危害更大。以及DOM型XSS完全在前端JS里發(fā)生不經過服務器。2.2 防御XSS的核心思路防御XSS的核心原則只有一條永遠不要信任任何用戶輸入永遠不要直接把不可信數(shù)據(jù)插入到HTML里。具體落地的時候分幾個層面來做。第一層是輸出編碼。根據(jù)數(shù)據(jù)要插入的位置選擇對應的編碼方式。插入HTML內容區(qū)用HTML實體編碼插入HTML屬性用屬性編碼插入JavaScript代碼塊用JS編碼插入URL參數(shù)用URL編碼。很多同學只知道一個HTML轉義結果把數(shù)據(jù)放進onclick屬性里就出問題了。第二層是使用安全的API。能用textContent就不用innerHTML能用setAttribute就不用字符串拼接。React、Vue這些框架默認會對插值做轉義但dangerouslySetInnerHTML和v-html是明確的逃生艙口用的時候必須確保內容已經過嚴格凈化。第三層是CSP內容安全策略。這是一個HTTP響應頭告訴瀏覽器只允許加載和執(zhí)行哪些來源的資源。配置得當?shù)脑捈词构粽叱晒ψ⑷肓四_本瀏覽器也會拒絕執(zhí)行。一個相對嚴格的CSP配置長這樣Content-Security-Policy: default-src self; script-src self https://trusted-cdn.com; style-src self unsafe-inline; img-src self data: https:; object-src none; base-uri self; form-action self這里script-src self表示只允許執(zhí)行同源腳本內聯(lián)腳本和eval都會被攔。object-src none禁止加載Flash等插件內容。base-uri self防止攻擊者通過base標簽劫持相對路徑。注意CSP配置里盡量避免使用unsafe-inline和unsafe-eval這兩個指令會大幅削弱防護效果。如果必須用內聯(lián)腳本可以用nonce或hash機制。第四層是輸入驗證。雖然輸入驗證不能替代輸出編碼但能在早期過濾掉明顯惡意的內容。比如用戶年齡字段只允許數(shù)字那就用正則嚴格限制別等到輸出的時候再處理。2.3 富文本場景下的XSS防護實際項目里最頭疼的是富文本編輯器場景。用戶需要加粗、斜體、插入鏈接、上傳圖片這些功能天然需要保留一部分HTML標簽。這時候不能簡單粗暴地全部轉義得用白名單機制做凈化。推薦使用成熟的凈化庫比如DOMPurify。它的用法很簡單import DOMPurify from dompurify; const dirty img srcx onerroralert(1)p正常內容/p; const clean DOMPurify.sanitize(dirty, { ALLOWED_TAGS: [p, b, i, u, a, img, br], ALLOWED_ATTR: [href, src, alt, title] }); document.getElementById(content).innerHTML clean;DOMPurify會解析HTML移除不在白名單里的標簽和屬性同時處理各種繞過技巧比如svg里的腳本、math標簽的變體等。自己寫正則做凈化幾乎一定會被繞過這不是危言聳聽是無數(shù)安全事件驗證過的結論。還有一個細節(jié)容易被忽略href屬性里的javascript:協(xié)議。a hrefjavascript:alert(1)點擊/a這種寫法點擊就會執(zhí)行腳本。DOMPurify默認會處理這個問題但如果自己寫過濾邏輯一定要檢查協(xié)議白名單只允許http:、https:、mailto:、tel:這些安全協(xié)議。3. CSRF跨站請求偽造借用戶之手干壞事3.1 CSRF的攻擊邏輯CSRF的全稱是Cross-Site Request Forgery跨站請求偽造。它的思路和XSS不同XSS是往頁面里注入代碼CSRF是誘導用戶在已登錄狀態(tài)下去訪問一個攻擊者構造的頁面這個頁面會自動向目標網站發(fā)起請求。舉個例子。假設某銀行網站有個轉賬接口https://bank.com/transfer?toxxxamount1000用的是cookie鑒權。用戶登錄銀行后cookie就存在瀏覽器里。這時候用戶點開了一個惡意頁面頁面里藏了這樣一段代碼img srchttps://bank.com/transfer?toattackeramount10000 styledisplay:none瀏覽器加載這個img時會自動向銀行網站發(fā)起GET請求并且?guī)显摼W站的cookie。銀行服務器一看cookie有效就執(zhí)行了轉賬操作。用戶完全不知情。這就是CSRF的可怕之處它不需要竊取用戶的cookie只需要借用用戶的登錄狀態(tài)。攻擊者甚至不需要知道cookie的內容瀏覽器會自動帶上。3.2 防御CSRF的幾種武器防御CSRF最有效的手段是CSRF Token。服務器在渲染表單時生成一個隨機token存在session里同時放在表單的隱藏字段中。提交時服務器比對token是否匹配。攻擊者的頁面無法獲取這個token因為同源策略限制了跨域讀取。form action/transfer methodPOST input typehidden namecsrf_token value隨機生成的token input typetext nameto input typenumber nameamount button typesubmit轉賬/button /form服務器端驗證邏輯app.post(/transfer, (req, res) { const { csrf_token, to, amount } req.body; if (csrf_token ! req.session.csrfToken) { return res.status(403).send(CSRF token驗證失敗); } // 執(zhí)行轉賬邏輯 });第二種武器是SameSite Cookie屬性。設置SameSiteLax或SameSiteStrict后瀏覽器在跨站請求時不會發(fā)送cookie。Lax模式允許頂級導航的GET請求攜帶cookieStrict模式則完全禁止。對于大多數(shù)網站Lax是平衡安全性和用戶體驗的選擇。Set-Cookie: sessionidabc123; SameSiteLax; Secure; HttpOnlySecure表示只在HTTPS連接中發(fā)送cookieHttpOnly表示JavaScript無法讀取cookie能有效緩解XSS竊取cookie的問題。第三種武器是驗證請求頭。檢查Origin和Referer頭確認請求來自合法來源。不過這兩個頭在某些情況下可能被省略或偽造所以只能作為輔助手段。實操心得CSRF Token要綁定用戶session并且設置合理的過期時間。不要用固定token也不要把token放在URL里URL會被記錄在瀏覽器歷史、服務器日志、Referer頭里容易泄露。3.3 前后端分離架構下的CSRF防護現(xiàn)在很多項目是前后端分離的前端用React或Vue后端提供RESTful API。這種架構下如果鑒權用的是JWT放在localStorage里那CSRF的風險會小一些因為攻擊者的頁面無法讀取localStorage。但JWT放在cookie里的話CSRF風險依然存在。我的建議是如果JWT存在cookie里必須配合SameSite屬性和CSRF Token雙重防護。如果JWT存在localStorage里要注意XSS的風險因為XSS可以讀取localStorage。兩種方案各有取舍沒有銀彈。對于API請求可以在請求頭里加一個自定義字段比如X-Requested-With: XMLHttpRequest然后服務器檢查這個頭。跨域請求默認不能帶自定義頭除非服務器明確允許。這也是一種輕量級的防護手段。4. 點擊劫持與界面?zhèn)窝b攻擊4.1 點擊劫持的原理點擊劫持的英文是Clickjacking也叫UI覆蓋攻擊。攻擊者做一個透明的iframe覆蓋在一個誘導性的頁面上。用戶以為自己在點擊“領取獎品”按鈕實際上點擊的是iframe里某個網站的真實按鈕比如“確認轉賬”或“授權登錄”。這種攻擊的防御手段主要是設置響應頭。X-Frame-Options可以告訴瀏覽器是否允許頁面被iframe嵌入X-Frame-Options: DENYDENY表示完全禁止嵌入SAMEORIGIN表示只允許同源頁面嵌入。這個頭兼容性很好老瀏覽器也支持。更現(xiàn)代的方案是CSP的frame-ancestors指令Content-Security-Policy: frame-ancestors selfframe-ancestors比X-Frame-Options更靈活可以指定多個允許的來源。如果兩者同時存在frame-ancestors優(yōu)先級更高。前端還可以用JavaScript做輔助防御比如檢測當前頁面是否在iframe中if (window.self ! window.top) { window.top.location window.self.location; }但這種方式可以被繞過只能作為補充不能替代響應頭。4.2 界面?zhèn)窝b與視覺欺騙除了iframe覆蓋還有一種攻擊叫界面?zhèn)窝b。攻擊者把惡意頁面的外觀做得和目標網站一模一樣誘導用戶輸入賬號密碼。這種攻擊嚴格來說不算技術漏洞更多是釣魚手段但前端可以做些事情來幫助用戶識別。比如在敏感操作頁面顯示用戶自定義的標識像“上次登錄時間”、“歡迎語”等讓用戶確認這是真實網站。銀行網站常用這招。另外全站強制HTTPS配合HSTS頭能防止中間人篡改頁面內容。Strict-Transport-Security: max-age31536000; includeSubDomains; preload這個頭告訴瀏覽器在接下來的一年內該域名的所有請求都必須用HTTPS。includeSubDomains覆蓋所有子域名preload表示可以申請加入瀏覽器預加載列表連第一次HTTP請求都不會發(fā)出。5. 第三方依賴與供應鏈安全5.1 npm生態(tài)的依賴風險現(xiàn)代前端項目動輒幾百個npm包直接依賴可能只有幾十個但傳遞依賴能到上千個。這些包來自全球各地的開發(fā)者質量參差不齊。一個包被投毒整個項目就淪陷了。2018年有個著名事件某個流行的npm包被作者注入惡意代碼會竊取用戶的比特幣錢包信息。這個包被下載了數(shù)百萬次影響范圍極廣。還有更隱蔽的攻擊者注冊和知名包名字很像的包比如cross-env和crossenv開發(fā)者手滑打錯字就中招了。防御供應鏈攻擊首先要鎖定依賴版本。package-lock.json和yarn.lock必須提交到版本庫確保每次安裝的依賴樹完全一致。其次要定期審計依賴npm audit npm audit fixnpm audit會檢查依賴中的已知漏洞并給出修復建議。對于無法自動修復的要評估風險必要時手動升級或替換。還可以用npm outdated查看哪些包有新版本定期更新。但更新前要在測試環(huán)境充分驗證避免引入破壞性變更。5.2 第三方腳本的安全管理很多項目會引入第三方腳本比如統(tǒng)計工具、客服插件、廣告SDK。這些腳本運行在頁面里擁有和自家代碼一樣的權限能讀取DOM、cookie、localStorage。如果第三方腳本被入侵后果不堪設想。管理第三方腳本第一要限制來源只從可信CDN加載。第二要用SRISubresource Integrity校驗文件完整性script srchttps://cdn.example.com/lib.js integritysha384-xxxxxxxxxxxxxxxxxxxxxxxx crossoriginanonymous/scriptintegrity值是文件的哈希瀏覽器加載后會校驗不匹配就拒絕執(zhí)行。crossoriginanonymous表示跨域請求不帶憑證。第三對于非關鍵的第三方腳本可以異步加載避免阻塞頁面。還可以用iframe沙箱隔離限制其訪問父頁面的能力。注意SRI只對靜態(tài)文件有效如果第三方腳本是動態(tài)生成的SRI無法使用。這時候只能靠CSP限制來源并定期審查第三方腳本的行為。6. 敏感信息泄露與前端存儲安全6.1 前端存儲的坑前端能用的存儲機制有好幾種cookie、localStorage、sessionStorage、IndexedDB。每種都有適用場景但用錯了就是安全隱患。cookie會自動隨請求發(fā)送所以適合存session標識但要設置HttpOnly、Secure、SameSite。localStorage容量大適合存不敏感的用戶偏好但XSS能直接讀取。sessionStorage和localStorage類似但關閉標簽頁就清空。IndexedDB適合存大量結構化數(shù)據(jù)同樣受同源策略保護但XSS也能訪問。絕對不要把敏感信息存在前端。API密鑰、數(shù)據(jù)庫密碼、用戶密碼明文這些都不應該出現(xiàn)在前端代碼或存儲里。有些同學圖省事把API密鑰寫在JS文件里以為壓縮混淆就安全了。實際上打開開發(fā)者工具就能看到混淆只是增加閱讀難度不是加密。6.2 源碼泄露與Source Map生產環(huán)境的Source Map是個雙刃劍。它能幫助定位線上錯誤但也可能泄露源碼結構和業(yè)務邏輯。如果Source Map文件被公開訪問攻擊者能還原出接近原始的代碼發(fā)現(xiàn)潛在漏洞。我的做法是生產環(huán)境生成Source Map但只上傳到錯誤監(jiān)控平臺不部署到CDN?；蛘哂胔idden-source-map模式生成map文件但不添加引用注釋只有知道文件名的人才能訪問。// webpack.config.js module.exports { devtool: hidden-source-map, // 其他配置 };另外要確保.env文件、配置文件、備份文件不會被部署到Web目錄。Nginx配置里加上規(guī)則禁止訪問.開頭的隱藏文件和常見備份后綴location ~ /\. { deny all; } location ~* \.(env|log|bak|sql|zip|tar\.gz)$ { deny all; }6.3 錯誤信息與日志泄露開發(fā)環(huán)境的詳細錯誤堆棧對調試很有幫助但生產環(huán)境必須關閉。一個未捕獲的異?？赡馨褦?shù)據(jù)庫表名、文件路徑、框架版本都暴露出來。攻擊者收集這些信息后能更有針對性地發(fā)起攻擊。前端要做的是統(tǒng)一錯誤處理給用戶展示友好的提示同時把詳細錯誤上報到監(jiān)控平臺。不要直接把error.stack渲染到頁面上。window.addEventListener(error, (event) { // 上報到監(jiān)控平臺 reportError({ message: event.message, filename: event.filename, lineno: event.lineno, colno: event.colno, stack: event.error?.stack }); // 給用戶展示友好提示 showFriendlyMessage(頁面出了點小問題請稍后重試); // 阻止默認的控制臺輸出 return true; });7. 常見問題與排查技巧實錄7.1 安全自查清單項目上線前我習慣過一遍下面這個清單。每項都確認過心里才踏實。檢查項檢查內容風險等級XSS防護所有用戶輸入是否經過編碼或凈化高CSP配置是否設置了合理的Content-Security-Policy高CSRF防護敏感操作是否有Token或SameSite保護高點擊劫持是否設置了X-Frame-Options或frame-ancestors中依賴安全是否運行過npm audit且無高危漏洞高敏感信息前端代碼和存儲中是否包含密鑰或密碼高HTTPS是否全站HTTPS并配置HSTS高Source Map生產環(huán)境是否隱藏或限制訪問中錯誤處理生產環(huán)境是否關閉詳細錯誤輸出中第三方腳本是否使用SRI且限制來源中7.2 排查XSS的實用技巧遇到疑似XSS的問題我一般按這個順序排查。先看數(shù)據(jù)流用戶輸入從哪來經過哪些處理最終插入到哪里。重點檢查innerHTML、outerHTML、document.write、eval、setTimeout字符串參數(shù)這些危險API。然后看編碼插入HTML內容區(qū)用HTML實體編碼插入屬性用屬性編碼插入JS用JS編碼。很多漏洞是因為編碼方式用錯了比如把用戶輸入直接拼進onclick屬性里HTML實體編碼在屬性里會被解碼等于沒編碼。最后看CSP打開開發(fā)者工具看Console里有沒有CSP違規(guī)報告。如果有說明有腳本被攔截了可能是攻擊嘗試也可能是自己的代碼需要調整。7.3 依賴漏洞的應急處理npm audit報出高危漏洞時先別慌。第一步看漏洞詳情確認影響范圍。有些漏洞只在特定條件下觸發(fā)如果你的項目沒用那個功能風險就低。第二步看有沒有修復版本有就升級。第三步如果暫時無法升級看能否通過配置或代碼調整規(guī)避。我遇到過一種情況某個依賴的漏洞需要升級大版本才能修復但大版本有破壞性變更短期升不了。這時候的臨時方案是用overrides字段強制指定子依賴的版本{ overrides: { vulnerable-package: ^2.0.1 } }這個字段在npm 8.3以上支持能強制所有依賴使用指定版本。但用之前要測試確保不會引入兼容性問題。7.4 安全與體驗的平衡做安全防護最怕的是為了安全把用戶體驗搞崩。CSP配得太嚴內聯(lián)腳本全掛SameSite設成Strict從外部鏈接跳轉過來登錄狀態(tài)就丟了CSRF Token過期時間太短用戶填個長表單提交就失敗。我的經驗是安全策略要分層核心操作嚴格非核心操作寬松。比如支付、改密碼、授權登錄這些必須強驗證瀏覽、搜索、看公開內容可以適當放寬。CSP可以用Report-Only模式先跑一段時間收集違規(guī)報告確認不影響正常功能后再強制啟用。Content-Security-Policy-Report-Only: default-src self; report-uri /csp-report這個頭不會攔截任何內容只上報違規(guī)行為。觀察一兩周把誤報處理完再切換到強制模式。8. 把安全變成開發(fā)習慣寫了這么多其實核心就一句話前端安全不是某個階段的任務而是貫穿開發(fā)全流程的習慣。寫組件的時候多想一步“這個數(shù)據(jù)來自用戶我轉義了嗎”引入依賴的時候多看一眼“這個包靠譜嗎”配置服務器的時候多檢查一遍“響應頭設對了嗎”。我自己的做法是在項目里建一個SECURITY.md把上面那些檢查項和配置示例都記進去。每次新項目啟動直接復制過來按清單過一遍。新同學入職也讓他們先讀這個文檔知道哪些線不能踩。還有一個習慣是定期做安全演練。找個測試環(huán)境自己嘗試構造XSS payload、CSRF請求、點擊劫持頁面看看防護措施是否生效。這種實戰(zhàn)比看文檔印象深得多。最后分享一個我常用的XSS測試payload集合放在測試環(huán)境里驗證防護效果img srcx onerroralert(1) svg onloadalert(1) a hrefjavascript:alert(1)click/a iframe srcjavascript:alert(1) div stylebackground:url(javascript:alert(1)) input onfocusalert(1) autofocus details open ontogglealert(1)這些payload在測試環(huán)境跑一遍如果都被攔截或轉義了說明防護基本到位。如果有一個彈窗就順著數(shù)據(jù)流往回查找到漏洞點修復。安全這件事做得好沒人夸出了事就是大事。與其事后救火不如平時多花點時間把基礎打牢。上面這些內容都是我這些年踩坑踩出來的經驗希望能幫你少走點彎路。