Find out whether a browser would let your code read an API response, and exactly which check blocks it. Real preflight and request diagnostics, not a header dump.
Un'origine per riga, fino a dieci. Utile per verificare che locale, staging e produzione siano tutte nell'allowlist. I risultati compaiono come tabella nella scheda Intestazioni.
Queste richieste vengono inviate dai server POLPROG all'endpoint che indichi, perché un browser non può eseguire questa diagnosi su se stesso: sarebbe CORS a bloccarla. Nessun tuo cookie viene inoltrato, non viene mai inviato alcun corpo della richiesta, i corpi delle risposte vengono scartati e nulla viene conservato una volta che il report ti è arrivato.
Una regola del browser, non del server. Quando JavaScript su un'origine chiede una risorsa su un'altra, il browser invia la richiesta ma si rifiuta di consegnare la risposta al tuo codice, a meno che il server non dichiari, nelle proprie intestazioni di risposta, che l'origine richiedente può leggerla. Cross-Origin Resource Sharing è l'insieme di intestazioni con cui lo si dichiara.
Se una richiesta funziona in curl, Postman, Insomnia o dal tuo backend, questo non dice nulla sul fatto che il JavaScript del browser possa leggerla. Quei client non applicano alcuna regola CORS. Di solito il server si comporta in modo identico nei due casi; la differenza sta tutta in ciò che il chiamante fa della risposta.
Per tutto ciò che non è una richiesta semplicissima, il browser invia prima una richiesta OPTIONS per chiedere se quella reale è permessa. Porta con sé Origin, Access-Control-Request-Method e, se serve, Access-Control-Request-Headers. Se la risposta non permette la richiesta, quella reale non viene mai inviata, quindi l'endpoint non la vede mai e nei log del tuo server non compare nulla.
Una richiesta è semplice solo quando il suo metodo è GET, HEAD o POST e ogni intestazione che imposta è nella safelist CORS: Accept, Accept-Language, Content-Language, Content-Type e Range. Conta anche il valore. Content-Type resta nella safelist solo per application/x-www-form-urlencoded, multipart/form-data e text/plain.
Non è tra i tre content type nella safelist. È tutta qui la ragione. Una POST con un corpo JSON è una richiesta con preflight, ed è per questo che aggiungere un'API JSON a una pagina esistente produce all'improvviso una richiesta OPTIONS che nessuno ha scritto, ed errori da una rotta che gestisce solo POST.
O una singola origine o *. Mai un elenco, mai un valore con un percorso, mai una wildcard dentro un nome host. Il confronto con l'origine richiedente è esatto, quindi una barra finale, una porta predefinita scritta per esteso, o http dove la richiesta ha usato https, faranno fallire tutto pur sembrando identici all'occhio di una persona.
Necessaria quando la richiesta invia cookie o autenticazione HTTP. L'unico valore accettato è la stringa minuscola esatta true. Una richiesta con credenziali non può inoltre essere soddisfatta da Access-Control-Allow-Origin: *, e per la stessa richiesta un asterisco in Allow-Methods, Allow-Headers o Expose-Headers smette di essere una wildcard e diventa un nome letterale.
Se il server sceglie il valore di Allow-Origin a partire dalla richiesta in arrivo, la risposta dipende dall'intestazione Origin, e va comunicato a qualsiasi cache condivisa. Senza Vary: Origin un CDN o un reverse proxy può conservare una risposta che indica un'origine e servirla a un'altra, e le richieste falliscono per motivi che nell'applicazione non compaiono mai.
Una risposta cross-origin espone allo script solo sette intestazioni: Cache-Control, Content-Language, Content-Length, Content-Type, Expires, Last-Modified e Pragma. Tutto il resto, comprese le tue intestazioni X- e Location, viene letto come null a meno che non sia indicato in Access-Control-Expose-Headers. Quell'intestazione riguarda la risposta e non ha nulla a che vedere con Allow-Headers, che riguarda la richiesta.
Decide quali origini possono leggere una risposta in un browser. Non decide chi può chiamare un endpoint, non concede alcun permesso e non ferma il cross-site request forgery: un attacco CSRF non ha bisogno di leggere la risposta, quindi una policy CORS severa lo lascia intatto. Mantieni autenticazione, autorizzazione e token CSRF esattamente com'erano.
Ogni verdetto riportato qui deriva da uno scambio reale con l'endpoint che hai indicato, valutato secondo le regole del Fetch standard che un browser applica. Descrive l'endpoint così come ha risposto all'infrastruttura POLPROG in quel momento: un server che varia la propria risposta in base alla rete, alla regione o all'autenticazione può rispondere al tuo browser in modo diverso. I tempi sono misurati dalla nostra infrastruttura e non sono una misurazione del browser. Il test della richiesta reale è disattivato per impostazione predefinita per i metodi che possono modificare dati, e non viene mai inviato alcun corpo della richiesta.
Perché CORS è applicato dai browser e da nient'altro. Postman, curl, Insomnia e il tuo backend non applicano alcuna regola CORS, quindi ricevono la risposta qualunque intestazione essa porti. Di solito il server si comporta in modo identico nei due casi. La differenza sta tutta in ciò che il chiamante fa della risposta, e un browser si rifiuta di consegnarla al tuo JavaScript a meno che la risposta non dichiari che quell'origine può leggerla.
Una richiesta OPTIONS che il browser invia prima di quella reale, per chiedere se quella reale è consentita. Porta con sé Origin, Access-Control-Request-Method e, quando serve, Access-Control-Request-Headers. Se la risposta non permette la richiesta, quella reale non viene mai inviata, quindi il tuo endpoint non la vede mai e nei log del tuo server non compare nulla. Solo le richieste che non sono semplici hanno un preflight.
Content-Type è nella safelist CORS solo per application/x-www-form-urlencoded, multipart/form-data e text/plain. Quei tre e nient'altro. Un corpo JSON porta la richiesta fuori dalla safelist, quindi il browser la annuncia in anticipo. È per questo che aggiungere un'API JSON a una pagina esistente produce all'improvviso una richiesta OPTIONS che nessuno ha scritto.
Perché una risposta legata a un utente autenticato non deve essere leggibile da ogni sito che quell'utente visita. Quando una richiesta invia cookie o autenticazione HTTP, il server deve indicare l'origine di cui si fida, e un browser rifiuta la wildcard senza appello, anche insieme ad Access-Control-Allow-Credentials: true. Lo stesso vale per un asterisco in Allow-Methods, Allow-Headers ed Expose-Headers: per una richiesta con credenziali ciascuno di essi viene letto come un nome di intestazione letterale invece che come una wildcard.
No. CORS decide quali origini possono leggere una risposta dentro un browser. Non è autenticazione, non concede alcun permesso e non ferma il cross-site request forgery, perché un attacco CSRF non ha bisogno di leggere la risposta. Qualsiasi client che non sia un browser lo ignora completamente. Mantieni la tua autenticazione, i tuoi controlli di autorizzazione e i tuoi token CSRF esattamente come sono.
Dai server POLPROG verso l'endpoint che indichi, perché un browser non può eseguire questa diagnosi su se stesso: sarebbe CORS a bloccarla. Vengono inviate solo le intestazioni necessarie all'analisi, nessun tuo cookie viene inoltrato, non viene mai inviato alcun corpo della richiesta e i corpi delle risposte vengono scartati. Nulla viene conservato una volta che il report ti è arrivato, e i valori delle intestazioni sensibili come Authorization non vengono mai mostrati né esportati.
Un’azienda spesso chiede “uno scanner di sicurezza”, ma il problema reale comprende più livelli:
Gli header di sicurezza HTTP consentono al server di comunicare al browser regole per script, frame, funzioni del dispositivo, referrer, tipi MIME e HTTPS. Una configurazione corretta limita l’impatto di XSS, clickjacking, MIME confusion, XS-Leaks e incorporamento cross-origin non autorizzato.
Un buon audit di un sito web non è un singolo punteggio Lighthouse né una lista di decine di avvisi automatici. Deve rispondere a quattro domande: un motore di ricerca riesce a trovare e comprendere correttamente il sito, l’utente riesce a completare il proprio compito senza ostacoli, il sito è abbastanza veloce e il proprietario o i visitatori sono esposti a rischi evitabili?
Sviluppiamo software e soluzioni su misura per le tue esigenze.