CORS Controllore

Comprendere la policy Cross-Origin Resource Sharing (CORS)

Il meccanismo Cross-Origin Resource Sharing (CORS) è un sistema di sicurezza implementato dai browser web per limitare le richieste HTTP cross-origin. Quando uno script in esecuzione su un'origine (definita da schema, host e porta) tenta di richiedere una risorsa a un'altra origine, il browser applica rigide regole di controllo. Questo strumento consente di verificare se una specifica richiesta verrebbe autorizzata o bloccata dal browser analizzando le intestazioni di risposta HTTP fornite.

La valutazione del browser si basa sul confronto tra i dettagli della richiesta (come l'origine del richiedente, il metodo HTTP e le intestazioni personalizzate) e le intestazioni di risposta restituite dal server. Lo strumento analizza questi dati localmente per determinare l'esito della policy.

Funzionamento del controllo e gestione della privacy

Questo strumento esegue l'analisi della policy CORS direttamente all'interno del browser dell'utente. Le intestazioni e i dettagli della richiesta rimangono nel tuo browser. Niente viene caricato o salvato da BroBroGo.

Il processo di verifica non prevede alcuna interazione con server esterni. Lo strumento non contatta il server, non legge URL, non imposta cookie, non controlla DNS o TLS e non modifica le configurazioni del server. L'analisi si basa esclusivamente sui dati inseriti manualmente nei campi di input.

Configurazione degli input e convalida dei dati

Per eseguire la verifica, è necessario configurare i seguenti parametri di input, ciascuno soggetto a specifiche regole di convalida:

• Risposta al controllo: Una scelta tra "Risposta effettiva" (per verificare se il browser può leggere la risposta finale) o "Risposta preliminare" (per verificare la risposta a una richiesta OPTIONS).
• Intestazioni di risposta HTTP: Il testo completo delle intestazioni restituite dal server, con un limite massimo di 200.000 caratteri. Se l'input è vuoto, viene mostrato l'errore "Incolla le intestazioni di risposta HTTP prima del controllo.". Se si supera il limite, compare il messaggio "Questa risposta è insolitamente ampia. Mantienilo sotto i caratteri ‹max›.". Ogni riga deve essere valida; in caso contrario, lo strumento restituisce "La riga ‹line› non è un'intestazione HTTP o una riga di stato valida." oppure "La riga ‹line› contiene un nome di intestazione HTTP non valido.".
• Richiedi origine: L'origine che effettua la richiesta, composta da schema, host e porta opzionale (ad esempio https://app.example.com). Non sono ammessi percorsi URL, parametri di query o credenziali. Se il formato non è corretto, viene visualizzato l'errore "Inserisci un'origine con solo uno schema, un host e una porta opzionale, come https://app.example.com.".
• Metodo richiesto: Il metodo HTTP della richiesta (es. GET, POST). Se il token non è valido, viene mostrato l'errore "Inserisci un token del metodo HTTP valido.". Se si inserisce un metodo non consentito dai browser nelle richieste fetch, viene restituito "I browser non consentono il metodo ‹method› nelle richieste fetch.".
• Nomi di intestazione richiesti: Le intestazioni personalizzate che la richiesta intende includere, separate da virgole o righe. Se un nome non è valido, viene mostrato l'errore ""‹header›" non è un nome di intestazione di richiesta HTTP valido.".
• Includi credenziali: Un selettore attivo per indicare se la richiesta include cookie o autenticazione HTTP.

In caso di errori di configurazione generali, lo strumento segnala il messaggio "Correggi l'input evidenziato e riprova.".

Analisi delle decisioni del browser e regole CORS

Il motore di valutazione applica le specifiche CORS per determinare la decisione del browser, che può corrispondere a uno dei seguenti stati:

• "Incolla una risposta per verificarne la policy CORS." (stato iniziale).
• "Inserisci una risposta e richiedi i dettagli, quindi controlla la policy CORS." (quando mancano i dati).
• "Consentito dalla risposta CORS incollata.".
• "Bloccato dalla risposta CORS incollata.".
• "Le intestazioni passano, ma lo stato del preflight è sconosciuto.".

Regole per l'origine e gestione dei caratteri jolly

L'intestazione Access-Control-Allow-Origin indica quali origini possono accedere alla risorsa.

• Se corrisponde esattamente all'origine della richiesta, viene mostrato "Access-Control-Allow-Origin corrisponde esattamente a ‹origin›.".
• Se l'intestazione contiene il carattere jolly * e la richiesta non include credenziali, viene mostrato "Access-Control-Allow-Origin consente qualsiasi origine per questa richiesta.".
• Se l'intestazione è assente, la decisione è bloccata con il motivo "Manca Access-Control-Allow-Origin.".
• Se l'intestazione contiene più valori o valori separati da virgole, viene considerata non valida, mostrando "Access-Control-Allow-Origin ha un valore non valido: ‹value›.".
• Se l'origine non corrisponde a quella richiesta, viene mostrato "Access-Control-Allow-Origin è ‹actual›, non ‹expected›.".

Impatto delle credenziali sulla policy

Quando la richiesta include credenziali (cookie o autenticazione HTTP), si applicano restrizioni severe:

• L'intestazione Access-Control-Allow-Origin non può utilizzare il carattere jolly *. In questo caso, la richiesta viene bloccata con il motivo "Access-Control-Allow-Origin non può essere * quando sono incluse le credenziali.".
• L'intestazione Access-Control-Allow-Credentials deve essere presente e impostata esattamente su true. Se corretta, viene mostrato "Access-Control-Allow-Credentials è esattamente vero.". Se manca o non è valida, viene mostrato "Una richiesta di credenziali richiede Access-Control-Allow-Credentials: true.".
• Se le credenziali non sono incluse nella richiesta, lo strumento indica che "Le credenziali non sono incluse, quindi Access-Control-Allow-Credentials non influisce su questa decisione.".

Gestione dei metodi e delle intestazioni nelle risposte preliminari (Preflight)

Per le richieste che richiedono un controllo preliminare (preflight tramite metodo OPTIONS), lo strumento verifica lo stato HTTP e le intestazioni di controllo accesso:

• Stato HTTP: Se la risposta preliminare non include una riga di stato HTTP, il risultato è indeterminato e viene mostrato "Non è stata incollata alcuna riga di stato HTTP, quindi non è possibile verificare lo stato di preflight 2xx richiesto.". Se lo stato è presente ed è un codice di successo 2xx, viene mostrato "Lo stato di preflight ‹status› ha avuto esito positivo.". Se lo stato non è un 2xx, viene mostrato "Lo stato di preflight ‹status› non è uno stato 2xx riuscito.".
• Metodi consentiti: Se il metodo richiesto è incluso nell'elenco di sicurezza CORS (CORS-safelisted), non deve apparire in Access-Control-Allow-Methods, mostrando "‹method› è un metodo incluso nell'elenco di sicurezza CORS e non è necessario che venga visualizzato in Access-Control-Allow-Methods.". Se il metodo richiede l'approvazione e questa è presente, viene mostrato "Il preflight consente ‹method›.". Se non è consentito, viene mostrato "Access-Control-Allow-Methods non consente ‹method›.".
• Intestazioni consentite: Se non sono richieste intestazioni particolari, viene mostrato "Nessun nome di intestazione richiesto necessita dell'approvazione preliminare.". Se le intestazioni richieste sono esplicitamente permesse, viene mostrato "Il preflight consente i nomi di intestazione richiesti: ‹headers›.".
• Uso dei caratteri jolly per le intestazioni: Se la richiesta non include credenziali, l'uso di Access-Control-Allow-Headers: * copre tutte le intestazioni richieste, mostrando "Access-Control-Allow-Headers: * copre questi nomi per una richiesta senza credenziali: ‹headers›.". Tuttavia, l'intestazione Authorization rappresenta un'eccezione: deve essere sempre elencata esplicitamente. Se si tenta di coprirla con un carattere jolly, la richiesta viene bloccata con il motivo "Authorization deve essere elencato in modo esplicito; Access-Control-Allow-Headers: * non lo copre.". Se le intestazioni richieste non sono permesse, viene mostrato "Access-Control-Allow-Headers non consente: ‹headers›.".

Limitazioni del controllo statico

Un risultato positivo all'interno dello strumento indica esclusivamente che le intestazioni fornite e i dettagli inseriti sono conformi alle regole CORS del browser. Questo controllo non garantisce che una richiesta live funzioni in un ambiente reale. Fattori esterni quali reindirizzamenti di rete, risposte memorizzate nella cache del browser, modifiche dinamiche delle regole del server, estensioni del browser attive o la risposta effettiva restituita dopo la fase di preflight possono modificare il comportamento del browser durante l'esecuzione della richiesta reale.

Domande frequenti (FAQ)

Devo incollare la risposta effettiva o la risposta di preflight?

Utilizza Risposta effettiva per verificare se il codice del browser può leggere una risposta. Utilizza la risposta preflight per la risposta OPTIONS che approva un metodo successivo e i nomi delle intestazioni richieste.

Perché un carattere jolly può fallire con le credenziali?

Quando sono inclusi i cookie o l'autenticazione HTTP, l'origine consentita deve corrispondere esattamente all'origine richiedente. Anche i caratteri jolly per i metodi e le intestazioni consentiti perdono il loro significato.

Un risultato positivo dimostra che la richiesta live funzionerà?

No. Questo risultato copre solo la risposta incollata e i dettagli della richiesta inseriti qui. Reindirizzamenti, risposte memorizzate nella cache, modifica delle regole del server, estensioni del browser e la risposta effettiva dopo un preflight possono comunque modificare il risultato.