セッションデータ(localStorage)
メリット
「純粋な JavaScript」という点が最高
- バックエンド側の言語やロジックを一切使わずに、思う存分ブラウザ側にデータを保存できる
- 最大サイズが 4 KB に制限されている cookie に比べてサイズの制約がかなり緩く、主要なブラウザなら 5 MB を超えるデータ・ストレージを楽々利用できる
デメリット
- 「string データしか保存できない」
- 同期的、local storage への操作は同時に 1 つしか実行できない
- パフォーマンス向上のためにバックグラウンド処理や Chrome 拡張などを用いるアプリケーションを構築する場合、local storage はまったく利用できなくなる…web workers では使えないから
- あらゆる JavaScript コードから自由にアクセスできてしまう
- 第三者の JavaScript コードが手違いで存在した場合にセキュリティリスクを大きく下げたければ、「local storage には決して秘密情報を保存しない」ことです。
使うべきシチュエーション
- 「秘密情報を一切含まないこと」
- 「一般に入手可能な情報であること」
- 「そこそこの量である(5 MB を超えない)こと」
- 「string のみの情報であること」
- 「保存するアプリケーションでパフォーマンスを要求されないこと」
重要なデータの保存
→ サーバーサイドセッションを使うべき
重要なデータの例
ユーザー ID
セッション ID
JWT
個人情報
クレジットカード情報
API キー
重要なデータを保存する必要が生じた場合
ユーザーが Web サイトにログインするときは、ユーザーのセッション ID を作成して、暗号化済み署名 cookie に保存します。
Web フレームワークを使っている方は、フレームワークガイドの「cookie でユーザーセッションを作成する方法」あたりの情報に従いましょう。
Web フレームワークで使う cookie ライブラリは、種類を問わずhttpOnly cookie フラグを必ず設定してください。このフラグを設定することで、ブラウザ側で JavaScript を用いて cookie を読み取ることは不可能になります。この設定は、cookie でサーバーサイドセッションを用いる場合の必須手順です。
使う cookie ライブラリでは、[* SameSite=strict cookie フラグ](これはクロスサイトリクエストフォージェリ: CSRF 攻撃を防止します)と、[* secure=true フラグ](cookie を暗号化済みコネクションでのみ設定できるようにします)も必ず設定してください
ユーザーがサイトにリクエストを送信するたびに、[* 必ずセッション ID](セッション ID はユーザーから送信された cookie から取り出します)を使ってアカウントの詳細情報をデータベースまたはキャッシュから取り出してください(どちらを使うかはサイトの規模によります)。
ユーザーのアカウント情報を取り出して検証を終えたら、後はそこから関連する秘密情報を自由に取り出して利用します。
参考サイト
・HTML5 の Local Storage を使ってはいけない(翻訳) https://techracho.bpsinc.jp/hachi8833/2019_10_09/80851
・yahoo tech ブログ JWT https://techblog.yahoo.co.jp/advent-calendar-2017/jwt/
・JWT・Cookie それぞれの認証方式のメリデメ比較 https://qiita.com/doyaaaaaken/items/02357c2ebca994160804
・外部認証 API (JWT) Nuxt.js https://ja.nuxtjs.org/examples/auth-external-jwt/