localhostでCORを有効にすることのセキュリティリスクは何ですか？
Cordovaベースのモバイルアプリで、モバイルのローカルサーバーを介して一部のAPIにアクセスしています。モバイルアプリはOriginをLocalhostとして設定します。ここでcorsが起動し、リクエストを行うことができません。現在、これらのAPIは、CORSをトリガーせずに、ターミナル、ポストマン、その他のブラウザー以外の環境で使用できます。
このシナリオで、localhostでCORを有効にするリスクは何ですか？明確にするために、実稼働中のlocalhostのcorをホワイトリストに登録したい。
答えは、実際に作成したAPIとその機能によって異なります。 このサイト CORSの商品と欠点について非常によく説明しています。つまり、作成者は別のドメインから電子メールを送信するために使用される架空のAPIを作成します。彼は述べています：
セッションCookieに基づく認証を使用している場合は、おそらく全員によるCORSリクエストを許可すべきではありません。悪意のあるWebサイトは、ユーザーの特定の許可なしに、AJAX要求を介してapi.yoursebsite.comに電子メール送信要求を発行する可能性があります。
これは（彼の仮定の場合）「corsを有効にすることのリスクは何ですか？」という質問に対する答えです。その場合、彼は緩和策について考える方法についてさらにいくつかの情報を提供します。
ユーザーがブラウザに有効なセッションCookieを持っている場合、それらはapi.yoursebsite.comでの認証に使用され、それにより不要な電子メール送信が行われます。ほとんどの場合、危険なリクエストは「プリフライト」されます。つまり、リクエストを送信する前にドメインを承認する必要があります。これにより、悪意のあるアクティビティの発生を防ぐことができます。
これは（わずかに隠された方法で）ダンダビスがすでに言ったことを述べています：CORSはセキュリティとはほとんど関係がありません。セキュリティはサーバー側で行われます。 SOPは、とにかくハッカーが従うことはありません。
あなたの場合、私が理解していることから、リクエストがいくつかの異なるドメインを通じて行われるように、CORSを介してドメインとしてlocalhostを有効にしたいですか？それが正しい場合私はあなたが本当のセキュリティ問題に直面しないと思います。ループバックアドレス（localhost）にのみバインドされたソケットを開いたという前提条件の下で、誰かが（悪意のある方法または別の方法で）それにアクセスできる唯一の方法は次のとおりです：彼はすでにループバックアドレスにアクセスできます。つまり、彼はすでにデバイスへのアクセス権を取得しています。
Conor Manconeの非常に正しいコメントに基づいて：CORSは主に不正な読み取り要求から保護します。サーバーを書き込みから保護したり、不正なアクションを引き起こしたりすることはありません。これは、承認の概念によって実施する必要があります。
いいえ、これは[〜＃〜]ではありません[〜＃〜]（必然的に）安全です。他の回答はほとんど正しいですが、2つの仮定（一般的ですが誤っています）を除いています。localhostは常に127.0.0.1であり、マシンで実行しているWebサーバーは実行したいものです。 これらは安全な想定ではありません。
一部のマシンでは、何らかの目的での意図的な変更または単にHOSTSファイルが最小（または欠落）であるため、localhostを127.0.0.1（IPv6の場合は:: 1）として定義せず、その名前のDNSルックアップを実行します。もちろん、DNSは一般的に安全ではありません。同じネットワーク上の攻撃者（または「ローカルホスト」がマップするIPアドレスを正式に宣言する意思があるDNSサーバーとの間の任意の場所）は、自分のIPアドレスを指定してDNS応答を挿入できます。その後、アプリは攻撃者のWebサーバーからWebコンテンツを読み込みます。攻撃者は、サービスへの信用を盗む被害者の悪意のあるWebコンテンツを送信し、アカウントからコンテンツを盗み、悪意を持ってアカウントを悪用し、JSからネイティブAPIへのブリッジを使用してデバイスを攻撃する（または少なくともモバイルにデータに悪意を持ってアクセスする）アプリで確認できます）など。
では、「localhost」の代わりに「127.0.0.1」を使用するとどうなるでしょうか。 IPアドレスはDNSを経由する必要はありません。127.0.0.1は常に自分のマシンだけにルーティングされます。
まだ悪い考えです！ TCPソケットは、ユーザー間（またはサンドボックス化されたアプリ間）の特権分離を尊重しません。モバイルユーザーがそのポートでWebサーバーを実行しているスケッチアプリを1つ持っている場合、アプリは悪意のあるサーバーに接続しますアプリが起動しようとしたもの（すでに使用されているため、ソケットのバインドに失敗します）ではなく、ほぼ確実にアプリストアにそれを入れることができます。許可されていないAPIや何かを使用していません。特定のポートにバインドされたループバックソケットでWebコンテンツを提供する（あなたと同じ）。同様にサーバー/デスクトップ/ラップトップで、マシンが非管理者に（SSH、リモートデスクトップなどを介して）リモートでアクセスできる場合は、これらのユーザーは、使用するポートで悪意のあるWebサーバーを起動し、アプリがそのサーバーに接続するのを待つ可能性があります。
もちろん、悪意のある試みがなくても、このアイデア全体はfragileにすぎません。上で述べたように、選択した同じポートで他のプロセスがWebサーバーを実行しているという保証はありません。選択できるのは2 ^ 16のみで、一部の範囲では、OS自体がそのポートにoutbound接続をランダムにバインドして、使用できるようにすることができますサーバーではなくクライアントアプリ（Webブラウザーのような）によって。どちらの方法でも、Webコンテンツを提供するために使用されるサーバーはポートのバインドに失敗し、アプリは期待するサーバーと通信できなくなり、ユーザーのエクスペリエンスが低下します。
これはCORSとは関係がないことに注意してください。 [〜＃〜]何でも[〜＃〜]Originがコンテンツをロードするとき、サーバーはそのOriginがWeb応答を表示できるようにする必要があります。
重要なポイントは、Webコンテンツが確実に読み込まれるようにすること、安全に、HTTP over normal TCP-つまり、接続を認証および保護するためのTLSまたはその他の方法がない場合-安全ではありません！
ソリューション：インターネットに接続しているWebサーバーから（HTTPS経由で）コンテンツをロードするだけです。その後、アプリはHTTP経由で何もロードする必要がなく、WebサービスはHTTP経由でロードされたWebページからのリクエストを許可する必要がありません。また、アプリは適切なサーバーからコンテンツをロードしていることを確認できます。
同じドメインからコンテンツを提供することもできるので、クロスオリジン（CORS）リクエストは必要ありません。昔ながらのXMLHttpRequests（またはCORSなしのFetch）を使用して、WebサービスからCORS関連のものを取り除いてください。
ストーリータイム：
私が働いていた以前の会社には、ローカルホストのWebサーバーからWebViewにデータをロードするというようなことをする製品があり、Webのビューが正しかったと報告しているという非常に面白い問題に遭遇しました。 .. 空の。内容はありません。ローカルサーバーが実行されていて、コンテンツが正しくパッケージ化されてインストールされており、webviewがwebリクエストを作成しようとしていました...しかし、サーバーが応答していないようです。要するに、これらのマシンでは「localhost」が定義されていないことを突き止めました。これは約10,000人中わずか数人のユーザー（Macでは、それがアプリを実行した唯一のプラットフォームだったため）でしたが、「localhost」の使用をやめたのは十分な問題でした。もちろん、「127.0.0.1」も上記で説明したように安全ではないことが判明しましたが、その決定は、チームに警備員がいる前に行われました。