1. 前端安全到底在防什么前端安全這個(gè)詞剛?cè)胄械耐瑢W(xué)聽起來容易覺得虛。頁(yè)面能跑、按鈕能點(diǎn)、接口能通不就完了嗎但真正做過線上項(xiàng)目的人都知道前端是離用戶最近的一層也是最容易被當(dāng)成突破口的一層。用戶輸入的數(shù)據(jù)在這里落地第三方資源在這里加載瀏覽器各種存儲(chǔ)機(jī)制在這里被調(diào)用稍有不慎一個(gè)看似不起眼的細(xì)節(jié)就能變成整個(gè)系統(tǒng)的軟肋。我做了十多年前端從最早寫jQuery插件到現(xiàn)在搞微前端架構(gòu)踩過的安全坑不算少。最典型的一次是某次大促前夜運(yùn)營(yíng)同學(xué)在后臺(tái)配置了一個(gè)帶特殊字符的商品標(biāo)題結(jié)果整個(gè)列表頁(yè)的DOM結(jié)構(gòu)被撐爆樣式全亂排查到凌晨三點(diǎn)才發(fā)現(xiàn)是拼接HTML時(shí)沒做轉(zhuǎn)義。這件事讓我徹底意識(shí)到前端安全不是“有空再優(yōu)化”的選項(xiàng)而是從第一行代碼開始就要刻在腦子里的習(xí)慣。這篇文章想聊的就是把前端常見的安全問題一次性捋清楚。我會(huì)按攻擊類型、觸發(fā)原理、實(shí)際代碼場(chǎng)景、防御手段這個(gè)順序來講每個(gè)點(diǎn)都配上能直接抄的代碼片段和配置示例。不管你是剛學(xué)完HTML CSS的新手還是已經(jīng)能獨(dú)立帶項(xiàng)目的資深開發(fā)都能從中找到能立刻用上的東西。核心關(guān)鍵詞就一個(gè)前端安全。圍繞它展開的XSS、CSRF、點(diǎn)擊劫持、依賴鏈攻擊、敏感信息泄露等問題咱們一個(gè)一個(gè)拆。2. XSS跨站腳本攻擊前端安全的第一大敵人2.1 XSS到底是怎么發(fā)生的XSS的全稱是Cross-Site Scripting翻譯過來叫跨站腳本攻擊。名字聽著繞原理其實(shí)特別簡(jiǎn)單攻擊者想辦法把一段可執(zhí)行的腳本代碼塞進(jìn)你的頁(yè)面里當(dāng)其他用戶訪問這個(gè)頁(yè)面時(shí)這段代碼就在他們的瀏覽器里跑起來了。因?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è)面顯示“您搜索的是前端安全”沒問題。但如果攻擊者構(gòu)造了這樣一個(gè)鏈接https://example.com/search?qimg srcx onerroralert(document.cookie)用戶點(diǎn)開這個(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ù)所有訪問該頁(yè)面的用戶都會(huì)中招危害更大。以及DOM型XSS完全在前端JS里發(fā)生不經(jīng)過服務(wù)器。2.2 防御XSS的核心思路防御XSS的核心原則只有一條永遠(yuǎn)不要信任任何用戶輸入永遠(yuǎn)不要直接把不可信數(shù)據(jù)插入到HTML里。具體落地的時(shí)候分幾個(gè)層面來做。第一層是輸出編碼。根據(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屬性里就出問題了。第二層是使用安全的API。能用textContent就不用innerHTML能用setAttribute就不用字符串拼接。React、Vue這些框架默認(rèn)會(huì)對(duì)插值做轉(zhuǎn)義但dangerouslySetInnerHTML和v-html是明確的逃生艙口用的時(shí)候必須確保內(nèi)容已經(jīng)過嚴(yán)格凈化。第三層是CSP內(nèi)容安全策略。這是一個(gè)HTTP響應(yīng)頭告訴瀏覽器只允許加載和執(zhí)行哪些來源的資源。配置得當(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防止攻擊者通過base標(biāo)簽劫持相對(duì)路徑。注意CSP配置里盡量避免使用unsafe-inline和unsafe-eval這兩個(gè)指令會(huì)大幅削弱防護(hù)效果。如果必須用內(nèi)聯(lián)腳本可以用nonce或hash機(jī)制。第四層是輸入驗(yàn)證。雖然輸入驗(yàn)證不能替代輸出編碼但能在早期過濾掉明顯惡意的內(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í)處理各種繞過技巧比如svg里的腳本、math標(biāo)簽的變體等。自己寫正則做凈化幾乎一定會(huì)被繞過這不是危言聳聽是無數(shù)安全事件驗(yàn)證過的結(jié)論。還有一個(gè)細(xì)節(jié)容易被忽略href屬性里的javascript:協(xié)議。a hrefjavascript:alert(1)點(diǎn)擊/a這種寫法點(diǎn)擊就會(huì)執(zhí)行腳本。DOMPurify默認(rèn)會(huì)處理這個(gè)問題但如果自己寫過濾邏輯一定要檢查協(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)下去訪問一個(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)開了一個(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è)面無法獲取這個(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無法讀取cookie能有效緩解XSS竊取cookie的問題。第三種武器是驗(yàn)證請(qǐng)求頭。檢查Origin和Referer頭確認(rèn)請(qǐng)求來自合法來源。不過這兩個(gè)頭在某些情況下可能被省略或偽造所以只能作為輔助手段。實(shí)操心得CSRF Token要綁定用戶session并且設(shè)置合理的過期時(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è)面無法讀取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。兩種方案各有取舍沒有銀彈。對(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è)允許的來源。如果兩者同時(shí)存在frame-ancestors優(yōu)先級(jí)更高。前端還可以用JavaScript做輔助防御比如檢測(cè)當(dāng)前頁(yè)面是否在iframe中if (window.self ! window.top) { window.top.location window.self.location; }但這種方式可以被繞過只能作為補(bǔ)充不能替代響應(yīng)頭。4.2 界面?zhèn)窝b與視覺欺騙除了iframe覆蓋還有一種攻擊叫界面?zhèn)窝b。攻擊者把惡意頁(yè)面的外觀做得和目標(biāo)網(wǎng)站一模一樣誘導(dǎo)用戶輸入賬號(hào)密碼。這種攻擊嚴(yán)格來說不算技術(shù)漏洞更多是釣魚手段但前端可以做些事情來幫助用戶識(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è)頭告訴瀏覽器在接下來的一年內(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è)。這些包來自全球各地的開發(fā)者質(zhì)量參差不齊。一個(gè)包被投毒整個(gè)項(xiàng)目就淪陷了。2018年有個(gè)著名事件某個(gè)流行的npm包被作者注入惡意代碼會(huì)竊取用戶的比特幣錢包信息。這個(gè)包被下載了數(shù)百萬次影響范圍極廣。還有更隱蔽的攻擊者注冊(cè)和知名包名字很像的包比如cross-env和crossenv開發(fā)者手滑打錯(cuò)字就中招了。防御供應(yīng)鏈攻擊首先要鎖定依賴版本。package-lock.json和yarn.lock必須提交到版本庫(kù)確保每次安裝的依賴樹完全一致。其次要定期審計(jì)依賴npm audit npm audit fixnpm audit會(huì)檢查依賴中的已知漏洞并給出修復(fù)建議。對(duì)于無法自動(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è)想。管理第三方腳本第一要限制來源只從可信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沙箱隔離限制其訪問父頁(yè)面的能力。注意SRI只對(duì)靜態(tài)文件有效如果第三方腳本是動(dòng)態(tài)生成的SRI無法使用。這時(shí)候只能靠CSP限制來源并定期審查第三方腳本的行為。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也能訪問。絕對(duì)不要把敏感信息存在前端。API密鑰、數(shù)據(jù)庫(kù)密碼、用戶密碼明文這些都不應(yīng)該出現(xiàn)在前端代碼或存儲(chǔ)里。有些同學(xué)圖省事把API密鑰寫在JS文件里以為壓縮混淆就安全了。實(shí)際上打開開發(fā)者工具就能看到混淆只是增加閱讀難度不是加密。6.2 源碼泄露與Source Map生產(chǎn)環(huán)境的Source Map是個(gè)雙刃劍。它能幫助定位線上錯(cuò)誤但也可能泄露源碼結(jié)構(gòu)和業(yè)務(wù)邏輯。如果Source Map文件被公開訪問攻擊者能還原出接近原始的代碼發(fā)現(xiàn)潛在漏洞。我的做法是生產(chǎn)環(huán)境生成Source Map但只上傳到錯(cuò)誤監(jiān)控平臺(tái)不部署到CDN?；蛘哂胔idden-source-map模式生成map文件但不添加引用注釋只有知道文件名的人才能訪問。// webpack.config.js module.exports { devtool: hidden-source-map, // 其他配置 };另外要確保.env文件、配置文件、備份文件不會(huì)被部署到Web目錄。Nginx配置里加上規(guī)則禁止訪問.開頭的隱藏文件和常見備份后綴location ~ /\. { deny all; } location ~* \.(env|log|bak|sql|zip|tar\.gz)$ { deny all; }6.3 錯(cuò)誤信息與日志泄露開發(fā)環(huán)境的詳細(xì)錯(cuò)誤堆棧對(duì)調(diào)試很有幫助但生產(chǎn)環(huán)境必須關(guān)閉。一個(gè)未捕獲的異?？赡馨褦?shù)據(jù)庫(kù)表名、文件路徑、框架版本都暴露出來。攻擊者收集這些信息后能更有針對(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)小問題請(qǐng)稍后重試); // 阻止默認(rèn)的控制臺(tái)輸出 return true; });7. 常見問題與排查技巧實(shí)錄7.1 安全自查清單項(xiàng)目上線前我習(xí)慣過一遍下面這個(gè)清單。每項(xiàng)都確認(rèn)過心里才踏實(shí)。檢查項(xiàng)檢查內(nèi)容風(fēng)險(xiǎn)等級(jí)XSS防護(hù)所有用戶輸入是否經(jīng)過編碼或凈化高CSP配置是否設(shè)置了合理的Content-Security-Policy高CSRF防護(hù)敏感操作是否有Token或SameSite保護(hù)高點(diǎn)擊劫持是否設(shè)置了X-Frame-Options或frame-ancestors中依賴安全是否運(yùn)行過npm audit且無高危漏洞高敏感信息前端代碼和存儲(chǔ)中是否包含密鑰或密碼高HTTPS是否全站HTTPS并配置HSTS高Source Map生產(chǎn)環(huán)境是否隱藏或限制訪問中錯(cuò)誤處理生產(chǎn)環(huán)境是否關(guān)閉詳細(xì)錯(cuò)誤輸出中第三方腳本是否使用SRI且限制來源中7.2 排查XSS的實(shí)用技巧遇到疑似XSS的問題我一般按這個(gè)順序排查。先看數(shù)據(jù)流用戶輸入從哪來經(jīng)過哪些處理最終插入到哪里。重點(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ì)被解碼等于沒編碼。最后看CSP打開開發(fā)者工具看Console里有沒有CSP違規(guī)報(bào)告。如果有說明有腳本被攔截了可能是攻擊嘗試也可能是自己的代碼需要調(diào)整。7.3 依賴漏洞的應(yīng)急處理npm audit報(bào)出高危漏洞時(shí)先別慌。第一步看漏洞詳情確認(rèn)影響范圍。有些漏洞只在特定條件下觸發(fā)如果你的項(xiàng)目沒用那個(gè)功能風(fēng)險(xiǎn)就低。第二步看有沒有修復(fù)版本有就升級(jí)。第三步如果暫時(shí)無法升級(jí)看能否通過配置或代碼調(diào)整規(guī)避。我遇到過一種情況某個(gè)依賴的漏洞需要升級(jí)大版本才能修復(fù)但大版本有破壞性變更短期升不了。這時(shí)候的臨時(shí)方案是用overrides字段強(qiáng)制指定子依賴的版本{ overrides: { vulnerable-package: ^2.0.1 } }這個(gè)字段在npm 8.3以上支持能強(qiáng)制所有依賴使用指定版本。但用之前要測(cè)試確保不會(huì)引入兼容性問題。7.4 安全與體驗(yàn)的平衡做安全防護(hù)最怕的是為了安全把用戶體驗(yàn)搞崩。CSP配得太嚴(yán)內(nèi)聯(lián)腳本全掛SameSite設(shè)成Strict從外部鏈接跳轉(zhuǎn)過來登錄狀態(tài)就丟了CSRF Token過期時(shí)間太短用戶填個(gè)長(zhǎng)表單提交就失敗。我的經(jīng)驗(yàn)是安全策略要分層核心操作嚴(yán)格非核心操作寬松。比如支付、改密碼、授權(quán)登錄這些必須強(qiáng)驗(yàn)證瀏覽、搜索、看公開內(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. 把安全變成開發(fā)習(xí)慣寫了這么多其實(shí)核心就一句話前端安全不是某個(gè)階段的任務(wù)而是貫穿開發(fā)全流程的習(xí)慣。寫組件的時(shí)候多想一步“這個(gè)數(shù)據(jù)來自用戶我轉(zhuǎn)義了嗎”引入依賴的時(shí)候多看一眼“這個(gè)包靠譜嗎”配置服務(wù)器的時(shí)候多檢查一遍“響應(yīng)頭設(shè)對(duì)了嗎”。我自己的做法是在項(xiàng)目里建一個(gè)SECURITY.md把上面那些檢查項(xiàng)和配置示例都記進(jìn)去。每次新項(xiàng)目啟動(dòng)直接復(fù)制過來按清單過一遍。新同學(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)義了說明防護(hù)基本到位。如果有一個(gè)彈窗就順著數(shù)據(jù)流往回查找到漏洞點(diǎn)修復(fù)。安全這件事做得好沒人夸出了事就是大事。與其事后救火不如平時(shí)多花點(diǎn)時(shí)間把基礎(chǔ)打牢。上面這些內(nèi)容都是我這些年踩坑踩出來的經(jīng)驗(yàn)希望能幫你少走點(diǎn)彎路。