すべてのCookieが同じ機能を持っているように見えるため、すべてのCookieをローカルストレージに移動することで、Webサイトの読み込み時間を短縮したいと考えています。明らかな互換性の問題を除いて、Cookieの機能を置き換えるためにローカルストレージを使用する場合、長所/短所（特にパフォーマンスに関して）はありますか？

Cookieとローカルストレージの目的は異なります。Cookieは主にサーバー側を読み取るためのもので、ローカルストレージはクライアント側のみが読み取ることができます。つまり、アプリでこのデータを必要とするのは、クライアントかサーバーか、ということです。

それがあなたのクライアント（あなたのJavaScript）であるなら、それなら必ず切り替えてください。各HTTPヘッダーですべてのデータを送信することにより、帯域幅を浪費しています。

それがあなたのサーバーであるなら、どうにかしてデータを転送する必要があるため、ローカルストレージはそれほど有用ではありません（Ajaxまたは非表示のフォームフィールドなどで）。これは、サーバーが各要求の合計データの小さなサブセットのみを必要とする場合は問題ありません。

ただし、どちらの方法でも、セッションCookieをCookieとして残しておきます。

技術的な違いと私の理解によると：

1. データを保存する古い方法であることに加えて、Cookieは4096バイト（実際には4095バイト）の制限を与えます— Cookieごとです。ローカルストレージとして大きな通りであるドメインごとに5メガバイト - SO質問もそれに言及しています。

2. localStorageStorageインターフェースの実装です。これは、とのデータを格納する有効期限なし、とクリアされます唯一のJavaScriptを通じて、またはブラウザのキャッシュ/ローカルに保存されたデータをクリア-クッキーの有効期限とは異なり。

JWTとの関連で、Stormpathは、それらを格納するための可能な方法と、各メソッドに関連する（欠点）の利点を概説したかなり役立つ記事を書いています。

また、XSS攻撃とCSRF攻撃の簡単な概要と、それらに対抗する方法についても説明します。

記事がオフラインになった場合やサイトがダウンした場合に備えて、以下の記事の短い抜粋を添付しました。

ローカルストレージ

問題：

Webストレージ（localStorage / sessionStorage）は、同じドメインのJavaScriptを介してアクセスできます。つまり、サイトで実行されているすべてのJavaScriptがWebストレージにアクセスできるため、クロスサイトスクリプティング（XSS）攻撃に対して脆弱になる可能性があります。簡単に言えば、XSSは一種の脆弱性であり、攻撃者がページで実行するJavaScriptを挿入する可能性があります。基本的なXSS攻撃は、フォーム入力を介してJavaScriptを挿入しようとします。この場合、攻撃者は警告を発します（ 'You are Hacked'）; それがブラウザによって実行され、他のユーザーが表示できるかどうかを確認するフォームに。

防止：

XSSを防ぐための一般的な応答は、すべての信頼できないデータをエスケープしてエンコードすることです。しかし、これは完全な話にはほど遠い。2015年、最新のウェブアプリは、CDNまたは外部インフラストラクチャでホストされているJavaScriptを使用しています。最新のウェブアプリには、A / Bテスト、目標到達プロセス/市場分析、広告用のサードパーティJavaScriptライブラリが含まれています。Bowerのようなパッケージマネージャーを使用して、他の人のコードをアプリにインポートします。

使用しているスクリプトの1つだけが侵害された場合はどうなりますか？悪意のあるJavaScriptがページに埋め込まれる可能性があり、Webストレージが危険にさらされます。これらのタイプのXSS攻撃は、知らないうちにサイトにアクセスする全員のWebストレージを取得する可能性があります。これがおそらく、多くの組織が、価値のあるものを保存したり、Webストレージに情報を信頼したりしないことを勧める理由です。これには、セッション識別子とトークンが含まれます。

ストレージメカニズムとして、Webストレージは転送中に安全な標準を適用しません。Web Storageを読んでそれを使用する人は、JWTを常にHTTPS経由で送信し、HTTP経由では送信しないように十分注意する必要があります。

クッキー

問題：

CookieをHttpOnly Cookieフラグと共に使用すると、JavaScriptを介してアクセスできなくなり、XSSの影響を受けなくなります。Secure cookieフラグを設定して、CookieがHTTPS経由でのみ送信されることを保証することもできます。これが、過去にCookieを利用してトークンやセッションデータを保存した主な理由の1つです。最近の開発者は、伝統的に状態をサーバーに保存する必要があり、RESTfulなベストプラクティスに違反しているため、Cookieの使用をためらっています。ストレージメカニズムとしてのCookieでは、JWTをCookieに保存する場合、サーバーに状態を保存する必要はありません。これは、JWTがサーバーが要求を処理するために必要なすべてをカプセル化するためです。

ただし、Cookieは、クロスサイトリクエストフォージェリ（CSRF）という別の種類の攻撃に対して脆弱です。CSRF攻撃は、悪意のあるWebサイト、電子メール、またはブログによって、ユーザーが現在認証されている信頼済みサイトでユーザーのWebブラウザーが不要なアクションを実行するときに発生する攻撃の一種です。これは、ブラウザがCookieを処理する方法の悪用です。Cookieは、許可されているドメインにのみ送信できます。デフォルトでは、これは最初にCookieを設定したドメインです。cookieは、galaxies.comとhahagonnahackyou.comのどちらを使用しているかに関係なく、リクエストに対して送信されます。

防止：

最新のブラウザは、およびに加えて、SameSiteフラグをサポートしています。このフラグの目的は、Cookieがクロスサイトリクエストで送信されないようにし、さまざまな種類のCSRF攻撃を防ぐことです。HttpOnlySecure

をサポートしていないブラウザの場合、SameSite同期されたトークンパターンを使用することでCSRFを防止できます。これは複雑に聞こえますが、すべての最新のWebフレームワークはこれをサポートしています。

たとえば、AngularJSには、Cookieがドメインからのみアクセス可能であることを検証するソリューションがあります。AngularJSドキュメントから直接：

XHRリクエストを実行すると、$ httpサービスはCookie（デフォルトではXSRF-TOKEN）からトークンを読み取り、HTTPヘッダー（X-XSRF-TOKEN）として設定します。ドメインで実行されているJavaScriptのみがCookieを読み取ることができるため、サーバーでXHRがドメインで実行されているJavaScriptからのものであることを確認できます。xsrfTokenJWTクレームを含めることで、このCSRF保護をステートレスにすることができます。

{
  "iss": "http://galaxies.com",
  "exp": 1300819380,
  "scopes": ["explorer", "solar-harvester", "seller"],
  "sub": "tom@andromeda.com",
  "xsrfToken": "d9b9714c-7ac0-42e0-8696-2dae95dbc33e"
}

WebアプリフレームワークのCSRF保護を活用すると、JWTを格納するためのCookieが確実になります。APIからHTTPリファラーとOriginヘッダーをチェックすることで、CSRFを部分的に防ぐこともできます。CSRF攻撃には、アプリケーションに関係のないリファラーとオリジンヘッダーが含まれます。

完全な記事はここにあります：https : //stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage/

また、トークン自体の構造に関して、JWTを最適に設計および実装する方法に関する役立つ記事もあります。https：//stormpath.com/blog/jwt-the-right-way/

を使用するとlocalStorage、ウェブアプリケーションはユーザーのブラウザ内でローカルにデータを保存できます。HTML5以前は、アプリケーションデータはすべてのサーバー要求に含まれるCookieに保存する必要がありました。Webサイトのパフォーマンスに影響を与えることなく、大量のデータをローカルに保存できます。でもlocalStorage、より近代的で、両方の技術にはいくつかの長所と短所があります。

クッキー

長所

• レガシーサポート（それは永遠にあります）
• 永続的なデータ
• 有効期限

短所

• 各ドメインは、すべてのCookieを単一の文字列に格納するため、データの解析が困難になる可能性があります
• データは暗号化されていないため、問題になります... ...サイズは小さいですが、HTTPリクエストごとにCookieが送信されます制限サイズ（4KB）
• SQLインジェクションはCookieから実行できます

ローカルストレージ

長所

• 最近のほとんどのブラウザーによるサポート
• ブラウザに直接保存される永続的なデータ
• 同一生成元ルールがローカルストレージデータに適用されます
• すべてのHTTPリクエストで送信されるわけではありません
• ドメインあたり最大5MBのストレージ（つまり5120KB）

短所

• これまでサポートされていなかったもの：IE 8、Firefox 3.5、Safari 4、Chrome 4、Opera 10.5、iOS 2.0、Android 2.0
• サーバーにクライアント情報を保存する必要がある場合は、意図的に送信する必要があります。

localStorage使用法はセッションのものとほとんど同じです。彼らはかなり正確な方法を持っているので、セッションからへの切り替えlocalStorageは本当に子供の遊びです。ただし、保存されたデータがアプリケーションにとって本当に重要である場合localStorageは、バックアップが利用できない場合のバックアップとして、おそらくCookieを使用します。のブラウザサポートを確認する場合はlocalStorage、次の簡単なスクリプトを実行するだけです。

/* 
* function body that test if storage is available
* returns true if localStorage is available and false if it's not
*/
function lsTest(){
    var test = 'test';
    try {
        localStorage.setItem(test, test);
        localStorage.removeItem(test);
        return true;
    } catch(e) {
        return false;
    }
}

/* 
* execute Test and run our custom script 
*/
if(lsTest()) {
    // window.sessionStorage.setItem(name, 1); // session and storage methods are very similar
    window.localStorage.setItem(name, 1);
    console.log('localStorage where used'); // log
} else {
    document.cookie="name=1; expires=Mon, 28 Mar 2016 12:00:00 UTC";
    console.log('Cookie where used'); // log
}

「セキュア（SSL）ページのlocalStorage値は分離されています」。 誰かが気付いたのは、cookieにアクセスできる「http」から「https」のセキュアなプロトコルに切り替えるとlocalStorageが利用できないことです。これは、安全なプロトコルで作業する場合に注意する必要がある種の重要なものです。

ローカルストレージの速度は、クライアントが使用しているブラウザーとオペレーティングシステムに大きく依存します。MacのChromeまたはSafariは、特に新しいAPIを使用すると、PCのFirefoxよりもはるかに高速になる場合があります。いつものように、テストはあなたの友達です（私はベンチマークを見つけることができませんでした）。

Cookieとローカルストレージに大きな違いはありません。また、互換性の問題についても心配する必要があります。すべてのブラウザが新しいHTML5 APIをサポートし始めたわけではないため、速度と互換性のためにCookieが最善の策となるでしょう。

それはまた言及する価値があります localStorage、モバイルSafariの一部のバージョンでユーザーが「プライベート」モードでブラウジングする場合は使用できないことにがあります。

MDNから引用（https://developer.mozilla.org/en-US/docs/Web/API/Window/localStorage）：

注：iOS 5.1以降、Safari MobileはlocalStorageデータをキャッシュフォルダーに保存します。これは、OSの要請により、通常はスペースが不足している場合に、クリーンアップされることがあります。Safari Mobileのプライベートブラウジングモードでは、localStorageへの書き込みが完全に禁止されます。

ローカルストレージは最大5 MBのオフラインデータを保存できますが、セッションは最大5 MBのデータも保存できます。ただし、Cookieは4kbのデータのみをテキスト形式で保存できます。

JSON形式のLOCAlおよびセッションストレージデータ。したがって、解析が容易です。ただし、Cookieデータは文字列形式です。

クッキー：

1. HTML5より前に導入されました。
2. 有効期限があります。
3. JS、またはブラウザの閲覧データの消去により、または有効期限が過ぎると消去されます。
4. 各リクエストごとにサーバーに送信されます。
5. 容量は4KBです。
6. 文字列のみがCookieに保存できます。
7. Cookieには、永続的とセッションの2つのタイプがあります。

ローカルストレージ：

1. HTML5で導入されました。
2. 有効期限はありません。
3. JSまたはブラウザの閲覧データの消去によりクリアされます。
4. データをサーバーに送信するタイミングを選択できます。
5. 容量は5MBです。
6. データは無期限に保存され、文字列でなければなりません。
7. タイプは1つだけです。