速報

imgproxyのICO処理にコード実行のおそれ|4.0.16だけでは残る問題を確認

CATEGORY

【JavaScript】データ永続化の選択肢!localStorage vs Cookieとセキュリティ戦略

※本ページのリンクにはプロモーションが含まれています。

【JavaScript】データ永続化の選択肢!localStorage vs Cookieとセキュリティ戦略

目次

Webアプリケーションにおいて、ユーザーの設定やトークンといったデータをブラウザ側に保持し、次回アクセス時にも利用できるようにするデータの永続化は不可欠です。この目的のために利用される主要なブラウザストレージ技術が、Web Storage(localStorage、sessionStorage)とです。

しかし、これらの技術は保存容量、有効期限、そして最も重要なセキュリティの側面に大きな違いがあります。誤った選択や不適切な使用は、アプリケーションのパフォーマンス低下や深刻なセキュリティリスク(例: 攻撃による情報漏洩)を招く可能性があります。

本記事では、localStorageとCookieの基本的な違いから、両者のメリット・デメリットを比較し、セキュリティリスクを最小限に抑えるための利用戦略と具体的な実装テクニックを徹底解説します。

ユーザーの認証トークンをどこに保存するのが一番安全で、CookieとlocalStorageのどちらを使うべき?

上記の疑問にお答えします。

スポンサーリンク

1. 基礎知識:Web StorageとCookieの根本的な違い

localStorageとCookieはブラウザにデータを保存しますが、その目的、容量、そしてアクセス方法が大きく異なります。

1.1. Web Storage (localStorage / sessionStorage)

Web Storageは、より大容量のデータをで安全に保持するためにECMAScript標準とは別に策定されたです。

特徴localStoragesessionStorage
有効期限永続的。ユーザーが明示的に削除するか、をクリアするまで残る。限り。タブまたはブラウザウィンドウを閉じると自動で削除される。
容量5MB〜10MB程度(ブラウザ依存)。5MB〜10MB程度。
サーバー送信なし。サーバーに自動送信されない。なし。サーバーに自動送信されない。
アクセスJavaScript (window.localStorage / window.sessionStorage) のみ。JavaScript のみ。

1.2. Cookie

Cookieは、本来サーバーとの状態管理のために設計された古い技術です。ヘッダーを通じてサーバーとデータをやり取りします。

特徴Cookie
有効期限設定可能(セッション限り、または最大期限まで)。
容量4KB以下と非常に小さい。
サーバー送信あり。すべてのHTTPリクエストで自動的にサーバーへ送信される。
アクセスJavaScript (document.cookie) または HTTPヘッダー。

比較:永続化のユースケース

ストレージ最適なユースケース
localStorageユーザーのテーマ設定、UIの表示状態、長期間保持する非機密データ。
sessionStorageフォームの入力内容の一時保存、ワンタイムセッションの非機密データ。
Cookie認証トークン(特にHttpOnly属性を利用する場合)、サーバーでのセッション管理。

2. Web Storageの利用戦略とデータ構造化

localStorageは文字列としてのみデータを保存するため、オブジェクトや配列を扱うには前処理が必要です。

2.1. データ保存の基本とJSONによる構造化

localStorageはキーと値のペアを保存しますが、値は必ず文字列です。オブジェクトや配列を保存する場合は、JSON.stringify()で文字列に変換する必要があります。

JavaScript

const userSettings = { theme: 'dark', notifications: true };
const key = 'app_settings';

// 1. 保存: オブジェクトをJSON文字列に変換
localStorage.setItem(key, JSON.stringify(userSettings));

// 2. 取得: JSON文字列を元のオブジェクトに戻す
const storedValue = localStorage.getItem(key);
const settings = JSON.parse(storedValue);

console.log(settings.theme); // -> 'dark'

2.2. 容量制限とエラーハンドリング

Web Storageの容量(約5~10MB)を超えてデータを書き込もうとすると、ブラウザはQuotaExceededErrorを投げます。データを保存する際には、必ずエラーハンドリングを組み込むべきです。

JavaScript

function safeSetItem(key, value) {
  try {
    localStorage.setItem(key, value);
    return true;
  } catch (e) {
    if (e.name === 'QuotaExceededError') {
      console.warn("localStorageの容量を超過しました。");
      // 古いデータを削除するなどのリカバリ処理を実装
      return false;
    }
    console.error("localStorageへの書き込みエラー:", e);
    return false;
  }
}

スポンサーリンク

3. Web StorageとCookieのセキュリティ考慮事項

ストレージ技術の選択において、最も重要な判断基準はセキュリティです。機密性の高い(例: )をどこに保存するかは、XSS攻撃への耐性に直結します。

3.1. 致命的なリスク:XSS攻撃とlocalStorage

localStorageに認証トークン(例: )などの機密情報を保存することは、一般的に非推奨とされています。

  • XSS (Cross-Site Scripting) 攻撃:
    攻撃者がWebサイトに悪意のあるJavaScriptコードを注入(インジェクション)した場合、そのコードはwindow.localStorageに容易にアクセスし、保存されている認証トークンを外部サーバーへ盗み出すことができます。
  • の欠如:
    localStorageは、同じ(、、ポート)であれば、すべてのJavaScriptから無制限にアクセス可能です。

3.2. Cookieによる安全性の向上:HttpOnly属性

認証トークンを安全に保持するための最も効果的な方法は、CookieとHttpOnly属性の組み合わせです。

属性役割セキュリティへの影響
HttpOnlyJavaScriptからのdocument.cookieによるアクセスを完全に禁止する。XSS攻撃が発生しても、攻撃者のJavaScriptはトークンを読み出せないため、情報漏洩リスクが大幅に減少する。
Secure接続(された通信)でのみCookieを送信するように強制する。(MITM)による盗聴リスクを防ぐ。
SameSite他サイトからのリクエスト時にCookieが送信されるか制御する。(Cross-Site Request Forgery)攻撃を防ぐのに役立つ。

結論:機密情報(特に認証トークン)は、サーバー側でHttpOnly属性を付けてCookieに保存するのが最も安全です。

最後に

フロントエンドでデータを永続化する際は、データの機密性と利用目的によってストレージを厳密に使い分ける必要があります。

データ特性推奨ストレージ理由と注意点
機密性が高い(認証トークン)Cookie(HttpOnly + Secure)JavaScriptから隔離し、XSSによる盗難リスクを防ぐ。
非機密、長期間保持localStorage大容量で永続的。設定や非同期データのキャッシュに最適。
非機密、一時的sessionStorageセッション終了時に自動消去されるため、一時的な状態管理に利用。

これらのセキュリティ原則と利用戦略を理解し、堅牢なWebアプリケーションを構築しましょう。

以上、JavaScriptにおけるWeb StorageとCookieによるデータ永続化とセキュリティ戦略のご紹介でした!

この記事を書いた人

Ryohei

Webエンジニア / アプリ開発者 / 技術ブログ運営者

福岡のWeb制作会社に勤務するWebエンジニアです。10年以上にわたりWeb制作・開発に携わり、ヒアリングや進行管理から、コーディング、CMSの構築、システム開発、サーバーの構築・保守・運用まで、Webサイト制作の工程を幅広く担当しています。Webサイトは、これまでに100以上の構築・保守を手がけてきました。

個人でもWebサイトの制作・改修やWebアプリの開発・運用を行い、AIを活用した開発にも取り組んでいます。近年はWebセキュリティにも注力しています。

2015年から技術メディア「Into the Program」を運営し、実務や開発で得た知識をもとに、プログラミングの実装方法やWebサイトの運用・セキュリティ情報を発信しています。

主な分野
Webサイト構築・保守・運用 / HTML/CSS / JavaScript / PHP / WordPress / サーバー構築・保守・運用 / アプリ開発 / セキュリティ対策
資格・試験合格
情報セキュリティマネジメント試験
基本情報技術者試験
AWS認定ソリューションアーキテクト アソシエイト
PHP8技術者認定ウィザード
メディア運営
2015年〜

記事の作成・更新について

セキュリティ記事は、ベンダーの公式アドバイザリやCVE・JVNなどの一次情報を参照し、出典と情報確認日を記載します。実環境での検証を行った場合は、その環境と確認範囲を明示します。重要な追加情報や誤りを把握した場合は、内容を確認して追記・訂正します。

関連する記事

おすすめの書籍

キーワードから探す

スポンサーリンク

CSRF

ログイン中の利用者に、本人が意図しないリクエストを送らせる攻撃。設定の変更や投稿などを本人になりすまして実行される。

詳しく見る

中間者攻撃

通信する二者の間に攻撃者が割り込み、通信の内容を盗み見たり書き換えたりする攻撃。

詳しく見る

暗号化

データを、鍵を持つ人以外には読めない形に変換すること。通信や保存したデータを盗み見から守る。

詳しく見る

HTTPS

HTTPの通信をTLSで暗号化したもの。Webサイトとの通信を盗み見や改ざんから守る。

詳しく見る

プロトコル

コンピューター同士が通信するときの決まりごと。データの形式や送る順番などを定めたもの。HTTP・TLS・DNSなど。

詳しく見る

ドメイン

インターネット上の住所にあたる名前。「example.com」のように、WebサイトやメールアドレスのURLに使う。

詳しく見る

オリジン

Webで、スキーム(httpsなど)・ホスト名・ポート番号の組み合わせ。ブラウザーはオリジンが同じかどうかで、ページ間のアクセスを制限する。

詳しく見る

アクセス制御

誰が、どの情報や機能に、どこまでアクセスできるかを決めて制限する仕組み。

詳しく見る

JWT

利用者の情報や権限を、署名付きのJSONで表したトークン。APIの認証やログイン状態の受け渡しに使う。

詳しく見る

アクセストークン

サービスやAPIを利用する権限を表す文字列。ログインや認可のあとに発行され、リクエストに付けて送る。

詳しく見る

認証情報

本人であることを証明するための情報。IDとパスワード、APIキー、アクセストークン、秘密鍵など。

詳しく見る

HTTP

ブラウザとWebサーバーがやりとりするための決まりごと(プロトコル)。暗号化したものはHTTPSと呼ぶ。

詳しく見る

セッション

利用者とシステムの一連のやり取りを、ひとまとまりとして扱う単位。Webでは、ログイン状態などをページをまたいで保つために使う。

詳しく見る

キャッシュ

一度取得したデータを一時的に保存しておき、次に使うときに再利用して処理を速くする仕組み。

詳しく見る

API

ソフトウェアやサービスの機能を、ほかのプログラムから決まった方法で呼び出して使えるようにした窓口。

詳しく見る

フロントエンド

Webサイトやアプリのうち、利用者が直接目にして操作する画面の部分。HTML・CSS・JavaScriptなどで作る。

詳しく見る

XSS

Webページに攻撃者のスクリプトを埋め込み、閲覧者のブラウザで実行させる攻撃。Cookieの窃取や画面の改ざんにつながる。

詳しく見る

Cookie

Webサイトがブラウザに保存させる小さなデータ。ログイン状態の維持や設定の記憶、アクセス解析などに使われる。

詳しく見る

認証

アクセスしてきた相手が本人であることを確かめる仕組み。パスワードや生体情報、電子証明書などを使う。

詳しく見る