CORS仕様では、欠落しているContent-Typeヘッダーを「単純なヘッダー」を意味すると見なしますか？

Question

ペイロード本文を含むメッセージを生成する送信者は、囲まれた表現の目的のメディアタイプが送信者に不明でない限り、そのメッセージにContent-Typeヘッダーフィールドを生成する必要があります。 Content-Typeヘッダーフィールドが存在しない場合、受信者はメディアタイプをapplication/octet-stream（ [RFC2046]、セクション4.5.1 ）と見なすか、データを調べて決定することができます。そのタイプ。

CORS推奨状態：

ヘッダーフィールド名がASCII Accept、Accept-Language、またはContent-Languageの大文字と小文字を区別しない一致）である場合、ヘッダーは単純なヘッダーであると言われます。または、それがContent-TypeのASCII大文字と小文字を区別しない一致であり、ヘッダーフィールド値のメディアタイプ（パラメーターを除く）がASCII case- application/x-www-form-urlencoded、multipart/form-data、またはtext/plainの大文字と小文字を区別しない一致。

application/octet-streamを使用すると、非単純ヘッダーのケースが強制されるため、これにより、POSTでのCORS実装に不特定のケースが作成されるようです。データを調べてそのタイプを判別することは簡単ではありません。

次の場合に最も合理的なことは何ですか？

Content-リクエストの長さは0です。（単純なヘッダーの場合を有効にするためにContent-Type: text/plainを想定したいと思います。）
Content-Lengthがゼロ以外です。（デフォルトはapplication/octet-streamで、非単純ヘッダーの場合を強制しますか？）

CORSがセキュリティ対策であるか、リソース共有の単なるモデルであるかに関するコメントに対処するために、これらのエッジケースの影響に関するいくつかの追加情報を追加します。はい、CORSは確かにリソース共有のモデルです。ただし、HTTPクライアントがクロスオリジンリソース検索を明示的に防止するセキュリティ対策を追加するまで、リソース共有はCORSなしで問題なく機能しました。不適切に実装された場合、CORSのサーバー側コンポーネントは、特に資格情報が関係している場合に、リソースを不適切に共有することにより、これらのセキュリティホールの一部を再び開く可能性があります。これらのエッジケースは、（上記の質問への回答に応じて）資格情報を持つリソースのクロスオリジンリクエストを許可するかどうかに関するセクションに直接つながるパスです。

単純なヘッダーと非単純なヘッダーを構成するものを決定する上記のエッジケースは、一部のリクエストが単純なリクエストと見なされるかどうかに影響し、パート4：セキュリティの考慮事項が有効になります。

単純なクロスオリジンリクエストは、この仕様に準拠していない現在デプロイされているユーザーエージェントによって生成される可能性のあるリクエストと一致するものとして定義されています。この仕様の範囲外で生成された単純なクロスオリジンリクエスト（GETまたはPOSTまたはスクリプト要素から生じるクロスオリジンGETリクエストなど）を使用したクロスオリジンフォーム送信など）には通常、ユーザー資格情報が含まれるため、この仕様は、資格情報を使用した単純なクロスオリジンリクエストを期待できるように常に準備する必要があります。

このため、単純なリクエストが取得以外の重要性を持つリソースは、明示的に提供されたリクエストのコンテンツに推測できないトークンを含めることを要求することにより、クロスサイトリクエストフォージェリ（CSRF）から自身を保護する必要があります。

Steffen Ullrich · Accepted Answer

コンテンツタイプの制限の背後にある主な考え方は、CORSを使用したXMLHttpRequestは、従来のセキュリティモデル内ですでに実行できるものと比較してデフォルトのセキュリティを弱めるべきではないということです。従来のセキュリティモデルでは、次のクロスオリジンリクエストが許可されていました。

ブラウザによって作成された単純なGETリクエスト。これはペイロードではないため、Content-typeヘッダーもありません。
フォームを送信して作成されたPOSTリクエスト。これらにはペイロードがありますが、コンテンツタイプ（属性enctype）はapplication/x-www-form-urlencoded、multipart/form-data、またはtext/plainのみです。

このような単純なリクエストやフォームの送信で実行できること以外のことは、新しい攻撃ベクトルが作成されないように、デフォルトでより厳密に処理する必要があります。これには、ブラウザが独自に送信しない、あらゆる種類のカスタムヘッダーとコンテンツタイプの設定が含まれます。