Verificador CORS

El funcionamiento de la política CORS y su evaluación

El intercambio de recursos de origen cruzado (CORS) es un mecanismo de seguridad que emplean los navegadores web para restringir o permitir que el código JavaScript de una página web realice peticiones a un origen distinto del que sirve el propio documento. Cuando se realiza una solicitud de este tipo, el navegador evalúa los encabezados HTTP de la respuesta del servidor para determinar si concede acceso a los datos.

El Verificador CORS analiza la viabilidad de estas interacciones simulando el comportamiento del navegador. Para ello, procesa los encabezados de respuesta HTTP proporcionados y los contrasta con los parámetros de la solicitud que se desea realizar: el origen, el método HTTP, los encabezados personalizados y la presencia de credenciales. El procesamiento de estos datos se realiza de manera local; los encabezados y los detalles de la solicitud permanecen en tu navegador, por lo que BroBroGo no recibe ni guarda nada. El analizador no realiza conexiones de red, no lee direcciones URL externas, no establece cookies, no consulta registros DNS ni TLS, ni modifica la configuración de ningún servidor.

Configuración de los parámetros de entrada

Para evaluar una política de origen cruzado, se deben definir los siguientes campos en la interfaz del evaluador:

• Respuesta al cheque: Permite seleccionar entre "Respuesta real" o "Respuesta previa al vuelo". La primera opción analiza si el navegador permitirá leer el cuerpo de una respuesta estándar, mientras que la segunda evalúa la respuesta de una petición de tipo OPTIONS (preflight).
• encabezados de respuesta HTTP: Campo de texto donde se deben pegar los encabezados devueltos por el servidor. Si se analiza una respuesta de verificación previa, es necesario incluir también la línea de estado HTTP. El límite máximo de entrada es de 200.000 caracteres. Si el campo se deja vacío, se muestra el mensaje "Pegue los encabezados de respuesta HTTP antes de verificar.". Si se supera el límite, el sistema devuelve "Esta respuesta es inusualmente grande. Manténgalo debajo de los caracteres ‹max›.". Si el formato es incorrecto, se generarán errores como "La línea ‹line› no es un encabezado HTTP ni una línea de estado válidos." o "La línea ‹line› contiene un nombre de encabezado HTTP no válido.".
• Origen de la solicitud: Especifica el esquema, el host y el puerto opcional desde el que se origina la petición (por ejemplo, https://app.example.com). Debe ser un origen puro o null, sin rutas, parámetros de consulta ni credenciales de usuario. De lo contrario, se mostrará el error "Ingrese un origen con solo un esquema, host y puerto opcional, como https://app.example.com.".
• Método solicitado: El método HTTP de la petición (como GET, POST o PUT). Si el formato es incorrecto, se muestra "Introduzca un token de método HTTP válido.". Si se introduce un método no permitido por la especificación de fetch, se devuelve "Los navegadores no permiten el método ‹method› en las solicitudes fetch.".
• Nombres de encabezado solicitados: Lista de encabezados que la aplicación web pretende enviar, correspondientes al encabezado Access-Control-Request-Headers. Se introducen separados por comas o saltos de línea. Si un encabezado no cumple con las especificaciones de nomenclatura HTTP, se muestra el error "“‹header›” no es un nombre de encabezado de solicitud HTTP válido.".
• Incluir credenciales: Un interruptor para indicar si la solicitud incluye cookies de sesión o mecanismos de autenticación HTTP.

Interpretación de las decisiones del navegador

Tras procesar los datos, la herramienta muestra un veredicto sobre la viabilidad de la petición:

• Permitido por la respuesta CORS pegada.: Los encabezados suministrados cumplen con las reglas del navegador para los parámetros de solicitud indicados.
• Bloqueado por la respuesta CORS pegada.: La política CORS del servidor deniega el acceso bajo las condiciones especificadas.
• Los encabezados pasan, pero se desconoce el estado de la verificación previa.: Los encabezados de control de acceso son correctos, pero no se ha podido validar el estado HTTP de la respuesta de preflight.
• Ingrese una respuesta y los detalles de la solicitud, luego verifique la política CORS.: Estado que se muestra si se intenta realizar la comprobación con campos vacíos.
• Pegue una respuesta para verificar su política CORS.: Estado inicial de la interfaz antes de introducir datos.

Si existen errores de formato en el formulario, se mostrará el aviso general "Corrija la entrada resaltada y vuelva a intentarlo.".

Reglas de evaluación y gestión de credenciales

La especificación CORS impone restricciones estrictas cuando se trabaja con solicitudes que incluyen credenciales (cookies o autenticación HTTP):

1. Restricción del comodín de origen: Si se incluyen credenciales, el encabezado Access-Control-Allow-Origin no puede utilizar el valor comodín *. Debe coincidir exactamente con el origen de la solicitud.
2. Restricción de comodines en métodos y encabezados: Con credenciales activas, los comodines en Access-Control-Allow-Methods y Access-Control-Allow-Headers pierden su función de comodín y no validan de forma automática cualquier método o encabezado.
3. Requisito de credenciales explícitas: Para solicitudes con credenciales, el servidor debe responder obligatoriamente con Access-Control-Allow-Credentials: true. Si este encabezado no está presente o tiene un valor distinto, el navegador bloqueará la transacción. Si la solicitud no incluye credenciales, este encabezado no influye en la decisión.
4. Invalidez por multiplicidad: Si el encabezado Access-Control-Allow-Origin contiene múltiples orígenes o valores separados por comas, el navegador lo considerará inválido y bloqueará la petición.

El proceso de preflight (verificación previa)

Las peticiones que no se clasifican como "solicitudes simples" requieren que el navegador envíe una petición previa de tipo OPTIONS antes de realizar la solicitud real. El Verificador CORS analiza estas respuestas bajo las siguientes directrices:

• Estado HTTP: Una respuesta de preflight válida requiere un código de estado de éxito de la serie 2xx. Si no se incluye la línea de estado en el texto pegado, el resultado de la verificación previa se marcará como indeterminado.
• Métodos permitidos: El método solicitado debe figurar en Access-Control-Allow-Methods. No obstante, los métodos catalogados como seguros por la especificación CORS (CORS-safelisted) no requieren aparecer de forma explícita en dicho encabezado.
• Encabezados permitidos: Los encabezados personalizados deben estar autorizados por Access-Control-Allow-Headers. Si no se usan credenciales, el comodín * cubre todos los encabezados solicitados, con una excepción crítica: el encabezado Authorization. Este último debe figurar siempre de manera explícita en Access-Control-Allow-Headers, ya que el comodín * no lo cubre.

Preguntas frecuentes

¿Debo pegar la respuesta real o la respuesta de verificación previa? Utilice la respuesta real para comprobar si el código del navegador puede leer una respuesta. Utilice la respuesta de verificación previa para la respuesta OPTIONS que aprueba un método posterior y sus nombres de encabezado solicitados.

¿Por qué un comodín puede fallar con las credenciales? Cuando se incluyen cookies o autenticación HTTP, el origen permitido debe coincidir exactamente con el origen solicitante. Los comodines para métodos y encabezados permitidos también pierden su significado de comodín.

¿Un resultado aprobado prueba que la solicitud en vivo funcionará? No. Este resultado cubre solo la respuesta pegada y los detalles de la solicitud ingresados aquí. Los redireccionamientos, las respuestas almacenadas en caché, el cambio de las reglas del servidor, las extensiones del navegador y la respuesta real después de una verificación previa aún pueden cambiar el resultado.