¿Los alias de host de API pueden eludir la revisión de destino?

Una revisión de destino solo aporta valor si revisa el nombre que recibe la credencial. Si un equipo aprueba https://api.example.test pero deja a los agentes usar libremente https://api-us.example.test, https://gateway.example.test o un endpoint de compatibilidad proporcionado por un proveedor, la aprobación describe una intención, no un límite.

He visto que esto falle de la forma más aburrida posible: alguien aprueba un nombre de host conocido, una variable de despliegue apunta a un alias regional y el mismo token de portador funciona. No hizo falta un exploit espectacular. El equipo simplemente tenía más nombres de destino de los que admitía su proceso de revisión.

La primera corrección es conceptual. Un registro CNAME, una URL base alternativa, una redirección, una dirección IP y una autoridad HTTP están relacionados, pero no son intercambiables. Tratarlos como si fueran lo mismo produce revisiones que parecen cuidadosas y controles que filtran credenciales.

Una revisión de destino solo cubre el host literal

Revisar api.example.test no aprueba api-eu.example.test, proxy.example.test ni api.example.test.evil.invalid. La credencial debe enviarse únicamente a un nombre de host exacto y normalizado que figure en un inventario explícito para esa credencial.

Los equipos suelen empezar con una regla informal como «este token es para la API de Example». Es una declaración de propiedad, no una regla de destino. Una empresa puede operar muchos dominios, un proveedor puede mover tráfico tras varios nombres y un tercero puede alojar una parte del perímetro del proveedor. El cliente HTTP necesita una URL concreta. Tu control también.

Escribe el límite en términos que un analizador de URL pueda comparar:

• esquema: normalmente https
• nombre de host: nombre de host ASCII en minúsculas tras procesar IDNA
• puerto: el puerto explícito o el predeterminado del esquema
• política de ruta: solo si la credencial está limitada a una superficie concreta de la API

No sustituyas la lista de nombres de host por una comprobación de sufijo. endsWith("example.test") acepta notexample.test. endsWith(".example.test") sigue aceptando todos los subdominios presentes y futuros. Puede ser aceptable en una malla de servicios interna con un solo propietario y controles sólidos de emisión. Para una credencial que puede modificar datos de producción, suele ser una salida fácil.

La pregunta incómoda es si una persona debe aprobar cada nombre de host antes de usarlo. Para un token con privilegios altos, sí. Para un token de alcance limitado que se usa con un proveedor que publica muchos endpoints regionales, aprueba una lista mantenida y convierte cada incorporación en un cambio deliberado. El coste de una revisión más es menor que el de explicar por qué un token llegó a un nombre de host que nadie registró.

Esto también separa el control de destino de la revisión del contenido de la solicitud. Una persona revisora puede estar cómoda con un GET hacia un host aprobado y rechazar un POST que modifica la facturación. Son cuestiones distintas. No afirmes que una comprobación de nombre de host decide si la solicitud es segura. Decide adónde puede ir la credencial.

Los CNAME cambian la ruta, no el host HTTP

Un CNAME cambia la resolución DNS. Por sí solo, no reescribe el nombre de host de la URL, la cabecera HTTP Host ni la indicación de nombre de servidor TLS que envía un cliente HTTPS convencional.

Supongamos que un agente llama a esta URL:

https://api.example.test/v1/orders

El DNS puede responder:

api.example.test.  300  IN  CNAME  api.edge.vendor.test.
api.edge.vendor.test. 300 IN A      203.0.113.42

La conexión TCP llega a 203.0.113.42, quizá a infraestructura operada por el proveedor. El cliente debe seguir solicitando api.example.test en TLS y enviar Host: api.example.test. Si el servidor no presenta un certificado válido para ese nombre original, la validación del certificado debe fallar. Si lo presenta, el servidor está autorizado a terminar el tráfico de ese nombre, al menos en ese momento.

Esta distinción importa porque desmonta una solución popular, pero errónea: aprobar el destino del CNAME como si fuera la autoridad de la API. El nombre de destino es evidencia de enrutamiento. Puede ayudarte a entender adónde va el tráfico, pero no sustituye la revisión del nombre de host de la URL que recibe la cabecera de autorización.

RFC 1034 describe un CNAME como un alias de otro nombre de dominio y exige que la búsqueda continúe con el nombre canónico. Eso explica el comportamiento del resolvedor, no una decisión sobre credenciales HTTP. DNS no sabe nada de tokens de portador, ámbitos de API ni aprobaciones de cambios.

Un CNAME cobra relevancia para la seguridad en cuatro casos prácticos:

1. El nombre DNS pertenece a otro equipo o proveedor, de modo que un cambio de registro puede alterar dónde termina la autoridad aprobada.
2. La dirección resuelta entra en una red inesperada, como un rango interno o una dirección de metadatos de la nube.
3. Un control aprueba nombres a partir de la salida de DNS en vez de la autoridad de la URL, permitiendo que una relación de alias sustituya una decisión de autorización real.
4. La aplicación construye una segunda URL a partir del nombre resuelto, el destino de redirección o un resultado de descubrimiento de servicios y después reenvía las credenciales.

El cuarto caso filtra tokens. Los tres primeros debilitan la revisión y hacen más probable una filtración futura. Merecen pruebas y responsables distintos.

Un CNAME tampoco te protege de la reasignación DNS. Si un nombre de host permitido por tu cliente resuelve más tarde a otra dirección, el cliente puede abrir una conexión nueva a esa dirección. Para destinos que controlas, supervisa los registros y limita dónde pueden resolver. Para destinos que no controlas, no supongas que una única consulta DNS demuestra una seguridad permanente.

Las URL base alternativas crean una elusión más silenciosa

Las URL base alternativas son la elusión más habitual porque cambian directamente la autoridad HTTP. Son los nombres ocultos en variables de entorno, valores predeterminados de SDK, datos de prueba y notas de migración.

Un servicio puede documentar todas estas opciones por motivos legítimos:

https://api.example.test
https://api-us.example.test
https://sandbox-api.example.test
https://gateway.example.test/service-a
https://tenant-42.api.example.test

Hoy pueden terminar en el mismo perímetro. Eso no significa que merezcan la misma credencial. El endpoint de producción puede aceptar un token a nivel de cuenta; el endpoint sandbox puede enviar solicitudes a otro sistema; la ruta de la puerta de enlace puede elegir otro servicio; el nombre de host del inquilino puede enrutar según la identidad del cliente. Los nombres codifican diferencias operativas que una comparación de IP oculta.

El patrón de fallo es previsible. Una base de código define API_BASE_URL con un valor predeterminado de producción. Una persona desarrolladora lo cambia para una prueba regional o una migración. La capa que inyecta credenciales ve una URL que aún parece relacionada y añade la cabecera. La revisión de destino estaba ligada a una etiqueta como «API de Example», no a la autoridad exacta, así que nadie detecta la ampliación.

Corrige el modelo de datos antes de corregir el código. Cada credencial necesita su propio registro con cuatro campos que los revisores puedan inspeccionar:

credential: orders-write-prod
allowed authorities:
  https://api.example.test:443
  https://api-us.example.test:443
purpose: create and amend production orders
owner: commerce operations
review trigger: DNS change, new endpoint, scope change

La palabra «autoridades» es deliberada. Guarda juntos el esquema, el host y el puerto. Que un nombre de host sea válido sobre HTTPS no implica que esté aprobado en un puerto no estándar. Una ruta puede importar cuando una puerta de enlace compartida usa un host para API no relacionadas, aunque las reglas de ruta requieren una normalización cuidadosa y nunca deben sustituir credenciales separadas cuando los ámbitos son distintos.

No dependas de la lista publicada por un proveedor como si fuera tu inventario final. La documentación del proveedor te dice qué puede existir. Tu código y tu configuración de despliegue te dicen qué puedes llamar. Necesitas ambas cosas, además de los nombres que quedan en automatizaciones antiguas después de una migración.

La audiencia de la credencial es el límite

La pregunta correcta no es «¿qué servidores pertenecen a este proveedor?». Es «¿qué autoridades HTTP pueden recibir este secreto exacto en esta ruta de solicitud exacta?».

Un token de portador no tiene una restricción de audiencia incorporada, salvo que el emisor la aplique. Cuando un cliente lo pone en una cabecera Authorization, cualquier destinatario que reciba la cabecera puede intentar usarlo. La autenticación básica y las cabeceras de claves de API personalizadas tienen el mismo problema de transporte. El cifrado de transporte protege la solicitud durante el trayecto, pero no restringe la audiencia en la capa de aplicación.

Los tokens de acceso OAuth a veces incluyen una reclamación aud. Eso ayuda al servidor de recursos a rechazar un token destinado a otra parte, pero no confundas el rechazo del lado del servidor con un comportamiento seguro del cliente. Enviar un token al nombre de host equivocado sigue exponiéndolo a ese host y lo deja en sus registros de acceso, telemetría o cola de incidentes. Un token rechazado es mejor que uno aceptado, pero sigue siendo una divulgación evitable.

La vinculación de credenciales tiene dos partes:

• El cliente inyecta la credencial solo para una autoridad revisada.
• El emisor de la credencial le da el alcance, la audiencia y el entorno más limitados que resulten prácticos.

Necesitas ambas. La vinculación a hosts evita que un error del cliente disperse un secreto por servicios cercanos. El alcance limita el daño si el host esperado, sus registros o su configuración de rutas se ven comprometidos.

Por eso una sola clave de API para toda la organización es un acuerdo tan malo. Facilita la configuración y complica la respuesta a incidentes. Si la misma clave llega a una API de pagos, un recopilador de analítica y una puerta de enlace de pruebas, no puedes revocar el acceso a un destino sin interrumpir los tres. Las credenciales separadas convierten un error de enrutamiento en una rotación limitada, en lugar de una caída que moviliza a todo el equipo.

Haz inventario de nombres desde el código, DNS y la documentación del proveedor

Un inventario de endpoints es creíble cuando recoge el uso observado, no solo la arquitectura planificada. Constrúyelo a partir del código, la configuración de despliegue, DNS y la documentación del proveedor, y después concilia las diferencias.

Empieza con una búsqueda en el repositorio de esquemas de URL y ajustes de URL base. Incluye código de aplicación, scripts de shell, definiciones de CI, archivos de ejemplo, definiciones de infraestructura y datos de prueba. Registra cada nombre de host, incluso los que parezcan obsoletos. Los nombres antiguos siguen siendo peligrosos cuando un trabajo cron o un prompt de agente todavía los invoca.

Después resuelve cada candidato mediante el mismo contexto de resolución que usa la máquina que hace las llamadas. En macOS u otro sistema Unix, una inspección básica se ve así:

dig +noall +answer api.example.test CNAME A AAAA

Una salida útil podría tener esta forma:

api.example.test.       300 IN CNAME api.edge.vendor.test.
api.edge.vendor.test.    60 IN A     203.0.113.42
api.edge.vendor.test.    60 IN AAAA  2001:db8::42

Haz consultas separadas para CNAME, A y AAAA si tu resolvedor no devuelve toda la cadena en una respuesta. Registra la fecha de la consulta y el resolvedor utilizado, porque el DNS dividido puede dar respuestas diferentes a un portátil, un ejecutor de CI y un host de producción. No copies la dirección IP resultante en una lista permanente de destinos permitidos para una API de internet. Los perímetros cambian de dirección con frecuencia. Regístrala como evidencia para la revisión y alerta ante cambios inesperados.

Después crea una tabla de inventario con una fila por autoridad, no una por proveedor. Debe responder estas preguntas sin necesidad de una reunión:

No inventes una fila solo porque un proveedor tenga un endpoint. Márcalo como no usado hasta que el código, la configuración o una migración aprobada lo necesite. El inventario debe hacer visible la capacidad accidental, no documentar todas las posibilidades.

La guía de prevención de SSRF de OWASP señala algo relacionado: cuando una aplicación se comunica solo con aplicaciones de confianza identificadas, una lista de permitidos es viable, pero la validación de dominios por sí sola no resuelve el comportamiento de DNS. Esa guía trata sobre SSRF, pero la lección operativa también se aplica aquí. Una lista de nombres de host solo es sólida cuando sabes quién mantiene los nombres, a qué resuelven y si quien llama puede convertir más adelante un nombre revisado en una solicitud distinta.

Las redirecciones necesitan su propia revisión

Una redirección es una decisión de destino nueva. Un cliente que sigue redirecciones automáticamente puede salir de una autoridad aprobada después de la primera solicitud, y una cabecera de autorización no debe acompañarlo.

Para llamadas de API con credenciales, empieza con las redirecciones desactivadas. Trata una respuesta 301, 302, 303, 307 o 308 como una respuesta que necesita una decisión explícita. Si la URL nueva ya figura en la lista exacta de autoridades de la credencial y el comportamiento del método y del cuerpo es aceptable, haz una solicitud separada hacia ella. Si no figura en la lista, detente.

Los códigos de estado no son intercambiables. Un 303 suele cambiar una solicitud a GET; 307 y 308 conservan el método y el cuerpo de la solicitud. Repetir automáticamente un POST con una cabecera de autorización tiene más consecuencias que un GET aparentemente inocuo, sobre todo si cambia el host.

Prueba el comportamiento de la biblioteca HTTP específica que uses. Algunos clientes eliminan cabeceras sensibles cuando cambia el host, otros conservan cabeceras en condiciones que quizá no esperes, y los envoltorios pueden modificar los valores predeterminados. Una prueba debe capturar la solicitud que llega a un segundo host controlado y verificar que no recibió ni la credencial ni una copia del cuerpo. El nombre de una biblioteca no demuestra su política de redirecciones.

Una ruta de llamada segura es fácil de expresar:

1. Analiza la URL solicitada.
2. Normaliza y compara su autoridad con el registro de la credencial.
3. Inyecta la credencial solo después de esa coincidencia.
4. Envía una sola solicitud con las redirecciones desactivadas.
5. Si llega una redirección, analiza y revisa la nueva autoridad antes de hacer otra solicitud.

Esta secuencia también protege contra un fallo más sutil: inyectar la cabecera en un cliente genérico antes de comprobar el destino. Cuando el código adjunta un token a un objeto de solicitud reutilizable, los cambios posteriores de URL pueden llevarlo a un lugar no previsto. Vincula las credenciales en el último momento responsable, cuando ya se conoce la URL final.

Los nombres de host compartidos exigen credenciales separadas

Un solo nombre de host puede alojar varias API, entornos e inquilinos. La coincidencia exacta de host es necesaria, pero no puede expresar todas las diferencias de seguridad detrás de una puerta de enlace compartida.

Considera https://gateway.example.test. Una ruta puede crear facturas, otra enviar telemetría y una tercera administrar usuarios. Si un token de portador autoriza las tres, una revisión de host solo ofrece protección general. Un fallo que cambie /telemetry por /admin sigue estando en el nombre de host aprobado y aun así funciona.

La respuesta adecuada suele ser usar credenciales separadas con ámbitos distintos. Dale al cliente de telemetría un token que no pueda administrar usuarios, incluso si ambas llamadas van al mismo host. Si el proveedor admite audiencias o indicadores de recurso, úsalos. Si solo admite tokens amplios, separa las cuentas de servicio o elige un límite de integración más seguro, en vez de fingir que una lista de rutas permitidas resuelve la autorización.

Las reglas de ruta siguen teniendo su lugar. Pueden detectar errores de programación y hacer que la intención sea revisable. Pero las rutas son más fáciles de manejar mal que los hosts: la codificación porcentual, las barras repetidas, los segmentos con puntos, las reescrituras de la puerta de enlace y las redirecciones de versión complican la comparación. Normaliza con el mismo analizador de URL y la misma biblioteca de solicitudes que envía la llamada. Nunca tomes una decisión de seguridad con una comprobación de subcadena escrita a mano.

El mismo razonamiento se aplica a los puertos. api.example.test:443 y api.example.test:8443 son autoridades distintas. Un proxy inverso puede encaminarlos a servicios diferentes, y quien prueba el segundo puerto puede asumir que la primera revisión también lo cubre. Registra ambos o no permitas ninguno.

Sitúa las aprobaciones donde una persona aún pueda juzgar el destino

Una aprobación que solo dice «permitir llamada de API» pide al revisor que firme un cheque en blanco. El aviso necesita el método, la autoridad completa normalizada, la ruta de la solicitud, la identidad de la credencial y el proceso solicitante. De lo contrario, una persona no tiene una forma práctica de detectar que el agente cambió de la API de producción a un nombre de host de compatibilidad olvidado.

Sallyport conserva la credencial en su bóveda cifrada y realiza la acción HTTP en lugar de entregar el secreto al agente. Esto resulta útil porque la aprobación puede situarse en el límite de la acción, donde el destino y el proceso solicitante se ven a la vez.

No conviertas una pantalla de aprobación en un ritual. La aprobación por sesión funciona para una ejecución conocida y breve de un agente que llama a un conjunto estable de autoridades aprobadas. Exige una confirmación por llamada para credenciales que pueden mover dinero, borrar datos o acceder a endpoints de administración. La fricción debe corresponder a la consecuencia de una llamada errónea, no a la paciencia del revisor.

Sallyport no tiene deliberadamente un lenguaje de políticas ni un motor de reglas, por lo que no debe usarse como excusa para omitir el inventario de endpoints. El control de acceso a su bóveda y sus autorizaciones responden a si un proceso puede usar una credencial ahora. El registro de credenciales debe seguir respondiendo qué autoridad tiene derecho a recibirla.

Los registros de actividad deben conservar evidencia suficiente para reconstruir la decisión después: autoridad solicitada, ruta resuelta cuando esté disponible, método, estado, sesión solicitante y registro de credencial aplicado. No registres el secreto ni cargas útiles sensibles completas solo para mejorar el rastro de auditoría. Un registro que crea un segundo almacén de secretos no mejora la auditoría.

Vuelve a comprobar los alias tras cada cambio de DNS e integración

La vinculación de destino se deteriora cuando cambian DNS, los endpoints del proveedor o los ajustes de despliegue. Haz que la revisión del inventario forme parte de esos cambios, en lugar de convertirla en un ejercicio anual que descubre una pila de nombres obsoletos.

Inicia una revisión cuando alguien añade o modifica un CNAME, cambia un registro A o AAAA de un nombre interno permitido, introduce un endpoint regional, sustituye un SDK, cambia una puerta de enlace de API o añade una redirección. El revisor debe comparar las listas de autoridades anteriores y nuevas, y luego decidir si la credencial existente puede seguir el cambio. Los cambios de propiedad del DNS merecen la misma atención que los cambios de propiedad del código.

Para los nombres que controlas, alerta cuando un nombre de host aprobado empiece a resolver a direcciones privadas, de bucle local, de enlace local o internas inesperadas. Es una defensa contra SSRF además de una defensa de credenciales. Para nombres públicos de proveedores, alerta ante cambios en el destino CNAME y cambios importantes en los rangos de direcciones, e investiga en vez de bloquear automáticamente cada rotación de CDN.

Mantén una pequeña prueba de regresión junto a la integración. Debe probar una URL aprobada, una URL base alternativa no listada, un host con un sufijo engañoso, un puerto alternativo explícito y una redirección a otro host. El resultado esperado no es solo que falle una conexión de red. El cliente debe negarse a adjuntar la credencial antes de que cualquier solicitud llegue al destino no listado.

Esa última condición es el estándar que conviene mantener. Si el agente puede enviar primero el secreto y descubrir después que el destino era incorrecto, la revisión falló cuando importaba.