APIアプリでOriginを制限する必要がありますか？
Rest-like APIを提供するアプリとangularそれのためのUI。クライアントはAPIを直接使用することも、UIを使用することもできます（クライアントが人間の場合）。
CORSがブラウザーで機能するためのOPTIONSリクエストとangularによって実行されるxhrリクエストが許可されるようにするには、アプリが特別なヘッダーを返す必要があります。
私の質問はなぜですか？これはユーザーをどのように保護していますか？別の質問は、ワイルドカード*すべてのドメインにAPIへのアクセスを許可することでセキュリティ上の問題があるかどうかです。ユーザーがcurlを使用しているか、独自のスクリプトを使用しているか、このAPIのカスタムUIを構築しているかどうかは気にしません。なぜ制限を設ける必要があるのですか？
これについて私が見ることができる唯一の考えられる理由は、サードパーティのサイトがブラウザに保存された資格情報を使用してAPIにアクセスする可能性を回避することです。ただし、Access-Control-Allow-Credentials: trueヘッダーが設定されていない限り、これは不可能です。ただし、これはワイルドカードのallow-Originヘッダーでは機能しません。
説明：問題はnotなぜアクセスを制限するが、Access-Control-Allow-Credentialsヘッダーがfalseの場合にOriginドメインを制限するのか。私の言い回しがこれについてはっきりしていなかったらすみません。
ブログ が見つかりました。それから、サイトがセキュリティ対策の一種としてクライアントネットワークを使用していない限り、ワイルドカードは危険に聞こえません。
たとえば、被害者のブラウザから誰かがVPNにアクセスしようとしていることを想像できます。多くの内部知識が必要になりますが、たとえば攻撃者が元従業員である場合、そのような知識があれば、内部の連絡先を使用して不正なWebページを開かせ、攻撃を実行する可能性があります。
Same-Origin-Policyとは何ですか？
Mozilla から：
Same-Originポリシーは、あるOriginからロードされたドキュメントまたはスクリプトが別のOriginのリソースとどのように相互作用するかを制限します。これは、潜在的に悪意のあるドキュメントを分離するための重要なセキュリティメカニズムです。
最新のブラウザはすべてこれを強制します。
なぜそれがあるのですか？
これにより、ブラウザは見たコードを実行するだけなので、攻撃者がユーザーをだまして悪意のあるURLをクライアントにロードしたり、金銭を攻撃者に送金したりすることを防ぎます。
[〜＃〜] csrf [〜＃〜] のOWASP情報を確認してください。具体的には、例と「攻撃はどのように機能しますか？」
クロスオリジンリソースシェアリングとは
Mozilla から：
クロスオリジンリソースシェアリング（CORS）は、追加のHTTPヘッダーを使用して、ユーザーエージェントが現在使用中のサイトとは異なるオリジン（ドメイン）上のサーバーから選択したリソースにアクセスするための権限を取得できるようにするメカニズムです。
要約すると、セキュリティバイパスのメカニズムです。
なぜ人々はCORSを必要とするのですか？
人々はまだAJAXはクールです。冗談です。あるいは、開発者はまだクライアント側の非同期モデルを使用してアプリケーションにデータをロードしていると考えています。
[〜＃〜] edit [〜＃〜]コメントに基づいて追加
Access-Control-Allow-Credentialsヘッダーがfalse（または欠落）に設定されている場合、このOriginドメインを制限する理由
あなたはおそらくこれを知っていますが、Access-Control-Allow-Credentialsは、クライアント/サーバーがサイトに公開されている資格情報を受け入れるかどうかのみを制御します。
応答に基づいて、APIは資格情報を必要としないため、このフラグは無関係です。ただし、CORSをワイルドカード '*'とともに使用するか、Originを返すか、またはOriginを制限する必要がありますか？
おそらくインターネット上には多くの赤いテキストがありますが、APIがオープン/パブリックである場合は、ワイルドを使用したり、Originをエコーしたりするよりは問題ありません。
APIがより組織固有である場合、それを使用するドメインをホワイトリストに登録し、そのリストと照合して、ホワイトリストでオリジンを返します。これらは優れたセキュリティプラクティスです。
私はそれを無効にしません
CORSがどのように機能するのか、いつ適用できるのかについて少し混乱しているようですが、これは特に質問の理由からです。
別の質問は、ワイルドカード*すべてのドメインがAPIにアクセスすることを許可することにセキュリティ上の問題があるかどうかです。ユーザーがcurlを使用しているか、独自のスクリプトを使用しているか、このAPIのカスタムUIを構築しているかどうかは気にしません。なぜ制限を設ける必要があるのですか？
CORSとプリフライトOPTIONリクエストはブラウザにのみ関係することを覚えておく必要があります。誰かが独自のAPIを作成し、CURLまたは他のサーバー間リクエストを使用している場合、プリフライトリクエストは発生せず、Access-Control-Allow-Originヘッダーは完全に無視されます。
ただし、JavaScriptを介してブラウザからajaxリクエストを行おうとすると、ブラウザ自体がCORSを適用します。プリフライトOPTIONリクエスト（必要な場合）を送信し、すべてがチェックされない場合はレスポンスを破棄します。でる。
CORSは書き込みではなく読み取りから保護することにも注意してください。 javascript/ajaxを介してPOSTリクエストを行った場合でも、リクエストはサーバーに送信されます。CORSチェックが検証されない場合、呼び出し側のJavaScriptアプリケーションは単にレスポンスを読み返すことができません。 。
あなた自身の答えは、おそらくCORSを使用したい理由を理解することです（ただし、すべてのオリジンを許可したい場合もあるでしょう）。すべてのブラウザリクエストにもCookieが添付されていることに注意してください。その結果、アプリケーションがCookieを介して認証され、Originが許可されている場合、理論的には、認証されたユーザーに代わってAPI呼び出しを行うサイトに誰でもJavaScriptを配置できます。
例として、商品のランディングページで[ワンクリック購入]ボタンをクリックすると、JavaScriptを介して行われるAPI呼び出しがAmazonにあるとします（参考として、このようなAPI呼び出しは確かに存在します）。さらに、認証資格情報がCookie（おそらくtrue）を介して管理され、攻撃者がAPI呼び出しの構造を理解するのにしばらく時間を費やしたことを想像してください（Javascriptコードは常に検査に利用できるため不可能ではありません）。
あなた（攻撃者）を入力してください。アマゾンで200ドルで土の袋を売っています。誰もあなたの製品を買っていません。したがって、Amazonエンドポイントを呼び出して、ゴミの袋でワンクリック購入を実行するJavaScriptを記述します。ただし、自分で購入したくないので、代わりに非常に人気の高い猫の動画を掲載したWebサイトを作成します（結局、猫が嫌いなのは誰ですか？）。そのWebサイトでは、ページの読み込み時にワンクリックで汚れた購入を自動的に呼び出すJavaScriptを配置します。これで、Amazonにログインしているときに誰かがWebサイトにアクセスするたびに、何もせずにすぐにゴミ袋を購入します。あなたの注文は次第に動き始め、Amazonはセキュリティが不十分なため、手に大きな混乱を抱えています。
オープンなOriginがあなたに噛み付くことができる理由の最良の例ではないかもしれませんが、うまくいけば、それが重要な意味を持つようになります。繰り返しますが、オープンOriginが完全に合理的であるいくつかのAPI呼び出しが確かにあります。良い例はほとんどのソーシャルメディアアプリです。Twitter/ facebook/etcなどは、最近のTwitterフィードを簡単にプルダウンできるように、他のWebサイトで実行されることを意図したJavaScriptを具体的に提供します。代わりに、API呼び出しを認証するためにジャンプする必要のある独自のフープがあります。したがって、APIを開きたい理由は確かにあります。ただし、そうしない理由もあります。どちらの場合でも、これはブラウザー内API呼び出しでのみ重要です。 Curlおよびその他の「直接」HTTPリクエストは、CORSをすべて無視します。