Why CORS preflight is not available for POST requests when Content-Type is application/x-www-form-urlencoded

Question

In oauth2 for single page application(SPA), we can revoke the access tokens of the implicit grant type by using an ajax request(this is not recommended now). I tried to do a request like below from such a SPA to an identity server in another domain. I wasn't getting blocked due to the CORS.

<script>
function revokeToken() {
var params= 'token='+ getAcceesToken() + '&token_type_hint=access_token&client_id=' + getClientID();

request = new XMLHttpRequest();
request.open('POST', getRevokeURL(), true);
request.setRequestHeader("Content-type", "application/x-www-form-urlencoded");

request.onreadystatechange = function() {//Call a function when the state changes.
    if(request.readyState == 4 && request.status == 200) {
        alert(request.responseText);
    }
}
request.send(params);
}
</script>

As I went through the docs in [1], it says that some requests don’t trigger a CORS preflight, this includes POST requests with Content-Type application/x-www-form-urlencoded as well.

I think there is a security risk due to such exemption. Even I was able to successfully do the revocation with chrome as well. Why are browsers allowing such cases?

CORS preflight triggered only when I changed the content type to application/json

[1] https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS

Answer 1

So my understanding of why this is allowed is so that the implementation of CORS wouldn't break existing and well understood functionality which was already allowed by browsers. This also means that preflights aren't required for text/plain and multipart/form-data in addition to application/x-www-form-urlencoded

These are referred to as "simple requests" and must be GET, HEAD, or POST and there are restrictions which headers can be set in addition to the Content-Type header.

The mozilla.org documentation on these notes:

These are the same kinds of cross-site requests that web content can already issue, and no response data is released to the requester unless the server sends an appropriate header. Therefore, sites that prevent cross-site request forgery have nothing new to fear from HTTP access control.

You can read the documentation here: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS