Comprobar cabeceras CORS

Pegue un bloque de cabeceras para confirmar que Access-Control-Allow-Origin está presente, detectar la combinación insegura de un origen comodín con credenciales e identificar la ausencia de Vary: Origin cuando se permite un origen concreto. El resultado es determinista y explica cada hallazgo, por lo que resulta útil en revisiones de despliegue, investigaciones de incidentes, controles automatizados y tareas habituales de refuerzo de API, sin enviar solicitudes al servidor de destino.

Interprete el resultado como una revisión específica

Empiece copiando las cabeceras de respuesta exactamente como las recibió el navegador o el cliente de línea de comandos, con un par Nombre: valor por línea. Los nombres se comparan sin distinguir mayúsculas de minúsculas y los valores de Vary separados por comas se procesan como elementos independientes. El comprobador exige Access-Control-Allow-Origin porque, sin esa cabecera, no existe una política CORS de respuesta que pueda evaluar; por ello, su ausencia genera un error de entrada y no un informe inconcluso. Un resultado correcto incluye el origen permitido normalizado, si están habilitadas las credenciales, si la respuesta varía según Origin y una lista ordenada de hallazgos. El campo valid indica que no se detectaron problemas con gravedad de error. Aun así, puede haber una advertencia, por lo que los sistemas consumidores también deben revisar issue_count e issues. El alcance es deliberadamente concreto: aporta datos estables sobre dos fallos frecuentes, pero no pretende certificar todo el modelo de autorización de una aplicación. Conserve la respuesta original y el origen de la solicitud junto al resultado si este control forma parte de una auditoría.

Comprenda los orígenes comodín y las solicitudes con credenciales

Access-Control-Allow-Origin: * resulta práctico para recursos realmente públicos y sin credenciales, ya que permite que cualquier origen solicitante lea la respuesta. No debe combinarse con Access-Control-Allow-Credentials: true. Los navegadores rechazan esa pareja para el acceso CORS con credenciales y, con frecuencia, la configuración revela que el límite de confianza previsto por el servidor no se expresó correctamente. El comprobador registra la combinación como wildcard_origin_with_credentials con gravedad de error. La solución no consiste en reflejar automáticamente cualquier Origin recibido. Determine qué orígenes son de confianza, compare el Origin de la solicitud con una lista explícita de permitidos y emita un único origen aprobado solo cuando haya coincidencia. Si las cookies u otras credenciales ambientales no son necesarias, desactive las credenciales y mantenga la política pública con comodín. Recuerde además que CORS controla si los scripts del navegador pueden leer una respuesta; no sustituye la autenticación, la autorización, la protección contra falsificación de solicitudes ni un cortafuegos. Revise por separado los atributos de las cookies, los permisos, los métodos, las cabeceras expuestas y las solicitudes preliminares.

Utilice Vary: Origin para proteger las cachés compartidas

Cuando un servidor elige un valor específico de Access-Control-Allow-Origin según el Origin de la solicitud, la representación de la respuesta depende de hecho de esa cabecera. Vary: Origin informa a navegadores, proxies inversos y redes de distribución de contenido de que las respuestas generadas para orígenes distintos no son intercambiables. Si falta, una caché puede reutilizar para otra solicitud una respuesta que contiene el origen permitido de un inquilino, lo que provoca fallos intermitentes y puede debilitar las premisas de la política sobre contenido almacenado. Por eso, el comprobador genera missing_vary_origin cuando el origen permitido es específico y Vary no contiene ni Origin ni el comodín. Acepta Origin tanto en una línea con valores separados por comas como en cabeceras Vary repetidas. El hallazgo es una advertencia porque una respuesta pegada no permite saber si el origen es constante para todas las solicitudes o si el almacenamiento en caché está deshabilitado en otro punto. Confirme la lógica real del servidor y sus directivas de caché antes de cambiar producción. Si el origen se refleja dinámicamente tras validarlo con una lista permitida, añadir Origin a Vary suele ser la señal más clara y segura.