私は、ブラウザ用にCORSプラグインを使用/使用したか、外部（または内部の）APIエンドポイントにAPI呼び出しを行う間に--disable-web-securityフラグを使用した唯一の人ではないと確信しています。このプラグインを使用してGoogleマップに関連するAPI呼び出しを作成しました。しかし、同じアプリケーション内で、ParseSDK API呼び出しには、CORSまたは--disable-web-securityフラグは必要ありませんでした。CORSプラグイン/ --disable-web-securityはどのようにブラウザ上で動作しますか？
私の質問は、これらのエンドポイントが異なる動作をする理由とCORSプラグインが（これらのAPIを制御できない場合でも）問題をどのように解決するのかです。
ありがとうございます。
まあ、何というプラグインが行うことは非常に無責任です。実際には、同じ発信元ポリシーを無効にするため、特定の発信元のWebサイトがその発信元に対してのみ要求を行うことができます。
同じ発信元ポリシーでは、実際にはWebサイトがGET/POST要求の応答を読み取ることができないだけで、その要求は保存されているため、要求自体が作成されます。
この優れたセキュリティ機能は、時間が経つにつれて負担となり、人々はJSONPのような回避策を使用しました。
だから我々は外来にアクセスするための新しい、標準化された方法しまっ：
CORS（クロスオリジンリソース共有）が、別の起源は、そのコンテンツにアクセスすることを許可されていることを指定するには、Webサーバーを可能にするメカニズムです。これはAccess-Control-Allow-Origin: example.comで行われ、応答が異なる起点からのものであっても、example.comは応答にアクセスできます。
Access-Control-Allow-Credentials: trueは、要求内でクッキーとHTTP基本認証を含む資格情報も許可します。
Access-Control-Allow-Origin: *にワイルドカードを指定して、すべてのWebサイトがこの応答にアクセスできるようにすることもできます。しかし、これを行うときににを指定すると、Access-Control-Allow-Credentials: falseが指定されるため、資格情報は公開されません。
これは、インターネットに公開されているアクセス可能なAJAX APIを実装する唯一の正しい方法です。
ただし、このプラグインは、単に非常に危険である同一生成元ポリシー完全を無効にします。
投稿したリンク（説明を読みましたか？）は、拡張機能の内容を正確に指定します。すべての応答にAccess-Control-Allow-Origin: *ヘッダーが追加されます。これは通常、サーバーが任意の起点からの要求を許可されていることをブラウザに通知するために送信するCORSヘッダーです。
Parse SDKは、おそらくサーバー側でCORSをサポートしています。
ほとんどの人がCORSと言うとき、あなたの情報のために、彼らはブラウザの拡張機能に言及していません。彼らはCORSと呼ばれるWeb標準を参照しています。以下のドキュメント
https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
これは明らかでした。ありがとう！ –