為了保證安全：請不停地重設(shè)session的重設(shè)；將過期時間設(shè)置短一些；監(jiān)控referrer與userAgent的值；使用HttpOnly禁止腳本讀取Cookie。這些措施并非萬無一失，但是增加了黑客的難度，因此也是有效的。
https://blog.fundebug.com/201...

傳的時候先加密唄，使用 md5 或者 sha1 加密算法的話，不知道 key 的情況下話根本不可能（或者說成本過高）反推 token。

如果你說，那我直接拿到這個 token 再偽造不就行了么，確實是沒錯，所以在此基礎(chǔ)上還要加上 session，一般就是 cookie 中存?zhèn)€ session_id，然后服務(wù)端通過一個 secret 去驗證 session_data，session_id + cookie 基本就安全了。

另外還可以給 cookie 生成簽名，生成簽名的 secret 同樣保存在服務(wù)端，然后每次請求驗證一下當(dāng)前生成的簽名和之前的簽名是否一樣。比如 username 為 foo，根據(jù)某個加密算法和 secret 加密后的簽名為 aaa，客戶端保存為 username=foo_aaa，然后有個人篡改 username 為 bar_aaa，傳到服務(wù)器之后發(fā)現(xiàn) bar 生成的簽名和 aaa 不一致，則證明 cookie 已被篡改。

其他的話，還有 httponly、secure 等配置，這些是防止第三方篡改 cookie 的設(shè)置，同時嘗試使用 https，這個是防止請求傳輸過程中中間者進行監(jiān)聽。

個人拙見，如有錯誤，還望指正。

如果你的網(wǎng)絡(luò)環(huán)境都能被抓包了，說明你的網(wǎng)絡(luò)已經(jīng)非常不安全了。那么 就是體現(xiàn)https優(yōu)勢的時候了。

最重要的是要防被抓包，其他的都只能加大被偽造的難度，并不能完全避免被“偽造”。

畢竟，無論是 cookie 或 session，或 token ，客戶端都要有一個登錄憑證，后端只能認(rèn)這個憑證，如果憑證都被別人拿起來，那后端也沒有什么辦法。

當(dāng)然，你可以通過多個認(rèn)證方式結(jié)合，加大偽造的難度。
比如：
cookie 中的字段意義不要太容易被看懂，多放幾個混淆一下，有些是請求的參數(shù)，有些是認(rèn)證身份的；
不只判斷 cookie，還要判斷客戶端是不是同一個，ip是不是同一個；
不只 cookie，localStorge 和 sessionStorage 也放一些認(rèn)證的字段。
....

另外，說一下幾種無效的方法：

1. 不斷刷新 cookie 或 session:

這是沒有用的，你刷新的時候還不是用舊的換新的，偽造的人手里有舊的，當(dāng)然就可以獲得新的。
當(dāng)然，可能加大偽造難度。

1. 前端傳輸?shù)臅r候用 md5 加密：

后端要認(rèn)證身份，必然需要能解密的算法，如果是用 md5 這種單身加密，后端根本沒有辦法認(rèn)證用戶身份。前端使用的加密后的字符串必須是由后端來加密的。
如果采用可解密的算法，但因為前端代碼別人是可以看到的，加密的方法自然也可以看到，使用已有的加密算法完全沒有意義，要使用一個只有自己才能解密的加密算法是比較難的。

總之，還是那句話：最重要的是要防被抓包。

說實話，不可能，除非你的cookie是一次性的，否則在你的cookie我抓了就能用。你只能通過各種策略去猜測他的行為是不是存在風(fēng)險，而沒法避免。