セキュリティに特別な配慮が必要なサーバサイドアプリケーションは、ブラウザに対してCORSの一部としてAccess-Control-Allow-Headersというアドバイスをします。これは、サーバサーイドでクロスオリジンサイトとして安全とアドバイスしたサイトに対し「但し、Access-Control-Allow-Headersにあるヘッダーに限る」と制限をつけるものです。しかしながらヘッダーの性質上セキュリティに問題なりにくいヘッダについてはわざわざここにリストされていなくてもOKという取り決めがあります。これがCORSセーフリクエストヘッダーとなります。

セーフリクエストヘッダーには以下の4つが決められています。どれもおなじみのものですね。

• Accept
• Accept-Language
• Content-Language
• Content-Type

従って、通常これらのヘッダーがAccess-Control-Allow-Headersにリストされる必要はありませんが、ややこしい事にこれらをAccess-Control-Allow-Headersに追加されることで、追加制約が解除される という仕様があります。

• Accept-LanguageとContent-Language: 0-9, A-Z, a-z, スペースまたは*,-.が利用可能になる。
• Accept と Content-Type: CORS-unsafeのリクエストヘッダバイト: 0x00-0x1F (許可されている 0x09 (HT) を除く)、"():<>?@[\]{}、および 0x7F (DEL)利用可能になる。
• Content-Typeの場合: application/x-www-form-urlencoded、multipart/form-data、text/plainのいずれかのMIMEタイプが利用可能になる。
• すべて:値の長さを128以上にすることができる。

覚えておいてもあまり使わなそうですね。ただ他人が書いたコードを読んでいてAccess-Control-Allow-Headersにセーフリクエストヘッダーが入っているのを発見して安易に削除すると挙動が変わってしまうことがあるので注意しましょう。

ワイルドカードによる指定

Access-Control-Allow-HeadersはAccess-Control-Allow-Headers: *のように、ワイルドカードによる指定が可能です。ただ一つ注意があってAuthorizationヘッダはワイルドカードに含まれません。*を使いたいけどさすがにAuthorizationを他サイトに送って欲しくないと言う心配は不要です。むしろ認証トークンの送信にAuthorization以外のカスタムHTTPヘッダーを利用するのは止めた方がいいと言うことですね。