Probador de CORS

Postman y curl no son navegadores, así que ignoran por completo la política de mismo origen: envían la solicitud y leen la respuesta sin importar qué encabezados devuelva el servidor. Un navegador es más estricto: cuando el JavaScript de un origen llama a un esquema, dominio o puerto distinto, solo deja que tu código lea la respuesta si el servidor devuelve el encabezado Access-Control-Allow-Origin correcto. Si ese encabezado falta, la solicitud igual llega al servidor y devuelve datos, pero el navegador oculta la respuesta a tu script y registra el error de CORS. Por eso un endpoint puede parecer sano en Postman y fallar en la consola. Esta herramienta inspecciona los encabezados CORS reales que devuelve un servidor, para que puedas confirmar que el problema es de configuración del servidor y no de tu código de fetch. Pega tu endpoint para ver exactamente qué encabezados están presentes.

Un preflight es una solicitud OPTIONS automática que el navegador envía antes de la solicitud real, preguntando al servidor si la llamada está permitida. Ocurre en solicitudes 'no simples': métodos como PUT, DELETE o PATCH, encabezados de solicitud personalizados, o tipos de contenido como application/json. El navegador incluye Access-Control-Request-Method y Access-Control-Request-Headers, y el servidor debe responder con valores coincidentes de Access-Control-Allow-Methods y Access-Control-Allow-Headers, o la solicitud real nunca se dispara. Las solicitudes GET y POST simples con encabezados estándar se saltan este paso. Como los preflights son invisibles en la mayoría del código de fetch, un handshake OPTIONS fallido es una causa común y confusa de errores de CORS. Este probador te permite enviar la solicitud como OPTIONS e inspeccionar los métodos y encabezados permitidos que reporta el servidor, para que verifiques el contrato de preflight directamente en lugar de adivinar a partir de un mensaje bloqueado en la consola.

La especificación de CORS prohíbe combinar solicitudes con credenciales con un origen comodín, y todos los navegadores lo hacen cumplir. Cuando envías cookies o encabezados de autorización de origen cruzado, el servidor debe devolver un origen específico en Access-Control-Allow-Origin, nunca el asterisco genérico. Si un servidor responde con Access-Control-Allow-Credentials: true y Access-Control-Allow-Origin configurado como comodín al mismo tiempo, el navegador rechaza la respuesta de plano y tu solicitud falla, aunque los encabezados parezcan permisivos. La solución es reflejar el origen exacto de la solicitud en lugar de usar un comodín, y mantener el encabezado de credenciales en true. Esta herramienta marca exactamente esa combinación peligrosa como error en su análisis de CORS, para que la detectes antes de que rompa un front-end autenticado. Ejecuta tu endpoint con credenciales a través de ella para confirmar que el origen sea específico y no un comodín.

Un origen comodín permite que cualquier sitio web de internet haga solicitudes de origen cruzado a tu API y lea la respuesta, lo cual está perfectamente bien para datos genuinamente públicos como conjuntos de datos abiertos, APIs públicas de solo lectura o JSON estático. Se vuelve arriesgado en el momento en que el endpoint devuelve algo sensible o es accesible con las cookies de un usuario, porque un sitio malicioso podría entonces llamarlo en nombre de un visitante. Como regla, restringe Access-Control-Allow-Origin a los dominios específicos que realmente necesitan acceso en lugar de abrirlo a todo el mundo, y nunca combines un comodín con credenciales. Este probador etiqueta un origen comodín como advertencia y un dominio específico como correcto, para que veas de un vistazo qué tan expuesto está un endpoint. Prueba tu URL aquí para comprobar si su política de origen se ajusta a la sensibilidad de los datos que sirve.

Access-Control-Max-Age le indica al navegador cuántos segundos puede almacenar en caché el resultado de una solicitud de preflight OPTIONS. Mientras esa caché sea válida, el navegador se salta el viaje de ida y vuelta adicional y envía la solicitud real directamente, lo que acelera notablemente las apps que disparan muchas solicitudes no simples al mismo endpoint. Sin él, el navegador puede repetir el preflight en cada llamada, añadiendo latencia. Los valores están limitados por el navegador —Chrome limita la caché a un par de horas sin importar un número mayor—, así que fijar un valor enorme no ayudará más allá de ese tope. Un Max-Age ausente simplemente significa que no hay ninguna caché de preflight. Esta herramienta lee el encabezado y traduce los segundos brutos a minutos en su análisis, para que juzgues rápidamente con qué agresividad se cachean los preflights. Prueba tu endpoint para ver si establece un Max-Age útil.