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