Planteamiento y contexto
Gateway API v1.5 trasladó el filtro CORS de HTTPRoute al canal Standard. Este permite que una regla de ruta declare los orígenes, métodos, encabezados de solicitud, encabezados expuestos y el tiempo de caché de preflight permitidos. La pregunta evalúa si puedes ubicar la política de origen cruzado en el límite de gateway adecuado, preservando al mismo tiempo la autorización del servidor y la verificación específica de la implementación.
Qué evalúan los entrevistadores
Los entrevistadores buscan que se distinga entre la protección CORS del navegador, los encabezados de respuesta del gateway y la autorización de identidad real. Una respuesta sólida cubre la ruta de preflight de OPTIONS, las credenciales y los orígenes, el riesgo de los comodines, el mínimo privilegio por ruta y si la implementación de Gateway admite el filtro. Escribir únicamente allowOrigins: "*" no demuestra un diseño seguro.
Preguntas para aclarar antes de responder
¿Qué orígenes y recursos necesitan acceso de origen cruzado?
Enumera los orígenes de producción, vista previa (preview), administración y desarrollo local, autorizándolos por ruta en lugar de hacerlo en todo un dominio. La lista debe ser auditable y tener expiración, manteniendo los orígenes de prueba fuera de producción.
¿Se incluyen credenciales?
Confirma si las solicitudes transportan cookies, autenticación HTTP u otra credencial. Las solicitudes con credenciales necesitan una política de orígenes y encabezados de respuesta más estricta; los orígenes arbitrarios no deben combinarse con credenciales por defecto.
¿Quién es responsable de la autorización y del despliegue de políticas?
Define las responsabilidades del Gateway, de la aplicación y del servicio de identidad. CORS controla si los scripts del navegador pueden leer una respuesta; no reemplaza la validación de tokens, el aislamiento de inquilinos (tenants) ni la autorización de recursos.
Estructura de respuesta en 30 segundos
“Primero delimito los orígenes por HTTPRoute y recurso de negocio en lugar de ampliar todo el Gateway. Para cada ruta especifico orígenes, métodos, encabezados, encabezados expuestos y maxAge; las rutas con credenciales utilizan orígenes revisados y encabezados de respuesta verificados. Pruebo el preflight OPTIONS, la solicitud real, los errores y la expiración de la caché, y confirmo que la implementación del Gateway admita el filtro. Finalmente, verifico CORS como un límite de acceso del navegador de forma independiente de la autorización, auditoría y reversión (rollback) del servidor.”
Respuesta detallada paso a paso
Paso 1: Establecer el mínimo privilegio por ruta
Registra el recurso, los orígenes, los métodos permitidos y las necesidades de encabezados para cada HTTPRoute. Los recursos públicos de solo lectura y los recursos de cuentas con credenciales deben usar reglas separadas para que una sola política permisiva no abarque todo el dominio.
Paso 2: Configurar los campos del filtro
Establece allowOrigins, allowMethods, allowHeaders, exposeHeaders y maxAge según la necesidad real. Revisa los patrones de origen cotejándolos con la documentación de la implementación y la política de seguridad; prioriza orígenes explícitos sobre comodines innecesarios.
Paso 3: Manejar el preflight correctamente
El navegador envía OPTIONS con Origin, Access-Control-Request-Method y, posiblemente, Access-Control-Request-Headers. El Gateway debe devolver encabezados CORS coherentes con la política y rechazar claramente las solicitudes no permitidas en lugar de reenviar el preflight a un backend que no entienda CORS.
Paso 4: Separar las credenciales de la autorización
Diseña el comportamiento de las credenciales con atributos de cookies, protección CSRF, validación de tokens y autorización en el servidor. Incluso si un navegador bloquea el acceso mediante scripts, el servidor debe autorizar la solicitud en sí.
Paso 5: Verificar la implementación y la reversión
Confirma que el controlador del Gateway admita el filtro CORS de v1.5 Standard y la semántica de sus campos. Reproduce el preflight, las solicitudes reales, los fallos, las redirecciones y el comportamiento de la caché con un navegador y curl; registra los cambios de política, las métricas y los pasos de reversión.
Respuesta de ejemplo de alta calidad
Delimitaría los orígenes por HTTPRoute, manteniendo separada una interfaz de búsqueda pública de una interfaz de cuenta con credenciales. Cada regla especificaría los orígenes, métodos, encabezados de solicitud, encabezados expuestos y el tiempo de caché de preflight permitidos; el acceso con credenciales utilizaría únicamente orígenes de producción revisados. Antes del despliegue, probaría OPTIONS y las solicitudes reales en un navegador, incluidos errores, redirecciones y expiración de caché; luego usaría curl y las condiciones de estado (status conditions) del controlador del Gateway para confirmar que la configuración esté activa. CORS solo define el límite de lectura del navegador; el servidor sigue aplicando la autorización de identidad, inquilino y recursos. Cualquier diferencia semántica del controlador se rastrearía en una matriz de compatibilidad con un mecanismo de respaldo (fallback) en la capa de aplicación.
Errores comunes
- Error: Permitir todos los orígenes de manera global. → Por qué falla: Cualquier ruta puede volverse legible para los scripts del navegador, lo que dificulta la auditoría y la revocación. → Solución: Construir el conjunto de orígenes más reducido por cada HTTPRoute.
- Error: Configurar solo las solicitudes reales e ignorar OPTIONS. → Por qué falla: Los métodos o encabezados complejos se bloquean primero en el preflight. → Solución: Probar el preflight y las respuestas reales por separado.
- Error: Tratar CORS como autorización. → Por qué falla: Los clientes que no son navegadores aún pueden llamar al servicio directamente. → Solución: Mantener las comprobaciones de identidad, inquilino y recursos en el servidor.
- Error: Enviar campos de v1.5 sin probar el controlador. → Por qué falla: Las implementaciones pueden ignorarlos, rechazarlos o interpretarlos de manera diferente. → Solución: Comprobar matrices de compatibilidad, condiciones de estado y reproducciones con tráfico real.
Preguntas de seguimiento y respuestas
Pregunta de seguimiento 1: ¿Por qué no configurar CORS únicamente en la aplicación?
La aplicación puede gestionar la política específica de los recursos, mientras que el Gateway puede encargarse del preflight a nivel de ruta y del límite entre servicios. Cuando ambas capas configuran encabezados, define la precedencia para evitar duplicados o conflictos.
Pregunta de seguimiento 2: ¿Debería maxAge ser siempre lo más largo posible?
No. Una caché de preflight más prolongada reduce el tráfico de OPTIONS pero retrasa la revocación. Elígelo en función de la frecuencia de cambios, el riesgo y el comportamiento del navegador, y mantén una ruta con orígenes versionados o con un TTL corto para retiradas urgentes.
Pregunta de seguimiento 3: ¿Cuándo es aceptable un origen comodín?
Únicamente para recursos genuinamente públicos sin credenciales y con una evaluación de riesgos aprobada. Los datos de cuentas, administración e inquilinos deben utilizar orígenes explícitos y un comportamiento de comodines probado.
Pregunta de seguimiento 4: ¿Cómo detectarías un origen permitido por error?
Registra Origin, la ruta, el resultado de preflight y la versión de la política; audita los cambios de origen. Ejecuta una matriz automatizada con orígenes permitidos, no permitidos y expirados, bloqueando el despliegue cuando los encabezados de respuesta difieran de la política.