Severamente vietato: chiunque visiti un sito web non deve assolutamente caricare ulteriori dati da server esterni! Ma ci possono essere delle eccezioni. Se entrambi i gestori di siti web concordano sulla cooperazione nulla impedisce un accordo. Il Cross-Origin Resource Sharing (CORS) regolamenta tale cooperazione. Ma come funziona?
La same origin policy (SOP) vieta il ricaricamento da altri server quando si visita un sito web. Tutti i dati devono provenire dalla stessa origine, quindi scaturire dallo stesso server. Questa è una misura di sicurezza in quanto JavaScript e CSS possono caricare contenuti di altri server, anche contenuti dannosi, all’insaputa degli utenti. Tale tentativo di accesso viene definito Cross-origin request. Tuttavia, se entrambi gli operatori del sito web sono a conoscenza dello scambio di dati e anzi lo richiedono, la procedura può essere consentita. Il server interpellato ovvero quello da cui ricaricare i contenuti, consente l’accesso tramite il Cross-Origin Resource Sharing.
Tuttavia ciò accade sempre e solo per determinati client. In altre parole CORS non è un lasciapassare per qualsiasi Cross-origin request. Anzi, il secondo server consente al primo l’accesso esclusivo tramite intestazione HTTP. Nell’intestazione della risposta HTTP è riportato con precisione quali server sono autorizzati a ricaricare i dati e infine a renderli disponibili per l’utente. Soltanto tramite l’integrazione di caratteri jolly è consentita un’autorizzazione generale all’accesso da parte di tutti i client. Tuttavia ciò ha senso soltanto per i server che offrono quelle informazioni che dovrebbero essere disponibili al grande pubblico, ad esempio i font per il web.
L’utente, nel migliore dei casi, non ottiene nulla dallo scambio dei due server interessati. Tutti i browser attuali supportano CORS e l’invio di richieste e risposte avviene in background, in brevissimo tempo, quando viene richiamato un sito web.
In base alla same origin policy, le informazioni sull’origine di una connessione al server sono costituite da tre elementi: host, porta e protocollo. La direttiva impedisce pertanto che nell’esempio sopra riportato ’https://example.com’ acceda a ’http://example.com’ oppure a ’https://example.org’. Nel primo caso il protocollo non è lo stesso, nel secondo i due dettagli relativi all’hostnon sono identici.
Una Cross-origin request è essenzialmente una richiesta HTTP. Alcuni metodi non costituiscono sostanzialmente un problema. GET e HEAD non possono modificare i dati e pertanto non sono generalmente percepiti come una minaccia alla sicurezza. La situazione è diversa per quanto riguarda PATCH, PUT o DELETE, che rendono possibile l’esecuzione di procedure dannose. È quindi necessario attivare in questo caso il Cross-Origin Resource Sharing. CORS può dunque contenere non solo informazioni sull'origine consentita, ma anche informazioni su quali richieste HTTP sono consentite dall’origine.
Nel caso di metodi HTTP inerenti alla sicurezza il client inoltra innanzitutto una preflight request, in cui in realtà si specifica solo quale metodo HTTP verrà poi inviato al server e ci si domanda se la richiesta è considerata sicura. Per questo viene utilizzata l’intestazione OPTIONS. Solo dopo una risposta positiva sarà possibile effettuare la richiesta effettiva.
Esistono diverse intestazioni CORS che si occupano rispettivamente di aspetti diversi. Sono già state citate le due importanti intestazioni per la determinazione di origini sicure e metodi consentiti. Ma ce ne sono altre:
Nel seguente esempio supponiamo che l’host A (example.com) voglia inviare una DELETE request all’host B (example.org). A tal fine il server originale invia prima una preflight request:
/OPTIONS
Origin: http://example.com
Access-Control-Request-Method: DELETESe l’host B non ha problemi con questa Cross-origin request risponde con le intestazioni CORS appropriate:
Access-Control-Allow-Origin: http://example.com
Access-Control-Allow-Methods: PUT, POST, DELETESe le intestazioni nella risposta non corrispondono alle specifiche della richiesta o se il server interpellato non risponde, nessuna Cross-origin request potrà essere eseguita.
In realtà CORS serve a eludere un’impostazione di base intrinsecamente sicura, ovvero la same origin policy. La SOP è anche un mezzo efficace per impedire connessioni potenzialmente pericolose. Tuttavia Internet si basa spesso proprio su tali Cross-origin requests poiché molte connessioni da un host all’altro sono piuttosto desiderate.
CORS offre quindi un percorso intermedio: per le situazioni in cui le Cross-origin requests sono esplicitamente richieste, CORS può creare eccezioni. Esiste tuttavia il rischio che i gestori di siti web utilizzino solo i caratteri jolly per motivi di praticità. Ciò significherebbe negare qualsiasi protezione da parte della SOP. È pertanto importante utilizzare CORS solo in casi speciali selezionati e configurarlo nel modo più restrittivo possibile.
I criminali informatici tentano regolarmente di sfruttare le falle di sicurezza della rete a danno degli utenti. Una tipologia frequente di attacco informatico è rappresentata ad esempio dagli attacchi Cross Site Forgery, abbreviati in CSRF. Senza che l’utente se ne accorga, con questi attacchi vengono effettuati acquisti e bonifici in sua vece. Cosa è possibile fare per contrastare un attacco di...
La same origin policy (SOP) impedisce ai linguaggi di scripting lato client, come JavaScript, di accedere ad oggetti situati su un altro URL, non facente parte dell’applicazione web in esecuzione. Uno strumento pratico per eseguire questa query tra domini è JSONP, variante di JSON. Vi spieghiamo di cosa si tratta esattamente e come funziona questo metodo.
Offri ai tuoi clienti servizi professionali e affidabili con l'hosting di IONOS.
Scopri i pacchetti
Dominio omaggio per un anno