Origin間のリクエストを受け入れたくない場合は、CORSを無視できますか？
CORS仕様では、リクエストメソッドとヘッダーが simple でない場合、プリフライトHTTP OPTIONSリクエストが送信され、リクエストがサーバーで許可されているかどうかが確認されます。
私のサーバーはCORS固有のヘッダーで応答しないため、これは要求が拒否されることを意味すると想定しています。セキュリティ会社は最近、私がCORSヘッダーでそれを特に拒否しない限り、要求は常に受け入れられることを意味すると私に言ったが、これは信じがたいと思う。
また、一部の古いブラウザーはCORSをまったく実装していないため、これらのブラウザーがCORSチェックをバイパスできる可能性があるというセキュリティホールがあるのではないかと思います。または、これらのブラウザは常にすべてを拒否するだけですか？
概要：クロスオリジンのリクエストを受け入れてほしくありません。 CORSが存在しないふりをしただけのセキュリティホールはありますか？
いいえ。CORSが存在しないふりをするだけではセキュリティホールはありません。 CORSはオプトインポリシーです。サーバーがCORSヘッダーを送信しない（オプトインしない）限り、ブラウザーは引き続き標準の同じオリジンポリシーを使用します。 CORSが存在しないふりをして、生活をシンプルに保つことができます。これは完全に合理的な戦略です。
CORSはオプションです。追加の機能が必要な場合は使用できますが、無視して使用しないこともできます。これは仕様によるものです。それ以外はクレイジーです。 CORSの前に書かれた何百万ものWebサイトがあり、変更されることはありません。これらのWebサイトを一晩で作成する標準を設計するのは、おかしいでしょう。 CORS標準の作成者は狂っていません。彼らはそれをしなかった。 （実際、彼らはそれをするために非常に苦労しましたnot！）
あなたのセキュリティ会社との誤解または誤解があったと思います（または、おそらくあなたのセキュリティ会社が間違っているだけかもしれません）。私の知る限り、WebアプリケーションがCORSヘッダーを送信しないことは問題ありません。
つまり、あなたはdo CSRFを理解する必要があります。 CSRFはWebの根本的な脆弱性です（CORSよりもはるかに古く、CORSに直角です）。だから、読んでください。 OWASP Webページおよびこのサイトには、CSRFに関する多くの優れたリソースがあります。 CSRFに対する標準的な防御策は、副作用をもたらす可能性のあるすべてのHTTP要求にCSRFトークンを使用することです。
クライアントまたはサーバーを保護しようとしていますか？ CORSは、クライアント側のアプリケーション（スクリプトなど）が「same-Origin-policy」外のリソースにアクセスする方法を提供することを目的としていると私は理解しています。標準に準拠したブラウザは、Access-Control-Allow-Origin HTTPヘッダーがない場合、スクリプトがドメイン外のリソースを取得することを許可しないでください（例：AJAX request））。そのため、答えはあなたの質問にあなたはそれについて心配する必要がないということです。しかし、CORS /同じオリジンのポリシーがクライアントによって強制されているので、クロスオリジンのリクエストを拒否するためにサーバー側で何ができるかわかりませんそのヘッダーで明示的に許可しないよりも。
Webサーバーがリクエストを受け取ると、クライアントが送信したものだけを認識します。ブラウザが存在する場合でも、ブラウザで何が起こっているかについての情報はありません（誰かがcurlまたはwgetを使用してリクエストを行ったとします）。したがって、CSRFを防止する責任は主にブラウザの責任であり、古いブラウザがそれを防止するために何もしない場合、それらの要求は受け入れられます。
CORSをまったく処理しないCSRFを防止するための 多くの手法 があります。最も効果的なAFAIKの1つはCRSFトークンの使用です。ランダムトークンをクライアントに送信し（サイトのCookieに保存し）、保護する必要があるすべての送信でそれを予期します。 SSLを使用している場合、攻撃者（Cookieにアクセスできない）がトークンを知る方法がないため、攻撃者は有効なリクエストを偽造できません。