OWASP API Security Top 10 expliqué - Édition 2023 détaillée

L'OWASP API Security Top 10 est le référentiel de vulnérabilités propres aux API, complémentaire de l'OWASP Top 10 web classique. Publié initialement en 2019, mis à jour en 2023, il liste les 10 classes d'erreurs les plus fréquentes dans les API REST/GraphQL/gRPC observées en production. Ce guide détaille chaque item de la version 2023 avec définition, exemples concrets, cas réels, et mitigations. Utile pour développeurs, AppSec, pentesters et DevSecOps qui sécurisent ou testent des API.

1. Contexte - pourquoi un Top 10 dédié aux API

1.1 Genèse

L'OWASP Top 10 historique (1ère édition 2003) cible les applications web classiques rendues en HTML. À partir de 2015, les attaques observées contre les API ont des patterns distincts que le Top 10 web ne capture pas proprement : BOLA, BFLA, mass assignment, scraping logic-aware. L'OWASP lance donc un projet dédié, publié en 2019 avec la première version de l'API Security Top 10.

1.2 Version 2023 - évolution de la 2019

Mise à jour basée sur les données de pentests, rapports d'incidents et feedback communautaire accumulés depuis 4 ans. Changements majeurs :

• Fusion de l'ex-API3 (Excessive Data Exposure) et l'ex-API6 (Mass Assignment) dans la nouvelle API3:2023 Broken Object Property Level Authorization (BOPLA) - les deux problèmes étaient deux faces de la même pièce : contrôle d'accès au niveau des propriétés d'un objet.
• Nouveauté API6:2023 : Unrestricted Access to Sensitive Business Flows - attaques via abus de flows métier légitimes (scalping, reservations automatisées, credential stuffing).
• Nouveauté API7:2023 : Server Side Request Forgery (SSRF) - enfin reconnu comme pattern API distinct vs le Top 10 web.
• Nouveauté API10:2023 : Unsafe Consumption of APIs - risque transféré sur le consommateur d'API tierces (supply chain applicative).

1.3 Positionnement par rapport au Top 10 web

Le Top 10 web et le Top 10 API se recouvrent partiellement (authentication, injection peuvent toucher les deux) mais les items spécifiques API (BOLA, BFLA, BOPLA, Business Flows) n'ont pas d'équivalent dans le Top 10 web, et réciproquement (XSS, Server-Side Request Forgery web-specific).

Un programme AppSec mature utilise les deux comme référentiels complémentaires.

2. API1:2023 - Broken Object Level Authorization (BOLA)

2.1 Définition

Un endpoint autorise l'accès à un objet par son identifiant sans vérifier que l'utilisateur authentifié est légitimement propriétaire ou autorisé sur cet objet.

L'utilisateur est bien authentifié (auth passe), mais l'autorisation au niveau de l'objet n'est pas vérifiée.

2.2 Exemple concret

Endpoint légitime :

GET /api/invoices/78901
Authorization: Bearer <token user Alice>

Serveur :

• Vérifie le token (Alice est bien authentifiée).
• Retourne l'invoice 78901.
• Ne vérifie pas que l'invoice 78901 appartient bien à Alice.

Attaque :

GET /api/invoices/78902
Authorization: Bearer <token user Alice>

Serveur retourne l'invoice 78902 qui appartient en réalité à Bob. Alice a accédé à la facture d'un autre client.

2.3 Cas réel - USPS 2018

Une API interne sur usps.com retournait les données de n'importe quel utilisateur USPS via modification d'ID dans l'URL. Un attaquant authentifié pouvait énumérer 60 millions de records. Correction Matin 2018 après signalement.

2.4 Pourquoi c'est le N°1

BOLA est présent dans plus de 40 % des API testées en pentest (Salt Security 2023). Causes :

• Les développeurs vérifient l'authentification (middleware global) mais oublient la vérification d'ownership (logique métier).
• Les ORMs par défaut chargent un objet par ID sans contexte utilisateur.
• Les tests unitaires testent le path heureux (propriétaire accède à sa propre ressource), rarement le path d'attaque.
• Les code reviews passent à côté car le code "marche" pour l'utilisateur légitime.

2.5 Mitigations

• Vérifier l'ownership systématiquement dans le handler :

def get_invoice(invoice_id: int, current_user: User):
    invoice = Invoice.objects.get(id=invoice_id)
    if invoice.customer_id != current_user.id:
        raise HTTPException(status_code=403, detail="Forbidden")
    return invoice

• Ou mieux : filter directement par user :

invoice = Invoice.objects.filter(
    id=invoice_id, 
    customer_id=current_user.id
).first()
if not invoice:
    raise HTTPException(status_code=404)

• UUIDs au lieu d'IDs séquentiels : empêche l'énumération triviale, ne remplace pas la vérification d'ownership.
• Tests d'autorisation automatisés avec 2+ users en CI : Alice ne peut pas accéder aux invoices de Bob.
• Policy engines centralisés (OPA, Cedar) pour externaliser la logique d'autorisation.
• Row-Level Security côté base quand applicable.

3. API2:2023 - Broken Authentication

3.1 Définition

Mécanismes d'authentification faibles, mal implémentés, ou contournables. Recouvre :

• Pas d'authentification sur des endpoints qui devraient en avoir.
• Authentification triviale à contourner.
• Tokens JWT mal validés.
• Credentials en dur dans les clients.
• Pas de rate limiting sur les endpoints de login.
• Reset password exploitable (email énumération, tokens prédictibles).

3.2 Cas réel - Peloton 2021

Un endpoint API Peloton retournait les données d'un utilisateur sans exiger d'authentification (endpoint laissé "public" par oubli). 3 millions de comptes exposés.

3.3 Cas réel - Twitter 2022

Une API de recherche permettait de retrouver un compte Twitter à partir d'un email ou numéro de téléphone, sans rate limiting adapté. Exploité à grande échelle pour produire une base de 5,4 millions d'utilisateurs liés à leurs contacts.

3.4 Pièges JWT fréquents

Les JWT sont massivement utilisés en API. Pièges récurrents :

• Algorithme none accepté par le serveur (pas de signature vérifiée).
• Confusion HMAC/RSA : serveur qui vérifie un JWT RS256 avec la clé publique comme secret HMAC, attaquant signe en HS256 avec la clé publique connue.
• Durée de vie infinie : JWT sans expiration ou avec expiration à 1 an.
• Pas de révocation : impossible d'invalider un JWT compromis avant son expiration.
• Secret HMAC faible : clé HS256 de 8 caractères cassable par bruteforce.
• Confiance sans vérification : client qui accepte un JWT auto-signé.

3.5 Mitigations

• Authentification obligatoire sur tous les endpoints non volontairement publics.
• Standards éprouvés : OAuth 2.0 Authorization Code + PKCE pour web/mobile, OIDC pour identity, mTLS pour service-to-service.
• JWT bien configuré : algorithme fixé côté serveur (pas négociable), expiration courte (15 min access token), rotation via refresh token, révocation via jti blacklist ou session server-side.
• Rate limiting agressif sur login, password reset, account creation.
• MFA obligatoire pour comptes à privilèges.
• Audit : loguer toutes les authentifications, surveiller les anomalies.
• Pas de credentials en dur dans les clients mobiles ou JS (cf. API keys).

4. API3:2023 - Broken Object Property Level Authorization (BOPLA)

4.1 Définition

Problème d'autorisation au niveau des propriétés d'un objet. Deux facettes :

• Excessive Data Exposure (ex-API3:2019) : l'API renvoie plus de champs que nécessaire. L'utilisateur voit des champs auxquels il n'a pas droit.
• Mass Assignment (ex-API6:2019) : l'API accepte la modification de champs qui devraient être read-only ou admin-only.

4.2 Excessive Data Exposure - exemple

Endpoint :

GET /api/users/123

Réponse :

{
  "id": 123,
  "name": "Jean Dupont",
  "email": "jean@example.com",
  "phone": "0612345678",
  "address": "12 rue de Paris, 75001",
  "ssn": "1-85-09-75-123-456",
  "password_hash": "$argon2id$...",
  "is_admin": true,
  "created_at": "2024-06-15",
  "stripe_customer_id": "cus_abc123"
}

L'application mobile n'affiche que le nom et l'email. Mais l'API renvoie tout. Un utilisateur malin sniffe le trafic et récupère tous les champs sensibles, y compris SSN et stripe_customer_id qui permettent fraude.

4.3 Mass Assignment - exemple

Endpoint profil :

PUT /api/users/me
Body: {"name": "Jean Dupont Nouveau"}

Code vulnérable (Ruby on Rails, Python Django, etc.) :

def update_profile(request):
    user = request.user
    for key, value in request.json.items():
        setattr(user, key, value)
    user.save()

Attaque :

PUT /api/users/me
Body: {"name": "Jean", "is_admin": true, "email_verified": true, "credits": 100000}

Le code applique tous les champs du JSON, y compris is_admin. L'attaquant devient admin.

4.4 Cas réel - GitHub 2012

Bug Mass Assignment Rails permettait à un utilisateur d'ajouter sa clé SSH à n'importe quel autre user. Signalé par Egor Homakov qui a push un commit dans le repo Rails officiel pour démontrer l'impact.

4.5 Mitigations Excessive Data Exposure

• Schéma de réponse explicite : DTO (Data Transfer Object) qui ne contient que les champs à exposer.
• Serializers avec fields whitelist (Django REST Framework, Marshmallow, Pydantic).
• GraphQL : l'avantage naturel est que seuls les champs demandés sont retournés - mais attention à l'autorisation par champ.
• Reviewer tout nouvel endpoint : quels champs sont renvoyés ? Chacun est-il nécessaire ?
• Scan automatisé : outils comme 42Crunch détectent les fields non nécessaires dans les schémas OpenAPI.

4.6 Mitigations Mass Assignment

• DTO stricts : parser le body dans une structure typée qui ne contient que les champs acceptables.
• Whitelist explicite :

class UpdateProfileDTO(BaseModel):
    name: str | None = None
    phone: str | None = None
    class Config:
        extra = "forbid"  # rejeter tout champ non prévu

• Éviter les méthodes ORM auto-populantes (.update() avec dict, fill() en Eloquent sans $fillable).
• Séparer les modèles : UserProfile pour user, UserAdmin pour admin, routage distinct.

5. API4:2023 - Unrestricted Resource Consumption

5.1 Définition

L'API ne limite pas les ressources consommées par requête ou par période : pas de rate limiting, pas de taille max, pas de profondeur max (GraphQL), pas de quotas.

5.2 Conséquences

• DoS économique : facture cloud qui explose (CPU, data egress).
• DoS de service : serveurs saturés, utilisateurs légitimes refusés.
• Scraping massif : exfiltration de données par volume.
• Abuse de flows : création de milliers de comptes fake, tests de CC volées, etc.

5.3 Cas réel - T-Mobile 2023

API partenaires sans rate limiting adapté. Attaquant a pu scraper 37 millions de records clients sur plusieurs semaines. 350 M$ d'amende FCC.

5.4 Mitigations

• Rate limiting multi-niveaux : par IP, par user authentifié, par endpoint, par action métier.
• Quotas : X requêtes par jour, Y Go par mois.
• Payload size limits : max 1 MB pour body JSON standard.
• Query complexity limits (GraphQL) : depth max 10, complexity score max 1000.
• Timeout : chaque requête coupée si plus de Y secondes.
• Pagination obligatoire : pas de ?limit=1000000, max enforced à 100-1000.
• Circuit breakers sur les services downstream pour éviter cascade failure.
• Detection de scraping : patterns d'accès séquentiel à IDs, volumes anormaux par user.

6. API5:2023 - Broken Function Level Authorization (BFLA)

6.1 Définition

Un utilisateur standard peut accéder à des fonctions réservées aux administrateurs en appelant directement l'endpoint. L'autorisation au niveau de la fonction n'est pas vérifiée.

Différence avec BOLA : BOLA concerne l'accès à un objet (ressource donnée), BFLA concerne l'accès à une fonction (action).

6.2 Exemple concret

API publique :

• GET /api/users/me : retourne mon profil.
• DELETE /api/users/me : supprime mon compte.

API admin :

• GET /api/admin/users : liste tous les utilisateurs.
• DELETE /api/admin/users/{id} : supprime n'importe quel user.
• POST /api/admin/users/{id}/promote : promote user to admin.

Si le code admin n'est pas protégé par un middleware qui vérifie le rôle admin, un user standard peut appeler POST /api/admin/users/me/promote et devenir admin.

6.3 Pourquoi c'est fréquent

• Développeurs qui "cachent" les endpoints admin dans l'URL sans enforcer le contrôle (security by obscurity).
• Middlewares d'autorisation qui vérifient l'authentification mais pas le rôle.
• Architectures microservices où chaque service implémente sa propre autorisation, certains oublient.
• Endpoints admin développés rapidement pour un POC interne, exposés sans réviser.

6.4 Mitigations

• Middleware d'autorisation par rôle obligatoire sur tous les endpoints admin :

@require_role("admin")
@app.post("/api/admin/users/{id}/promote")
def promote_user(id: int):
    ...

• Séparation des routers : tout /api/admin/* passe par un router avec vérification admin globale.
• Deny by default : chaque endpoint doit explicitement déclarer qui y accède. Pas de route "par défaut ouverte".
• Tests automatisés : un user standard doit recevoir 403 sur tous les endpoints admin.

7. API6:2023 - Unrestricted Access to Sensitive Business Flows

7.1 Définition

Nouveauté 2023. Les flows métier sensibles sont abusés par automation : réservations, achats, votes, créations de comptes, applications promo.

Chaque requête est techniquement légitime. C'est leur fréquence et leur patterns d'usage qui trahissent l'abus.

7.2 Exemples

• Scalping de stocks limités : bots qui achètent les 1000 PS5 disponibles en 5 secondes pour revendre.
• Abus de promo codes : génération de milliers de comptes pour accumuler des crédits d'essai.
• Vote manipulation : scripts qui votent des milliers de fois dans un sondage en ligne.
• Credential stuffing : tests massifs de couples email/password volés ailleurs.
• Card cracking : tests de numéros de cartes sur endpoints de paiement ouverts.
• Fake account creation : milliers de comptes jetables pour influence, fraude, manipulation.

7.3 Cas réel - Ticketmaster et Nike

Les bots de scalping pour billets et sneakers sont si efficaces qu'un humain réel n'a quasi aucune chance d'obtenir une édition limitée. Économies parallèles de bots-as-a-service.

7.4 Mitigations

• Threat modeling par flow : identifier les flows abusables (value création, ressource rare, identité création).
• Bot management spécialisé : DataDome, Imperva Advanced Bot Protection, Cloudflare Bot Management, Akamai Bot Manager. Ces solutions distinguent humain de bot via fingerprinting, comportement souris, challenges invisibles.
• Rate limiting contextuel : moins de X achats par user par minute, moins de Y créations de compte par IP par jour.
• Captcha adaptatif : silencieux pour humains, bloquant pour bots.
• Device fingerprinting pour détecter la réutilisation de devices.
• Proof of Work pour rendre le scraping économiquement non viable.

8. API7:2023 - Server Side Request Forgery (SSRF)

8.1 Définition

L'API accepte en entrée une URL, un hostname ou une ressource identifier utilisé pour faire une requête côté serveur. Un attaquant peut manipuler cet input pour forcer le serveur à accéder à des URLs internes ou sensibles.

8.2 Exemples

Endpoint webhook :

POST /api/webhooks
Body: {"url": "https://attacker.com/callback"}

Légitime : le serveur appelle l'URL pour tester la connectivité. Attaque :

POST /api/webhooks
Body: {"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}

Le serveur (dans AWS EC2) récupère les credentials IAM de l'instance. Incident Capital One 2019 : 100 millions de records exfiltrés via SSRF.

Autres payloads SSRF classiques :

• http://localhost:8500/ (Consul service mesh).
• http://10.0.0.1/admin/ (hosts internes).
• file:///etc/passwd (protocole file).
• gopher:// (pour attaquer des services non-HTTP).

8.3 Cas réel - Capital One 2019

SSRF dans une application WAF mal configurée → vol des credentials IAM de l'instance EC2 → accès aux buckets S3 → 100 millions de records. 80 M$ d'amende régulateur.

8.4 Mitigations

Voir l'article dédié c'est quoi une vulnérabilité SSRF pour les détails. Résumé :

• Allowlist stricte des URLs autorisées (domaines, pas patterns trop larges).
• Parse et validation : résoudre le hostname, vérifier que l'IP résultante n'est pas privée (RFC 1918), pas loopback, pas 169.254.169.254.
• Requêtes via proxy dédié qui applique la policy (Smokescreen, tinyproxy + rules).
• Protocol whitelist : seulement https, pas file://, gopher://, dict://.
• IMDSv2 côté AWS (Capital One n'aurait pas marché avec IMDSv2).

9. API8:2023 - Security Misconfiguration

9.1 Définition

Configurations par défaut non durcies, headers manquants, CORS trop permissif, verbose errors, TLS faible, panels admin exposés.

9.2 Exemples courants

• CORS Access-Control-Allow-Origin: * sur des endpoints avec credentials : n'importe quel site peut appeler l'API avec les cookies de l'utilisateur.
• Verbose errors en production : stack traces, queries SQL, noms de tables exposés dans les responses 500.
• Directory listing activé sur endpoints statiques.
• Panels admin (phpMyAdmin, Kibana, Elasticsearch, Grafana) exposés sans auth.
• TLS 1.0/1.1 ou cipher suites faibles acceptés.
• Headers sécurité manquants : HSTS, CSP, X-Content-Type-Options, Referrer-Policy (voir security headers complet).
• Debug endpoints oubliés en prod : /debug, /__debug, /api/internal.

9.3 Mitigations

• Hardening baseline par framework (Express + helmet, Spring Security, Django security middleware).
• Automated scans : Checkov, tfsec pour IaC ; security headers scanners.
• Secure defaults : CORS restrictif par défaut, errors génériques en prod, TLS 1.2 minimum.
• Review systématique de config avant prod.
• Bastion pour admin panels : pas d'exposition directe sur Internet.

10. API9:2023 - Improper Inventory Management

10.1 Définition

L'organisation ne sait pas combien d'API elle expose, quelles versions sont actives, quels endpoints existent. Shadow APIs, zombie APIs, rogue APIs.

10.2 Formes

• Shadow API : créée par une équipe sans passer par la gouvernance. Non inventoriée, non documentée, non scannée.
• Zombie API : ancienne version (v1, v2) restée active après déploiement de v3, maintenue par personne mais utilisable par les attaquants.
• Rogue API : endpoint de debug/test oublié en prod. Exemple : /api/admin/reset-db.

10.3 Conséquences

• Vulnérabilités dans shadow APIs qui ne sont pas patchées car non suivies.
• Zombie APIs avec authentification obsolète, exploitables facilement.
• Audits et conformité incomplets si l'inventaire est faux.

10.4 Cas réel - Optus 2022

Une API "publique" sans authentification, apparemment oubliée du processus normal d'inventory. 10 millions de records clients exfiltrés.

10.5 Mitigations

• API discovery automatique : Akto, Salt Security, 42Crunch, Cloudflare API Shield, AWS Firewall Manager.
• API Gateway obligatoire : toute API passe par le gateway, impossible d'exposer directement.
• Versioning strict : désactivation des vieilles versions après période de deprecation communiquée.
• Inventaire central versionné (registre OpenAPI, Postman Network, Kong Developer Portal).
• Audit régulier : scan externe de l'espace IP pour détecter les API exposées inconnues.
• Ownership : chaque API a un owner, responsable maintenance et documentation.

11. API10:2023 - Unsafe Consumption of APIs

11.1 Définition

Nouveauté 2023. Risque lié au fait de consommer des API tierces sans validation. L'API tierce peut être compromise, malveillante, ou simplement buggée, et votre application propage les dégâts.

11.2 Exemples

• Webhook inbound : votre API reçoit un webhook d'un partenaire. Si vous faites confiance aveuglément aux données, une compromission du partenaire injecte des données malveillantes dans votre DB.
• API tierce que vous appelez (Stripe, Twilio, SendGrid, OpenAI) : la réponse peut contenir des données que vous réinjectez dans votre interface sans encoding, vulnérabilité XSS.
• API partenaires sans contrats clairs sur les données envoyées : données mal formatées ou excessives qui cassent votre app.
• Redirections non validées : votre API suit un redirect d'une API tierce vers une URL attaquant.

11.3 Cas réel - SolarWinds supply chain (2020)

Pas strictement API, mais même principe : le consommateur (organisations SolarWinds Orion) faisait confiance aveuglément au fournisseur compromis. Principe applicable : toute consommation d'API tierce introduit un risque de supply chain.

11.4 Mitigations

• Validation stricte des inputs de webhooks (schéma, authentification du webhook via signature HMAC).
• Verify partner identity : mTLS pour les appels inter-entreprises B2B critiques.
• Rate limiting inbound : un partenaire compromis ne doit pas pouvoir flooder votre API.
• Output encoding des données tierces avant injection dans UI ou DB.
• Timeouts et circuit breakers sur les appels outbound.
• Audit log de toutes les interactions inter-API.
• Regular verification que les certificats, signatures, tokens sont à jour.

12. Comment utiliser le Top 10 en pratique

12.1 En développement

• Formation équipe : session de 2-4 heures où chaque item est expliqué avec exemples code base interne.
• Checklists PR : chaque PR touchant un endpoint est reviewée contre le Top 10.
• Linting automatique : Spectral (Stoplight) avec règles OWASP API, 42Crunch CLI.
• Tests sécurité unitaires : pour chaque endpoint, test BOLA (user A ne voit pas data user B), test BFLA (user standard n'accède pas fonctions admin).

12.2 En CI/CD

• Schema linting en CI : rejeter les OpenAPI qui contiennent des anti-patterns connus.
• Tests d'intégration authorization : scénarios avec 2+ users, 1 admin + 1 standard.
• DAST API : OWASP ZAP, Postman Collection Runner avec tests de sécurité.
• Fuzzing schema-based : Schemathesis, Restler (Microsoft Research).

12.3 En pentest

• Pentest API dédié annuel minimum, distinct du pentest web.
• Scope : tous les endpoints (pas juste les "publics"), incluant mobile, partenaires, webhooks.
• Methodology OWASP WSTG-API (Web Security Testing Guide section API).
• Outils : Burp Suite + extensions API, Postman avec tests, curl scripts custom.

12.4 En runtime

• WAAP (Web Application and API Protection) qui comprend la sémantique API.
• API security platform (Salt, Noname, Traceable, Wallarm) avec détection comportementale.
• Observability : logs fins par endpoint, tracing (OpenTelemetry), alertes SIEM.

12.5 En training

• Apprentissage pratique via CTF API : APIsec University (gratuit), PortSwigger Academy API section, crAPI (OWASP Vulnerable API).

13. Limites du Top 10 et comment aller plus loin

13.1 Limites

• 10 items = synthèse, pas exhaustif. Des sujets importants absents : GraphQL-specific attacks, JWT specific issues (hors Broken Auth), gRPC, WebSocket, OAuth flows attacks, signature bypass, cryptographic issues API-specific.
• Focus REST : le Top 10 reste très orienté REST classique. GraphQL et gRPC ont des patterns spécifiques mal couverts.
• Évolutif : le paysage API change vite (AI, agents, WebSockets, server-sent events). Le Top 10 est mis à jour tous les 3-4 ans, peut prendre du retard.

13.2 Ressources complémentaires

• OWASP API Security Project : attaques et défenses détaillées au-delà du Top 10.
• OWASP Web Security Testing Guide (WSTG) - API section : checklist de pentest.
• OWASP Cheat Sheets : REST Security Cheat Sheet, GraphQL Cheat Sheet, JSON Web Token Cheat Sheet.
• NIST SP 800-95 : Guide to Secure Web Services.
• API Security in Action (Neil Madden, Manning) : livre de référence.

14. Verdict et posture Zeroday

L'OWASP API Security Top 10 est le point de départ incontournable pour toute équipe qui sécurise des API. Il ne suffit pas, mais sans lui on passe à côté des 80 % des vulnérabilités réellement exploitées.

Pour un développeur : connaître les 10 items et les vérifier mentalement sur chaque nouveau code API est la compétence minimale attendue en 2026 dans tout rôle back-end.

Pour un AppSec : structurer son programme autour du Top 10 (formation, tests, pentest, runtime) produit une couverture cohérente et démontrable. C'est le langage commun pour dialoguer avec les développeurs, le management, et les auditeurs externes.

Pour un pentester : maîtriser la traduction des 10 items en scénarios de test concrets est la grille professionnelle pour mener un pentest API crédible. Les profils capables le font paient actuellement 500 à 900 EUR/jour freelance en France.

Pour aller plus loin : chaque item du Top 10 mériterait un article détaillé propre. Les prochains articles de la catégorie API Security approfondiront individuellement BOLA, Broken Auth, BOPLA, Rate Limiting et les autres. En complément : pourquoi les API sont attaquées pour le contexte stratégique, introduction à l'OWASP Top 10 pour le pendant web, broken access control pour la racine commune de BOLA et BFLA, c'est quoi une vulnérabilité SSRF pour le focus SSRF API7, métier expert API security pour le parcours métier.