ブラウザーがCORSなしで一部のヘッダーを設定できるが、他のヘッダーを設定できないのはなぜですか？プリフライトを回避しようとしています
待機中のパフォーマンス上の理由から、許可されたGETリクエストに対するCORSプリフライトリクエストを回避しようとしています。これを行う簡単な方法は、URLクエリパラメータにアクセストークンを配置することですが、これはセキュリティの習慣として不適切です 1 。
この回答によれば、 2 によると、ブラウザの目標は、imgやscriptなどのHTMLタグでは実現できなかったものをブロックすることです。しかし、その場合、AcceptやContent-Langageなどのヘッダーを設定できるのはなぜですか？これらをimgタグに設定することはできません。また、次のようにAcceptヘッダーでアクセストークンを非表示にできない理由：
Accept: */*, x-access-token/<access_token>
この場合のブラウザポリシーは追加の保護を追加するものではなく、開発者に安全でない方法や厄介なハッキングを使用するように勧めています。何が欠けていますか？
質問はなんですか？
参考までに：あなたは実際に答えることができる単一の質問を持っていません。あなたは100万を持っています.
タイトルはかなり哲学的で答えられない質問をしますが、投稿はユースケースの解決策を求めています。
ブラウザーがCORSなしで一部のヘッダーの設定を許可し、他のヘッダーを許可しないのはなぜですか？
個人/チームの偏見。政治。宗教。
この場合のブラウザポリシーは追加の保護を追加するものではなく、開発者に安全でない方法や厄介なハッキングを使用するように勧めています。何が欠けていますか？
「セキュリティシアター」と呼ばれています。
それは、そのようなことを理解する知識を持っていない（またはそれらを実装する必要がない）人々が理解するのが非常に簡単（または非常に難しい）と思われる政治的選択を、よりよく知っている人が受け入れる場合、彼らが自分たちの生活を続けることができるように-またはベリサイン、VPN、その他の場合-利益を上げるために。
acceptやContent-Langageなどのヘッダーを設定できるのはなぜですか？
これらは、特に識別可能な情報や機密情報を含まない無害なヘッダーです
アクセストークンによるプリフライトを回避しようとしています
これを行う簡単な方法は、URLクエリパラメータにアクセストークンを配置することですが、これはセキュリティ上の問題です。
はいといいえ。
それがセッショントークンであり、90日間続く場合...確かに、いくつかの欠点があります... https（IS bad））を使用していないか、または攻撃者alreadyはユーザーのマシンに（コードなどを介して）アクセスできます...この場合、攻撃者は自分の電子メールにアクセスしてすべてのパスワードをリセットし、ログイン、そしておそらくそれらのMFA（すなわちiMessage/Authy/LastPass）もそうです... meh
機密性の低いデータ（ソーシャルメディアジャンクなど）の有効期間が短い（ "短い"意味、たとえば15分）トークンの場合、誰が気にかけますか？
single-useトークンを作成することもできます。これは、トークン自体に機密情報を入れないことを前提として、全員を幸せにします。
汚い考え
リクエストをプロキシできる単一のエンドポイントを設置することを検討しましたか？これが、最近すべての子供たちが行っていることです（GraphQLを見てください）。
そして、十分に努力すれば、iframesには常に問題を解決するために悪用される方法がいくつかあります。それらはウェブのWD-40（またはダクトテープ）です。 あなたの気持ちを検索してください...あなたはそれが本当であることを知っています。