Perché il preflight CORS non è disponibile per le richieste POST quando Content-Type è application / x-www-form-urlencoded

2

In oauth2 per l'applicazione a singola pagina (SPA), possiamo revocare i token di accesso del tipo di concessione implicita utilizzando una richiesta Ajax (questo non è raccomandato ora). Ho provato a fare una richiesta come di seguito da un tale SPA a un server di identità in un altro dominio. Non mi sono bloccato a causa del 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>

Mentre esaminavo i documenti in [1], si dice che alcune richieste non attivano un preflight CORS, questo include anche le richieste POST con Content-Type application / x-www-form-urlencoded.

Penso che ci sia un rischio per la sicurezza a causa di tale esenzione. Anche io sono stato in grado di eseguire correttamente la revoca con Chrome. Perché i browser consentono tali casi?

Il preflight CORS è stato attivato solo quando ho cambiato il tipo di contenuto in application / json

[1] link

    
posta Prakhash 08.06.2018 - 09:35
fonte

1 risposta

4

Quindi la mia comprensione del motivo per cui questo è permesso è che l'implementazione di CORS non romperebbe le funzionalità esistenti e ben comprese che erano già consentite dai browser. Ciò significa anche che i preflights non sono richiesti per text/plain e multipart/form-data oltre a application/x-www-form-urlencoded

Queste sono chiamate "richieste semplici" e devono essere GET , HEAD o POST e vi sono restrizioni a cui è possibile impostare le intestazioni oltre all'intestazione Content-Type .

La documentazione di mozilla.org su queste note:

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.

Puoi leggere la documentazione qui: link

    
risposta data 08.06.2018 - 10:06
fonte

Leggi altre domande sui tag