作WEB開發的時候，很少對深層次的安全性進行考慮，國內現在的氛圍也不是太好，讀書的時候總是會逛烏雲，後面工作一直也沒怎麼考慮，都是依靠框架去解決問題。但是由於安全部門對我們的網站檢測比較多，雖然都是指令碼檢測的，但是依舊鬧出了很多事情，需要處理
處理的辦法，指令碼掃描一般都是掃描框架漏洞，或者字串，還有xml包處理的一些問題。處理起來並不複雜，通常是升級，加過濾，加判斷。這些指令碼都能通過。
但是假如我自己現在突然成為程式的壞人，我是否能攻破我們的系統了？我思考了一下，我覺得完全沒問題，給我一個基礎賬號，基本上可以更改任何資料了，因為我們的介面判斷並沒有做許可權控制，只要是一個有敵意的公司，如果真想給我們麻煩，我們肯定是沒辦法的。這也是現在常見的WEB開發人員的一個素質的缺失。或者說產品已經迭代了很久了，很難去動程式碼去改。
有一種方法叫做IP限制，這種方法簡直是無腦至極，但是又非常有效，能幹掉大部分的惡意指令碼，對後臺的攻擊。但是這樣子侷限性非常大，這是國企的ERP常見的使用方式，不考慮使用人的友好性。
我們現在會從三個角度出發
前端的介面無法改變，以前也沒有做check，我們用Node或者其他封裝一箇中間層出來，作為介面的轉發，在這層check和防止攻擊
後端的加日誌，IP，做異常監控，為什麼不IP限制？不能做，做了異常有什麼好處了？其實很少人會去攻擊，然後做了日誌，後面就可以去查，恢復。一種亡羊補牢的手段
重構程式碼，先把本來不用暴漏的介面暴漏出去的先給改回來，比如說A->B是非暴漏，但是B->C是暴漏的，導致A是暴漏的。B這裡就是一個豬隊友。之前加日誌了，因為做的是AOP，那麼我這裡同樣也可以改改，加功能成功為安全攔截，但是這裡我還沒有完全改好的原因是，工作量太大，並且最主要是怕出問題，一出問題，就爆炸了，所以改的小心翼翼