【ITニュース解説】Stop Using `localStorage` for Everything – Here's What to Use Instead

Webアプリケーションの開発において、ブラウザにデータを保存する機能は非常に便利だ。その中でも、手軽に利用できるlocalStorageは多くの開発者に使われている。しかし、何でもかんでもlocalStorageに保存するのは避けるべきだ。なぜなら、localStorageには重大な欠点があり、適切な状況で使わないとセキュリティやパフォーマンスの問題を引き起こす可能性があるからだ。システムエンジニアを目指すなら、これらの問題を理解し、状況に応じて最適な保存方法を選ぶ知識が不可欠となる。

localStorageが抱える最大の問題はセキュリティだ。ここに保存されたデータは暗号化されず、すべて平文（誰でも読める形式）で保存される。これは、もし悪意のあるスクリプト（プログラム）がウェブサイトに侵入する「クロスサイトスクリプティング（XSS）攻撃」が発生した場合、localStorage内のデータが簡単に盗み見られてしまうことを意味する。例えば、ユーザーの認証情報や個人情報が平文で保存されていたら、それが盗まれて悪用される危険性があるのだ。また、localStorageへのデータの読み書きは同期的に行われるため、データ量が増えたり頻繁にアクセスしたりすると、ウェブアプリケーションの動作が一時的に停止し、ユーザー体験を損ねる原因となる。さらに、保存したデータに有効期限を設定できないため、一度保存されると手動で削除しない限り永久に残ってしまう。複雑なデータ構造を扱うのにも不向きで、基本的には単純な「キーと値」のペアしか扱えない。

このようなlocalStorageの欠点を補い、より安全で効率的なデータ保存を可能にする代替手段がいくつか存在する。それぞれの用途に応じて使い分けることが重要となる。

まず、「sessionStorage」は、現在のブラウザタブが開いている間だけデータを保存するのに適している。localStorageと使い方は似ているが、タブを閉じるとデータは自動的に消去される点が異なる。一時的なフォーム入力の内容や、そのタブ固有のユーザーインターフェースの状態など、セッションが終了すれば不要になるデータを保存するのに最適だ。他のタブには影響を与えないため、タブ間のデータ干渉を心配する必要もない。

次に、大規模で複雑なデータを保存したい場合には、「IndexedDB」が強力な選択肢となる。これはブラウザに組み込まれた非同期型のNoSQLデータベースで、リレーショナルデータベースのような構造化されたデータを、はるかに大きな容量で保存できる。データの読み書きは非同期で行われるため、ウェブアプリケーションのメインスレッド（主要な処理の流れ）をブロックすることなく、スムーズな動作を保つことができる。IndexedDBのAPIは少し複雑だが、Dexie.jsのようなラッパーライブラリを使うことで、より簡単に操作できるようになる。ユーザープロファイル、アプリケーションの複雑な状態、オフラインで利用する大量のデータなど、さまざまな用途でその真価を発揮するだろう。

特に重要な認証トークンなど、セキュリティが求められるデータには「HttpOnly Cookies」を利用すべきだ。localStorageに認証トークンを保存すると、XSS攻撃によってJavaScriptから簡単に盗まれてしまうリスクがある。しかし、HttpOnly Cookiesは、その名の通り「HttpOnly」属性が設定されているため、JavaScriptから直接アクセスできないようになっている。これにより、悪意のあるスクリプトがトークンを読み取ることを防ぎ、セキュリティを大幅に向上させる。クッキーはサーバーからのHTTPレスポンスによって設定され、ウェブサイトへのリクエスト時に自動的にサーバーへ送信されるため、認証フローを簡素化するメリットもある。ただし、保存できるデータ容量は4KBと小さく、サーバー側の設定が必要となる。

オフライン環境でのウェブアプリケーションの利用や、読み込み速度の向上を目指す場合は、「Cache API」が有効だ。これは「Service Worker（サービスワーカー）」というブラウザのバックグラウンドで動作する特殊なスクリプトと連携して使用される。Cache APIを使うことで、画像、スクリプト、スタイルシートなどの静的ファイルや、APIから取得したデータなどをブラウザに一時的に保存（キャッシュ）できる。これにより、次回同じリソースが必要になった際にネットワークからのダウンロードを待つことなく、高速に表示できるようになる。プログレッシブウェブアプリ（PWA）の実現において中心的な役割を果たす技術であり、オフラインでのアクセスや起動速度の改善に貢献する。

さらに、ブラウザ内で本格的なリレーショナルデータベースの機能を使いたい場合は、「SQLite with WebAssembly」（例えばsql.jsライブラリ）という選択肢がある。WebAssemblyは、ウェブブラウザで高性能なコードを実行するための技術であり、これを利用することで、SQLiteのような既存の強力なデータベースシステムをブラウザ内で動作させることが可能になる。これにより、SQLクエリを使った複雑なデータの検索、結合、更新など、本格的なデータベース操作をウェブアプリケーション内で行えるようになる。ダッシュボードやCRM（顧客関係管理）システムのように、大量の構造化データをブラウザ内で管理・分析する必要があるアプリケーションに適している。セットアップにはWebAssemblyに関する知識が必要となるが、その分、高度なデータ管理機能を提供する。

ここまでlocalStorageの代替手段を説明してきたが、localStorageが全く使えないわけではない。セキュリティ上の懸念が低く、かつ一時的ではないが永続的に保存したいような、シンプルなデータを扱う場合にはlocalStorageも有効な選択肢となる。例えば、ユーザーが選択したウェブサイトのテーマ（ダークモードかライトモードか）、実験的な機能のON/OFFを切り替える設定（フィーチャートグル）、その他、公開されても問題ない非機密なアプリケーション設定など、個人情報や認証情報とは無関係なUIの好みなどを保存するには手軽で十分な機能を提供する。

各保存方法の特徴をまとめると、localStorageとsessionStorageはどちらも数MB程度の容量を持ち、同期的に動作するが、sessionStorageはタブを閉じるとデータが消える。IndexedDBは100MB以上の大容量を非同期で扱え、構造化データやセキュリティにも優れる。HttpOnly Cookiesは4KB未満の容量で、JavaScriptからはアクセスできないセキュリティが特徴で、永続性も設定できる。Cache APIはService Workerと連携して無制限に近い容量を非同期で扱え、主にリソースのキャッシュに利用される。セキュリティ面ではlocalStorageとsessionStorageが劣り、IndexedDB、HttpOnly Cookies、Cache APIはより安全と言える。構造化データの扱いはIndexedDBやSQLiteが優れ、localStorage、sessionStorage、HttpOnly Cookiesは単純なキーバリュー形式だ。

最終的に、ウェブアプリケーションでデータを保存する際には、localStorageに安易に頼るのではなく、目的やデータの性質に応じて適切なツールを選ぶことが極めて重要となる。セキュリティが最優先ならHttpOnly Cookies、複雑な構造の大量データならIndexedDBやSQLite、オフライン対応やパフォーマンス向上ならCache APIを活用すべきだ。これらの選択肢を理解し、使い分けることで、より安全で高速、そして効率的なウェブアプリケーションを構築できるようになる。システムエンジニアとして、適切な技術選定はプロジェクトの成功に直結する重要なスキルの一つだ。