VoriTools

Analizador de cabeceras CORS

Configura los campos de la petición. No se envía ninguna solicitud; el servidor y las restricciones de valores requieren pruebas aparte.

Se ejecuta localmente en tu navegador
Ver categoría: Desarrollo de API (15)
Esta herramienta procesa todos los datos localmente en tu navegador.
Solicitud del navegador y cabeceras de respuesta copiadasEste comprobador solo modela reglas del navegador; no contacta la API ni reproduce credenciales.

Modelar una solicitud CORS del navegador frente a cabeceras de respuesta copiadas

Este analizador modela una solicitud CORS del navegador frente a las cabeceras de respuesta que pegues. Responde a una sola pregunta: ¿dejaría el navegador que la página leyese esa respuesta y se aceptaría el preflight cuando hace falta?

Todo se ejecuta en la pestaña. No se envía ninguna solicitud: el resumen describe lo que permiten las cabeceras copiadas, no lo que devuelve hoy el servidor real.

  1. Introduce el origen de la solicitud (esquema, host, puerto) y elige el método. PUT, PATCH y DELETE provocan un preflight; GET, HEAD y POST normalmente no.
  2. Escribe las cabeceras que el navegador pondría en Access-Control-Request-Headers, por ejemplo Authorization, X-Request-ID, y marca credenciales cuando la solicitud envíe cookies o autenticación HTTP.
  3. Pega el bloque completo de cabeceras de respuesta como líneas `Nombre: valor` y pulsa Analizar política CORS.
  4. Lee primero la decisión y después las comprobaciones: cada línea indica la cabecera que permitió o bloqueó la solicitud. Copia o descarga el resumen para conservarlo.

Cómo lee el analizador las cabeceras Access-Control y dónde se detiene

Coincidencia de origen y credenciales

Access-Control-Allow-Origin debe repetir el origen exacto de la solicitud: esquema y host en minúsculas, puertos por defecto omitidos y sin barra final. Chrome rechaza `https://app.example.com/` para el origen `https://app.example.com`, y el analizador informa del mismo desajuste.

`*` permite cualquier origen solo si la solicitud no envía credenciales. Con cookies o autenticación HTTP la respuesta debe repetir el origen y añadir `Access-Control-Allow-Credentials: true`; el origen comodín queda bloqueado aunque parezca permisivo.

Qué exige preflight y qué pasa sin él

Un Content-Type JSON o cualquier cabecera personalizada hacen que el navegador envíe un preflight OPTIONS antes de la solicitud. Chrome exige entonces una entrada correspondiente en Access-Control-Allow-Methods y en Access-Control-Allow-Headers para cada cabecera listada; sin ellas la respuesta se bloquea, mientras que `text/plain` con la misma política sí pasa.

GET, HEAD y POST son métodos de la lista segura: pasan el preflight aunque Access-Control-Allow-Methods no los incluya. PUT, PATCH y DELETE deben aparecer listados. Los nombres de método y de cabecera se comparan sin distinguir mayúsculas: `post` y `x-test` coinciden.

Comodines que dejan de valer con credenciales

`Access-Control-Allow-Methods: *` y `Access-Control-Allow-Headers: *` son comodines solo para solicitudes sin credenciales. Una solicitud con credenciales necesita su método y cada cabecera listados de forma literal, y el analizador ahora lo indica en lugar de fiarse del asterisco.

Lo que el analizador no hace: no envía la solicitud ni reproduce credenciales, no juzga restricciones de valor de cabecera (un esquema de Authorization, un valor de Content-Type) y no cubre redirecciones, orígenes nulos, Access-Control-Expose-Headers, Max-Age ni Vary.

Herramientas recientes: