Inizia separando due cose cambiate insieme: il percorso di rete e l’applicazione del browser. Una VPN cambia l’indirizzo di uscita; non cambia l’origine della pagina, composta da schema, host e porta. Se la richiesta ora riesce, qualcosa nella risposta è cambiato, oppure è cambiata la richiesta stessa. Stabilire quale delle due è tutta l’indagine.

CORS è un protocollo di intestazioni applicato dal browser, quindi nulla sul percorso di rete può disattivarlo.

L’origine non è un indirizzo IP

Un’origine è uno schema, un host e una porta. Non è l’indirizzo da cui partono i pacchetti e non è l’IP che vede il server. Per questo una VPN può cambiare ogni indirizzo osservabile e lasciare l’origine identica. Il browser confronta l’Access-Control-Allow-Origin della risposta con l’origine della pagina, e l’indirizzo di uscita non entra mai in quel confronto.

Quindi un’estensione o un proxy che sembra correggere un errore CORS fa altro: riscrive intestazioni oppure instrada la richiesta in modo che non sia più cross-origin. Nessuna delle due è una proprietà della VPN.

Cosa invia davvero il browser

Per una richiesta cross-origin non semplice, il browser invia prima una pre-verifica OPTIONS, che porta il metodo e le intestazioni previsti. Il server deve rispondere con i permessi che concede, e la richiesta reale segue solo se quella risposta rispetta le regole. Una VPN cambia il percorso che trasporta entrambi gli scambi e può cambiare ciò che rispondono i servizi intermedi. Non cambia la stringa dell’origine né il requisito della pre-verifica.

Un client da riga di comando di solito non mostra nulla di tutto ciò. Potrebbe non inviare l’intestazione Origin, spesso salta la pre-verifica e può portare credenziali diverse. Un corpo restituito a curl dimostra che il server ha risposto a curl.

Trova la risposta che è cambiata

Confronta la risposta reale su ogni percorso, non solo il codice di stato. Guarda le intestazioni che portano i permessi CORS, il tipo di contenuto, ogni reindirizzamento e se una variante WAF o CDN ha prodotto una pagina diversa. Un rifiuto regionale, un reindirizzamento di autenticazione o una pagina di errore senza l’intestazione di permesso falliscono nel browser pur sembrando un bug CORS. Sono differenze del percorso di consegna, e sono ciò che va documentato.

Cattura le intestazioni di risposta dei due percorsi e confrontale riga per riga. Se l’unica differenza è l’assenza di Access-Control-Allow-Origin su una pagina di errore, hai trovato la causa.

Correggi il servizio, non l’applicazione

Quando il servizio è tuo, dichiara esplicitamente le origini consentite e le funzionalità della richiesta, poi leggi gli errori che il suo frontend e i suoi intermediari producono. Se non lo fai, invia al proprietario del servizio un confronto ripulito. Non includere mai cookie, intestazioni di autorizzazione o esportazioni di sessione in quel rapporto, perché sono le credenziali che la politica esiste per proteggere.

Evita le estensioni del browser che disattivano CORS. Cambiano il confine di sicurezza mentre nascondono la differenza di risposta che andava spiegata, e lasciano lo stesso guasto per tutti gli altri utenti.

Registra entrambe le risposte, l’origine usata e il percorso seguito. Quel verbale trasforma una voce sulla VPN in un bug del servizio.

Articoli correlati