Saltar al contenido

Probador de CORS

CORS Tester

Envía la petición preflight que enviaría un navegador desde el origen que indiques, más un GET con esa cabecera Origin, y explica según las reglas del estándar Fetch qué cabecera lo bloqueó.

Un fallo de CORS en la consola nombra la cabecera que faltaba y casi nunca la razón, y la petición que el navegador envió realmente no es la que está en tu código. Esta herramienta envía el preflight que un navegador enviaría desde un origen que tú eliges, después un GET con ese Origin, y lee el resultado según las reglas del estándar Fetch.

☁️ Usa nuestro servidorcorshttpdebugweb

Nuestro servidor hace esta solicitud por ti. Solo se le envía la URL, el origen, el método y los nombres de cabecera que escribes: ninguna de tus cookies ni tu sesión iniciada viaja con ella. El servidor solo se conecta a direcciones públicas y rechaza las privadas e internas.

Un servidor envía el preflight (OPTIONS) que enviaría un navegador y después la petición en sí, y el resultado se juzga con las reglas CORS del estándar Fetch. La petición real siempre es un GET (o HEAD): esto no dispara un PUT ni un DELETE contra la API de otra persona en tu nombre.

El esquema, el host y el puerto de la página web que hace la llamada.

application/json siempre dispara un preflight.

Cómo se usa

  1. Introduce la URL y el origen

    El origen es el sitio *desde* el que vendría la petición: la página que hace la llamada, no la API. Ponerlos al revés es la razón más común de que una prueba no coincida con el navegador.

  2. Añade el método y las cabeceras que usas de verdad

    Un preflight solo ocurre para peticiones no simples. `Content-Type: application/json` o una cabecera `Authorization` es lo que lo dispara, así que omitirlas prueba una petición que nunca haces.

  3. Lee qué regla falló

    El resultado nombra la comprobación concreta —origen no permitido, método no listado, cabecera no listada, credenciales con un origen comodín— en lugar de informar de un fallo genérico.

Preguntas frecuentes

Aquí pasa, pero el navegador sigue bloqueándolo.

Comprueba que el método, las cabeceras y el modo de credenciales coinciden exactamente con lo que envía tu código, y que el servidor no varía su respuesta según la cookie o el agente de usuario. Esto corre desde un servidor, así que una respuesta que dependa de una sesión que tú tienes será distinta.

¿Por qué `Access-Control-Allow-Origin: *` no funciona con cookies?

El estándar lo prohíbe. Con `credentials: 'include'`, el origen debe devolverse literalmente y `Access-Control-Allow-Credentials: true` debe estar presente. Un comodín con credenciales se rechaza por diseño, no por un fallo.

¿Esto corre en mi navegador?

No. Corre desde un servidor, porque un navegador no puede hacer la petición que CORS bloquea. Eso significa que ve la respuesta pública, sin tus cookies ni tu posición en la red.

¿Puedo probar una dirección interna?

No. La petición se origina en un servidor que no puede llegar a tu red, y las direcciones que solo resuelven dentro de ella fallarán sea cual sea su configuración de CORS.

Puede recibir de

Después

Estas aceptan lo que produce esta herramienta, así que el resultado puede pasar directamente.