问题
I'm trying to avoid0 CORS preflight requests for authorized GET requests, for latency performance reasons. The simple way to do that is putting the access token in a URL query parameter, but this is a bad security practice1.
According to this answer2, the goal of browsers is to block anything that couldn't already be accomplished with HTML tags like img or script. But if that's the case, why is it allowed to set headers like Accept or Content-Langage? You can't set those on an img tag. Also, what's preventing me from hiding my access token in the Accept header like this:
Accept: */*, x-access-token/<access_token>
It seems like the browser policies in this case don't add extra protection, and encourage developers to use insecure practices or nasty hacks. What am I missing?
回答1:
What's the question?
FYI: You don't actually have a singular question that can be answered. You've got, like, a million.
Your title asks a rather philosophical unanswerable question, but your post is asking for a solution to a use case.
Why do browsers allow setting some headers without CORS, but not others?
Personal / team bias. Politics. Religion.
It seems like the browser policies in this case don't add extra protection, and encourage developers to use insecure practices or nasty hacks. What am I missing?
It's called "Security Theater".
It's when people who know better make a political choice that appears to be so easy (or so difficult) to understand to those who don't have the knowledge to understand such things (or don't have to implement them) just accept it, so that they can get on with their lives - or in the case of Verisign, VPNs, and others - to make a profit.
why is it allowed to set headers like Accept or Content-Langage?
Those are benign headers that don't carry anything particularly identifiable or sensitive
Trying to avoid pre-flights with access tokens
The simple way to do that is putting the access token in a URL query parameter, but this is a bad security practice.
Yes and no.
If it's the session token and it lasts 90 days... sure, there are some downsides... assuming that you're either not using https (which IS bad) or that the attacker already has access to the user's machine (via code or otherwise)... in which case the attacker has access to their email to reset all of their passwords and logins, and probably their MFA (i.e. iMessage / Authy / LastPass) as well so... meh
If it's a short-lived ("short" meaning, say 15 minute) token on non-sensitive data (i.e. social media junk), who cares?
You could also make a single-use token which, assuming you don't put sensitive info in the token itself, would make everyone happy.
Dirty thoughts
Have you considered putting up a single endpoint that can proxy the requests? That's what all the kids are doing these days (looking at you GraphQL).
And if you try hard enough, iframes always have some way to be abused to solve your problem. They're the WD-40 (or duct-tape) of the web. Search your feelings... you know it to be true.
来源：https://stackoverflow.com/questions/61563348/why-do-browsers-allow-setting-some-headers-without-cors-but-not-others-trying