¿Qué es CORS?

Scrapeless Agent Browser ejecuta sesiones de navegador que pueden observar cómo se comporta un sitio web bajo las reglas de origen cruzado del navegador.

El intercambio de recursos de origen cruzado, o CORS, es un mecanismo de encabezado HTTP que permite a un servidor declarar cuándo un navegador puede exponer una respuesta a un script que se ejecuta en otro origen. Un origen es la combinación de esquema, host y puerto. CORS es importante porque una página cargada desde un origen a menudo quiere llamar a una API en otro; el navegador restringe esa lectura a menos que la respuesta cumpla con las reglas de CORS.

Un error de CORS es fácil de interpretar erróneamente como una interrupción de red o un problema de autenticación de API. La solicitud puede haber alcanzado el servidor, y el servidor puede haber devuelto datos, mientras que el navegador se niega a hacer esos datos disponibles para el script de la página. Diagnostica la decisión del navegador por separado de la decisión comercial de la API.

El Límite de Origen al que se Aplica CORS

Dos URL comparten un origen solo cuando su esquema, host y puerto coinciden. Cambiar de http a https, pasar a un subdominio o usar otro puerto crea un origen diferente. Una página puede realizar algunas solicitudes de origen cruzado sin obtener acceso al cuerpo de la respuesta. El guía de CORS de MDN describe esto como una relajación controlada de la política de mismo origen para las solicitudes HTTP de origen cruzado realizadas por scripts.

El servidor comunica permiso con encabezados de respuesta como Access-Control-Allow-Origin. Un navegador compara el valor con el origen de la página solicitante. El navegador es el punto de aplicación para el script de la página. Un cliente de línea de comandos puede enviar una solicitud HTTP sin aplicar las reglas de CORS del navegador, por lo que una respuesta exitosa de línea de comandos no prueba que una página web pueda leer el mismo recurso.

CORS no es un sistema de autorización. Un servidor aún debe autenticar a los llamadores y verificar los permisos de recursos. Conceder a un origen permiso para leer una respuesta es diferente de decidir que un usuario puede ver un registro de cuenta privada. Trata esos como controles separados y prueba ambos. Una configuración de CORS permisiva no puede reemplazar de manera segura las comprobaciones de acceso del lado del servidor.

Solicitudes Simples y Solicitudes Preflight

Para algunas solicitudes de origen cruzado, el navegador envía la solicitud real y luego verifica el permiso de respuesta. Otras solicitudes requieren un preflight: el navegador primero envía una solicitud OPTIONS para preguntar si el método y los encabezados propuestos están permitidos. El definición de preflight identifica los campos Origin y Access-Control-Request-Method, con Access-Control-Request-Headers cuando sea necesario.

Una solicitud con un encabezado de autorización personalizado o un tipo de contenido no permitido puede activar un preflight. Si el preflight falla, el navegador no envía la solicitud real asociada. Esa diferencia es importante durante el diagnóstico. Un registro de servidor de aplicación sin POST aún puede mostrar una solicitud OPTIONS, y un desarrollador que verifica solo la ruta POST puede perder el punto de rechazo.

La aprobación de preflight está limitada al método, encabezados, origen y reglas de recursos solicitados. No significa que la operación comercial posterior tendrá éxito. La solicitud real aún puede fallar en autenticación o validación. Por el contrario, un preflight fallido no es evidencia de que la API rechazó los datos del usuario; la solicitud que lleva los datos puede nunca haber llegado a la aplicación.

Las Credenciales Cambian las Reglas de Respuesta

Una solicitud de origen cruzado puede involucrar cookies u otras credenciales gestionadas por el navegador. Cuando una página espera una respuesta con credenciales, un valor Access-Control-Allow-Origin comodín no es suficiente. El servidor debe identificar un origen permitido y aplicar la regla de respuesta de credencial relevante. La guía de errores de credenciales de MDN explica por qué la combinación de comodín y credenciales falla.

El modo de credencial de la solicitud y la política de cookies son entradas separadas. Un navegador puede omitir una cookie debido a su configuración SameSite, Secure o de dominio incluso cuando los encabezados CORS parecen correctos. Un error de autenticación puede aparecer entonces después de que la verificación de CORS se haya realizado con éxito. Inspecciona la solicitud y la respuesta en herramientas de desarrollador en lugar de cambiar campos CORS para compensar por una cookie que nunca se envió.

Permitir cada origen solicitante dinámicamente sin validación puede exponer respuestas sensibles a páginas no confiables. Mantén una política de origen explícita para datos que requieren credenciales, y asegúrate de que las cachés varíen apropiadamente cuando las respuestas dependan de Origin. La revisión de seguridad debe incluir el recurso autenticado real, no solo un punto final de prueba que devuelve texto público.

Cómo Diagnosticar un Error de CORS en el Navegador

Comienza con el origen de la página y el origen final de destino, incluyendo redirecciones. Una solicitud que redirige a un host de inicio de sesión puede necesitar una política diferente que la URL API original. En las herramientas de desarrollador del navegador, inspecciona el intercambio OPTIONS si existe, la solicitud real si fue enviada, y los encabezados de respuesta. El catálogo de errores de CORS mapea mensajes de consola comunes a campos de respuesta faltantes o incompatibles.

Una llamada fetch fallida puede exponer solo un error genérico a JavaScript mientras que la consola contiene la razón específica del CORS. Registra ambas superficies. Verifica si la respuesta carece de Access-Control-Allow-Origin, nombra un origen diferente, omite un método o encabezado permitido, o entra en conflicto con el modo de credencial. Realiza un cambio de configuración en el servidor que controlas, luego prueba la misma página y solicitud nuevamente.

No agregues extensiones de navegador o desactives las verificaciones de seguridad como solución en producción. Tal cambio local puede ocultar un defecto de integración mientras deja a los usuarios reales bloqueados. Si la API es de terceros y no permite el origen de tu página, utiliza una arquitectura de integración del lado del servidor soportada o pide al proveedor un camino de acceso documentado para el navegador.

CORS en Automatización de Navegadores y Recolección de Datos

Una sesión real del navegador ejecuta scripts de página bajo las reglas de seguridad del navegador. Navegador Agente Sin Rastro proporciona una ejecución remota controlada del navegador, para que se pueda observar una página que realiza solicitudes entre orígenes en ese entorno. La introducción al Navegador Agente descrita el producto del navegador. No convierte una respuesta API no autorizada en una autorizada.

Una solicitud de datos del lado del servidor tiene un límite CORS diferente: el CORS del navegador no rige un cliente HTTP de backend. Otros controles aún se aplican, incluyendo credenciales del proveedor, permisos de destino y políticas de tasa. Elija el navegador cuando necesite probar o reproducir el comportamiento de la propia página. Elija una API de servidor documentada cuando la tarea sea un intercambio directo de datos y el proveedor lo apoye.

El relacionado guía de inspección de red del navegador discute la observación de solicitudes utilizadas por una página. La observación no equivale a un permiso para utilizar puntos finales privados fuera de su contexto previsto. Al revisar un seguimiento del navegador, concéntrese en los datos públicos o explícitamente autorizados necesarios para la tarea y mantenga las credenciales fuera de los registros compartidos.

Una lista de verificación práctica de decisiones CORS

Identifique al propietario del recurso y el origen de la página que lo llama. Decida si el script del navegador realmente necesita leer la respuesta. Si es así, configure el servidor de recursos para permitir solo el origen, métodos, encabezados y comportamientos de credenciales previstos. Si no, mantenga la llamada en un backend controlado donde el navegador nunca necesite acceso directo a la API de terceros.

Pruebe el método exacto y los encabezados utilizados en producción. Un GET sin campos personalizados puede funcionar mientras que un POST JSON con un encabezado de autorización activa un preflight. También pruebe la ruta de error: una respuesta de éxito con encabezados CORS correctos es insuficiente si las fallas de autenticación o redirecciones los omiten. Los usuarios del navegador necesitan que la falla real sea visible y diagnosable.

Finalmente, separe tres observaciones en notas de incidentes: si se realizó la solicitud de red, si el servidor aceptó la operación, y si el navegador expuso la respuesta al script de la página. Esas respuestas pueden diferir. Mantenerlas distintas evita que un problema de política del navegador sea “solucionado” debilitando la autorización del servidor no relacionada.

Conclusión

CORS permite a un servidor de recursos especificar qué otros orígenes pueden leer sus respuestas desde los scripts del navegador. Su efecto depende del origen de la página, la forma de la solicitud, el preflight y el modo de credenciales. Diagnostique esas partes en el navegador mientras mantiene intactas las verificaciones de autenticación y permisos del lado del servidor.