こんにちは、Habr！ Randall Deggesの記事「 ローカルストレージの使用をやめてください 」の翻訳を紹介します。

ますます多くの開発者がlocalStorageを使用して、自分のサイトをハッキングしていることを疑うことなく、機密データを含むデータを保存しています。 それが、私がそのような慣習を放棄することを強く勧める理由であり、この記事では、理にかなって私の視点を実証しようとします。

はじめに

したがって、localStorageはHTML5の新しい機能であり、JavaScriptのおかげでユーザーのブラウザーに情報を保存できます。 これは、キーと値のペアを追加および削除できる古き良きJSオブジェクトです。 小さなコードの例を見てみましょう。

//     localStorage.userName = ""; localStorage.setItem("favoriteColor", ""); //    localStorage,    //   ,      alert(`${localStorage.userName}  ${localStorage.favoriteColor} .`); //       localStorage.removeItem("userName"); localStorage.removeItem("favoriteColor"); 

テストHTMLページでこのコードを実行すると、警告ウィンドウに「Petyaは黒い色を好む」というフレーズが表示されます。 開発者のツールを使用して、データを削除する行を以前にコメントアウトした場合、両方の値がブラウザーのローカルストレージに保存されていることを確認できます。

今、あなたは次の質問に興味があるかもしれません：保存されたデータが自動的に削除されるようにローカルストレージを使用する方法はありますか？ 幸いなことに、HTML5開発者は、localStorageとまったく同じように機能するグローバルなsessionStorageオブジェクトを追加することでこれを処理しました。

メリット

この記事の目的は、localStorageを使用しないことですが、それでも多くの利点があります。

まず第一に、それは純粋なJavaScriptです！ Cookieに関する不快な点の1つは（実際、ローカルストレージに対する唯一の本当の代替手段です）、サーバーによって作成されなければならないということです。 ホラー。Webサーバーでの作業は退屈で時間がかかるためです。 静的サイト（SPAなど）を作成する場合、localStorageを使用すると、バックエンドなしでサイトを機能させることができます。 これは非常に強力な概念であり、このプラクティスが開発者の間で人気がある主な理由の1つです。

もう1つの利点は、localStorageにデータストレージ用に少なくとも5 MBあることです（このサイズはすべての主要なWebブラウザーでサポートされています）。これは、Cookie（〜4 Kb）よりも桁違いに大きいです。 これは、後で使用するためにブラウザに比較的大量のアプリケーションデータをキャッシュする必要がある場合に大きな利点をもたらします。

短所

LocalStorageには非常にシンプルなAPIがあり、多くの開発者はそれがどれほどシンプルかを知りません。 さらに詳しく考えてみましょう。

• 文字列のみを含めることができるため、少なくとも文字列よりも複雑なものであれば完全に役に立たなくなります。 もちろん、すべてのデータ型を文字列に変換できますが、これはい解決策です。
• 同期的です。 これは、リポジトリに関連付けられている各操作が順番に実行されることを意味します。 複雑なアプリケーションでは、速度が低下する可能性があるため、これは重要です。
• Webワーカーは使用できません。 つまり、パフォーマンスのためのバックグラウンド処理、Chromeの拡張機能、または他の同様のものを利用するアプリケーションを作成する場合、残念ながら、ローカルストレージを使用しても機能しません。
• 保存するデータのサイズを制限します（上記のとおり、約5 MB）。 これは、大量のデータを保存する必要があるアプリケーションや、インターネットに接続せずに機能する必要があるアプリケーションにとっては、かなり小さな制限です。
• 残念ながら、保護は提供されていないため、ページ上のJavaScriptコードはリポジトリにアクセスできます。 この最も重要な欠点については、少し後で説明します。

localStorageは、多くの条件下でのみ優れたツールであることがわかりました。

安全性

ここに問題があります。ローカルストレージの欠点のほとんどはごくわずかです。 しかし、セキュリティは決定的な要因であるため、それについてさらに詳しく説明しましょう。
したがって、localStorageは安全ではありません ！ 絶対に！ 機密データを保存するためにそれを使用する誰もが間違っています。

機密データの意味を理解しましょう：
-ユーザーID
-セッションID
-JWT（JSON Webトークン）
-個人情報
-クレジットカード情報
-APIキー
-一般に公開しないその他の情報

LocalStorageは、ブラウザにデータを保存するための安全なメカニズムとしてではなく、小さなサイト/ Webアプリケーションの作成を容易にするためのキーと値の単純なストレージとして開発されました。 そしてそれだけです。 世界で最も危険なことは何だと思いますか？ そう！ Javascript したがって、重要なものをローカルストレージに保存する場合、地球上で最も信頼性の低い金庫に最も秘密の情報を隠したいことを想像してください。 良い考えではありません。

実際、問題はクロスサイトスクリプティング（ XSS ）です。 この脆弱性の詳細な説明を負担したくないので、簡単に説明します。ハッカーがサイトでJavaScriptコードを実行できる場合、localStorageからすべての情報を簡単に引き出してサーバーに送信し、ユーザーセッションデータなどを取得します。 。
あなたは反対するかもしれません：「まあ、私のサイトは安全です。誰も私のサイトでスクリプトを実行できません。」 そして、ここにキャッチがあります。 理論的には、あなたは絶対に正しいですが、実際これを達成することは実際上不可能です。 理由を見てみましょう。

きっとあなたのサイトには他のサーバーからダウンロードされたスクリプトが含まれています。 最も一般的なオプションは、次へのリンクです。
-ブートストラップ
-jQuery
-Vue、React、Angularなど
-Google Analytics

まあなど。 その後、攻撃者がサイトでスクリプトを実行する可能性があります。 次のコードが含まれていると想像してください。

 <script src="https://awesomejslibrary.com/minified.js"></script> 

awesomejslibrary.comが攻撃され、minifed.jsスクリプトも変更されたとします。 この場合、スクリプトがlocalStorageからすべてのデータを収集し、盗まれた情報を保存するために特別に作成されたAPIに送信するリスクがあります。 ハッカーはユーザーデータを盗みましたが、彼もあなたも（開発者として）知ることはありませんでした。 悪いオプション。

私たちは皆、すべてのjsスクリプトをサーバーにローカルに配置する必要があると考えることがよくありますが、実際にはこれはめったに起こりません。 多くの企業では、マーケティング担当者はWYSIWYGエディターやその他のツールを使用して、サイトに直接変更を加えることができます。 これは疑問を投げかけます。サードパーティのJSがサイトのどこでも使用されていないことを本当に確信していますか？ 答えます：いいえ。 したがって、ユーザー情報の漏洩のリスクを減らすために、 localStorageに機密データを保存しないでください 。

トークンについて

ローカルストレージに機密データを保存する必要がない理由を十分に説得力をもって説明したように思えますが、JSON Web Token（JWT）を使用して状況を個別に明らかにする価値があります。 localStorageにJWTを保存する多くの開発者は、これがユーザー名/パスワードと本質的に同じであることを認識していません。

ハッカーがこれらのトークンをコピーすると、サーバーにリクエストを送信できるようになり、ユーザーはそれについて知ることができなくなります。 したがって、クレジットカード情報やパスワードと同じように扱います。つまり、数千のチュートリアル、Youtubeのビデオ、さらには大学のプログラミングコースに反して、localStorageに保存しないでください。 これは間違っています！ 認証のためにトークンをローカルリポジトリに保存するようアドバイスされた場合は、この記事を見せてください。

代替案

したがって、localStorageが情報を保存するための理想的なソリューションとはほど遠いことを確認した後、代替オプションに精通する時が来ました。

機密データ

このようなデータを保存するための唯一の正しい決定は、サーバー側のセッションです。 アルゴリズムは次のとおりです。

• ユーザーがサイトにログインするとき、一意のセッション識別子を作成し、暗号化された暗号化されたCookieに保存する必要があります。 あらゆる種類のWebフレームワークを使用している場合は、「Cookieを使用してユーザーセッションを作成する方法」をグーグルで検索し、このガイドに従ってください。
• フレームワークで使用されるCookieライブラリの設定で「httpOnly」が有効になっていることを確認してください。 これにより、ブラウザでCookieを表示できなくなります。これは、サーバー側での安全な使用に必要です。 詳細については、 Jeff Atwoodの記事を読むことをお勧めします。
• さらに、設定がSameSite = strict （ CSRF攻撃を防ぐため）を示し、 secure = true （暗号化された接続のみを介してCookieの送信を保証する ）を示すことを確認する必要があります。
• ユーザーがサイトを要求するとき、セッション情報（Cookieから抽出）を使用してアカウント情報を取得します。 その後、セッション識別子を再確認せずに、このアカウントに関連付けられた機密データをユーザーに自由に送信できます（もちろん、最初の検証に合格した場合）

このシンプルで、最も重要なことは、安全なモデルです。 そして、もちろん、それを使用して、任意のレベルのプロジェクトをスケーリングできます。

非行データ

機密ではなく、文字列よりも複雑な情報を保存する必要がある場合は、IndexedDBが最適なソリューションです。 これは、低レベルAPIを備えたデータベーストランザクションシステムです。これは、さまざまなデータ（/ blobファイルを含む）をブラウザーに直接格納するのに適したオプションです。 詳細については、Googleのガイドから入手できます 。

オフラインデータ

インターネットに接続せずにアプリケーションが機能するようにするには、IndexedDBとCache API（Service Workerの一部）の組み合わせが最適なソリューションになります。これにより、正しい操作に必要なすべてのリソースをキャッシュできます。 Googleからの使用に関する優れたチュートリアルはこちらです。

おわりに

皆さんが今理解したことを願っています（結局理解できますか？） パブリックで高性能なアプリケーションで使用されていないデータを保存する必要がある場合、5 MBを超えず、文字列のみで構成されているため、ローカルストレージは目的に適したツールになります。
それ以外の場合はすべて、 ローカルストレージを使用しないでください ！ 代替ソリューションを使用します。

そして、お願いします、セッション情報（JSON Webトークンなど）をlocalStorageに保存しないでください。 これにより、ユーザーに害を及ぼす多数の攻撃に対してサイトが脆弱になります。

PSなぜXSSから保護する方法としてContent Sequiriy Policy （CSP）に言及しなかったのか疑問に思う人のために。 その理由は簡単です。それは、私が説明した状況では役に立たないでしょう。 CSPを使用してJavaScriptを接続するすべてのサードパーティドメインをチェックしても、ホワイトリストのサイトがハッキングされた場合、これは役に立ちません。

残念ながら、 PPS サブリソースの整合性も問題の解決策ではありません。 ほとんどのマーケティングツール、広告ネットワークなど。 （最も一般的なサードパーティのスクリプト）サブリソースの整合性はほとんど使用されません。これらのスクリプトのプロバイダーは、機能やその他の機能を拡張するためにスクリプトを変更することが多いためです。

Local Storageの使用を停止してくださいの翻訳。
著者の許可を得て公開。