Rete/HTTP
CORS Checker / Explainer
Spiegare passo dopo passo se il browser consentirà una richiesta cross-origin — classificazione simple/preflight, verifica delle intestazioni Access-Control-* della risposta, riepilogo.
Una per riga, "Nome" o "Nome: valore" — il valore non influisce sulla classificazione.
Prendile dalla scheda Network delle DevTools (intestazioni della risposta stessa o del preflight OPTIONS) oppure con curl -I.
CORS (Cross-Origin Resource Sharing) is a browser mechanism that decides whether JavaScript from one site is allowed to read a response from a server on a different domain. This tool walks through, step by step, whether a specific request will succeed and which Access-Control-* headers it needs.
How to use it
- Provide the method, the request's origin, and the server's response headers (Access-Control-Allow-Origin, etc.) and the tool determines whether the browser will let the request through.
- The "simple" vs. "preflight" classification shows whether the browser will first send an OPTIONS preflight request before the actual one.
- The summary gives the exact reason for a failure when a request would be blocked — faster than parsing the browser console's error message.
Common uses
- Debugging the classic "has been blocked by CORS policy" error with a step-by-step explanation of what's missing, instead of guessing.
- Checking a backend's CORS configuration before the frontend and API end up on separate domains in production.
- Understanding why a request with credentials: include is rejected even though Access-Control-Allow-Origin looks correct.
Things to keep in mind
CORS protects the user's browser, not the server — the restriction only applies to requests made from page JavaScript in a browser, not to requests from curl, Postman, or server-to-server calls.
Access-Control-Allow-Origin: * is incompatible with credentials: include — for requests carrying cookies or authorization, the server must return a specific origin instead of a wildcard.
Domande frequenti
Perché una richiesta fallisce con un errore CORS anche se il server ha risposto con successo?
CORS è applicato dal browser, non dal server — se alla risposta manca un'intestazione Access-Control-Allow-Origin corrispondente all'origine richiedente, il browser impedisce a JavaScript di leggere la risposta, anche se la richiesta stessa si è completata.
Qual è la differenza tra una richiesta semplice e una richiesta con preflight?
Le richieste semplici (GET/POST di base con intestazioni standard) passano direttamente, mentre le richieste con intestazioni personalizzate, altri metodi o certi tipi di contenuto attivano prima una richiesta preflight OPTIONS per verificare il permesso prima di inviare la richiesta reale.
Controllare le intestazioni CORS qui invia i miei dati a un server?
Lo strumento ispeziona le intestazioni che fornisci o le recupera direttamente dal tuo browser — nessun server intermediario memorizza i dati della tua richiesta.
CORS protegge un'API dalle richieste malevole?
No. CORS limita solo ciò che il JavaScript nel browser può leggere — un aggressore che usa curl, Postman o uno script backend lo aggira completamente, quindi la vera autenticazione e autorizzazione devono essere implementate sul server.
Perché Access-Control-Allow-Origin: * non funziona insieme a credentials: include?
La specifica vieta deliberatamente questa combinazione per motivi di sicurezza: consentire le credentials (cookie, header di autorizzazione) insieme a un carattere jolly che accetta qualsiasi origin sarebbe una grave falla di sicurezza, quindi il server deve restituire un origin esatto quando si usano le credentials.