Por qué la verificación previa de CORS no está disponible para solicitudes POST cuando Content-Type es application / x-www-form-urlencoded

2

En oauth2 para la aplicación de una sola página (SPA), podemos revocar los tokens de acceso del tipo de concesión implícita utilizando una solicitud ajax (esto no se recomienda ahora). Intenté hacer una solicitud como la siguiente desde un SPA a un servidor de identidad en otro dominio. No me estaban bloqueando debido al 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>

Cuando revisé los documentos en [1], dice que algunas solicitudes no activan una verificación previa de CORS, esto incluye solicitudes POST con la aplicación Content-Type / x-www-form-urlencoded también.

Creo que existe un riesgo de seguridad debido a dicha exención. Incluso pude hacer con éxito la revocación con Chrome también. ¿Por qué los navegadores permiten estos casos?

La verificación previa de CORS se activó solo cuando cambié el tipo de contenido a application / json

[1] enlace

    
pregunta Prakhash 08.06.2018 - 09:35
fuente

1 respuesta

4

Por lo tanto, mi comprensión de por qué se permite esto es para que la implementación de CORS no rompa la funcionalidad existente y bien entendida que ya estaba permitida por los navegadores. Esto también significa que no se requieren preflights para text/plain y multipart/form-data además de application/x-www-form-urlencoded

Estas se denominan "solicitudes simples" y deben ser GET , HEAD o POST y existen restricciones que los encabezados se pueden establecer además del encabezado Content-Type .

La documentación de mozilla.org en estas notas:

  

Estos son los mismos tipos de solicitudes entre sitios que el contenido web ya puede emitir, y no se liberan datos de respuesta al solicitante a menos que el servidor envíe un encabezado apropiado. Por lo tanto, los sitios que evitan la falsificación de solicitudes entre sitios no tienen nada nuevo que temer del control de acceso HTTP.

Puede leer la documentación aquí: enlace

    
respondido por el GreatSeaSpider 08.06.2018 - 10:06
fuente

Lea otras preguntas en las etiquetas