補充一下，雖然說 session 的內容無法透過 javascript 直接存取，只能透過後端處理。
但是要注意 跨站請求偽造（英語：Cross-site request forgery；簡稱：CSRF） 的問題。
如果是用框架在作網站的話，很多框架已經有提供 CSRF 的防護。
如果是自己寫的，那就要注意一下了。

除了 CSRF 之外，有種狀況是自己的網站有 XSS 漏洞，這讓攻擊者有可能插入 javascript 在其他使用者的頁面。
這時候如果 session id 沒有設定 HttpOnly 等相關屬性，就可能透過 javascript 把使用者的 session id 傳給攻擊者。
假如後端沒再比對來自前端請求的一些資訊（來源 IP 等），那麼攻擊者也可以偽裝成使用者登入了。參考

我只給一個簡單的重點。

前端不可能給session。
session一定都是後端設定的。

除非你開放通路給前端到後端跑session。

所以你要注意的只是注入的問題。而不是去注意session。

關於 session,
前端部份只會知道 session id,
這個 session id 沒什麼資訊內容…

但是這個 session id,
被後端拿到後，
可以透過 session 的機制(存在檔案或資料庫)，
讀到之前存的機密資料...
並將其導入後端的某陣列
例如 PHP 的話應該是 $_SESSION
而這些是不會被竄改或植入的，
因此應該是不必擔心這些...

session內容不是由前端js可以更動的，覺得你想太多了
反倒是注入的問題..............
如果你有由前端送回(GET/POST)到後端的字串組成SQL的習慣，這才是最可怕的事

比如前端POST使用者名稱USERID、密碼PW，回後端組成SQL，就會是

$SQL = "SELECT COUNT(*) AS CNT FROM USERDATA WHERE USERID = '{$_POST["USERID"]}' AND PASSWORD = '{$_POST["PW"]}'

如果你沒有把USERID跟PW做逸脫字元置的話，入侵者只要幹一件事
把要送回後端的 USERID / PW 做點手腳，你們就gg了

USERID = "admin" ;
PW = "12345' OR '1'='1" ;

或是用註解錨點
USERID = "' or 1=1 /*" ;

他就能取得最大權限了(以上假設你們的管理員的帳號是admin)
這就是SQL Injection....
處理的方法很簡單，更新PHP、MYSQL、MSSQL，或是手動過濾掉POST回來的帳號密碼裡的逸脫字元 ' /* 及空白.....

或是更改驗証帳密的方法