La maggior parte degli sviluppatori incontra CORS la prima volta quando il browser gli urla contro in console. L'obiettivo in quel momento è uno solo: far smettere quell'errore.
E la soluzione arriva subito: Access-Control-Allow-Origin: *. Funziona. Da quel momento CORS diventa mentalmente "quella cosa che si disabilita quando rompe le scatole."
Il problema è che questo schema si ripete. Per anni.
Cos'è CORS e perché continua a fare danni
Cos'è CORS? Cross-Origin Resource Sharing è un meccanismo di sicurezza del browser che controlla quali origini esterne possono fare richieste a un server. Non è un bug del framework, non è un problema del tuo ambiente locale. È una protezione deliberata.
Il guaio è che CORS si manifesta come problema di sviluppo, ma è una misura di sicurezza. Questa dissociazione cognitiva è il vero motivo per cui non si impara: la misura di sicurezza sembra un ostacolo al tuo lavoro, non una protezione per l'utente finale.
Il malinteso più pericoloso: "tanto il server risponde comunque"
Molti non capiscono un dettaglio fondamentale: CORS non protegge il server. Protegge il browser dell'utente.
Il server riceve la richiesta e risponde comunque. È il browser che blocca il risultato. Questo crea una falsa sensazione di innocuità: "se allento CORS non cambia niente, il mio server è lo stesso."
Falso. Il problema vero emerge con cookie e credenziali.
Quando trovi Access-Control-Allow-Credentials: true insieme a una validazione dell'origin fatta male, apri la porta a un attacco concreto: un sito malevolo può fare richieste autenticate per conto dell'utente, senza che l'utente se ne accorga.
Non è teoria. È CSRF amplificato da una misconfiguration CORS.
Perché la vulnerabilità dorme per anni senza che nessuno la veda
La ragione per cui CORS si misconfigura e resta misconfigureto è semplice: le conseguenze non sono immediate e visibili.
Non crasha niente. Non arriva nessun alert. Il sistema continua a funzionare. La vulnerabilità dorme lì finché qualcuno non la trova — e quell'"attivamente" nella maggior parte delle aziende non succede mai.
Nessun monitoring la rileva. Nessuna PR la blocca. Nessun test la copre. Va in produzione silenziosa.
Quanto deve sapere davvero uno sviluppatore su CORS?
Qui vale la pena prendere una posizione.
C'è un dibattito legittimo: ha senso che ogni sviluppatore conosca CORS in profondità teorica, oppure è un virtuosismo da specialista? Non tutti devono sapere tutto. La specializzazione esiste per un motivo.
La risposta onesta è che dipende dal contesto. Ma c'è un livello minimo sotto il quale non si può scendere: capire che CORS è sicurezza, non burocrazia. Capire che Allow-Origin: * con credenziali attive è una porta aperta, non una scorciatoia. Sapere che la validazione dell'origin va fatta sul server, non bypassata.
Non serve un dottorato in HTTP. Serve non trattare una misura di sicurezza come un fastidio da silenziare.
La differenza tra uno sviluppatore che conosce CORS e uno che non lo conosce non si vede nel codice che funziona. Si vede nel codice che non fa danni.