Probador de CORS

Siguiente

Los errores de CORS son el rojo “clásico” de la consola del navegador: accedes a una API desde un origen diferente y el navegador bloquea la respuesta. Este probador envía una solicitud OPTIONS de preflight a cualquier URL que pegues, con el origen y el método que elijas, y luego decodifica los encabezados Access-Control-* para que puedas ver exactamente qué permite el servidor, qué bloquea y por qué se queja el navegador.

Cómo probar CORS

  1. 1

    Ingresa la URL de destino

    El endpoint de la API que deseas llamar desde tu front-end. Incluye la cadena de consulta y el protocolo.

  2. 2

    Establece el método y el origen

    GET/POST/PUT/DELETE/PATCH. El origen puede ser la URL de tu sitio o cualquier origen que desees simular.

  3. 3

    Entiende el preflight

    El probador siempre envía una solicitud OPTIONS con el origen y el método elegidos, más el encabezado Access-Control-Request-Headers: Content-Type, exactamente el preflight que envía un navegador antes de una solicitud JSON.

  4. 4

    Ejecuta la prueba

    El probador envía el preflight y reporta el estado HTTP más los encabezados de respuesta CORS: Allow-Origin, Allow-Methods, Allow-Headers, Allow-Credentials y Max-Age.

  5. 5

    Corrige la mala configuración

    El informe señala lo que falta o está mal, falta Allow-Origin, encabezado prohibido, método no permitido.

Los encabezados que importan

Encabezado Qué hace
Access-Control-Allow-Origin Qué orígenes pueden leer la respuesta
Access-Control-Allow-Methods Preflight: qué métodos están permitidos
Access-Control-Allow-Headers Preflight: qué encabezados de solicitud están permitidos
Access-Control-Allow-Credentials Si se permiten cookies/autenticación
Access-Control-Expose-Headers Qué encabezados de respuesta puede leer JS
Access-Control-Max-Age Cuánto tiempo se almacena el resultado del preflight

Solicitudes simples vs. preflighted

Una solicitud es “simple” (sin preflight) solo si todas estas son verdaderas:

  • El método es GET, HEAD o POST.
  • Los encabezados están limitados a Accept, Accept-Language, Content-Language, Content-Type (con valores específicos).
  • Content-Type, si está presente, es application/x-www-form-urlencoded, multipart/form-data o text/plain.

Cualquier otra cosa, un cuerpo JSON, un encabezado Authorization, un encabezado personalizado X-Foo, un PUT/DELETE/PATCH, desencadena un preflight OPTIONS. Los servidores deben responder al preflight con los encabezados Allow-* correctos o la solicitud real nunca se envía.

Fallos comunes de CORS

  • “No se establece el encabezado Access-Control-Allow-Origin” → el servidor no establece el encabezado. Corrige en el servidor, no en el cliente.
  • “El modo de credenciales requiere que Allow-Origin no sea *” → si envías cookies, Allow-Origin debe ser un origen específico (o reflejar el encabezado Origin).
  • “El encabezado de solicitud X no está permitido” → agrega X a Access-Control-Allow-Headers en la respuesta de preflight.
  • “Método no permitido” → agrega el método a Access-Control-Allow-Methods.
  • “Redirección no permitida en preflight” → el preflight no puede seguir redirecciones. El endpoint OPTIONS debe responder directamente.

Allow-Origin: * vs. reflejar Origin

Access-Control-Allow-Origin: * es permisivo pero no se puede combinar con credenciales. En producción, refleja el Origin de la solicitud (después de validar contra una lista de permitidos) y establece Allow-Credentials: true si necesitas cookies.

Uso de un proxy como solución alternativa

Si no puedes controlar el servidor, un proxy delgado en tu propio dominio elimina CORS por completo, el navegador ve el mismo origen. Muchas plataformas de alojamiento (Vercel, Netlify, Cloudflare) ofrecen reglas de reescritura para exactamente esto.

Preguntas frecuentes

Para evitar que una página maliciosa lea datos privados en otro sitio utilizando las cookies de tu navegador. Sin CORS, visitar evil.com podría permitirle solicitar la API interna de tu banco como tú. CORS obliga al banco a permitir explícitamente las lecturas de origen cruzado.

Solo en desarrollo. Chromium tiene una bandera --disable-web-security pero afecta a todos los sitios y es peligrosa. La solución correcta son los encabezados del lado del servidor o un proxy.

Postman no es un navegador, ignora CORS por completo. CORS solo se aplica en navegadores para solicitudes de JavaScript. Un servidor que funciona en Postman no es automáticamente correcto para CORS.

Las imágenes y las etiquetas <script> clásicas se cargan de origen cruzado sin CORS, pero JS no puede leer su contenido. <img crossorigin> y fetch() sí aplican CORS, por lo que las imágenes dibujadas en canvas se vuelven “contaminadas” sin él.

Herramientas relacionadas