私の理解では、CORSモジュールを使用するとリソースからAccess-Control-Allow-Originヘッダーが削除され、XmlHttp要求がブラウザから失敗する原因となります。ASP.net Core CORSポリシーは、ブラウザ以外の要求からのリソースアクセスを防止しますか？
しかし、CURLや他のネイティブアプリケーション/ Webサーバー（つまり、PHPを使用して書かれたリクエスト）からのHttpリクエストが、そのリソースからデータを正常に取得できないようにしますか？
を参照してください？
いいえ他のクライアントがリソースを正常に取得できないようにすることはできません。
CORSプロトコルは、ブラウザによってのみ適用されます。サーバーによって強制されません。要求にCORSの詳細がない場合、サーバーは何らかの理由で要求をブロックしたり、応答の送信を拒否したりすることはありません。実際、CORSプロトコルの場合、クライアントが送信する特別な詳細はありません。
サーバーでCORSサポートを構成する場合、サーバーが異なるのは、Access-Control-Allow-Origin応答ヘッダーと他のCORS応答ヘッダーを送信するだけです。
プロトコルが動作する仕組みは、CORSの設定をサーバー側で行う場合でも、すべてのクライアント（ブラウザでさえ）は通常どおりサーバーからの応答を引き続き取得します。しかし、curlやその他のネイティブアプリや、PHPなどのバックエンドサーバー側プログラミング環境では、Access-Control-Allow-Originレスポンスヘッダーが含まれていないと、クライアントコードがレスポンスにアクセスできません。しかし、ブラウザはそうするでしょう。
特に、ブラウザのdevtoolsで、フロントエンドJavaScriptコードからのクロスオリジン要求に失敗した場合でも、ブラウザのdevtoolsで応答を確認することができます。
あなたのブラウザが応答を見ることができても、ブラウザがフロントエンドのJavaScriptコードにそれを公開するとは限りません。ブラウザーは、特定の起点で実行されているフロントエンドコードに対して、クロス起点リクエストからの応答のみを表示します。サーバーが、その起点を許可するAccess-Control-Allow-Originヘッダーを使用して応答することによって要求を許可するように要求が送信された場合です。
しかし、ブラウザはそれを行う唯一のクライアントです。ブラウザはCORSプロトコルを実装する唯一のクライアントです。 curlなどのネイティブアプリケーションやPHPなどのバックエンドサーバー側環境ではCORSプロトコルが実装されていないため、サーバー側でCORS構成を行うことで要求をブロックすることはできません。
だから、ブラウザ以外のクライアントからのリクエストをブロックする場合は、CORS設定以外の方法でリソースをリクエストする必要があります。
Curlと他の非ブラウザHTTPクライアントは、Access-Control-Allow-Originヘッダーを無視する必要があります。しかし、これはCURLからのHTTP要求を防ぐない、または他のネイティブアプリケーション/ウェブサーバ（すなわち。PHPを経由して書かれており、実行要求）を成功裏にそのリソースからデータを取得から How can you debug a CORS request with cURL?