Comment auditer et verrouiller les API avec le Top 10 OWASP de la sécurité des API

La sécurité des API reste l’un des moyens les plus rapides d’être compromis parce que les API exposent des fonctions métier, des identifiants d’objets, des actions privilégiées et des données sensibles d’une manière facile à automatiser à grande échelle. Une petite faille d’autorisation sur un endpoint peut souvent être rejouée sur des milliers d’ID, de tenants ou d’objets. C’est pourquoi un audit d’API ne devrait pas s’arrêter à “nous utilisons OAuth” ou “la gateway a l’auth activée.”

Les intégrations modernes IA et SaaS aggravent le problème. De nombreuses équipes consomment désormais des API tierces comme si c’étaient des systèmes internes de confiance, proxifient des prompts et résultats IA à travers des couches API, et ajoutent des endpoints spécifiques aux partenaires ou en bêta plus vite que l’inventaire ne peut suivre. Cette combinaison crée exactement les types de problèmes que OWASP met en évidence dans la gestion incorrecte de l’inventaire, la consommation non restreinte des ressources et la consommation non sécurisée des API.

Ce tutoriel vous donne un workflow d’audit pratique basé sur le Top 10 OWASP de la sécurité des API. Vous allez construire un inventaire d’API utilisable, vérifier l’autorisation et les limites des tenants, inspecter les contrôles de schéma et d’abus, vérifier l’exposition des données, examiner la sécurité opérationnelle, puis convertir les résultats en un plan de remédiation qui corrige les plus gros risques en premier.

Étape 1 : Construire ou vérifier votre inventaire d’API

Ne commencez pas par le scan de vulnérabilités. Commencez par la visibilité. Si vous ne savez pas quelles API existent, qui les possède, quelle version est en production et qui peut les atteindre, vous êtes déjà en territoire API9.

Inventorier les API publiques, internes, partenaires et shadow

Construisez un seul fichier d’inventaire qui répond à ces questions pour chaque surface API :

• Quel est le hostname ou chemin de base ?
• Est-elle publique, interne, réservée aux partenaires ou inconnue ?
• Qui en est propriétaire ?
• Quel modèle d’auth utilise-t-elle ?
• Dans quel environnement est-elle ?
• Y a-t-il un plan de dépréciation documenté ?

Fichier : api-inventory.csv

service,base_url,audience,owner,environment,auth,openapi_spec,current_version,status
payments-api,https://api.example.com/payments,public,payments-team,production,oauth2,openapi/payments.yaml,v2,active
admin-api,https://admin-api.internal.example.com,internal,platform-team,production,jwt-rbac,openapi/admin.yaml,v1,active
partner-orders,https://partners.example.com/orders,partner,bizops-team,production,api-key-plus-hmac,openapi/partner-orders.yaml,v1,active
legacy-beta,https://beta-api.example.com,unknown,unknown,production,unknown,missing,v0,investigate

Extraire l’inventaire du code et du trafic, pas seulement de la documentation

La documentation est un point de départ, pas la vérité. Pour trouver les endpoints non documentés ou obsolètes, combinez recherche dans le code source et logs d’accès.

Exemple de recherche dans le code source :

grep -R "router\.\|app\.\|@RequestMapping\|@GetMapping\|@PostMapping" ./services
grep -R "openapi\|swagger" ./services

Exemple d’inventaire dérivé des logs à partir de logs d’accès JSON :

jq -r '.host + "," + .method + "," + .path' access.log \
  | sort -u \
  | tee observed-routes.csv

Si votre gateway logue des ID de route ou des noms de service upstream, extrayez-les aussi.

Marquer explicitement les API shadow et obsolètes

Un vrai audit a besoin d’un panier pour les endpoints que vous ne comprenez pas encore complètement. Ne les forcez pas dans “interne” ou “sûr” juste pour que le tableur ait l’air plus propre.

Créez une fiche de revue :

Fichier : shadow-api-review.md

# Shadow API Review

## beta-api.example.com
- Owner: unknown
- Environment: production
- OpenAPI spec: missing
- Auth model: unknown
- Last seen in traffic: 2026-03-08
- Public DNS: yes
- Action: classify or remove within 7 days

Inventorier les versions et flux de données

N’inventoriez pas seulement les hostnames. Suivez aussi les versions et les chemins de partage de données.

Fichier : api-data-flows.yaml

payments-api:
  inbound_clients:
    - web-app
    - mobile-app
  outbound_dependencies:
    - tax-provider
    - fraud-provider
  sensitive_data:
    - customer-name
    - partial-card-metadata
    - billing-address

partner-orders:
  inbound_clients:
    - reseller-a
    - reseller-b
  outbound_dependencies:
    - warehouse-api
  sensitive_data:
    - customer-email
    - shipping-address

Vous devriez maintenant avoir un inventaire d’API fonctionnel avec de vraies routes, audiences, versions, propriétaires et flux de données.

Étape 2 : Vérifier l’auth et l’autorisation

C’est la partie de l’audit la plus rentable. Les plus grandes compromissions d’API viennent généralement de vérifications d’autorisation manquantes ou incohérentes, pas de charges utiles exotiques.

Vérifier l’autorisation au niveau objet

L’autorisation au niveau objet demande : cet appelant peut-il accéder à cet objet spécifique ?

Si votre API charge un enregistrement à partir d’un ID, UUID, slug ou clé étrangère fourni par l’utilisateur, vous avez besoin d’une vérification de propriété ou de politique après la recherche et avant de retourner ou modifier l’objet.

Fichier : src/middleware/ownership.ts

import { Request, Response, NextFunction } from "express";

export function requireAccountOwnership(
  fetchAccount: (accountId: string) => Promise<{ id: string; tenantId: string } | null>
) {
  return async (req: Request, res: Response, next: NextFunction) => {
    const accountId = req.params.accountId;
    const account = await fetchAccount(accountId);

    if (!account) {
      return res.status(404).json({ error: "Not found" });
    }

    if (account.tenantId !== req.auth?.tenantId) {
      return res.status(403).json({ error: "Forbidden" });
    }

    res.locals.account = account;
    next();
  };
}

Si votre chemin de code ressemble à “lire l’ID du chemin, chercher l’objet, retourner l’objet”, mais ne vérifie jamais le tenant ou la propriété, c’est un signal d’alerte.

Vérifier l’autorisation au niveau fonction

L’autorisation au niveau fonction demande : cet appelant peut-il accéder à cette fonction ou action ?

Cela inclut les routes admin, les exports, les actions en masse, les flux d’approbation et les opérations métier sensibles.

Fichier : src/middleware/requireScope.ts

import { Request, Response, NextFunction } from "express";

export function requireScope(requiredScope: string) {
  return (req: Request, res: Response, next: NextFunction) => {
    const scopes = req.auth?.scopes ?? [];

    if (!scopes.includes(requiredScope)) {
      return res.status(403).json({ error: "Missing required scope" });
    }

    next();
  };
}

Et utilisez-le de manière cohérente :

app.post(
  "/admin/users/:userId/suspend",
  requireScope("admin:user:suspend"),
  suspendUserHandler
);

Vérifier la séparation des tenants

Les API multi-tenant ne devraient pas s’appuyer uniquement sur un ID de tenant fourni par le client. Le contexte de tenant devrait provenir de claims d’auth vérifiés ou d’une recherche côté serveur, pas d’un header arbitraire que le client peut changer.

Mauvais pattern :

const tenantId = req.headers["x-tenant-id"];

Meilleur pattern :

const tenantId = req.auth?.tenantId;

Puis vérifiez que chaque chemin d’accès aux données est contraint par ce tenant.

Vérifier le scope du token, l’audience et l’expiration

Pour chaque mécanisme d’auth, répondez :

• Le token a-t-il une vérification d’audience ?
• Les scopes ou rôles sont-ils suffisamment étroits ?
• L’expiration est-elle raisonnable ?
• Les refresh tokens sont-ils gérés séparément ?
• Un seul token peut-il accéder aux API publiques et admin ?

Créez une matrice d’auth simple :

Fichier : auth-matrix.yaml

payments-api:
  auth_type: oauth2-jwt
  audience: payments-api
  scopes:
    - payments:read
    - payments:write
  admin_scopes:
    - payments:refund
  max_access_token_lifetime_minutes: 15

admin-api:
  auth_type: internal-jwt
  audience: admin-api
  scopes:
    - admin:users:read
    - admin:users:suspend
  max_access_token_lifetime_minutes: 10

Vous devriez maintenant savoir si vos API appliquent la propriété, les permissions au niveau action, les limites de tenant et des règles de scope de token sensées.

Étape 3 : Vérifier la gestion des entrées et les contrôles de schéma

C’est dans cette étape que vous trouvez les bugs de type mass-assignment, la validation faible des requêtes, le parsing non sécurisé et la dérive de schéma entre la documentation et le comportement réel.

Valider les corps de requête contre un schéma

Ne vous reposez pas sur des instructions if écrites à la main dispersées dans les contrôleurs. Utilisez des schémas de requête explicites pour le corps, les paramètres de chemin et les paramètres de requête.

Fichier : src/validation/updateProfile.ts

import { z } from "zod";

export const updateProfileSchema = z.object({
  displayName: z.string().min(1).max(80),
  marketingOptIn: z.boolean().optional(),
});

Fichier : src/middleware/validateBody.ts

import { AnyZodObject } from "zod";
import { Request, Response, NextFunction } from "express";

export function validateBody(schema: AnyZodObject) {
  return (req: Request, res: Response, next: NextFunction) => {
    const result = schema.safeParse(req.body);

    if (!result.success) {
      return res.status(400).json({
        error: "Invalid request body",
        details: result.error.flatten(),
      });
    }

    req.body = result.data;
    next();
  };
}

Empêcher le dépassement de propriétés d’objet

N’autorisez que les propriétés connues à passer. Ne liez pas du JSON arbitraire dans des modèles ORM ou des objets de mise à jour directement.

Mauvais pattern :

await userRepository.update(req.params.userId, req.body);

Meilleur pattern :

const allowed = {
  displayName: req.body.displayName,
  marketingOptIn: req.body.marketingOptIn,
};

await userRepository.update(req.params.userId, allowed);

Valider les paramètres de requête et la pagination

Les paramètres de requête font aussi partie de la surface d’attaque. Appliquez des plages et des valeurs par défaut.

Fichier : src/validation/listOrdersQuery.ts

import { z } from "zod";

export const listOrdersQuerySchema = z.object({
  limit: z.coerce.number().int().min(1).max(100).default(25),
  offset: z.coerce.number().int().min(0).default(0),
  status: z.enum(["pending", "paid", "failed"]).optional(),
});

Vérifier le comportement de désérialisation et du parser

Signalez tout endpoint qui :

• accepte des objets sérialisés bruts sans validation de schéma
• interprète dynamiquement des opérateurs ou noms de champs depuis le JSON
• accepte des requêtes GraphQL avec des contrôles de complexité faibles
• accepte des formats de fichiers ou transformations de documents non sécurisés

Aligner OpenAPI avec le comportement réel

Si votre spec OpenAPI dit que seul displayName est modifiable, mais que l’endpoint accepte réellement isAdmin, tenantId ou accountBalance, vous avez un écart entre la spec et le runtime.

Un extrait de schéma de requête sûr ressemble à ceci :

Fichier : openapi/profile.yaml

paths:
  /v1/me/profile:
    patch:
      requestBody:
        required: true
        content:
          application/json:
            schema:
              type: object
              additionalProperties: false
              properties:
                displayName:
                  type: string
                  maxLength: 80
                marketingOptIn:
                  type: boolean

Vous devriez maintenant savoir si votre API applique des schémas de requête, limite les propriétés modifiables, contraint les paramètres de requête et garde le comportement du runtime aligné avec le contrat documenté.

Étape 4 : Vérifier la limitation de débit et les contrôles anti-abus

C’est ici que vous vérifiez à la fois l’abus classique d’API et les chemins modernes d’amplification de coût. Tous les cas d’abus ne sont pas de la force brute. Certains sont l’abus de pagination, l’abus d’export en masse, les floods OTP, l’abus de dépenses de tokens IA ou l’automatisation de workflows partenaires.

Créer des profils de débit par route

N’appliquez pas une seule limite globale à tout. Différents endpoints nécessitent différents contrôles.

Fichier : rate-limit-profile.yaml

routes:
  /v1/auth/login:
    limit_per_minute: 5
    burst: 2
    key: ip_plus_username
  /v1/password/reset:
    limit_per_hour: 3
    key: account_identifier
  /v1/orders/search:
    limit_per_minute: 30
    burst: 10
    key: token_subject
  /v1/ai/generate:
    limit_per_minute: 10
    burst: 2
    key: tenant_id

Ajouter des limites au niveau implémentation

Fichier : src/middleware/rateLimit.ts

import rateLimit from "express-rate-limit";

export const loginRateLimit = rateLimit({
  windowMs: 60 * 1000,
  max: 5,
  standardHeaders: true,
  legacyHeaders: false,
  keyGenerator: (req) => `${req.ip}:${req.body.username ?? "unknown"}`,
});

Vérifier la protection contre l’énumération

Vérifiez si des attaquants peuvent énumérer à moindre coût :

• des ID utilisateurs
• des ID de comptes
• des ID de factures
• l’existence d’emails
• les flux de réinitialisation de mot de passe
• des tokens d’invitation
• des enregistrements partenaires

Cherchez des réponses 404 vs 403 incohérentes, des différences de timing et des corps d’erreur différents pour “existe” versus “n’existe pas.”

Vérifier l’abus de bot et de flux métier

Identifiez les flux à haute valeur métier :

• création de coupons
• création d’essais
• échange de cartes cadeaux
• téléchargements en masse
• attribution de sièges
• endpoints de génération IA
• endpoints d’envoi OTP ou email

Ajoutez des contrôles comme :

• des quotas spécifiques par route
• des clés d’idempotence
• CAPTCHA ou challenge sur les flux publics
• des alertes d’anomalie de workflow
• mise en file d’attente pour les jobs async coûteux

Vérifier les chemins d’amplification de coût

Les API modernes proxifient souvent des coûts externes :

• SMS
• email
• rendu de documents
• inférence IA
• géocodage
• vérifications de fraude

Si une route peut brûler de l’argent par requête, elle a besoin de contrôles plus stricts qu’un endpoint normal en lecture seule.

Vous devriez maintenant savoir quels endpoints nécessitent des contrôles de rafale plus forts, une résistance à l’énumération et des quotas conscients des coûts.

Étape 5 : Vérifier l’exposition des données sensibles

Cette étape attrape les API qui techniquement exigent l’auth mais exposent quand même trop de données au mauvais appelant, au mauvais sink de logs ou au mauvais service downstream.

Auditer l’exposition des champs de réponse

Pour chaque ressource sensible, définissez une liste blanche de réponse par rôle ou audience.

Fichier : src/serializers/customerSerializer.ts

type Customer = {
  id: string;
  email: string;
  fullName: string;
  internalRiskScore: number;
  billingAddress: string;
};

export function serializeCustomerForSelf(customer: Customer) {
  return {
    id: customer.id,
    email: customer.email,
    fullName: customer.fullName,
    billingAddress: customer.billingAddress,
  };
}

export function serializeCustomerForSupport(customer: Customer) {
  return {
    id: customer.id,
    email: customer.email,
    fullName: customer.fullName,
  };
}

Ne retournez pas directement des entités ORM complètes.

Masquer les logs

Les logs d’accès et d’application fuient souvent des tokens, emails, numéros de compte ou corps de requête complets. Masquez avant d’écrire.

Fichier : src/logging/redact.ts

export function redact(value: string): string {
  return value
    .replace(/Bearer\s+[A-Za-z0-9._-]+/g, "Bearer [REDACTED]")
    .replace(/[A-Z0-9._%+-]+@[A-Z0-9.-]+\.[A-Z]{2,}/gi, "[REDACTED_EMAIL]");
}

Et ne loggez jamais les corps sensibles par défaut sur les routes d’auth, de paiement ou de prompt IA.

Supprimer ou verrouiller les endpoints de debug

Vérifiez toutes les routes comme :

• /debug
• /internal
• /health/details
• /graphql-playground
• /swagger
• /metrics
• /__admin

Ceux-ci sont souvent laissés exposés parce qu’ils sont “pour les ops”, mais l’exposition en production doit être intentionnelle et protégée.

Vérifier le transfert vers des tiers

Si votre API transfère des prompts, charges utiles, données client ou identifiants vers des fournisseurs SaaS externes, documentez et validez ce flux explicitement.

Fichier : third-party-forwarding-review.yaml

dependency: external-ai-provider
forwarded_fields:
  - prompt
  - account_tier
  - locale
disallowed_fields:
  - raw_access_token
  - full_payment_card
  - national_id
response_validation: required
timeout_seconds: 15

Vous devriez maintenant savoir si vos API retournent trop de données, fuient des informations dans les logs, exposent des surfaces de debug ou transfèrent plus de données que nécessaire vers des tiers.

Étape 6 : Vérifier la sécurité opérationnelle

De bons contrôles au niveau du code échouent quand même si la frontière API est mal configurée ou si vous ne pouvez pas détecter l’abus à temps.

Vérifier les contrôles de gateway et reverse proxy

Pour chaque frontière API, vérifiez :

• TLS partout où il devrait être
• seules les méthodes HTTP requises exposées
• limites de taille de corps
• timeout de requête et politique de timeout upstream
• propagation de l’ID de requête
• validation de schéma où supportée
• listes blanches d’IP pour les API partenaires ou admin

Vérifier la surveillance et les alertes

Au minimum, suivez :

• les pics de 401 et 403
• les pics de 429
• la latence par route
• les 5xx par route
• les échecs d’auth par endpoint
• les balayages de volume élevé d’ID d’objets
• le trafic vers les versions dépréciées
• l’utilisation inhabituelle des partenaires

Créez une petite checklist de métriques :

Fichier : api-monitoring-checklist.md

# API Monitoring Checklist

- 401/403 dashboard per route
- 429 dashboard per route
- Token subject or tenant-based rate anomaly alerts
- Object enumeration detection on high-value routes
- Deprecated version traffic alerts
- Third-party dependency timeout alerts

Vérifier le versioning et la dépréciation

Chaque version devrait avoir :

• un propriétaire
• une audience
• une date de fin de vie
• un plan de communication de dépréciation
• une vérification de retrait de trafic

Vous pouvez aussi exposer des headers de dépréciation et de sunset.

Fichier : src/middleware/deprecation.ts

import { Request, Response, NextFunction } from "express";

export function markDeprecated(res: Response) {
  res.setHeader("Deprecation", "true");
  res.setHeader("Sunset", "Wed, 30 Sep 2026 23:59:59 GMT");
  res.setHeader("Link", '</docs/migrate-v2>; rel="deprecation"');
}

Vérifier aussi les API partenaires et internes

De nombreuses organisations font un travail correct sur les API publiques et un travail faible sur les API “internes uniquement”. Les routes internes, partenaires et admin devraient quand même être inventoriées, versionnées, surveillées et auditées.

Vous devriez maintenant savoir si la frontière API est durcie, si vous pouvez détecter l’abus et si les anciennes versions et routes cachées sont gérées délibérément.

Étape 7 : Transformer les résultats en plan de remédiation

Un audit d’API n’a d’importance que s’il produit des changements. Les meilleurs plans de remédiation séparent la réduction rapide des risques du travail de conception qui nécessite plus de temps.

Capturer les résultats dans un format structuré

Fichier : api-audit-findings.yaml

findings:
  - id: API-001
    category: API1-BOLA
    service: payments-api
    endpoint: GET /v1/accounts/{accountId}
    severity: critical
    issue: Account lookup does not verify tenant ownership
    quick_fix: Add tenant-scoped query and authorization middleware
    owner: payments-team
    due_in_days: 7

  - id: API-002
    category: API3-BOPLA
    service: partner-orders
    endpoint: PATCH /v1/orders/{id}
    severity: high
    issue: Writable object accepts undocumented internal fields
    quick_fix: Add request schema with explicit allowlist
    owner: bizops-team
    due_in_days: 14

  - id: API-003
    category: API9-Inventory
    service: legacy-beta
    endpoint: unknown
    severity: high
    issue: Public beta host has no owner, no spec, and no retirement plan
    quick_fix: Remove public exposure or assign owner immediately
    owner: platform-team
    due_in_days: 3

Séparer les corrections rapides des corrections architecturales

Bonnes corrections rapides :

• ajouter des vérifications de propriété
• ajouter des vérifications de scope manquantes
• restreindre les champs de réponse
• ajouter la validation de schéma
• baisser les limites de route
• désactiver les endpoints de debug
• supprimer les DNS publics ou le routage obsolètes

Corrections architecturales à moyen terme :

• déplacer l’authz dans une couche de politique centralisée
• séparer les API admin et publiques
• reconcevoir l’isolation des tenants
• créer une découverte automatisée de l’inventaire
• ajouter des contrôles de politique d’admission ou de gateway
• standardiser les sérialiseurs de réponse et la génération de schéma

Assigner des propriétaires et des dates d’échéance

Chaque résultat a besoin de :

• une équipe propriétaire
• une sévérité
• une approche de remédiation
• une date cible
• une méthode de validation

Re-tester la correction

Une correction n’est pas complète tant que vous ne pouvez pas prouver que le chemin d’abus a disparu. Pour chaque résultat, sauvegardez un test positif et un test négatif.

Fichier : tests/account-ownership.http

### Allowed: own tenant account
GET https://api.example.com/v1/accounts/acc_123
Authorization: Bearer {{tenant_a_token}}

### Blocked: another tenant account
GET https://api.example.com/v1/accounts/acc_999
Authorization: Bearer {{tenant_a_token}}

Problèmes courants de configuration

Auditer uniquement les API publiques

Les équipes auditent souvent la gateway publique et ignorent les surfaces internes, admin, partenaires, bêta et dépréciées. Cela laisse certaines des routes les plus risquées en dehors de l’audit.

Supposer que l’authentification équivaut à l’autorisation

Un token valide n’est pas la preuve que l’appelant devrait accéder à un objet, champ ou fonction spécifique. Vérifiez l’authz séparément aux niveaux objet, champ, fonction et tenant.

Trouver des API shadow mais ne pas les supprimer

Le travail d’inventaire ne réduit le risque que si les API obsolètes ou inconnues obtiennent une propriété, une protection ou une suppression. Un tableur seul ne ferme pas l’exposition.

Générer des specs OpenAPI mais ne pas les appliquer

Une spec qui n’est pas liée à la validation, aux tests ou à la revue peut dériver jusqu’à devenir décorative. Préférez la validation de schéma et les tests de contrat aux specs uniquement documentaires.

Corriger un endpoint au lieu du pattern

Si vous trouvez un problème d’autorisation au niveau objet cassé, cherchez le même pattern d’accès dans toute la base de code. Les failles d’API se répètent souvent par framework, sérialiseur ou pattern de repository.

Conclusion

Un audit d’API solide commence par l’inventaire et se termine par une remédiation priorisée. Le chemin de revue le plus rentable est généralement : vérifier toutes les surfaces API, vérifier l’autorisation au niveau objet et fonction, contraindre les schémas et propriétés modifiables, verrouiller les contrôles anti-abus, réduire l’exposition des données sensibles, puis nettoyer les lacunes opérationnelles comme les versions cachées et la surveillance faible.

Répétez cet audit selon un calendrier, pas seulement après les incidents. Un rythme pratique est trimestriel pour les API à haut risque, après les changements majeurs d’auth ou de gateway, et chaque fois que vous ajoutez de nouvelles intégrations partenaires, SaaS ou dépendantes de l’IA. Pour maintenir l’inventaire à jour, liez la découverte de routes à la revue de code, aux changements de configuration de gateway et à la télémétrie du trafic au lieu de vous appuyer uniquement sur les mises à jour de documentation.

L’objectif principal n’est pas de “passer OWASP.” C’est de s’assurer que vos API sont difficiles à énumérer, difficiles à abuser, difficiles à surconsommer, et faciles à comprendre et à retirer quand elles ne devraient plus exister.