CORS serve solo a impedire la cross-origine lettura all'interno del browser .
Prima che CORS fosse implementato nei browser, le richieste semplici (ad esempio caricamento del modulo, immagine di incorporamento ecc.) potevano fare richieste di origine incrociata (e quindi anche attacchi CSRF ) potrebbe visualizzare la risposta all'interno del browser ma non può accedere alla risposta dall'interno di JavaScript. E XMLHTTPRequest e simili erano limitati all'accesso solo alla stessa origine, ma potevano leggere la risposta all'interno di JavaScript quando eseguivano una richiesta di origine identica (Same-Origin-Policy).
CORS si occupa principalmente di quest'ultima restrizione: se il server consente esplicitamente l'accesso tra le origini, allora XHR di origine incrociata consentirà sia di inviare una richiesta sia di leggere la risposta da JavaScript (come solo con la stessa origine prima di ). E il browser può includere cookie esistenti e simili quando si effettua tale richiesta cross-site e quindi eseguire letture incrociate all'interno di una sessione precedentemente autenticata.
Ma cosa significa questo per le applicazioni esterne al browser: poiché non ci si aspetta che queste vengano utilizzate come vettore di attacco per la lettura cross-site, in primo luogo sono irrilevanti nel contesto di CORS. Naturalmente, se un'applicazione di questo tipo implementa effettivamente un comportamento simile a un browser e supporta effettivamente richieste cross-site autenticate, dovrebbe anche implementare le protezioni rilevanti dei browser, ad esempio Same-Origin-Policy e CORS.
Si noti che CORS non sostituisce l'autenticazione. Un server deve ancora implementare l'autenticazione corretta per limitare il tipo di dati che gli utenti possono recuperare. Con CORS, tuttavia, è possibile effettuare una richiesta cross-site che utilizza l'autenticazione esistente per recuperare il contenuto protetto sul sito, ma solo se consentito dalla politica CORS.