一、XSS(Cross Site Scripting)跨站JS腳本攻擊，如何防範？
針對接口進行 XSS攻擊，即把js腳本或者帶惡意js腳本的html標籤，作爲GET或者POST參數提交到服務器，然後服務器解釋並響應，在響應結果裏把腳本或者html標籤原樣返回明顯示和執行。這明顯是很有問題。防範方式：1）提交數據前前端要做數據校驗，對用戶輸入的信息(js代碼及dom節點)進行過濾。2）對重要的cookie設置爲httponly（服務器端可設置此字段），客戶端就沒有操作此cookie的權限。3）服務器端也要數據合法性校驗
針對的DOM節點攻擊,如果本身頁面代碼中使用了window.eval來執行代碼。eval本身會把一段字符串變成可執行的js代碼，這是非常危險的。還有拼接html字符串後直接顯示DOM時也會遇到同樣的問題。防範方式：儘量避免使用eval，拼接html字符串時應校驗字符串的合法性，過濾非法元素節點與屬性節點,如iframe,script標籤，onerror事件, style, src, href等。
可能產生危害：泄露了個人的cookie信息，身份認證被套取後，被用作非法用途
非法字符過濾可以使用第三方的過濾庫如：HTMLParser.js及he.js
參考引用自：https://www.cnblogs.com/unclekeith/p/7750681.html
二、CSRF(Cross-site request forgery)跨站請求(GET和POST)僞造攻擊，如何防範？
由於瀏覽器一般都是可同時打開多標籤的。舉個例了，現瀏覽器同時打開了兩個標籤，一個是已被合法登錄並保持登錄狀態的網站A，另外一個是已被欺騙打開的含惡意代碼的網站B（不一定是來源於非法網站，也可能藏在各大合法論壇上的一些非法鏈接被你打開了），則可以通過在惡意網站B上靜態或者動態創建img,script等標籤發起GET或者POST請求，發出的惡意請求是身份認證後的，這就構成CSRF攻擊了。將其src屬性指向發起對A網站的接口請求（如一個GET請求：api.a.com/blog/del?id=1）。通過標籤的方式發起的請求不受同源策略的限制。
可能產生危害：模擬表單提交盜取用戶資金，篡改目標網站上的用戶數據，盜取用戶隱私數據
防範方式：
1）後端接口要對接口請求來源如（* Referer:）字段進行合法校驗。
2）添加token，帶token請求。
參考引用自：https://www.cnblogs.com/unclekeith/p/7788057.html
三、SQL注入，攻擊如何防範？
老生常談的了，總之：
1.永遠不要信任用戶的輸入。對用戶的輸入進行校驗，可以通過正則表達式，或限制長度；對單引號和
雙”-“進行轉換等。
2.永遠不要使用動態拼裝sql，可以使用參數化的sql或者直接使用存儲過程進行數據查詢存取。
3.永遠不要使用管理員權限的數據庫連接，爲每個應用使用單獨的權限有限的數據庫連接。
4.不要把機密信息直接存放，加密或者hash掉密碼和敏感的信息。
5.應用的異常信息應該給出儘可能少的提示，最好使用自定義的錯誤信息對原始錯誤信息進行包裝
6.sql注入的檢測方法一般採取輔助軟件或網站平臺來檢測，軟件一般採用sql注入檢測工具jsky,網站平臺就有億思網站安全平臺檢測工具。
參考引用自：https://www.cnblogs.com/sdya/p/4568548.html
四、接口訪刷問題，前端如何與後端配合？
在IT行業混得有一點資歷的人估計都會遇到過接口被刷的情況了。如：聽說搞某某活動，大獎瞬間被刷走。某某營銷活動，獎品瞬間被搶光了。某某平臺，短信驗證碼幾天被刷到欠費。
認真去查查記錄，發現這些行爲都是人家用機器寫程序自動刷你接口的。現在還有卡商有各種短信接碼平臺，專業批量接發驗證碼的。
如何能更好的做接口防刷：
1.發送請求之前前端這邊要做人機識別。（如微信的靜默授權返回一次唯一碼，小程序的wx.login接口返回的code，可供後端二次驗證，還有發送短信驗證碼前要手動先輸入驗證碼，或者使用拖動方塊填充缺塊那種人機識明系統）
2.接口傳參要帶加密簽名。
五、前端常用的js加密方式有哪些？
sha1，base64，md5，aes, SHA256，SHA512，RMD160等
常用開源庫有：
https://github.com/blueimp/JavaScript-MD5
https://github.com/h2non/jshashes
https://github.com/dankogai/js-base64
https://github.com/auth0/jwt-decode