Console de démonstration pour une API de trésorerie B2B. Aujourd'hui, les requêtes atteignent directement l'origine Worker.
Le client fictif
Kestrel Flow transforme la trésorerie en infrastructure.
Kestrel Flow fournit aux entreprises une API pour consulter leurs comptes, gérer leurs bénéficiaires et initier des virements. Ses clients sont des plateformes SaaS qui veulent intégrer des paiements sans construire toute la chaîne bancaire.
Le problème métier
Les endpoints de paiement exposent des données sensibles et des actions à fort impact. L'équipe doit donc savoir qui appelle l'API, si la requête respecte le contrat et si le parcours utilisateur ressemble à un comportement légitime.
Question de la démonstration : que se passe-t-il entre le client de Kestrel Flow et le code métier qui traite le virement ?
API exposée par le Worker
Contrat source : openapi.yaml
GET /api/v1/accountsdocumenté
GET /accounts/{id}/balancelecture
GET /api/v1/beneficiariesdocumenté
POST /transfersaction sensible
GET /api/v1/internal/reconciliationshadow API
Lab Guide / étape 02
Découvrir l'API inconnue
Le problème de départ est simple : une équipe ne peut pas protéger correctement une API qu'elle ne connaît pas. Nous allons utiliser la Shadow API de Kestrel Flow pour montrer le cycle découverte, observation et remédiation.
À exécuter dans Cloudflare
1. Ce que nous allons faire
Générer du trafic vers des endpoints documentés et vers GET /api/v1/internal/reconciliation, qui fonctionne mais n'existe pas dans openapi.yaml.
2. À faire dans l'environnement de test
1
Sélectionner un scénarioChoisir Shadow API ou Solde autorisé.
2
Vérifier la méthodeLaisser la méthode GET.
3
Choisir le volumeEntrer par exemple 500 appels.
4
Lancer la générationCliquer sur Générer et attendre le résumé.
3. À observer dans le dashboard Cloudflare
Ouvrir Security → Web Assets → Operations, puis rechercher le hostname kestrel.dgcf.ovh.
Si les opérations ne sont pas encore dans l'inventaire, utiliser l'action adding them from Discovery depuis la page Operations. Cette action permet de sélectionner les opérations trouvées par la découverte et de les ajouter à l'inventaire.
Vérifier ensuite les opérations avec leur méthode, leur hostname et leur chemin. La Shadow API doit apparaître comme une opération candidate si les conditions de découverte et de disponibilité de la fonctionnalité sont remplies.
À noter : la découverte ajoute l'opération à l'inventaire. Elle ne commence pas automatiquement l'apprentissage de profil et ne bloque pas le trafic.
4. Comprendre les modes d'ajout
Adding them from Discovery signifie que Cloudflare a observé l'opération dans le trafic. On la sélectionne pour l'ajouter à Web Assets, après avoir vérifié qu'elle est légitime.
Entering them manually signifie créer une opération connue sans attendre sa découverte. On saisit la méthode HTTP, le hostname et le chemin, par exemple GET, kestrel.dgcf.ovh et /api/v1/accounts/{account_id}/balance.
L'ajout manuel est utile pour une API peu utilisée, une opération privée ou un endpoint que l'équipe connaît déjà. Il crée une entrée d'inventaire, mais ne prouve pas que l'origine répond et ne remplace pas l'apprentissage du profil.
5. Résoudre le problème dans Cloudflare
Pour chaque opération découverte, décider avec l'équipe propriétaire si elle est légitime.
Si la Shadow API est légitime : l'ajouter au contrat OpenAPI, importer le schéma dans Schema Validation ou l'ajouter manuellement dans Endpoint Management, puis sélectionner Learn profile après vérification de son identité.
Si elle n'est pas légitime : identifier son propriétaire, la retirer du Worker ou créer une règle adaptée après analyse. Ne pas bloquer une opération inconnue sans avoir confirmé qu'elle est indésirable.
Scénarios
Requête
Générateur de trafic
Émet des requêtes GET depuis le navigateur pour alimenter l'observation API Shield, sans créer plusieurs virements. Utilisez le scénario de solde, qui répond en 2xx.