Keep in mind this is only true for requests that don't require a preflight check.

This also means if you rely on CORS to prevent XSRF attacks (which is maybe not the best idea), you must be ensuring that any request that came in would have been preflighted (for example, reject requests unless they have a special header)

However, the preflight check is sufficient to check latency :)

"Preflight check" is such a wrong analogy, since with CORS you fly all the way to the destination to check if you're allowed to fly to the destination.

It’s more of a cargo check, you fly all the way there to see if they’ll let you take some cargo back with you

*cargo isn’t really the right analogy… but close enough

Customs check basically. If you aren't allowed to bring something into the country you land in, they simply confiscate it when you get there. (And I'm sure arrest you and make you miserable because ... that's what justice is I guess.)

Depends on the destination country and on exactly what it was you were trying to bring in with you.

Nah, the whole thing is just a "Can I ask you a question?" implemented in code.

That is a good point. I presume this site uses GETs just for simplicity but haven’t checked.

addendum: one can rarely state anything entirely accurate about CORS briefly.

This is true. I’ve never seen an article or comment about CORS where someone didn’t disagree or add some major missing caveat. It’s never just a bunch of head nodding or “duh of course” responses.

I think CORS first sends an HTTP OPTIONS request. The headers received in the response dictate if the actual POST/PUT/GET/etc is sent to the server in a subsequent request.

That's only if you have headers outside a default-allowed list set.

This isn't true in general. For many requests, an OPTIONS request is sent first. If the OPTIONS request contains permissive CORS headers, then the normal request proceeds. See: https://developer.mozilla.org/en-US/docs/Glossary/Preflight_...