篡改的兩種方式：
1.第三方篡改
意思是說在資料由使用者發到伺服器的途中，資料被第三方篡改，造成傳送的資料和接收的資料不一致，防止此類情況的發生的常用做法如下：
1）將要提交的引數先做加密
2）然後把加密的資訊做一次md5摘要，也就是簽名
3）然後把摘要連同引數一起回傳給伺服器
4）伺服器拿到引數後，同樣的方式加密做md5摘要
5）兩個摘要做對比，如果不相等引數便是被篡改了，否則可信。
2.使用者自行修改
其實這種方式不能算作被篡改，因為是使用者自己修改的，並且是在傳送資料前修改 的，這樣傳送和接收雙的都是相同的資料，但是可能是不是期望的資料。
例如，乙個充值頁面，使用者點選了充值10元的按鈕，在提交前，f12把10改為10000，那麼實際上傳送的資料是10000，後台接收到的資料也是10000，那麼這個值是沒有被篡改的，但是不是期望的（對於服務端）。
對於這種修改方式，無法通過加密等手段進行驗證，只能通過業務邏輯進行驗證。比如要刪除一篇文章，只能在業務層保證使用者是刪除的自己的，而不會通過修改id等方式刪除了別人的。對於上邊充值的例子也可以在業務邏輯上驗證是給當前使用者自己充值並是由當前使用者支付的，這樣付款的還是自己，就沒有什麼問題了。
對於f12進行資料修改也有響應的解決辦法，可以監聽瀏覽器一些事件來阻止使用者修改。例如禁止右鍵檢視原始碼，禁用f12鍵，在可能被修改的元素資料被修改後重新載入頁面等等。
web 頁面阻止使用者f12篡改頁面元素和資料
web安全學習 web安全防禦
影響web安全的主要因素就是使用者輸入的不可控，這篇文章就從乙個巨集觀的角度來分析一下如何去保證乙個應用程式的安全。為了保證web安全，首先就是要分析應用程式中那些方面容易遭受到攻擊，然後根據分析結果在制定具體的安全方案。web應用程式的基本安全問題 所有使用者的輸入都是不可信的 致使應用程式實施大...
web層安全防範
1.銘記乙個基本原則 永遠也不要相信使用者的輸入！2.輸入檢測。是否驗證了它的 是否檢查了字段的長度？為空或者超長是否會產生問題？是否限制了字段的可用字符集？數值型 英文本母 可見字元 中文字元，etc是否含有對程式有特殊含義的字元？是否限制了字段的取值範圍 特別是數值型資料 是否限制了字段的格式？...
Web安全防範 防止重放攻擊
我們在開發介面的時候通常會考慮介面的安全性，比如說我們通常會要求請求的url攜帶乙個經過演算法加密的簽名sign到服務端進行驗證，如果驗證通過，證明請求是合法的。比如以下的url 醬紫，可能語言難以理解，我畫個圖先 首先正常的請求系統會要求校驗，當你的合法請求被黑客攔截之後，黑客就會重複地傳送該合法...