OWASP API Security Top 10 vs IBM API Connect

/dans /par
Sécurité des APIs · OWASP · IBM API Connect

OWASP API Security Top 10 vs IBM API Connect.

Les 10 risques critiques de sécurité des APIs selon OWASP, un par un, mappés sur les capacités réelles d'IBM API Connect et DataPower. Là où la passerelle résout, là où elle aide, et là où le travail reste celui de votre backend.

10 min de lecture●Analyse technique●

Les APIs sont le principal vecteur d'attaque contre les applications d'entreprise, et avec l'adoption croissante des agents d'IA et de protocoles comme MCP, l'inventaire des consommateurs autonomes continue de croître. Les risques du OWASP API Security Top 10 (édition 2023, en vigueur) ne changent pas — ils deviennent simplement plus critiques.

Cet article va droit au but : un mapping risque par risque de ce que couvrent IBM API Connect + DataPower et de ce qu'ils ne couvrent pas. Sur les 10, la passerelle a une couverture native sur 4, une aide partielle sur 4 autres, un impact indirect sur 1 et en laisse 1 au backend. Savoir lequel est lequel est ce qui distingue une équipe formée d'une équipe qui découvre les choses en production.

10
Risques critiques
dans la liste OWASP
2023
Édition OWASP
en vigueur
4 / 10
Couverture native
passerelle IBM
3
Nouvelles catégories
vs 2019
01 · Contexte

OWASP quoi, et pourquoi ça compte plus en 2026 ?

L'OWASP API Security Top 10 est la liste de référence du secteur avec les 10 risques les plus critiques en sécurité des APIs. La dernière édition date de 2023 — et en 2026 elle reste le standard, sans réédition en attente. Ce qui a changé, ce n'est pas la liste, c'est le contexte dans lequel elle s'applique :

  • Les APIs restent l'un des principaux vecteurs d'attaque contre les applications d'entreprise.
  • L'adoption croissante d'agents d'IA et de protocoles comme MCP ajoute des consommateurs autonomes à la carte — distincts des apps et partenaires habituels.
  • L'API sprawl — APIs non documentées ni gouvernées — reste un défi récurrent dans les organisations avec des années d'intégrations accumulées.

Dans ce contexte la passerelle cesse d'être un simple proxy et devient la pièce où les contrôles du OWASP API Top 10 sont appliqués — ou non.

Comment lire cet article

Chaque risque porte un badge de couverture avec quatre niveaux : Native (la passerelle le couvre par elle-même), Partielle (elle aide mais nécessite un bon design), Indirecte (contribution limitée) ou Non directe (le problème vit dans le backend). L'objectif n'est pas de vendre — c'est de savoir où mettre l'effort.

02 · Les 10 risques

OWASP API Top 10 (2023) · mapping sur IBM API Connect + DataPower

API1:2023 Broken Object Level Authorization (BOLA) Couverture partielle

Le client change un ID dans l'URL (/orders/42 → /orders/43) et accède à un objet qui ne lui appartient pas. Toujours le risque n°1 — parce que la logique de propriété vit dans le backend.

Ce que la passerelle FAIT Valide le JWT, extrait les claims utilisateur et les passe au backend dans des en-têtes signés. Peut appliquer des politiques par scope OAuth.
Ce que votre backend doit faire Vérifier que le user_id du token correspond au propriétaire de l'objet demandé sur chaque endpoint. La passerelle ne connaît pas votre modèle de données.
API2:2023 Broken Authentication Native

Tokens mal validés, mécanismes d'authentification non sécurisés, JWT signés avec none, identifiants par défaut. L'authentification est le plan où la passerelle apporte le plus, sans discussion.

Ce que la passerelle FAIT OAuth 2.0 complet (authorization server, scopes, refresh), validation JWT (signature, exp, aud, iss), OIDC, mTLS, clés API avec rotation, intégration avec LDAP/AD/IAM externe. C'est WD509G et WE752G à l'état pur.
Ce que votre backend doit faire Faire confiance au résultat de validation de la passerelle. Si vous re-validez côté backend, assurez-vous de ne pas introduire d'incohérences.
API3:2023 Broken Object Property Level Authorization Couverture partielle

Le backend renvoie plus de champs que l'utilisateur ne devrait voir (excessive data exposure) ou accepte plus de champs en écriture (mass assignment). Combine les anciens API3:2019 et API6:2019.

Ce que la passerelle FAIT Transformations de réponse (masquage de champs sensibles, filtrage par scope). DataPower peut appliquer du XSLT ou du GatewayScript pour assainir les payloads.
Ce que votre backend doit faire Ne pas renvoyer de champs que le rôle ne devrait pas voir. Ne pas accepter de champs non attendus en écriture. La passerelle peut aider a posteriori, mais la responsabilité reste sur le design de l'API.
API4:2023 Unrestricted Resource Consumption Native

Absence de rate limiting, pas de quotas, payloads sans taille maximale. S'appelait auparavant « Lack of Resources & Rate Limiting ». Là où la passerelle brille.

Ce que la passerelle FAIT Rate limit par consommateur, par plan, par endpoint. Quotas journaliers/mensuels. Throttling configurable. Limite de taille de payload. Burst control. Tout configuré dans le manager et appliqué dans DataPower ou Nano Gateway.
Ce que votre backend doit faire Définir les SLAs de chaque plan/consommateur. La passerelle applique ce que vous décidez — elle ne décide pas pour vous ce qui est raisonnable.
API5:2023 Broken Function Level Authorization Couverture partielle

Un utilisateur normal accède à des endpoints admin parce que l'API ne vérifie pas le rôle au-delà de l'authentification.

Ce que la passerelle FAIT Applique des politiques différentes par endpoint en fonction des scopes OAuth. Bloque l'accès aux routes admin depuis des tokens sans le scope correspondant. Routage conditionnel.
Ce que votre backend doit faire Concevoir correctement les scopes OAuth dès le départ. Un scope admin est inutile si tous les flows l'accordent. La passerelle applique des règles — elle ne les invente pas.
API6:2023 Unrestricted Access to Sensitive Business Flows Couverture partielle

Une API expose un flow métier sensible (achats, virements, votes) et un attaquant automatise des milliers d'appels légaux mais abusifs. Le dommage ne vient pas d'un exploit technique — il vient du volume.

Ce que la passerelle FAIT Throttling par consommateur, détection de patterns, geo-blocking, intégration CAPTCHA, intégration WAF (DataPower) pour des règles avancées.
Ce que votre backend doit faire Identifier quels flows sont sensibles (tous ne le sont pas) et concevoir des compteurs métier que la passerelle peut consommer via analytics.
API7:2023 Server Side Request Forgery (SSRF) Non directe

Une API accepte une URL de l'utilisateur et l'utilise pour faire des requêtes internes — l'attaquant l'utilise pour attaquer votre réseau interne. Vecteur en hausse en cloud à cause des services de metadata (AWS IMDS, Azure IMDS).

Ce que la passerelle FAIT Peu directement. Si le backend transmet via la passerelle vers l'outbound, on peut restreindre les destinations. Pas le pattern habituel.
Ce que votre backend doit faire Valider les URLs entrantes contre une liste blanche. Bloquer les plages internes (RFC 1918, link-local). Ne pas utiliser les entrées utilisateur directement dans des requêtes HTTP server-side. C'est 95 % backend.
API8:2023 Security Misconfiguration Native

Défauts non sécurisés, TLS mal configuré, CORS trop ouvert, en-têtes de sécurité absents, stack traces exposées. Le classique qui continue à causer des incidents.

Ce que la passerelle FAIT DataPower arrive avec des défauts sécurisés et permet des politiques centralisées de TLS, CORS, en-têtes de sécurité (HSTS, CSP, X-Frame-Options), suppression de stack traces. Audit de configuration unifié depuis API Connect V12.
Ce que votre backend doit faire Ne pas annuler côté backend ce que la passerelle fait déjà correctement (erreurs de double configuration). Maintenir des défauts sécurisés également à l'intérieur du réseau interne.
API9:2023 Improper Inventory Management Native

APIs zombies en production, anciennes versions jamais retirées, environnements de staging accessibles depuis internet, pas de documentation. La base de l'API sprawl.

Ce que la passerelle FAIT Le cœur d'API Connect est exactement cela : catalogue d'APIs, versioning, cycle de vie (création, publication, dépréciation, retrait), gouvernance fédérée en V12 (passerelles hétérogènes visibles depuis un seul plan de contrôle), Developer Portal avec documentation auto-générée.
Ce que votre backend doit faire Respecter le processus de gouvernance : chaque API publiée passe par le manager. Les APIs absentes du catalogue sont shadow — et ce sont elles qui génèrent les brèches.
API10:2023 Unsafe Consumption of APIs Couverture indirecte

Votre app consomme des APIs tierces sans valider ce qu'elles renvoient — et un fournisseur compromis vous emporte avec lui. Nouveau en 2023, particulièrement pertinent dans les architectures avec de nombreuses intégrations SaaS.

Ce que la passerelle FAIT Si la consommation d'APIs externes passe par la passerelle en outbound, on peut appliquer une validation de schéma, une sanitization des réponses et un rate limit du fournisseur. Pas toujours le pattern.
Ce que votre backend doit faire Valider les contrats d'API consommés. Ne pas faire confiance aux payloads reçus. Isoler les dépendances. C'est de la discipline de développement, plus que de la configuration de plateforme.
03 · Résumé visuel

Les 10 risques, en un coup d'œil

Tableau de couverture de la passerelle IBM (API Connect + DataPower) par risque OWASP :

Risque Nom court Couverture passerelle Capacité clé
API1
BOLA
Partielle
JWT claims propagés
API2
Broken Authentication
Native
OAuth, JWT, OIDC, mTLS
API3
Object Property Level Authz
Partielle
Masquage de champs
API4
Unrestricted Resource Consumption
Native
Rate limit, quotas, throttling
API5
Function Level Authorization
Partielle
Scopes OAuth + politiques
API6
Sensitive Business Flows
Partielle
Détection patterns, WAF
API7
SSRF
Non directe
Backend principalement
API8
Security Misconfiguration
Native
TLS, CORS, en-têtes, audit
API9
Improper Inventory Management
Native
Catalogue, versioning, V12
API10
Unsafe Consumption of APIs
Indirecte
Validation des contrats

Bilan : 4 couverture native (API2, API4, API8, API9) · 4 couverture partielle (API1, API3, API5, API6) · 1 indirecte (API10) · 1 non directe (API7).

04 · Le facteur humain

La passerelle applique des règles — quelqu'un doit les concevoir

La conclusion honnête après ce mapping est celle qui sort rarement dans le matériel marketing : la passerelle est un outil puissant, mais sans jugement propre. Elle applique à la lettre ce que votre équipe configure. Si les scopes OAuth sont mal pensés, la passerelle ne les répare pas pour vous. Si vous mettez un rate limit de 10 000 req/s sur un endpoint de virements, la passerelle vous aide à échouer plus vite.

Les capacités d'API Connect et DataPower sont celles que vous avez vues ci-dessus. La différence entre « nous avons API Connect » et « nous avons API Connect qui atténue correctement 8 des 10 risques OWASP » est faite par l'équipe qui l'opère.

Les 5 cours officiels qui couvrent tout cela WD509G et WD514G pour le noyau d'API Connect ; WE761G, WE752G et WE754G pour DataPower. En français, en intra-entreprise dès 2 personnes.
Catalogue de cours
Ce qu'il y a dans les cours

Pas seulement « ce que fait chaque nœud DataPower ». C'est quand appliquer quelle politique, comment concevoir des scopes OAuth qui passent à l'échelle, quand le rate limit par consumer ne suffit plus et il faut passer au business flow throttling — le type de décision opérationnelle qui se voit en projet, pas dans le manuel.

Résumé

L'essentiel en 5 points

À retenir

→ OWASP API Top 10 2023 reste le standard en vigueur en 2026 — pas de réédition en attente, mais plus pertinent avec l'adoption de l'IA agentique.

→ La passerelle IBM (API Connect + DataPower) a une couverture native sur 4 risques — authentification, rate limiting, configuration sécurisée et inventaire d'APIs.

→ Aide partielle sur 4 autres (BOLA, property authz, function authz, business flows) — la logique métier reste backend.

→ SSRF et unsafe consumption sont principalement le territoire des développeurs — n'attendez pas que la passerelle les résolve pour vous.

→ La différence entre avoir l'outil et atténuer les risques est l'équipe qui le configure.

FAQ

Questions fréquentes

La version 2023 d'OWASP API Top 10 est-elle toujours d'actualité en 2026 ?

Oui. La Fondation OWASP a publié la dernière mise à jour de l'API Security Top 10 en 2023 et aucune nouvelle édition n'a paru en 2026. La liste reste le standard de référence du secteur — d'autant plus pertinente avec la consommation croissante d'APIs par les agents d'IA.

API Connect / DataPower couvre-t-il les 10 risques OWASP ?

Non, et ce n'est pas un défaut de la passerelle. Sur les 10 risques, la passerelle a une couverture native sur 4 (API2, API4, API8, API9), une couverture partielle sur 4 (API1, API3, API5, API6), un impact indirect sur 1 (API10) et laisse 1 au backend (API7 SSRF). Le reste exige un design backend correct et une revue humaine.

Quel risque est le plus simple à atténuer avec la passerelle ?

API4 (Unrestricted Resource Consumption) et API9 (Improper Inventory Management). Rate limiting, quota plans et throttling sont le territoire natif d'API Connect. Catalogue, versioning et gouvernance fédérée en V12 couvrent directement la gestion d'inventaire.

Où apprendre à configurer tout cela dans API Connect ?

Les cours officiels WD509G (admins) et WD514G (devs), plus ceux de DataPower (WE761G, WE752G, WE754G). Chez SIXE on les anime en intra-entreprise dès 2 personnes avec des ingénieurs qui déploient ces produits en environnement client réel. Catalogue complet sur le hub de formation API Connect.

Sources

Références

OWASP Foundation. OWASP API Security Project. owasp.org/www-project-api-security

OWASP Foundation. API Security Top 10 (édition 2023). owasp.org/API-Security · édition 2023

IBM. IBM API Connect — Cloud Pak for Integration. ibm.com/products/api-connect

IBM. IBM DataPower Gateway. ibm.com/products/datapower-gateway

SIXE. Hub de formation officielle IBM API Connect. sixe.be/formation/ibm-api-connect

Dernière mise à jour : .

Formation API Connect & DataPower

Parlons formation pour votre équipe.

Dites-nous quels risques OWASP vous préoccupent le plus, combien vous êtes et où vous êtes basés. On revient vers vous en moins de 24 heures avec itinéraire, modalité et devis fermé. Sans formulaire à rallonge.

Voir le hub complet Contact
Informix 2026 : v15, watsonx et fin de support 12.10
SIXE