Probador de CORS en Línea: Diagnostica Problemas de Intercambio de Recursos de Origen Cruzado
· 12 min de lectura
Tabla de Contenidos
- Entendiendo CORS y su Importancia
- Cómo Funciona CORS: La Inmersión Técnica Profunda
- Problemas Comunes de CORS y Mensajes de Error
- Usando un Probador de CORS Efectivamente
- Ejemplos Prácticos de Diagnóstico de Problemas de CORS
- Implementando CORS en el Lado del Servidor
- Encabezados CORS Explicados en Detalle
- Consideraciones de Seguridad y Mejores Prácticas
- Guía Avanzada de Solución de Problemas
- Estrategias de Prueba para Configuración de CORS
- Preguntas Frecuentes
- Artículos Relacionados
Entendiendo CORS y su Importancia
El Intercambio de Recursos de Origen Cruzado (CORS) es un mecanismo de seguridad implementado en navegadores web que controla cómo las aplicaciones web pueden solicitar recursos de diferentes orígenes. Piénsalo como un portero en un club—decide quién entra y quién no basándose en un conjunto específico de reglas.
Por defecto, los navegadores aplican la Política del Mismo Origen (SOP), que impide que JavaScript ejecutándose en un dominio acceda a recursos en otro dominio. Esta es una característica de seguridad fundamental que protege a los usuarios de scripts maliciosos. Sin embargo, las aplicaciones web modernas a menudo necesitan comunicarse con APIs y servicios alojados en diferentes dominios, que es donde entra CORS.
CORS proporciona una forma estandarizada para que los servidores le digan a los navegadores: "Sí, está bien que este sitio web en particular acceda a mis recursos." Sin una configuración CORS adecuada, las solicitudes legítimas de origen cruzado serán bloqueadas, rompiendo la funcionalidad en tus aplicaciones web.
Consejo profesional: CORS es una característica de seguridad aplicada por el navegador. Herramientas como cURL o Postman no encontrarán problemas de CORS porque no son navegadores. Siempre prueba las configuraciones de CORS en un entorno de navegador real.
Considera un escenario del mundo real: Estás construyendo una plataforma de comercio electrónico donde el frontend está alojado en https://mitienda.com, pero tu API de inventario de productos vive en https://api.servicio-inventario.com. Sin encabezados CORS, tu JavaScript del frontend no podrá obtener datos de productos, dejando a tus clientes mirando estantes vacíos.
CORS se vuelve aún más crítico cuando estás trabajando con:
- APIs de terceros a las que tu frontend necesita acceder directamente
- Arquitecturas de microservicios donde diferentes servicios se ejecutan en diferentes dominios
- Redes de Distribución de Contenido (CDN) que sirven activos desde diferentes orígenes
- Aplicaciones de Página Única (SPA) que se comunican con APIs de backend
- Fuentes web, imágenes u otros recursos cargados desde dominios externos
Cómo Funciona CORS: La Inmersión Técnica Profunda
Entender cómo funciona CORS internamente te ayuda a diagnosticar problemas de manera más efectiva. El mecanismo CORS involucra dos tipos de solicitudes: solicitudes simples y solicitudes de verificación previa.
Solicitudes Simples
Una solicitud simple es aquella que cumple todas estas condiciones:
- Usa uno de estos métodos HTTP: GET, HEAD o POST
- Solo incluye encabezados seguros para CORS como Accept, Accept-Language, Content-Language o Content-Type
- Si se usa Content-Type, debe ser application/x-www-form-urlencoded, multipart/form-data o text/plain
Para solicitudes simples, el navegador envía la solicitud directamente con un encabezado Origin. El servidor responde con un encabezado Access-Control-Allow-Origin indicando si el origen está permitido. Si el encabezado coincide con el origen solicitante (o está configurado como *), el navegador permite que la respuesta sea leída por el código JavaScript.
Solicitudes de Verificación Previa
Cualquier solicitud que no cumpla los criterios de solicitud simple desencadena una solicitud de verificación previa. Esta es una solicitud OPTIONS enviada por el navegador antes de la solicitud real para verificar si el protocolo CORS es entendido y la solicitud real es segura de enviar.
La solicitud de verificación previa incluye encabezados como:
Access-Control-Request-Method: El método HTTP de la solicitud realAccess-Control-Request-Headers: Encabezados personalizados que se enviarán con la solicitud realOrigin: El origen que hace la solicitud
El servidor debe responder a la verificación previa con encabezados CORS apropiados indicando qué está permitido. Solo si la verificación previa tiene éxito, el navegador envía la solicitud real.
Consejo rápido: Las solicitudes de verificación previa pueden impactar el rendimiento. Usa el encabezado Access-Control-Max-Age para almacenar en caché las respuestas de verificación previa y reducir el número de solicitudes OPTIONS que tu servidor necesita manejar.
Problemas Comunes de CORS y Mensajes de Error
Los errores de CORS están entre los problemas más frustrantes que encuentran los desarrolladores. Desglosemos los problemas más comunes y qué significan realmente.
Falta el Encabezado Access-Control-Allow-Origin
Este es el error de CORS más común que verás. La consola del navegador mostrará algo como:
El acceso a fetch en 'https://api.ejemplo.com/data' desde el origen 'https://miaplicacion.com' ha sido bloqueado por la política CORS: No hay un encabezado 'Access-Control-Allow-Origin' presente en el recurso solicitado.
Esto significa que el servidor no incluyó el encabezado CORS requerido en su respuesta. La solución es directa: configura tu servidor para enviar el encabezado Access-Control-Allow-Origin con el origen específico o * para APIs públicas.
Método HTTP Incorrecto
Cuando intentas usar un método HTTP que el servidor no ha permitido explícitamente, verás un error como:
El acceso a fetch en 'https://api.ejemplo.com/data' desde el origen 'https://miaplicacion.com' ha sido bloqueado por la política CORS: El método PUT no está permitido por Access-Control-Allow-Methods en la respuesta de verificación previa.
Esto sucede durante la fase de verificación previa. Tu servidor necesita incluir el método HTTP en el encabezado Access-Control-Allow-Methods.
Credenciales No Soportadas
Si estás intentando enviar cookies o encabezados de autenticación pero el servidor no está configurado para ello, encontrarás:
El acceso a fetch en 'https://api.ejemplo.com/data' desde el origen 'https://miaplicacion.com' ha sido bloqueado por la política CORS: El valor del encabezado 'Access-Control-Allow-Credentials' en la respuesta es '' que debe ser 'true' cuando el modo de credenciales de la solicitud es 'include'.
Para arreglar esto, el servidor debe enviar Access-Control-Allow-Credentials: true, y lo importante, no puede usar Access-Control-Allow-Origin: * cuando las credenciales están involucradas—debe especificar el origen exacto.
Encabezados Personalizados No Permitidos
Las aplicaciones modernas a menudo usan encabezados personalizados para claves de API, tokens de autenticación u otros metadatos. Si estos no están explícitamente permitidos, verás:
El campo de encabezado de solicitud x-api-key no está permitido por Access-Control-Allow-Headers en la respuesta de verificación previa.
La solución es incluir tus encabezados personalizados en el encabezado de respuesta Access-Control-Allow-Headers.
| Tipo de Error | Causa Común | Solución Rápida |
|---|---|---|
| Sin Access-Control-Allow-Origin | Servidor no configurado para CORS | Agregar el encabezado a las respuestas del servidor |
| Método no permitido | Método HTTP no en la lista permitida | Actualizar Access-Control-Allow-Methods |
| Credenciales no soportadas | Falta encabezado de credenciales | Establecer Access-Control-Allow-Credentials: true |
| Encabezado no permitido | Encabezado personalizado no en lista blanca | Agregar a Access-Control-Allow-Headers |
| Comodín con credenciales | Usando * con modo de credenciales | Especificar origen exacto en lugar de * |
Usando un Probador de CORS Efectivamente
Un probador de CORS es una herramienta invaluable para diagnosticar problemas de origen cruzado sin escribir código. Simula solicitudes del navegador y te muestra exactamente qué encabezados CORS se están enviando y recibiendo. Puedes usar nuestro Probador de CORS para diagnosticar problemas rápidamente.
Qué Debe Hacer un Buen Probador de CORS
Una herramienta efectiva de prueba de CORS debe proporcionar:
- La capacidad de especificar la URL objetivo y el origen
- Opciones para seleccionar diferentes métodos HTTP (GET, POST, PUT, DELETE, etc.)
- Configuración de encabezados personalizados para probar escenarios específicos
- Visualización clara de encabezados de solicitud y respuesta
- Indicación de si la verificación CORS pasó o falló
- Mensajes de error detallados explicando qué salió mal
Proceso de Prueba Paso a Paso
Aquí está cómo usar un probador de CORS efectivamente:
- Ingresa la URL del endpoint de la API que quieres probar
- Especifica el origen que hará la solicitud (tu dominio frontend)
- Selecciona el método HTTP que tu aplicación usará
- Agrega cualquier encabezado personalizado que tu aplicación envíe (como Authorization o X-API-Key)
- Ejecuta la prueba y examina los resultados
- Revisa los encabezados de respuesta para ver qué políticas CORS están en su lugar
- Identifica encabezados faltantes o incorrectos que necesitan ser configurados en el servidor
Consejo profesional: Siempre prueba con el origen exacto que tu aplicación de producción usará. Algunos servidores tienen configuraciones CORS específicas de origen que podrían funcionar para localhost pero fallar para tu dominio de producción.
Interpretando Resultados de Prueba
Cuando ejecutas una prueba de CORS, presta atención a estos indicadores clave:
- Estado de verificación previa: ¿Tuvo éxito la solicitud OPTIONS? Si no, tu servidor podría no estar manejando las solicitudes de verificación previa correctamente.
- Valor de Access-Control-Allow-Origin: ¿Coincide con tu origen o está configurado como *? Si no coincide, la solicitud fallará.
- Métodos permitidos: ¿Está tu método HTTP previsto listado en Access-Control-Allow-Methods?
- Encabezados permitidos: ¿Están todos tus encabezados personalizados incluidos en Access-Control-Allow-Headers?
- Soporte de credenciales: Si necesitas enviar cookies, ¿está Access-Control-Allow-Credentials configurado como true?
También puedes usar nuestro Analizador de Encabezados HTTP para obtener un desglose detallado de todos los encabezados que se están enviando y recibiendo, lo que complementa perfectamente las pruebas de CORS.
Ejemplos Prácticos de Diagnóstico de Problemas de CORS
Ejemplo 1: Integración de Redes Sociales
Digamos que estás construyendo un panel de redes sociales que agrega publicaciones de múltiples plataformas. Tu frontend en https://panel.ejemplo.com necesita obtener datos de https://api.redessociales.com.
Estás haciendo una solicitud POST para crear una nueva publicación, pero sigues obteniendo errores de CORS. Aquí está cómo diagnosticarlo:
- Abre tu probador de CORS e ingresa
https://api.redessociales.com/posts - Establece el origen como
https://panel.ejemplo.com - Selecciona POST como el método
- Agrega el encabezado Content-Type:
application/json - Agrega tu encabezado Authorization:
Bearer tu-token-aqui - Ejecuta la prueba
La prueba revela que el servidor solo permite solicitudes GET. El encabezado Access-Control-Allow-Methods muestra: GET, HEAD, OPTIONS. Necesitas contactar al proveedor de la API para habilitar solicitudes POST, o verificar si hay un endpoint diferente para crear publicaciones.
Ejemplo 2: Sistema de Inventario de Comercio Electrónico
Tu sitio de comercio electrónico en https://tienda.ejemplo.com obtiene datos de inventario de https://inventario.ejemplo.com. La API requiere un encabezado personalizado X-Shop-ID para identificar qué tienda está haciendo la solicitud.
Las pruebas revelan el error: "El campo de encabezado de solicitud x-shop-id no está permitido p