はい、私は自分の質問に答えていることに気づきましたが、とにかくここに行きます。私はこれについていくつかの調査を行いましたが、行動は2つの陣営に分類されるようです。
1）CORSリクエストが無効な場合は、エラーを返します。これは、JavaCORSフィルタープロジェクトがたどるルートです。このライブラリは
2）応答でCORSヘッダーを返し、ブラウザにアクセスの詳細を分類させます。これははるかに一般的なアプローチのようで、Amazon S3、SoundCloud、FourSquare、SpotifyのAPIで使用されます（後者の2つのAPIは、単純なCORSリクエストのみをサポートすることでメリットがあります）。この場合、サーバーはエラーチェックを行わず、サポートされているオリジン、メソッド、ヘッダーのCORSヘッダーを返すだけです。ブラウザは引き続きリクエストを行いますが、CORS応答ヘッダーがユーザーのリクエストと一致しない場合、ブラウザはユーザーからの応答を保留します。
これらの方法にはそれぞれ長所と短所があります。方法＃1はCORS仕様により厳密に調整されていますが、ユーザーに有用なデバッグ情報を提供していません。
方法2は、サポートされている方法とヘッダーが何であるかについてのより多くの洞察を提供します。サーバーはリクエストヘッダーに関係なく同じレスポンスヘッダーを返すため、実装も簡単です。ただし、これには、ブラウザがユーザーからの応答をブロックする場合でも、サーバー側で実際にリクエストを実行するという犠牲が伴います。これは、POST、PUT、DELETEなどの副作用のあるメソッドには望ましくない場合があり、CORSを認証メカニズムとして使用してはならないという事実を浮き彫りにします。
（上記の私の調査は決して網羅的ではないことに注意してください。多くのAPIの実際の動作を確認するのは困難でした。これは、APIが認証を必要とするか、サポートされていないメソッドなどの他のエラーのために別のレベルでリクエストをブロックしたためです。）
モンスールの答えに付け加えたいだけです。もう1つの動作（現在S3で使用されている動作）があります。
リクエストのオリジンと一致する場合にのみCORSレスポンスヘッダーを送信します。それ以外の場合は、CORSヘッダーをまったく送信せず、ブラウザまたは他のクライアントに自分で決定させます。
少なくともこれは私にとってそれがどのように機能するかです。
また、Javaに関しては、403を送信するのが一般的です。そのJavaリンクはかなり古いものですが、JavaのデファクトスタンダードであるSpringのアプローチは同じです。ここで私のリファレンスを参照してください。
エラーの性質によって異なると思いますが、403（リクエストが必要な基準を満たしていない場合）や404（メソッドが利用できない場合）などの4xxエラーが予想されます。