Che cos'è CORS (Cross-Origin Resource Sharing)?

CORS è un meccanismo del browser con cui un server dichiara quali altre origin possono chiamarlo, allentando di proposito la same-origin policy. Due riformulazioni dissolvono quasi tutta la confusione: è il browser a imporlo (non il server, ed è per questo che curl funziona), ed è il server a correggerlo (non il frontend, ed è per questo che nessuna quantità di JavaScript cambia le cose). Tutto il resto sono header.

Punti chiave

Tutto il protocollo, sul filo

# Preflight: il browser chiede prima di un PUT con un header di autenticazione
OPTIONS /classes/Product HTTP/1.1
Origin: https://app.example.com
Access-Control-Request-Method: PUT
Access-Control-Request-Headers: x-parse-session-token

# Il permesso rilasciato dal server
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://app.example.com   ← questa origin può leggere
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: x-parse-session-token
Access-Control-Max-Age: 7200         ← risposta in cache; nessun preflight ripetuto

# Allora, e solo allora, parte la richiesta vera.

Come si presenta dal codice applicativo – e la verità di piattaforma che insegnano le schede: CORS è una questione di browser, che le app native non incontrano mai:

// Browser JavaScript — Back4app JS SDK
// A cross-origin call that just works: the platform answers the
// preflight and sends the CORS headers, so the browser lets it through
Parse.initialize('APP_ID', 'JS_KEY');
Parse.serverURL = 'https://parseapi.back4app.com'; // different origin than your site

const products = await new Parse.Query('Product').find();
// No proxy hacks, no "disable CORS" — the server side is configured correctly.

// Flutter / Dart — Back4app Flutter SDK
// Native apps have no same-origin policy — CORS is a browser concern.
// Flutter Web, however, DOES enforce it: same browser rules apply there.
final query = QueryBuilder<ParseObject>(ParseObject('Product'));
final response = await query.query();
// Works identically on mobile and web because the server sends CORS headers.

// iOS / Swift — Back4app Swift SDK
// No browser, no same-origin policy: CORS never applies to native iOS.
// The same backend serves browsers (with CORS headers) and apps alike.
let query = Product.query()
query.find { result in
  if case .success(let products) = result { render(products) }
}

// Android / Kotlin — Back4app Android SDK
// No browser, no same-origin policy: CORS never applies to native Android.
// The same backend serves browsers (with CORS headers) and apps alike.
val query = ParseQuery.getQuery<ParseObject>("Product")
query.findInBackground { products, e ->
  if (e == null) render(products)
}

Il flusso, deciso

Due dettagli reggono la maggior parte delle sessioni di debug: una richiesta semplice (GET/HEAD/POST con header della safelist e content type basilari) salta il preflight – ed è per questo che aggiungere un header Authorization all’improvviso “rompe” un endpoint che funzionava; e le richieste con credentials stringono tutto – i cookie circolano solo con Access-Control-Allow-Credentials: true più un’origin esatta, mai il wildcard, secondo la specifica.

Come correggere gli errori CORS più comuni (errore → causa → correzione)

E l’anti-correzione che vale la pena nominare: disattivare CORS con un flag del browser o passare da proxy di sviluppo permissivi rende l’errore invisibile solo su una macchina – il deployment resta rotto per gli utenti. La correzione vera è una configurazione del server che si misura in minuti.

Casi d’uso tipici

• SPA + API su origin diverse – app.example.com che chiama api.example.com: il caso quotidiano per cui CORS esiste.
• Sviluppo locale – localhost:3000 contro un backend reale; conviene consentire l’origin di sviluppo, non disattivare lo scudo.
• API pubbliche – origin wildcard, senza credentials: corretto e sicuro per dati davvero pubblici.
• Piattaforme multi-frontend – più app, un solo backend, un elenco esplicito di origin per ambiente.
• Backend BaaS – la piattaforma risponde ai preflight e invia gli header; resta soltanto da dichiarare le origin consentite.

Wildcard vs. origin esplicite: matrice decisionale

Una riformulazione di sicurezza chiude la matrice: CORS non è controllo degli accessi – le app native e i server lo ignorano del tutto, quindi protegge gli utenti del browser dai siti malevoli, non l’API da chi la chiama. Quel lavoro lo fanno l’autenticazione e i permessi al livello dei dati; CORS decide soltanto quali script di quali siti possono leggere le risposte.

Limiti e trade-off

• Governa soltanto i browser. Tutto ciò che non è un browser gli passa davanti – un elenco di origin non va mai confuso con un’autorizzazione.
• I preflight costano un round trip sulle richieste non semplici; la messa in cache via Access-Control-Max-Age è la correzione a basso costo che tutti dimenticano.
• Una configurazione sbagliata fallisce chiusa e in modo rumoroso – bene per la sicurezza, brutale per il debug senza la tabella errore→correzione qui sopra.
• Gli elenchi di origin sono stato dell’ambiente. Le origin di staging si infilano nelle configurazioni di produzione; l’elenco va verificato come qualsiasi credenziale.
• CORS ≠ CSRF ≠ CSP. Acronimi vicini, difese distinte – i cookie hanno comunque bisogno di protezione SameSite o a token, e le pagine di una content policy, mentre CORS gestisce soltanto la lettura cross-origin.

CORS su Back4app

Back4app è una piattaforma open-source di Backend as a Service (BaaS) che combina database gestito, API REST e GraphQL generate automaticamente, autenticazione, archiviazione di file e funzioni serverless con Cloud Code. La scocciatura CORS arriva già risolta: le API della piattaforma rispondono ai preflight e inviano gli header corretti, così le app nel browser chiamano il backend dalle origin consentite senza trucchi con i proxy – la scheda JavaScript qui sopra è tutta l’esperienza – mentre le schede Flutter, Swift e Kotlin dimostrano la verità più discreta: i client nativi non incontrano mai la cerimonia. La sicurezza vera resta dove deve stare: sessioni, ACL e permessi di classe applicati lato server a ogni richiesta, da qualunque origin.