reactjsを使ってlocalStorageにjwtを格納しても安全ですか？
私は現在、reactjsを使用して単一ページのアプリケーションを構築しています。 localStorageを使用しない理由の多くはXSSの脆弱性によるものです。 Reactはすべてのユーザー入力をエスケープするので、localStorageを使用しても安全ですか？
最近のシングルページアプリケーションのほとんどでは、実際にトークンをクライアント側のどこかに保存する必要があります（最も一般的な使用例 - ページの更新後もユーザーをログインさせ続けるために）。
Webストレージ（セッションストレージ、ローカルストレージ）とクライアントサイドのクッキーの2つのオプションがあります。 両方のオプションが広く使用されていますが、これはそれらが非常に安全であることを意味しません。
Tom Abbottは、 JWT sessionStorageおよびlocalStorage security ）をよくまとめています。
Web Storage（localStorage/sessionStorage）は同じドメイン上のJavaScriptを通してアクセス可能です。つまり、あなたのサイトで実行されているJavaScriptはすべてWebストレージにアクセスできることになります。このため、{クロスサイトスクリプティング（XSS）攻撃に対して脆弱になる可能性がありますです。一言で言えば、XSSは攻撃者があなたのページ上で走るJavaScriptを注入することができる一種の脆弱性です。基本的なXSS攻撃はフォーム入力を通してJavaScriptを挿入しようとします。攻撃者はフォームが
<script>alert('You are Hacked');</script>をフォームに入れて、それがブラウザによって実行され、他のユーザによって閲覧されることができるかどうかを確認します。
XSSを防ぐための一般的な対応は、信頼できないデータをすべてエスケープしてエンコードすることです。 React（ほとんど）はあなたのためにそれをします！これはすばらしい XSSの脆弱性保護がReactに を担当している程度についての議論です。
しかし、それがすべての脆弱性を網羅するわけではありません。もう1つの潜在的な脅威はCDNまたは外部インフラストラクチャでホストされているJavaScriptの使用法です。
これもトムです。
最新のWebアプリケーションには、A/Bテスト、ファンネル/市場分析、および広告用のサードパーティJavaScriptライブラリが含まれています。 Bowerのようなパッケージマネージャを使って、他の人のコードを私たちのアプリにインポートします。
使用しているスクリプトのうち1つだけが危険にさらされているとどうなりますか？悪意のあるJavaScriptがページに埋め込まれる可能性があり、Web Storageが危険にさらされます。 これらのタイプのXSS攻撃では、知らないうちにあなたのサイトを訪問しているすべての人のWeb Storageを攻撃することができます。多くの組織は価値のあるものを保存したりWebストレージに情報を信頼しないように勧めます。これにはセッションIDとトークンが含まれます。
したがって、私の結論は、ストレージメカニズムとして、Web Storage 転送中に安全な規格を強制しないです。 Web Storageを読んでそれを使用する人は誰でも彼らが常にHTTPS経由でJWTを送信し、決してHTTP経由で送信しないことを保証するために彼らの十分な注意を払わなければなりません。
これは古い質問ですが、@ mikejones1477が言ったように、最新のフロントエンドライブラリとフレームワークはテキストをエスケープし、XSSに対する保護を提供します。 Cookieが資格情報を使用した安全な方法ではない理由は、localStorageがCookieを使用してもCSRFが妨げられないためです（また、JavaScriptでもCookieにアクセスできるため、XSSはここでは大きな問題ではないことに注意してください）、 この答え理由を再開 。
認証トークンをローカルストレージに保存し、各リクエストに手動で追加してCSRFから保護する理由は、Word：マニュアルというキーです。ブラウザは自動的に認証トークンを送信しないため、evil.comにアクセスしてPOST http://example.com/delete-my-account を送信した場合、認証トークンを送信できないため、リクエストは無視されます。
もちろんhttpOnlyが聖杯ですが、あなたはCSRFの脆弱性がまだ残っているので、reactjsやjsフレームワークからはアクセスできません。私の推奨事項はlocalstorageであるか、Cookieを使用する場合は、 CSRFの問題（Djangoがそうです を解決するようにしてください。
CDNに関しては、GoogleやbootstrapのようなCDNなどの奇妙なCDNを使用していないことを確認してください。コミュニティによって維持され、悪意のあるコードが含まれていない場合は、自由にレビューできます。
CDNを使用するのであれば安全ではありません。
悪意のあるJavaScriptがページに埋め込まれる可能性があり、Web Storageが危険にさらされます。この種のXSS攻撃は、知らないうちにあなたのサイトを訪問しているすべての人のWeb Storageを攻撃することができます。これが、多くの組織が価値のあるものを保存したり、Webストレージに情報を信頼したりしないことをお勧めする理由です。これにはセッションIDとトークンが含まれます。
via ストームパス
あなたが外部から要求するどんなスクリプトも潜在的に危険にさらされ、あなたのクライアントのストレージからJWTSをつかみ、攻撃者のサーバーに個人データを送り返す可能性があります。
基本的にあなたのJWTをあなたのlocalStorageに保存しても大丈夫です。
そしてこれは良い方法だと思います。 XSS、CDNを使用したXSSについて話しているのであれば、クライアントのログイン/パスを取得する危険もあります。ローカルストレージにデータを保存すると、少なくともCSRF攻撃を防ぐことができます。
あなたは両方を知っていて、あなたが望むことを選ぶ必要があります。どちらの攻撃も、あなたが知っておく必要があるのはそれだけではありません。覚えておいてください。
もう一度保存しても問題ありません、XSS、CSRFに対して脆弱であることなど
LocalstorageはJavaScriptでアクセスできるように設計されているため、XSS保護は提供されません。他の回答で述べたように、XSS攻撃を実行するにはたくさんの方法がありますが、デフォルトではlocalstorageは保護されていません。
ただし、CookieにはXSSやCSRF攻撃から保護するためのセキュリティフラグがあります。 HttpOnlyフラグはクライアントサイドのJavaScriptがCookieにアクセスするのを防ぎ、Secureフラグはブラウザがsslを介してCookieを転送することのみを許可し、SameSiteフラグはCookieがOriginにのみ送信されるようにします。私が調べたところ、SameSiteは現在OperaとChromeでのみサポートされていますが、CSRFから保護するために他の戦略を使用することをお勧めします。たとえば、暗号化されたトークンを他のCookieでパブリックユーザーデータと共に送信する場合などです。
そのため、Cookieは認証データを保存するためのより安全な選択です。
LocalStorageとhttpOnlyのどちらのCookieも使用できませんか？危険にさらされているサードパーティのライブラリに関しては、私が知っている唯一の解決策が機密情報の盗難を減らす/防ぐことです Subresource Integrity 。
Subresource Integrity（SRI）は、ブラウザが（CDNなどから）フェッチしたリソースが予期しない操作なしで配信されることを確認できるようにするセキュリティ機能です。取得したリソースが一致しなければならない暗号化ハッシュを提供できるようにすることで機能します。
侵害されたサードパーティのライブラリがあなたのウェブサイトでアクティブである限り、キーロガーはユーザ名、パスワード、およびあなたがサイトに入力したその他のもののような情報を収集し始めることができます。
HttpOnlyクッキーは他のコンピュータからのアクセスを防ぎますが、ハッカーがユーザのコンピュータを操作するのを防ぐために何もしません。