Penso che il problema sia che potresti avere un po 'di incomprensioni sullo scopo di SOP / CORS in primo luogo. Un punto importante che spesso viene perso è che il SOP non ti impedisce di inviare dati a un'origine diversa, ma ti impedisce solo di leggere la risposta dall'origine separata. Dici questo:
First I thought it may be so that an XSS breach into a web app doesn't
allow the attacker to send critical data to himself
E poi chiarire che l'attaccante sarebbe ancora in grado di inviare dati a se stesso abilitando alcune intestazioni CORS sul server ricevente. Tuttavia, anche questo non è necessario. Per le semplici richieste GET e POST, il browser invia invia la richiesta al server di destinazione e quel server sarà in grado di ricevere e agire normalmente senza alcun problema. L'unica cosa che cambierà in seguito al SOP è che il browser rifiuterà di consentire allo script chiamante di ricevere la risposta dal server [** exeception in fondo].
Questa è davvero la chiave. La politica di origine identica riguarda il rifiuto di lasciare che l'origine A legga qualsiasi cosa dall'origine B, a meno che non sia esplicitamente consentito dall'origine B. Ecco perché le intestazioni CORS sono impostate sul server ricevente, non sul server di origine. Se qualcuno visita accidentalmente evil.com , non vogliamo che javascript su quella pagina sia in grado di leggere i dati da facebook.com a meno che facebook.com abbia esplicitamente detto altrimenti.
Ovviamente il caso d'uso principale per questo è con le credenziali di accesso. Il browser allegherà automaticamente i cookie da facebook.com a ogni singola richiesta che esce a facebook.com , anche se il javascript che esegue la richiesta viene eseguito su evil.com . Di conseguenza se il SOP non ha impedito la lettura tra domini, chiunque sarebbe in grado di leggere il tuo profilo Facebook ogni volta che hai visitato qualsiasi pagina che abbia javascript che controlli. L'insistenza del browser sull'invio di cookie con ogni richiesta a un determinato dominio (che è praticamente un requisito per il corretto funzionamento di molte applicazioni Web) è il principale impulso dietro le restrizioni SOP e CORS.
Per un sito Web che non utilizza l'autenticazione CORS è in genere molto meno importante. Dopotutto (come dici tu) la richiesta potrebbe essere semplicemente fatta da un server e la risposta viene inoltrata a qualunque javascript sia in esecuzione nel browser. In tal caso, un sito può persino disabilitare CORS inviando il Access-Control-Allow-Origin: * su tutte le richieste. Nota che se un server lo fa, non può anche impostare il flag Access-Control-Allow-Credentials: true su. I browser non ti consentono di consentire a tutti di leggere i tuoi contenuti e di inviare anche cookie per tutte le richieste.
Tutto ciò che viene ribadito: SOP si basa sul divieto di javascript in esecuzione sull'origine A dalla lettura di qualsiasi cosa dall'origine B. Separa i domini / il protocollo / porta in modo che le persone possano leggere solo le proprie cose ed è uno dei la maggior parte delle protezioni di base inserite nei browser Web.
** Ho detto che SOP / CORS non impedisce al browser di inviare la richiesta. C'è un'eccezione a questa regola. Nel caso di una richiesta "non standard" il browser invierà una richiesta di verifica "pre-volo". In particolare, invierà una richiesta all'endpoint con un metodo di richiesta di "OPZIONI", chiedendo al server che tipo di richieste accetterà. Se la richiesta inviata non corrisponde, il browser non invierà la richiesta in primo luogo.
Modifica per aggiungere
Ovviamente la tua domanda principale è "Ma se non sono coinvolti i cookie, allora perché anche il blocco legge in primo luogo?". Volevo ottenere quello con la mia risposta originale, ma vorrei provare ad affrontarlo più direttamente:
Stai guardando la sicurezza dalla prospettiva sbagliata (in questo caso particolare). Stai effettivamente cercando una ragione per negare l'accesso a un particolare privilegio (ad es. "Perché non posso farlo?"). Un modo molto più robusto per affrontare i problemi di sicurezza è dalla direzione opposta: tutti dovrebbero avere i privilegi minimi di cui hanno bisogno e dovrebbero avere accesso solo se c'è un motivo. Invece di chiedere "Perché non posso farlo?" la domanda migliore è "Perché dovrei lasciarti fare questo?".
Quando lo guardi da quella prospettiva, la politica predefinita del SOP per bloccare tutte le richieste di lettura a meno che non sia esplicitamente autorizzato ha molto più senso ed è fondamentalmente solo la sicurezza standard. Sì, le persone possono aggirare questa fase di sicurezza facendo cose come fare la richiesta tramite un server. Tuttavia, il fatto che una fase di sicurezza possa essere aggirata non significa che sia una cattiva idea. Ci sono molti modi per aggirare la serratura della portiera della tua auto, ma ciò non significa che dovresti semplicemente smettere di bloccare la tua auto. Una buona sicurezza web riguarda la difesa a più livelli: la sicurezza a più livelli, in modo che se si trova un punto debole in un'area, il sistema può essere ancora sicuro. Le restrizioni SOP e read sono fondamentalmente solo il primo livello di sicurezza per le applicazioni Web.