¿Qué es una solicitud de preflight? Comprobaciones CORS explicadas

Scrapeless Agent Browser ejecuta flujos de trabajo basados en navegador en los que las páginas de destino siguen estando sujetas a las reglas de solicitudes entre orígenes del navegador.

Un preflight pregunta por una solicitud de navegador propuesta

Un preflight CORS es una solicitud HTTP OPTIONS que un navegador envía para comprobar si un servidor permite una solicitud entre orígenes concreta. Describe el origen que realiza la llamada, el método previsto y los nombres de campos de solicitud relevantes. Si la respuesta del servidor satisface las comprobaciones del navegador, el navegador puede continuar con la solicitud de aplicación. El preflight es una negociación de permisos en el modelo de acceso del navegador, no la operación de aplicación en sí.

El modelo CORS del Fetch Standard define este comportamiento. Un origen se determina por esquema, host y puerto, por lo que dos URLs pueden pertenecer a orígenes diferentes incluso cuando sus dominios parecen muy relacionados. Un frontend servido desde un origen y una API servida desde otro pueden necesitar configuración CORS para que el JavaScript del navegador acceda a la respuesta de la API.

CORS significa Cross-Origin Resource Sharing. Permite que un servidor opte por ciertas interacciones entre orígenes en el navegador dentro del modelo de seguridad de mismo origen. La política la aplica el navegador, mientras que el servidor declara lo que permite a través de campos de respuesta. Una aplicación no puede resolver una solicitud entre orígenes denegada añadiendo campos de permiso de respuesta a su propia solicitud saliente.

No todas las solicitudes entre orígenes se someten a preflight

Algunas solicitudes entre orígenes entran dentro de las reglas de métodos y campos incluidos en la lista segura de CORS y no necesitan preflight. Las condiciones exactas incluyen el método, los valores de los campos de solicitud y el comportamiento relevante de Fetch. Una solicitud GET con un campo que no está en la lista segura puede requerir un preflight, mientras que un POST adecuadamente restringido puede evitarlo. El nombre del método por sí solo es, por tanto, una regla de decisión incompleta.

Los desencadenantes comunes incluyen métodos fuera del conjunto de lista segura, un campo Authorization y un tipo de contenido JSON que no está entre los tipos de medios de la lista segura. Esos ejemplos explican muchas trazas de red del navegador, pero la prueba completa pertenece a las reglas de Fetch. Evita describir todas las GET como simples o todos los POST como sometidos a preflight. Inspecciona la configuración real de la solicitud.

La explicación de la solicitud de preflight del navegador distingue la solicitud preliminar OPTIONS de la solicitud real. Un servidor puede recibir solicitudes que no necesitan preflight mientras que el navegador aún se niega a exponer sus respuestas a JavaScript. Por lo tanto, CORS no debe describirse como una barrera universal que impide que todas las solicitudes entre orígenes lleguen a un servidor.

El navegador describe el método y los campos previstos

El preflight incluye Origin para identificar el origen que realiza la llamada. Access-Control-Request-Method nombra el método que el navegador propone usar para la solicitud real. Access-Control-Request-Headers enumera los nombres de campos de solicitud relevantes que necesitan permiso. Estas son descripciones de una operación propuesta; no significan que la solicitud OPTIONS en sí misma realice esa operación o transporte la carga útil completa de la aplicación.

El servidor responde con campos que describen los orígenes, métodos y campos de solicitud permitidos, según corresponda. El navegador evalúa esas declaraciones frente a la solicitud propuesta. Un manejador genérico de OPTIONS exitoso es insuficiente cuando omite el permiso requerido u otorga un método diferente. Mantén la comparación precisa para que el diagnóstico identifique qué parte de la política falló.

Una solicitud de aplicación sigue siendo un intercambio separado. Una vez que llega, la API valida sus credenciales, parámetros y permisos. Su respuesta también necesita los campos CORS apropiados para el acceso del navegador. Superar la verificación preliminar no hace que una operación de aplicación posterior no autorizada o mal formada tenga éxito, y no exime a la respuesta real del manejo según la política de orígenes.

Las credenciales hacen que la configuración de origen sea más específica

Las solicitudes con credenciales desde el navegador requieren que la política CORS de respuesta coincida con el modo de credenciales y el origen solicitante. No se puede usar un origen comodín permitido como sustituto general de un origen explícito al exponer una respuesta con credenciales. El servidor también necesita el permiso de credenciales apropiado. Configure estos campos desde una política de orígenes controlada en lugar de reflejar entrada arbitraria sin comprobarla.

Las cookies introducen reglas adicionales más allá de CORS. Una solicitud puede cumplir su política CORS mientras la entrega de cookies está limitada por los atributos de las cookies o el comportamiento de privacidad del navegador. A la inversa, la presencia de una cookie no establece que un servidor haya aceptado la sesión. Mantenga la entrega de cookies, la exposición CORS y la autorización de la aplicación como cuestiones de diagnóstico separadas.

El La guía sobre credenciales CORS y campos de respuesta cubre estas interacciones. Un preflight normalmente excluye credenciales bajo el modelo estándar, incluso cuando la solicitud de aplicación propuesta usa credenciales. Un middleware que requiere una sesión iniciada para cada solicitud OPTIONS puede, por lo tanto, bloquear la negociación antes de que se evalúe la solicitud de aplicación autorizada.

Un preflight fallido y una llamada de API fallida son diferentes

Un preflight fallido puede impedir que el navegador envíe la solicitud de aplicación propuesta. En ese caso, la ruta de la API puede no tener ninguna operación de aplicación correspondiente en sus registros, mientras que la puerta de enlace registra OPTIONS. Comience el diagnóstico determinando qué intercambio se produjo. Un error CORS genérico en la consola no identifica por sí mismo si el problema lo causó el enrutamiento, la política de campos, las credenciales o la respuesta real.

Si la solicitud de aplicación sí llegó al servidor, inspeccione su propio estado y los campos CORS de la respuesta. Un servicio puede devolver un cuerpo de error útil que el JavaScript del navegador no puede leer porque la respuesta de error omitió el permiso de origen. Aplique la política CORS prevista de forma coherente a las respuestas de éxito y de error admitidas, preservando al mismo tiempo la autorización normal de la API. No convierta cada fallo en un cambio de la lista de orígenes permitidos.

Una solicitud OPTIONS no siempre es un preflight CORS. HTTP define OPTIONS de forma más general como una solicitud sobre las opciones de comunicación para un recurso de destino. Las semánticas de HTTP OPTIONS y la presencia de los campos de solicitud CORS ayudan a distinguir un preflight de navegador de una solicitud OPTIONS emitida manualmente u otra comprobación de infraestructura. Diagnostique la solicitud que realmente está presente en lugar de basarse solo en su nombre de método.

El almacenamiento en caché del preflight tiene su propio ciclo de vida

Los navegadores pueden almacenar en caché un permiso de preflight satisfactorio según las reglas aplicables, incluidas Access-Control-Max-Age y los límites de implementación. Esa caché es distinta del contenido de respuesta de aplicación almacenado en caché ordinariamente. Puede explicar por qué una solicitud posterior aparece sin un nuevo intercambio OPTIONS. La ausencia de un preflight en una traza no demuestra que la solicitud nunca lo requeriría.

El alcance del almacenamiento en caché también depende del contexto de la solicitud, el origen, el destino, el método y los permisos de campos. Una verificación exitosa para una ruta o conjunto de campos no es una aprobación general para todas las operaciones en el host. Al depurar, registre el método propuesto y los campos de solicitud junto con la URL de destino. Comparar trazas sin esos detalles puede hacer que diferencias normales de política parezcan inconsistentes.

Un servidor que devuelve distintos permisos de origen para distintos llamantes debe tener en cuenta el comportamiento de la caché intermediaria. Las reglas de selección de caché HTTP explican cómo debe representarse la variación de la respuesta para evitar una reutilización inapropiada. Cuando una respuesta de aplicación varía según Origin, configure la variación de caché relevante en lugar de permitir que la declaración de origen de un llamante se reutilice indiscriminadamente para otro.

Depure el intercambio desde el origen hasta la aplicación

Comience con el origen completo de la página que realiza la llamada y el destino final de la API. Compruebe si una redirección o puerta de enlace enruta OPTIONS de manera diferente al método de la aplicación. Compare el método y los campos propuestos con la política explícita del servidor. Luego inspeccione si la solicitud real llegó y si su respuesta incluye los campos CORS esperados. Esta secuencia localiza el fallo sin debilitar la política indiscriminadamente.

Un cliente de línea de comandos puede ayudar a inspeccionar una respuesta HTTP, pero no reproduce por sí mismo la aplicación de CORS del navegador. Que una solicitud tenga éxito desde un proceso de backend solo prueba que este proceso obtuvo una respuesta bajo su propio contexto de red y credenciales. El navegador sigue evaluando las reglas de origen. Cambiar el cliente a un modo que oculte la respuesta no crea permiso para leer contenido de respuesta protegido.

Mantenga los diagnósticos saneados. No se deben pegar valores de autorización y cookies en trazas compartidas. Por lo general, los nombres de los campos, el origen, la ruta, el método, el estado y los valores de los campos de permiso son suficientes para explicar un desajuste CORS. Si la aplicación toca registros personales, capture solo el contenido mínimo necesario para la investigación autorizada y mantenga esa captura dentro del límite de acceso apropiado.

La automatización de navegadores sigue respetando el modelo de origen

Mantén la conexión de control del navegador separada del JavaScript que se ejecuta dentro de la página de destino. Un cliente de automatización que llega a un navegador en la nube y un script de página que llega a una API de origen cruzado son interacciones de red diferentes. El éxito en el canal de control no puede demostrar que la llamada de la API de la página superó CORS. Observa la solicitud de destino y su respuesta correspondiente al explicar a qué podía acceder la página.

El Flujo de trabajo de solicitudes Fetch es una lectura relacionada para clientes HTTP, y Precios de Scrapeless cubre el uso del servicio de navegador. Para una prueba autorizada, define el origen esperado, la operación y el resultado visible en la página. Una observación del navegador que apruebe debe confirmar tanto el intercambio de políticas como el comportamiento resultante de la aplicación, en lugar de detenerse en un estado OPTIONS.

Conclusión

Una preflight evalúa una operación propuesta específica de origen cruzado antes de que continúen ciertas solicitudes del navegador. Inspecciona el origen que llama, el método, los nombres de los campos, el modo de credenciales y ambas respuestas. Mantén las comprobaciones de permisos del navegador separadas de la autorización de la API y diagnostica la política en el componente que posee el intercambio fallido.