API et services connectés

Comprendre les API, les intégrations et les services connectés pour automatiser les échanges sans perdre en sécurité ni en maintenabilité.

52 articles · Dernier article mis à jour

La recherche couvre tous les articles de cette rubrique, y compris les archives et le texte des articles.

Comprendre le sujet

Repères pour explorer cette catégorie

Une fonctionnalité connectée dépend d’identités, de contrats d’interface, de fournisseurs et de modes de défaillance. Cette rubrique relie conception d’API, sécurité, continuité et qualité du service rendu. Une intégration API fiable sépare identité du client, autorisation sur l’objet et effet demandé. Les erreurs, délais et reprises doivent préserver cette distinction. La documentation d’un endpoint n’est complète que si le consommateur peut reconnaître un refus, un résultat provisoire et une opération terminée.

Angles à examiner
  • Identifier les appels indispensables à chaque parcours et leurs propriétaires.
  • Prévoir délais, erreurs, répétitions sûres et dégradation visible pour l’utilisateur.
  • Exercer les scénarios de panne, la reprise et la réponse à incident.
  • Comparer les réponses réelles au contrat documenté avant de modifier une interface.
  • Tester les droits sur chaque objet et champ GraphQL, puis borner profondeur, listes et alias selon leur coût réel.
  • Passer d’une notification reçue à un effet métier unique, traçable et récupérable après une panne.
  • Distinguer cache partagé, cache privé et cache applicatif, contrôler les clés, la revalidation et l’invalidation après un changement de droits.
  • Prévenir les attaques SSRF dans les téléchargements, aperçus et connecteurs utilisant une adresse fournie par un utilisateur.
  • Définir budgets, identités et reprises pour préserver le service lorsqu’un client atteint une limite.
  • Définir ordre, jetons, autorisations et reprise lorsque la collection change pendant sa lecture.
  • Contrôler format, ressources, accès et états de la réception au téléchargement.
  • Accélérer les réponses publiques sans réutiliser celles d’un autre compte et sans conserver des versions périmées.
  • Ne pas confondre requête acceptée, traitement démarré et résultat final d’une opération longue.
  • Distinguer événements produits, reçus et exploitables pour expliquer une interruption sans confondre silence et absence d’incident.
  • Définir un contrat pour les échanges avec une iframe ou une fenêtre afin de refuser les messages inattendus.
  • Contrôler chemins, liens et volumes décompressés avant de promouvoir les fichiers d’une archive.
  • Suivre le renouvellement jusqu’aux points de terminaison et vérifier les clients avant de déclarer le changement terminé.
Questions utiles
  • Que se passe-t-il si le fournisseur ne répond plus ?
  • Une nouvelle tentative peut-elle répéter une action ?
  • Quelle preuve montre que la reprise fonctionne ?
  • Quels clients existants seraient affectés par une nouvelle version ?
  • Un résolveur peut-il renvoyer un champ privé après un accès autorisé au parent ?
  • Quel octet est signé ?
  • no-cache signifie-t-il ne rien conserver ?
  • HTTPS suffit-il ?
  • Un code 429 suffit-il à protéger le service ?
  • Une page vide signifie-t-elle la fin ?
  • Une extension correcte suffit-elle ?
  • no-cache signifie-t-il ne rien stocker ?
  • 202 signifie-t-il que la tâche est terminée ?
  • Trois lignes reçues prouvent-elles que trois événements sont conservés ?
  • Vérifier event.origin suffit-il pour accepter une commande ?
  • Une archive petite ou un filtre d’extraction garantit-il un résultat sûr ?
  • Le renouvellement ACME réussi suffit-il à fermer le changement ?

Exemple illustratif de décision

Situation
Exemple fictif : ces données ne décrivent aucun client ni résultat réel. Deux lectures sont rapides, mais l’une affiche encore une ancienne disponibilité après une modification de la source.
Vérifier
Comparer valeur, version, point de lecture et délai après modification. Tester invalidation, expiration et accès direct à la source selon le contrat du système.
Agir
Fixer la fraîcheur acceptable par usage et surveiller les divergences. Un gain de latence ne démontre pas la cohérence des données servies.

Cache d’API : maîtriser fraîcheur, isolation et cohérence

Cache HTTP : protéger les réponses personnalisées

IETF — RFC 9111, HTTP Caching

Vérifier le destinataire et les droits

Un jeton signé n’autorise pas automatiquement une opération sur un objet. Testez émetteur, audience, expiration et accès croisé entre comptes ; ajoutez des refus attendus aux tests de succès.

Un jeton valide pour une autre API ou un autre rôle est-il effectivement refusé ?

Passer à la méthode

Lire les données · vérifier · décider

Reprises API : compter le budget de bout en bout

Quatre tentatives ne sont pas quatre reprises. Comptez le temps des appels et les attentes entre appels avant de comparer à l’échéance du parcours.

Tentatives au total
4Une initiale et trois reprises
Attentes cumulées
700 ms100 + 200 + 400
Budget modélisé
1 700 ms4 × 250 + 700

Cas pédagogique fictif — les chiffres ne décrivent pas CIE ni un client.

Essayer un budget de reprise

n × délai + attente × (2^(n−1) − 1). Attentes doublées, sans jitter ni plafonnement.

Questions pour préparer vos décisions

Des réponses et des points de contrôle à retrouver dans les analyses de cette rubrique.

À découvrir dans les archives

D’autres analyses de cette rubrique, au-delà des articles récents affichés ci-dessous.

Références : données, usages et limites

Documentation consultée le .

Renseignement cyber : contenu, échange et diffusionTrois fonctions distinctes. STIX 2.1 · Décrire. TAXII 2.1 · Échanger. TLP 2.0 · Partager. Aucune n’établit seule la vérité. Objets et relations. Collections et protocole. Destinataires autorisés. Validation locale : origine, période, pertinence et autorisations.Renseignement cyber : contenu, échange et diffusionTrois fonctions distinctesAucune n’établit seule la véritéSTIX 2.1 · DécrireObjets et relationsTAXII 2.1 · ÉchangerCollections et protocoleTLP 2.0 · PartagerDestinataires autorisésValidation locale : origine, période, pertinence et autorisations
Renseignement cyber : contenu, échange et diffusion
Références : données, usages et limites
Source et objetDonnée ou repère vérifiéComment l’utiliserLimite à conserver
MITRE · Common Weakness Enumeration

Nommer des classes de faiblesses logicielles et matérielles.

Une CWE décrit une faiblesse pouvant contribuer à l’introduction de vulnérabilités. Elle ne représente pas un incident particulier. Reliez la faiblesse au mécanisme observé : entrée, traitement et contrôle manquant. Utilisez cette description pour corriger la cause et préparer des tests de régression.

Approfondir la méthode →

La présence d’un mot-clé dans un rapport ne suffit pas à établir la bonne classification CWE.
OASIS · STIX 2.1

Décrire du renseignement sur les menaces avec des objets et relations structurés.

STIX 2.1 est un standard OASIS du 10 juin 2021. Il définit des objets, leurs propriétés et une sérialisation JSON. Conservez identifiants, dates, provenance et relations. Vérifiez que le destinataire interprète le même type d’objet et la même période de validité.

Approfondir la méthode →

Un objet syntaxiquement valide peut rester périmé, mal attribué ou insuffisamment étayé.
OASIS · TAXII 2.1

Échanger du renseignement sur les menaces par un protocole applicatif.

TAXII 2.1 est un standard OASIS du 10 juin 2021. Il organise notamment la découverte de services et l’accès à des collections. Testez authentification, droits de collection, pagination et reprise après interruption. Documentez quels objets ont réellement été reçus et traités.

Approfondir la méthode →

TAXII transporte des données ; il ne remplace ni leur modèle de contenu ni leur évaluation de fiabilité.
MDN · Cookie boundaries

Comprendre la portée des cookies de session et les limites de SameSite.

Secure, HttpOnly, SameSite et le préfixe __Host- répondent à des risques distincts. Un site peut regrouper plusieurs origines. Tester navigation externe, sous-domaines, retour prestataire et opérations authentifiées séparément.

Approfondir la méthode →

Une configuration de cookie ne remplace ni les contrôles CSRF ni les autorisations côté serveur.

Identités : facteurs, sessions et récupération

API d’identité : séparer authentification et autorisation

Un jeton valide identifie une session ou une identité selon le protocole. Il ne donne pas automatiquement le droit d’accéder à tout objet métier. La récupération et la révocation doivent être vérifiées sur le backend consommateur.

  • Contrôler émetteur, destinataire, expiration et permissions applicables.
  • Rejouer l’accès à un objet non autorisé et à une session révoquée.
  • Tracer les décisions utiles sans journaliser les secrets d’authentification.

Ouvrir le comparatif des facteurs et de la récupération →

Sources consultées le · NIST SP 800-63B-4 · final publication NIST · Authenticator Event Management W3C · WebAuthn Level 3

ETag, cache HTTP et modifications concurrentes

Spécifier les conflits dans le contrat API

Le contrat doit expliquer quel validateur accompagne une représentation et comment le client réagit aux refus.

  • Préciser si PUT exige un champ conditionnel et quand 428 est émis.
  • Documenter If-Match fort, 412 et le parcours de résolution du conflit.
  • Prévoir HEAD et 304 sans contenu et tester le comportement du SDK.

Explorer les comparaisons et le simulateur ETag →

Références relues le · RFC 9110 · §13 · RFC 9111 · RFC 6585 · §3

Retry-After : attente, budget et décision de reprise

Documenter le droit de répéter avant le délai de reprise

Retry-After explique une attente. Le contrat doit aussi définir les opérations rejouables, les clés, les versions et les états de résultat inconnu.

  • Préciser si le champ contient une durée ou une date et comment le client traite les valeurs absentes ou invalides.
  • Définir le pilote de reprise et le budget global pour éviter les tentatives superposées.
  • Conserver les paramètres, le contexte et la fenêtre d’idempotence sans généraliser un contrat Stripe à toutes les API.

Explorer Retry-After et le modèle de reprise →

Références relues le · RFC 9110 · §9.2.2, §10.2.3 · RFC 6585 · §4 · AWS

Explorer le catalogue KEV de CISA

Un même identifiant, plusieurs couches techniques

Une notice peut concerner une bibliothèque, un serveur ou un composant inclus dans une appliance. Rechercher le nom exact, puis les dépendances connues et l’avis du produit distribué. Les alias du catalogue ne constituent pas une nomenclature complète des versions affectées.

  • Rapprocher CVE, fournisseur du composant et fournisseur du produit final.
  • Vérifier version, configuration et chemin d’exécution dans l’environnement autorisé.
  • Ne pas déduire la correction d’un simple résultat de recherche vide.

Consulter le catalogue et sa méthode →

CISA KEV · 2026.10.21 · Consultation documentaire : 2026-10-22

Extensions : permissions et accès

Une authentification robuste ne décrit pas les accès de l’extension

La résistance au phishing ne dispense pas d’examiner ce qui fonctionne dans le navigateur une fois la session ouverte. Le manifeste donne des pistes sur cookies, scripts, débogage et identité, sans démontrer à lui seul une collecte.

  • Tester les extensions autorisées sur un profil dédié aux opérations sensibles.
  • Pour identity, examiner les scopes OAuth et destinataires ; cette permission n’énumère pas les droits du fournisseur d’identité.
  • Distinguer révocation de session, révocation de jetons, désactivation d’extension et retrait d’un composant natif.

Consulter le répertoire et les exemples de manifestes →

Google Chrome · Stay secure · Documentation consulted 2026-10-23; browser behaviour remains version-dependent

Codes syslog et preuves de collecte

Une normalisation doit conserver le sens des événements

Dans une API distribuée, un entier PRI mélange deux codes. Une conversion opaque peut perdre la famille du message ou inverser la gravité. Testez la chaîne de collecte avec des événements identifiés avant d’en déduire une fiabilité opérationnelle.

  • Conserver facility, severity et valeur brute dans des champs distincts.
  • Distinguer heure source, heure de réception et disponibilité dans la recherche.
  • Rendre visibles les rejets, troncatures, pertes et règles de conversion.

Lire les codes syslog et tester le calcul PRI →

IANA · syslog Parameters · Registry updated 2016-04-26 · consulted 2026-10-23

ASD ACSC and partners · Best practices for event logging and threat detection · Published and reviewed 2024-08-22 · consulted 2026-10-23

Erreurs API : types, statuts et preuves

Inclure les erreurs dans les tests de contrat

Une nouvelle URI de type, une extension retirée ou un statut modifié peut changer le comportement d’un consommateur. Les exemples d’échec font partie du contrat au même titre que les réponses réussies.

  • Rejouer les anciens clients sur les refus représentatifs.
  • Vérifier la tolérance aux extensions inconnues et aux textes localisés.
  • Documenter la migration d’une identité de problème et les usages réellement observés.

Explorer les types de problèmes et les huit réponses fictives →

IETF · M. Nottingham, E. Wilde, S. Dalal · RFC 9457 · July 2023 · obsoletes RFC 7807 · §3.1, §3.2, §4.2, §5

GraphQL : erreurs, listes et données partielles

API GraphQL : contrat, accès et expérience de lecture

Compléter les contrôles API par une recette de réponses partielles, des tests de droits sur les champs et un budget de ressources propre au service.

  • Comparer data absente, data partielle et data: null.
  • Conserver le chemin original, même si un parent devient null.
  • Tester les droits, les quotas et les états d’interface séparément.

Explorer les réponses GraphQL et leur nullabilité →

GraphQL Specification · September 2025 · Published edition · September 2025

API : dépréciation et retrait

Préparer le retrait au-delà du numéro de version

Une version publiée ne dit pas quand les consommateurs doivent migrer. Relier les annonces de dépréciation, les dates de retrait et les tests des clients existants.

  • Distinguer Deprecation, Sunset et les liens vers les politiques.
  • Vérifier que Sunset n’est pas antérieur à Deprecation lorsque les deux dates sont fournies.
  • Mesurer les consommateurs restants et valider le remplacement avant une bascule.

Comparer les annonces de dépréciation et de retrait →

IETF · RFC 9745 · Deprecation · Standards Track · March 2025 · §2–5 · consulted 2026-10-23

IETF · RFC 8594 · Sunset · Informational · May 2019 · §3–5, §8 · consulted 2026-10-23

Références pour approfondir

Documents de référence publiés par les organismes responsables de ces méthodes et standards.