Red/HTTP
CORS Checker / Explainer
Explicar paso a paso si el navegador permitirá una solicitud cross-origin — clasificación simple/preflight, verificación de las cabeceras Access-Control-* de la respuesta, resumen.
Una por línea, "Nombre" o "Nombre: valor" — el valor no afecta la clasificación.
Tómalas de la pestaña Network en DevTools (cabeceras de la respuesta o del preflight OPTIONS) o de 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.
Preguntas frecuentes
¿Por qué una solicitud falla con un error CORS aunque el servidor respondió correctamente?
CORS lo impone el navegador, no el servidor — si a la respuesta le falta un encabezado Access-Control-Allow-Origin que coincida con el origen solicitante, el navegador bloquea que JavaScript lea la respuesta, aunque la solicitud en sí se haya completado.
¿Cuál es la diferencia entre una solicitud simple y una con preflight?
Las solicitudes simples (GET/POST básicos con encabezados estándar) pasan directamente, mientras que las solicitudes con encabezados personalizados, otros métodos o ciertos tipos de contenido activan primero una solicitud preflight OPTIONS para verificar el permiso antes de enviar la solicitud real.
¿Verificar encabezados CORS aquí envía mis datos a un servidor?
La herramienta inspecciona encabezados que proporcionas u obtiene directamente desde tu navegador — ningún servidor intermediario almacena los datos de tu solicitud.
¿Protege CORS una API de solicitudes maliciosas?
No. CORS solo restringe lo que JavaScript puede leer en el navegador — un atacante que use curl, Postman o un script backend lo ignora por completo, así que la autenticación y autorización reales deben implementarse en el servidor.
¿Por qué Access-Control-Allow-Origin: * no funciona junto con credentials: include?
La especificación lo prohíbe deliberadamente por seguridad: permitir credenciales (cookies, cabeceras de autorización) junto con un comodín que acepta cualquier origen sería un fallo de seguridad grave, así que el servidor debe devolver un origen exacto cuando se usan credenciales.