Comprendere e Implementare CORS in NGINX: Una Guida Dettagliata - 🏆 Managed Server

BLOG

15 Settembre 2023

Comprendere e Implementare CORS in NGINX: Una Guida Dettagliata

Scopri cosa sono i CORS a livello di header HTTP e come implementarli in un ambiente NGINX per migliorare la sicurezza e la funzionalità del tuo sito web.

Nel mondo moderno del web, la sicurezza è una delle principali preoccupazioni per gli sviluppatori e gli amministratori di sistema. Una delle funzionalità di sicurezza che spesso viene sottovalutata ma è fondamentale è quella dei CORS, o Cross-Origin Resource Sharing. Questa funzionalità è particolarmente rilevante per le aziende che si occupano di hosting e sistemistica, specialmente quelle che utilizzano server web come NGINX. In questo articolo, esploreremo in dettaglio cosa sono i CORS a livello di header HTTP e a cosa servono, con un focus particolare su come implementarli in un ambiente NGINX.

Cos’è CORS?

CORS, acronimo di “Cross-Origin Resource Sharing” (Condivisione delle Risorse tra Origini Diverse), è un protocollo di sicurezza web implementato nei browser moderni per controllare e gestire le richieste di risorse tra domini web diversi. In termini più semplici, CORS è un insieme di regole e header HTTP che permettono a un sito web di accedere a risorse su un altro sito web senza violare la politica della stessa origine (Same-Origin Policy).

La Politica della Stessa Origine (Same-Origin Policy)

Per comprendere appieno l’importanza dei CORS, è fondamentale capire la politica della stessa origine. Questa è una misura di sicurezza implementata nei browser per limitare le interazioni tra domini diversi. Secondo questa politica, script eseguiti su una pagina web possono accedere solo a risorse provenienti dallo stesso dominio, protocollo e porta da cui è stata caricata la pagina stessa. Ad esempio, se un sito web su http://dominioA.com tenta di fare una richiesta AJAX a http://dominioB.com, la richiesta verrà bloccata a meno che dominioB.com non fornisca le adeguate autorizzazioni CORS.

Tipi di Risorse

CORS è applicabile a una varietà di risorse web, tra cui:

  • File JavaScript
  • Fogli di stile CSS
  • Immagini e video
  • Font
  • API RESTful e dati JSON

Funzionamento dei CORS

Quando una risorsa da un dominio A tenta di accedere a una risorsa su un dominio B, il browser invia una richiesta HTTP al dominio B. Questa richiesta include diversi header CORS, come Origin, che indica da quale dominio proviene la richiesta. Il server su dominio B può quindi rispondere con i propri header CORS, come Access-Control-Allow-Origin, per indicare se la richiesta è autorizzata o meno.

 

Se la richiesta è autorizzata, il browser procede con l’operazione. In caso contrario, il browser blocca la richiesta e solitamente segnala un errore nella console di sviluppo, informando che la richiesta è stata bloccata a causa della politica della stessa origine.

CORS Preflight

In alcuni casi, prima di inviare la richiesta “reale”, il browser invia una richiesta preliminare chiamata “preflight” utilizzando il metodo HTTP OPTIONS. Questo serve per verificare se la richiesta successiva è sicura da effettuare. Il server risponde a questa richiesta preliminare con gli header CORS appropriati, indicando se la richiesta originale è permessa.

CORS è insomma un meccanismo essenziale che permette una maggiore interattività e integrazione tra siti web, pur mantenendo alti standard di sicurezza. Attraverso un insieme di header HTTP e regole ben definite, CORS offre un modo per aggirare in modo sicuro le restrizioni imposte dalla politica della stessa origine, rendendo il web un ambiente più flessibile e sicuro.

Perché è Importante ?

Nell’era moderna del web, le applicazioni sono spesso distribuite su più domini o servizi. Ad esempio, potreste avere un’applicazione front-end ospitata su dominioA.com che interagisce con un back-end API su dominioB.com. In un mondo ideale, vorreste che queste due parti dell’applicazione potessero comunicare liberamente tra loro per fornire un’esperienza utente fluida e funzionale. Tuttavia, la realtà è un po’ più complicata a causa di una misura di sicurezza implementata nei browser chiamata “politica della stessa origine” (Same-Origin Policy).

La politica della stessa origine è stata introdotta per proteggere gli utenti da potenziali attacchi di tipo Cross-Site Request Forgery (CSRF), Cross-Site Scripting (XSS) e altri tipi di vulnerabilità di sicurezza che potrebbero sorgere quando siti web di origine diversa interagiscono tra loro. In pratica, questa politica impedisce a una pagina web di fare richieste ad un altro dominio senza esplicita autorizzazione. Quindi, senza un meccanismo come CORS, il browser bloccherebbe qualsiasi tentativo del front-end su dominioA.com di fare richieste al back-end su dominioB.com.

Questo diventa un problema significativo quando si tratta di applicazioni web moderne che richiedono un alto grado di interattività e funzionalità dinamiche. Ad esempio, se avete un negozio online con un carrello che necessita di verificare la disponibilità di un prodotto in tempo reale, o un’applicazione di social media che deve caricare i post da un server API, la limitazione imposta dalla politica della stessa origine potrebbe rappresentare un ostacolo insormontabile.

Ecco dove entra in gioco CORS. Con CORS, è possibile impostare regole specifiche sul server back-end che permettono al front-end di interagire con esso nonostante siano ospitati su domini diversi. Questo non solo migliora la funzionalità e l’usabilità delle applicazioni web, ma lo fa in un modo che mantiene alte le misure di sicurezza. In altre parole, CORS offre il miglior equilibrio tra sicurezza e funzionalità, permettendo agli sviluppatori di costruire applicazioni web ricche e interattive senza compromettere la sicurezza dell’utente finale.

CORS a Livello di Header HTTP

I CORS funzionano aggiungendo nuovi header HTTP che permettono ai server di descrivere quali origini sono permesse ad accedere alle risorse su un server web. Alcuni degli header CORS più comuni includono:

  • Access-Control-Allow-Origin: Specifica quali origini possono accedere alla risorsa.
  • Access-Control-Allow-Methods: Specifica i metodi HTTP che possono essere usati quando si accede alla risorsa.
  • Access-Control-Allow-Headers: Specifica gli header che possono essere usati quando si effettua una richiesta HTTP.

Implementazione CORS in NGINX

NGINX è uno dei web server più popolari e offre un’elevata flessibilità per configurare le impostazioni CORS. Ecco un esempio di come potete configurare CORS in NGINX:

location /api/ {
if ($request_method = 'OPTIONS') {
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
add_header 'Access-Control-Max-Age' 1728000;
add_header 'Content-Type' 'text/plain; charset=utf-8';
add_header 'Content-Length' 0;
return 204;
}
if ($request_method = 'POST') {
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
}
if ($request_method = 'GET') {
add_header 'Access-Control-Allow-Origin' '*';
add_header 'Access-Control-Allow-Methods' 'GET, POST, OPTIONS';
add_header 'Access-Control-Allow-Headers' 'DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range';
}
}

In questo esempio, abbiamo utilizzato la direttiva location per specificare che le regole CORS si applicano solo alle richieste che puntano alla risorsa /api/. Abbiamo poi utilizzato la variabile $request_method per applicare differenti set di header CORS a seconda del metodo HTTP utilizzato.

Considerazioni di Sicurezza

Mentre l’uso del carattere jolly * nell’header Access-Control-Allow-Origin è conveniente per permettere a qualsiasi origine di accedere alle vostre risorse, è anche una pratica potenzialmente pericolosa dal punto di vista della sicurezza. È consigliabile specificare esplicitamente quali origini sono autorizzate.

Conclusione

I CORS sono un elemento fondamentale per la sicurezza e la funzionalità nel moderno sviluppo web. Essi permettono una comunicazione sicura tra domini diversi, superando le limitazioni imposte dalla politica della stessa origine. L’implementazione di CORS in NGINX è relativamente semplice ma richiede una comprensione dettagliata degli header HTTP e delle potenziali implicazioni per la sicurezza. Speriamo che questo articolo vi abbia fornito le informazioni necessarie per implementare efficacemente e in modo sicuro i CORS nel vostro ambiente NGINX.

Hai dei dubbi? Non sai da dove iniziare? Contattaci !

Abbiamo tutte le risposte alle tue domande per aiutarti nella giusta scelta.

Chatta con noi

Chatta direttamente con il nostro supporto prevendita.

0256569681

Contattaci telefonicamente negli orari d’ufficio 9:30 – 19:30

Contattaci online

Apri una richiesta direttamente nell’area dei contatti.

INFORMAZIONI

Managed Server S.r.l. è un player italiano di riferimento nel fornire soluzioni avanzate di sistemistica GNU/Linux orientate all’alta performance. Con un modello di sottoscrizione dai costi contenuti e prevedibili, ci assicuriamo che i nostri clienti abbiano accesso a tecnologie avanzate nel campo dell’hosting, server dedicati e servizi cloud. Oltre a questo, offriamo consulenza sistemistica su sistemi Linux e manutenzione specializzata in DBMS, IT Security, Cloud e molto altro. Ci distinguiamo per l’expertise in hosting di primari CMS Open Source come WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart e Magento, affiancato da un servizio di supporto e consulenza di alto livello adatto per la Pubblica Amministrazione, PMI, ed aziende di qualsiasi dimensione.

Red Hat, Inc. detiene i diritti su Red Hat®, RHEL®, RedHat Linux®, e CentOS®; AlmaLinux™ è un marchio di AlmaLinux OS Foundation; Rocky Linux® è un marchio registrato di Rocky Linux Foundation; SUSE® è un marchio registrato di SUSE LLC; Canonical Ltd. detiene i diritti su Ubuntu®; Software in the Public Interest, Inc. detiene i diritti su Debian®; Linus Torvalds detiene i diritti su Linux®; FreeBSD® è un marchio registrato di The FreeBSD Foundation; NetBSD® è un marchio registrato di The NetBSD Foundation; OpenBSD® è un marchio registrato di Theo de Raadt. Oracle Corporation detiene i diritti su Oracle®, MySQL®, e MyRocks®; Percona® è un marchio registrato di Percona LLC; MariaDB® è un marchio registrato di MariaDB Corporation Ab; REDIS® è un marchio registrato di Redis Labs Ltd. F5 Networks, Inc. detiene i diritti su NGINX® e NGINX Plus®; Varnish® è un marchio registrato di Varnish Software AB. Adobe Inc. detiene i diritti su Magento®; PrestaShop® è un marchio registrato di PrestaShop SA; OpenCart® è un marchio registrato di OpenCart Limited. Automattic Inc. detiene i diritti su WordPress®, WooCommerce®, e JetPack®; Open Source Matters, Inc. detiene i diritti su Joomla®; Dries Buytaert detiene i diritti su Drupal®. Amazon Web Services, Inc. detiene i diritti su AWS®; Google LLC detiene i diritti su Google Cloud™ e Chrome™; Microsoft Corporation detiene i diritti su Microsoft®, Azure®, e Internet Explorer®; Mozilla Foundation detiene i diritti su Firefox®. Apache® è un marchio registrato di The Apache Software Foundation; PHP® è un marchio registrato del PHP Group. CloudFlare® è un marchio registrato di Cloudflare, Inc.; NETSCOUT® è un marchio registrato di NETSCOUT Systems Inc.; ElasticSearch®, LogStash®, e Kibana® sono marchi registrati di Elastic N.V. Hetzner Online GmbH detiene i diritti su Hetzner®; OVHcloud è un marchio registrato di OVH Groupe SAS; cPanel®, L.L.C. detiene i diritti su cPanel®; Plesk® è un marchio registrato di Plesk International GmbH; Facebook, Inc. detiene i diritti su Facebook®. Questo sito non è affiliato, sponsorizzato o altrimenti associato a nessuna delle entità sopra menzionate e non rappresenta nessuna di queste entità in alcun modo. Tutti i diritti sui marchi e sui nomi di prodotto menzionati sono di proprietà dei rispettivi detentori di copyright. Ogni altro marchio citato appartiene ai propri registranti. MANAGED SERVER® è un marchio registrato a livello europeo da MANAGED SERVER SRL, Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italia.

Torna in alto