ブラウザのローカル領域にデータを保存できる便利な仕組みの Web Storage ですが、その使い方についてはいくつが注意点があります。
Web Storage (localStorage, sessionStorage) の詳細について知りたい方は、前回の記事をチェックしてみてください。
この記事では、Web Storage を使用する上で注意した方が良い点について紹介します。
プライベート・シークレットモードでも Web Storage API が使えるか
少し前まで、Safari ではブライベートモードにして localStorage にアクセスするとエラーになる問題がありました。この件に関しては 2019 年現在 Fix されていますが、サポートするプラウザの範囲が広い場合、念のためしっかり確認しておいた方が安心かなと思います。
通常モードからプライベートモードに切り替えた場合（またはその逆）の挙動を確認する
通常モードとプライベートモードを切り替えながらアプリを操作することも想定に入れ、主要機能やユーザー認証後の正常動作が localStorage に依存していないかチェックしておく必要があります。
※例えば、URL 直打ちでの表示・画面遷移・エラーハンドリングなど
各種ブラウザの仕様上、プライベートモードになると localStorage も通常モードとは別の領域となりますので、基本的に localStorage に関しては別ブラウザで開くのと同じ状態になると考えた方が良いですね。
ユーザーに紐づくデータの扱いに注意する
ユーザー情報を含め、アプリの主要機能において localStorage にデータをキャッシュするような仕組みは多く使われています。この時、localStorage に保存するデータは有効期限をつけて管理することができないため、ログイン／ログアウトまたはセッション切れなどの状態変更に伴い、適度にクリーンアップするといった対応が必要になります。
センシティブな情報、機密情報を含めない
前回の記事でも触れていますが、Web Storage は JavaScript の API を利用することになっており、XSS(Cross-Site Scripting) のような脆弱性で任意の JavaScript コードが実行されてしまうと Web Storage の内容が抜かれてしまう可能性があります。よって、個人情報を含む情報・セッショントークンなど、漏れてはいけない情報を格納しないようにすることが望ましいとされています。
その点、WebAPI の認証トークンなど機密性の高い情報についてはhttponly属性をつけた Cookie をサーバー側からセットして回避するようなやり方もあったりします。
※httponly属性をつけることで JavaScript から Cookie を操作することができなくなるため
また、JWT(JSON Web Token) のようなステートレスなトークンを保存するケースもあります。上記のようなリスクを十分考慮して、他の手段を検討するか、有効期限をかなり短くするといった工夫が必要になります。
キー名が重複する場合がないか確認する
開発が進むに連れて多数のライブラリを利用することになります。この時、アプリ実装側とライブラリ又はライブラリ同士で同じキーを用いて Web Storage にアクセスすることがまれにあります。
当然ながらキーが同じであれば後から書き込まれた値で上書きされてしまいます。これを 100% 事前に把握することは難しいですが、アプリ側であればキーに prefix をつけたり、ライブラリ導入時は念入りに確認しておくことで、バグが減る結果に繋がることもあるかと思います。
以上、一見便利そうな Web Storage ですが、いくつか考慮すべきポイントがあるので記事にしてみました。皆さんの参考になれば幸いです。最後まで読んでいただきありがとうございました。