Verifica header CORS

Incolli un blocco di header per confermare la presenza di Access-Control-Allow-Origin, rilevare la combinazione non sicura tra origine jolly e credenziali e individuare l’assenza di Vary: Origin quando è consentita un’origine specifica. Il risultato è deterministico e spiega ogni rilievo; è quindi utile per revisioni dei rilasci, analisi degli incidenti, controlli automatici e normale consolidamento delle API, senza inviare richieste al server di destinazione.

Legga il risultato come una verifica mirata

Inizi copiando gli header di risposta esattamente come sono stati ricevuti dal browser o dal client a riga di comando, con una coppia Nome: valore per riga. I nomi vengono confrontati senza distinzione tra maiuscole e minuscole e i valori Vary separati da virgole sono trattati come token distinti. Il controllo richiede Access-Control-Allow-Origin perché senza questo header non esiste una politica CORS di risposta da esaminare; la sua assenza produce quindi un errore di input, non un rapporto inconcludente. Un rapporto riuscito restituisce l’origine consentita normalizzata, indica se le credenziali sono abilitate, precisa se la risposta varia in base a Origin e presenta un elenco ordinato dei rilievi. Il campo valid segnala che non sono stati rilevati problemi con gravità di errore. Può comunque essere presente un avviso: i sistemi che consumano il risultato devono controllare anche issue_count e issues. Questo perimetro ristretto è intenzionale: offre informazioni stabili su due errori comuni senza pretendere di certificare l’intero modello di autorizzazione dell’applicazione. Se il controllo fa parte di una verifica formale, conservi insieme al risultato la risposta originale e l’origine della richiesta.

Comprenda origini jolly e richieste con credenziali

Access-Control-Allow-Origin: * è adatto a risorse realmente pubbliche e prive di credenziali, perché consente a qualsiasi origine richiedente di leggere la risposta. Non deve essere abbinato ad Access-Control-Allow-Credentials: true. I browser rifiutano questa combinazione nell’accesso CORS con credenziali e la configurazione spesso indica che il confine di fiducia previsto dal server non è stato espresso correttamente. Lo strumento registra il caso come wildcard_origin_with_credentials con gravità di errore. La soluzione non consiste nel riflettere automaticamente ogni Origin ricevuto. Stabilisca quali origini sono affidabili, confronti l’Origin della richiesta con una lista esplicita e restituisca una sola origine approvata dopo una corrispondenza. Se cookie o altre credenziali ambientali non sono necessari, disabiliti le credenziali e mantenga la politica pubblica con jolly. Ricordi inoltre che CORS controlla se gli script del browser possono leggere una risposta; non equivale ad autenticazione, autorizzazione, protezione dalla falsificazione delle richieste o firewall. Verifichi separatamente attributi dei cookie, controlli di autorizzazione, metodi, header esposti e comportamento delle richieste preflight prima di considerare sicuro l’endpoint.

Usi Vary: Origin per proteggere le cache condivise

Quando un server sceglie un valore specifico di Access-Control-Allow-Origin in funzione dell’Origin della richiesta, la rappresentazione della risposta dipende di fatto da quell’header. Vary: Origin comunica a browser, proxy inversi e reti di distribuzione che le risposte prodotte per origini diverse non sono intercambiabili. In sua assenza, una cache può riutilizzare per un’altra richiesta una risposta contenente l’origine consentita di un tenant, causando errori intermittenti e indebolendo potenzialmente le premesse della politica sui contenuti memorizzati. Lo strumento genera quindi missing_vary_origin quando l’origine consentita è specifica e Vary non contiene né Origin né il token jolly. Accetta Origin in una riga Vary con valori separati da virgole e in header Vary ripetuti. Il rilievo è un avviso perché una risposta incollata non rivela se il valore dell’origine sia costante per tutte le richieste o se la cache sia disabilitata altrove. Verifichi la reale logica di selezione del server e le direttive di cache prima di modificare la produzione. Se l’origine viene riflessa dinamicamente dopo la verifica su una lista consentita, aggiungere Origin a Vary è in genere il segnale più chiaro e sicuro.