En la mayoría de las organizaciones, el inventario de API vive en la documentación de aplicaciones, archivos de esquema desactualizados o listas mantenidas por equipos individuales. Pero las aplicaciones cambian con cada versión: se agregan nuevos endpoints, los antiguos se olvidan, las rutas de prueba se quedan en producción. Los equipos de seguridad generalmente se enteran de qué APIs están activas en el tráfico real después que los equipos de aplicaciones.
Esta brecha amplifica el riesgo de shadow API y endpoints zombie. Un endpoint no documentado puede quedar completamente fuera de la política WAF; un endpoint que ya no debería estar en uso puede seguir siendo accesible. Desde el punto de vista de un atacante, estas áreas son de baja visibilidad, débilmente protegidas y vale la pena sondearlas.
Confiar únicamente en un archivo de esquema proporcionado externamente también es insuficiente. Si el esquema no está actualizado, no coincidirá con el tráfico real. El equipo de aplicaciones puede haber cambiado un endpoint sin actualizar el esquema, o una ruta que nunca aparece en el esquema puede estar ejecutándose en producción. En ese caso, la política de protección descansa en una suposición desactualizada en lugar del comportamiento real de la aplicación.
El modelo de seguridad negativa tradicional no resuelve este problema por sí solo. Bloquear patrones de ataque conocidos es importante, pero la fortaleza real en la seguridad de API es definir explícitamente los métodos, cabeceras, parámetros, tipos MIME y campos del cuerpo permitidos. Sin seguridad positiva, solicitudes maliciosas desconocidas pero aparentemente válidas pueden pasar sin ser desafiadas.
TR7 API Discovery & Schema cierra esta brecha: aprende el comportamiento de la API del tráfico real, admite la generación de esquemas desde el flujo OpenAPI o la generación de reglas desde un esquema, y lleva los controles de seguridad positiva inline.
TR7 aplica API discovery junto con aprendizaje del tráfico, esquema positivo, límites de tamaño y profundidad, y validación por campo.
TR7 puede aprender el comportamiento de rutas y métodos del tráfico real y construir patrones de endpoint. Las rutas que contienen IDs, fechas o tokens variables se normalizan en un inventario de API más legible.
Se pueden definir listas de permitidos para métodos, cabeceras, parámetros de query, claves JSON, elementos XML, campos de formulario y tipos MIME. En lugar de buscar solo patrones conocidos malos, la política declara explícitamente el comportamiento esperado de la API.
Se pueden aplicar límites como longitud de ruta, profundidad de ruta, conteo de cabeceras, conteo de queries, profundidad JSON, profundidad XML y tamaño del cuerpo raw. Estos límites garantizan que las solicitudes de tamaño excesivo o demasiado complejas se verifiquen antes de llegar al backend.
Se puede definir validación regex para cada cabecera, parámetro de query, campo de formulario o campo del cuerpo. Los formatos de email, teléfono, ID, código de país o específicos del servicio se verifican a nivel de campo.
API Discovery & Schema convierte el inventario de endpoints aprendido en reglas de seguridad positiva ejecutables.
TR7 puede analizar la información de ruta y método de las solicitudes entrantes para derivar patrones de endpoint. Rutas como `/api/users/123` y `/api/users/456` pueden agruparse bajo un único patrón lógico. Este enfoque hace visibles los endpoints que no están en la documentación pero se ejecutan activamente en producción. El inventario de API se basa en el comportamiento real del tráfico, no en suposiciones.
TR7 está posicionado para admitir un flujo de trabajo de generación de esquemas compatibles con OpenAPI a partir del comportamiento de API aprendido. En la dirección inversa, las reglas TR7 pueden generarse a partir de un esquema OpenAPI proporcionado por el usuario. Este modelo bidireccional reduce la brecha entre el tráfico real y el contrato de API documentado. El operador utiliza la misma plataforma tanto para el descubrimiento como para el enforcement.
La lista de métodos permitidos — GET, POST, PUT, DELETE, PATCH y otros — puede definirse por endpoint. Si se envía un POST a un endpoint que solo espera GET, por ejemplo, ese comportamiento puede tratarse como una violación de política. Una lista de permitidos basada en métodos es una capa de seguridad positiva simple pero efectiva. El comportamiento incorrecto o abusivo del endpoint se detecta antes.
Las cabeceras y parámetros de query permitidos pueden definirse por endpoint. Para cada campo se puede aplicar un nombre, formato de valor y validación regex. Las cabeceras o parámetros inesperados pueden vincularse a una puntuación de seguridad, alerta o bloqueo. Los datos fuera del contrato de API no se pasan al backend sin verificación.
TR7 puede construir listas de permitidos a nivel de clave JSON, elemento XML y campo de formulario. Los campos requeridos pueden definirse con mustArgs; los campos desconocidos pueden excluirse de la lista de permitidos. Esta estructura describe el cuerpo de solicitud esperado en lugar de solo buscar firmas de ataque. Los endpoints de API se protegen de una manera que se mantiene más cercana a su propio contrato.
Se pueden definir listas de permitidos para los tipos MIME permitidos para formularios y cuerpos raw. Enviar datos a un endpoint que espera JSON con un tipo de contenido diferente puede tratarse como una violación de política. Este control es especialmente importante para las APIs de carga de archivos o basadas en formularios. El tipo de contenido se convierte en una entrada directa a la decisión de seguridad.
Se pueden aplicar límites de tamaño general para cabeceras, query strings, formularios, JSON, XML y cuerpo raw. Los controles de profundidad de anidamiento de JSON y XML evitan que los payloads demasiado profundos añadan carga al parser y al backend. También se pueden definir límites como conteo de claves, conteo de valores, longitud por campo y conteo de duplicados. Estos controles crean un límite protector tanto para la seguridad como para el rendimiento.
Algunos endpoints puede que no necesiten aceptar cuerpos JSON o XML en absoluto. TR7 puede proporcionar controles para deshabilitar completamente el uso de cuerpos JSON o XML por endpoint. Esto evita que los formatos de cuerpo inesperados lleguen al backend. Es particularmente efectivo para endpoints GET simples y servicios que no aceptan transacciones que no son de formulario.
Se puede aplicar validación basada en regex para cada cabecera, parámetro de query, campo de formulario o campo del cuerpo. Los formatos de email, teléfono, UUID, ID numérico, código de país o específicos de la organización se verifican de esta manera. Los valores fuera del formato no se dejan a la aplicación para que los gestione — se detectan en el borde. Este modelo lleva la dimensión de formato de datos del contrato de API a la política de seguridad.
Los endpoints aprendidos del tráfico pueden compararse con la lista de API documentada existente. Los endpoints activos que no están en la documentación pueden marcarse como candidatos a shadow API; los endpoints que ya no deberían recibir tráfico pero aún lo hacen pueden marcarse como candidatos a endpoints zombie. Estas recomendaciones se presentan como sugerencias de aprendizaje para que el operador las revise, no como decisiones de enforcement absolutas. Los equipos de seguridad pueden mapear la superficie real de la API más rápidamente.
Con el tiempo, pueden aparecer nuevas claves JSON, nuevos parámetros de query o un uso diferente de métodos. TR7 puede hacer visibles las diferencias entre el comportamiento aprendido y la política de esquema actual. Estas diferencias pueden señalar un cambio de versión de la aplicación, un cliente que se comporta mal o un intento de abuso. El operador puede aceptar el cambio y añadirlo al esquema o tratarlo como una violación de política.
API discovery ayuda a informar qué endpoints estuvieron activos durante un período determinado. Preguntas como "¿Qué endpoints recibieron tráfico en los últimos 30 días?" son importantes para los equipos de seguridad y cumplimiento. Un inventario basado en tráfico proporciona una base de auditoría más realista que un documento estático. La organización monitorea su superficie de API frente al comportamiento en vivo.
Los controles de API discovery y esquema operan en los alcances path, query, header, form, JSON, XML y raw.
Los controles de esquema TR7 cubren los campos path, query, header, form, JSON, XML y raw. Cada alcance puede tener sus propios límites, listas de permitidos y reglas de validación. La seguridad de API se define por tanto sobre la superficie completa de la solicitud, no solo el cuerpo.
Las reglas de esquema pueden definirse con diferentes tipos como complexInput, regex, numeric, boolean y enumSelect. Los controles simples de activado/desactivado y las listas de campos detalladas se gestionan dentro del mismo DSL. El operador selecciona el tipo de regla según el comportamiento de la API.
Las reglas pueden aplicarse en diferentes niveles objetivo: web application, api endpoint y application server. Esto permite distinguir entre una política de servicio general y un esquema específico para un único endpoint. Elegir el alcance correcto produce una política con menos repetición y un área de efecto más clara.
El modelo de aprendizaje puede mantener nodos por ruta, conteos de frecuencia e información de ruta secundaria. Se puede extraer información de resumen por host o grupo de servicios. Esta estructura ayuda a comprender qué partes de la superficie de la API son de alto tráfico, escasas o de nueva aparición.
Los cambios aprendidos pueden someterse a aprobación del administrador en lugar de aplicarse automáticamente. El operador revisa las propuestas de nuevos endpoints, nuevos campos o nuevos patrones y convierte los apropiados en política. Este modelo posiciona el aprendizaje como soporte de decisiones guiado en lugar de automatización incontrolada.
Los archivos de logs históricos pueden analizarse por lotes para derivar el comportamiento de la API de forma retrospectiva. Esto significa que el proceso de API discovery no se limita solo al tráfico en vivo. Los períodos de tráfico anteriores, las ventanas de campaña o los momentos de incidentes pueden examinarse por separado.
Los equipos de seguridad pueden comparar la lista de endpoints aprendida del tráfico real con la documentación de API existente. Las rutas activas que no están en la documentación se toman para revisión como candidatos a shadow API.
Los equipos de microservicios pueden ver el comportamiento de endpoints de cada servicio desde el tráfico sin esperar documentación manual. TR7 ayuda a convertir el inventario basado en ruta y método en una política de seguridad.
Los equipos de cumplimiento pueden informar qué endpoints estuvieron activos durante un período determinado. Esto hace que la superficie de API que gestiona datos sea más claramente visible durante una auditoría.
Si los endpoints abiertos para pruebas o staging aparecen en el tráfico de producción, pueden notarse dentro de las recomendaciones de aprendizaje. El equipo de operaciones puede entonces cerrarlos, restringirlos o colocarlos bajo la política de seguridad correcta.
Inventario de endpoints basado en tráfico, visibilidad de shadow APIs y reglas de esquema positivas — recorramos una configuración en vivo en sus propios servicios.