Dans la plupart des organisations, l'inventaire des API vit dans la documentation d'application, des fichiers de schéma obsolètes ou des listes maintenues par des équipes individuelles. Mais les applications changent à chaque release : de nouveaux endpoints sont ajoutés, les anciens sont oubliés, des chemins de test sont laissés en production. Les équipes sécurité apprennent généralement quelles API sont actives dans le trafic réel après que les équipes applicatives l'ont fait.
Ce fossé amplifie le risque de shadow API et d'endpoints zombie. Un endpoint non documenté peut se trouver entièrement hors de la politique WAF ; un endpoint qui ne devrait plus être utilisé peut encore être accessible. Du point de vue d'un attaquant, ces zones sont à faible visibilité, faiblement protégées et valent la peine d'être sondées.
Se fier uniquement à un fichier de schéma fourni de manière externe est également insuffisant. Si le schéma n'est pas à jour, il ne correspondra pas au trafic réel. L'équipe applicative peut avoir modifié un endpoint sans mettre à jour le schéma, ou un chemin qui n'apparaît jamais dans le schéma peut s'exécuter en production. Dans ce cas, la politique de protection repose sur une hypothèse obsolète plutôt que sur le comportement réel de l'application.
Le modèle de sécurité négative traditionnel ne résout pas ce problème seul. Bloquer les patterns d'attaque connus est important, mais la vraie force de la sécurité des API est de définir explicitement les méthodes, headers, paramètres, types MIME et champs de corps autorisés. Sans sécurité positive, des requêtes malveillantes inconnues mais apparemment valides peuvent passer sans être challengées.
TR7 API Discovery & Schema comble ce fossé : il apprend le comportement des API depuis le trafic réel, supporte la génération de schémas depuis le flux OpenAPI ou la génération de règles depuis un schéma, et met les contrôles de sécurité positive inline.
TR7 applique la découverte d'API conjointement avec l'apprentissage du trafic, le schéma positif, les limites de taille et de profondeur, et la validation par champ.
TR7 peut apprendre le comportement des chemins et des méthodes depuis le trafic réel et construire des patterns d'endpoints. Les chemins contenant des IDs, dates ou tokens variables sont normalisés en un inventaire d'API plus lisible.
Des allow-lists peuvent être définies pour les méthodes, headers, paramètres de requête, clés JSON, éléments XML, champs de formulaire et types MIME. Plutôt que de rechercher uniquement des patterns malveillants connus, la politique déclare explicitement le comportement attendu de l'API.
Des limites telles que la longueur du chemin, la profondeur du chemin, le nombre de headers, le nombre de paramètres de requête, la profondeur JSON, la profondeur XML et la taille brute du corps peuvent toutes être appliquées. Ces limites garantissent que les requêtes surdimensionnées ou excessivement complexes sont vérifiées avant d'atteindre le backend.
Une validation regex peut être définie pour chaque header, paramètre de requête, champ de formulaire ou champ de corps. Les formats d'e-mail, de téléphone, d'ID, de code pays ou spécifiques au service sont vérifiés au niveau du champ.
API Discovery & Schema transforme l'inventaire d'endpoints appris en règles de sécurité positive applicables.
TR7 peut analyser les informations de chemin et de méthode des requêtes entrantes pour dériver des patterns d'endpoints. Des chemins tels que `/api/users/123` et `/api/users/456` peuvent être regroupés sous un seul pattern logique. Cette approche rend visibles les endpoints qui ne figurent pas dans la documentation mais s'exécutent activement en production. L'inventaire des API est basé sur le comportement réel du trafic, pas sur des hypothèses.
TR7 est positionné pour prendre en charge un flux de travail de génération de schémas compatibles OpenAPI depuis le comportement API appris. Dans le sens inverse, des règles TR7 peuvent être générées depuis un schéma OpenAPI fourni par l'utilisateur. Ce modèle bidirectionnel réduit l'écart entre le trafic réel et le contrat API documenté. L'opérateur utilise la même plateforme pour la découverte et l'application.
La liste des méthodes autorisées — GET, POST, PUT, DELETE, PATCH et autres — peut être définie par endpoint. Si un POST est envoyé à un endpoint qui n'attend que du GET, par exemple, ce comportement peut être traité comme une violation de politique. Une allow-list basée sur les méthodes est une couche de sécurité positive simple mais efficace. Le comportement incorrect ou abusif des endpoints est détecté plus tôt.
Les headers et paramètres de requête autorisés peuvent être définis par endpoint. Pour chaque champ, un nom, un format de valeur et une validation regex peuvent être appliqués. Les headers ou paramètres inattendus peuvent être liés à un score de sécurité, une alerte ou un blocage. Les données hors du contrat API ne sont donc pas transmises au backend sans vérification.
TR7 peut construire des allow-lists au niveau de la clé JSON, de l'élément XML et du champ de formulaire. Les champs requis peuvent être définis avec mustArgs ; les champs inconnus peuvent être exclus de la liste autorisée. Cette structure décrit le corps de requête attendu plutôt que de rechercher uniquement des signatures d'attaque. Les endpoints API sont protégés d'une manière qui reste plus proche de leur propre contrat.
Des allow-lists pour les types MIME autorisés peuvent être définies pour le corps de formulaire et brut. Envoyer des données à un endpoint attendant du JSON avec un type de contenu différent peut être traité comme une violation de politique. Ce contrôle est particulièrement important pour les API de téléchargement de fichiers ou basées sur des formulaires. Le type de contenu devient une entrée directe dans la décision de sécurité.
Des limites globales de taille peuvent être appliquées pour les headers, les chaînes de requête, les formulaires, JSON, XML et le corps brut. Les contrôles de profondeur d'imbrication JSON et XML empêchent les payloads trop profonds d'ajouter de la charge au parseur et au backend. Des limites telles que le nombre de clés, le nombre de valeurs, la longueur par champ et le nombre de doublons peuvent également être définies. Ces contrôles créent une frontière de protection pour la sécurité et les performances.
Certains endpoints peuvent ne pas avoir besoin d'accepter de corps JSON ou XML du tout. TR7 peut fournir des contrôles pour désactiver entièrement l'utilisation du corps JSON ou XML sur une base par endpoint. Cela empêche les formats de corps inattendus d'atteindre le backend. C'est particulièrement efficace pour les endpoints GET simples et les services qui n'acceptent pas de transactions non formulaires.
Une validation basée sur la regex peut être appliquée pour chaque header, paramètre de requête, champ de formulaire ou champ de corps. Les formats d'e-mail, de téléphone, d'UUID, d'ID numérique, de code pays ou spécifiques à l'organisation sont vérifiés de cette manière. Les valeurs hors format ne sont pas laissées à l'application — elles sont interceptées à la périphérie. Ce modèle intègre la dimension de format des données du contrat API dans la politique de sécurité.
Les endpoints appris depuis le trafic peuvent être comparés à la liste d'API documentée existante. Les endpoints actifs absents de la documentation peuvent être signalés comme candidats shadow API ; les endpoints qui ne devraient plus recevoir de trafic mais qui en reçoivent encore peuvent être signalés comme candidats endpoints zombie. Ces recommandations sont présentées comme des suggestions d'apprentissage pour l'examen par l'opérateur, pas comme des décisions d'application absolues. Les équipes sécurité peuvent cartographier la surface API réelle plus rapidement.
Au fil du temps, de nouvelles clés JSON, de nouveaux paramètres de requête ou une utilisation différente des méthodes peuvent apparaître. TR7 peut rendre visibles les différences entre le comportement appris et la politique de schéma actuelle. Ces différences peuvent signaler un changement de version d'application, un client mal configuré ou une tentative d'abus. L'opérateur peut accepter le changement et l'ajouter au schéma ou le traiter comme une violation de politique.
La découverte d'API aide à rapporter quels endpoints étaient actifs pendant une période donnée. Des questions telles que « Quels endpoints ont reçu du trafic au cours des 30 derniers jours ? » sont importantes pour les équipes sécurité et conformité. Un inventaire basé sur le trafic fournit une baseline d'audit plus réaliste qu'un document statique. L'organisation surveille sa surface API par rapport au comportement réel.
Les contrôles de découverte d'API et de schéma opèrent sur des portées de chemin, requête, header, formulaire, JSON, XML et brut.
Les contrôles de schéma TR7 couvrent les champs de chemin, requête, header, formulaire, JSON, XML et brut. Chaque portée peut avoir ses propres limites, allow-lists et règles de validation. La sécurité des API est donc définie sur l'ensemble de la surface de requête, pas seulement sur le corps.
Les règles de schéma peuvent être définies avec différents types tels que complexInput, regex, numeric, boolean et enumSelect. Les contrôles on/off simples et les listes de champs détaillées sont gérés dans le même DSL. L'opérateur sélectionne le type de règle en fonction du comportement de l'API.
Les règles peuvent être appliquées à différents niveaux cibles : web application, api endpoint et application server. Cela permet une distinction entre une politique de service générale et un schéma spécifique à un seul endpoint. Choisir la bonne portée produit une politique avec moins de répétition et une zone d'effet plus claire.
Le modèle d'apprentissage peut contenir des nœuds par chemin, des compteurs de fréquence et des informations de chemin enfant. Des informations récapitulatives peuvent être extraites par hôte ou groupe de services. Cette structure aide à comprendre quelles parties de la surface API sont à fort trafic, éparses ou nouvellement apparues.
Les changements appris peuvent être soumis à l'approbation de l'administrateur plutôt qu'appliqués automatiquement. L'opérateur examine les propositions pour les nouveaux endpoints, les nouveaux champs ou les nouveaux patterns et convertit les plus appropriés en politique. Ce modèle positionne l'apprentissage comme un support décisionnel guidé plutôt que comme une automatisation non contrôlée.
Les fichiers journaux historiques peuvent être analysés par lots pour dériver le comportement des API de manière rétrospective. Cela signifie que le processus de découverte n'est pas limité au seul trafic en direct. Les périodes de trafic antérieures, les fenêtres de campagne ou les moments d'incidents peuvent être examinés séparément.
Les équipes sécurité peuvent comparer la liste d'endpoints appris depuis le trafic réel à la documentation API existante. Les chemins actifs absents de la documentation sont pris en compte pour examen en tant que candidats shadow API.
Les équipes de microservices peuvent voir le comportement d'endpoint de chaque service depuis le trafic sans attendre une documentation manuelle. TR7 aide à transformer l'inventaire basé sur les chemins et méthodes en politique de sécurité.
Les équipes de conformité peuvent rapporter quels endpoints étaient actifs pendant une période donnée. Cela rend la surface API qui traite les données plus clairement visible lors d'un audit.
Si des endpoints ouverts pour les tests ou la qualification apparaissent dans le trafic de production, ils peuvent être remarqués dans les recommandations d'apprentissage. L'équipe opérationnelle peut alors les fermer, les restreindre ou les placer sous la politique de sécurité correcte.
Inventaire d'endpoints basé sur le trafic, visibilité des shadow API et règles de schéma positif — parcourons ensemble une configuration en direct sur vos propres services.