Aller au contenu
Guide

OWASP API Security Top 10 : liste de contrôle avec correctifs

| 12 min read

Parcourez les 10 risques de sécurité de l'API OWASP (édition 2023) avec des scénarios d'attaque réels, des correctifs concrets et une liste de contrôle copier-coller pour votre examen de sécurité.

Cybersecurity command center with multiple monitoring screens
Photo by Adi Goldstein on Unsplash

Votre API traite 10 000 requêtes par heure. Trois de ces demandes proviennent d'un attaquant qui modifie un order_id paramètre et télécharge chaque enregistrement client dans votre base de données. Vous trouvez lorsque vos utilisateurs le font, sur Twitter.

Le Top 10 de sécurité des API OWASP (édition 2023) répertorie les dix risques responsables de la majorité des Violations d'API. Ce guide passe en revue chaque risque avec une explication en un paragraphe, une attaque réaliste scénario et une solution concrète. Lorsqu'un point de terminaison de l'API botoi vous aide à détecter ou à prévenir le risque, le le point final pertinent est inclus avec un document de travail curl commande.

API1 : 2023 Autorisation au niveau de l'objet brisée (BOLA)

BOLA se produit lorsqu'une API renvoie des données basées sur un ID d'objet sans vérifier si le demandeur l'utilisateur est propriétaire de cet objet. Un attaquant appelle GET /api/orders/1001, récupère les données, puis itère à travers 1002, 1003, et ainsi de suite. Chaque enregistrement de la table est désormais exposé. BOLA s'est classé comme le risque d'API numéro un depuis la première liste de sécurité des API de l'OWASP en 2019.

Scénario d'attaque : Une application de livraison de nourriture expose GET /api/orders/:id. Un attaquant écrit une boucle de 1 à 100 000 et télécharge chaque commande, y compris les adresses de livraison, numéros de téléphone et détails du mode de paiement.

Voici le code vulnérable :

// Vulnerable: no ownership check
app.get("/api/orders/:id", async (req, res) => {
  const order = await db.orders.findById(req.params.id);
  res.json(order); // Any user can read any order
});

Et voici le correctif :

// Fixed: verify the requesting user owns the resource
app.get("/api/orders/:id", async (req, res) => {
  const order = await db.orders.findById(req.params.id);

  if (!order) return res.status(404).json({ error: "Not found" });
  if (order.userId !== req.user.id) {
    return res.status(403).json({ error: "Forbidden" });
  }

  res.json(order);
});

Chaque point de terminaison qui accepte un identifiant du client nécessite une vérification de propriété. Aucune exception. Utiliser middleware ou un filtre de requête (par exemple, WHERE user_id = ?) pour appliquer cela au niveau de la couche de données.

API2 : 2023 Authentification interrompue

L'authentification interrompue couvre la génération de jetons faibles, la validation des jetons manquants et le bourrage d'informations d'identification. attaques et les points de terminaison qui acceptent des jetons expirés ou falsifiés. Les attaquants ciblent les points de terminaison de connexion avec des listes d'informations d'identification violées, ou ils volent des jetons dans un stockage non sécurisé.

Scénario d'attaque : Un attaquant obtient une liste de 10 millions de paires email/mot de passe une violation de données. Ils écrivent un script qui teste chaque paire par rapport à votre POST /api/login point final. Votre API n'a pas de limite de débit pour les tentatives de connexion, l'attaquant compromet donc 2 000 comptes en une heure.

Réparer: Appliquez une limitation de débit sur les points de terminaison d’authentification (5 tentatives par minute et par IP). Exiger une authentification multifacteur pour les opérations sensibles. Vérifiez les informations d'identification de l'utilisateur par rapport aux informations connues violations avant d’autoriser la création de compte.

La API de vérification des violations de Botoi vous dit si une adresse e-mail est apparue dans des violations de données connues : 

curl -s -X POST https://api.botoi.com/v1/breach/check \\
  -H "Content-Type: application/json" \\
  -d '{
    "email": "user@example.com"
  }'

Réponse:

{
  "success": true,
  "data": {
    "breached": true,
    "count": 3,
    "breaches": [
      { "name": "ExampleCorp", "date": "2024-01-15", "dataTypes": ["email", "password"] },
      { "name": "DataDump2023", "date": "2023-08-22", "dataTypes": ["email", "username"] },
      { "name": "LeakedDB", "date": "2022-11-03", "dataTypes": ["email", "phone"] }
    ]
  }
}

Appel /v1/breach/check lors de l’inscription ou de la réinitialisation du mot de passe. Si l'e-mail apparaît dans des violations, inviter l'utilisateur à choisir un mot de passe unique et plus fort et à activer l'authentification à deux facteurs.

API3 : 2023 Autorisation au niveau de la propriété d'un objet cassé

Ce risque combine affectation massive et exposition excessive des données. L'affectation en masse se produit lorsqu'une API lie les champs du corps de la requête directement à un modèle de données sans filtrage. Un utilisateur envoie "role": "admin" dans une mise à jour de profil et obtient des privilèges élevés. Exposition excessive des données se produit lorsqu'une API renvoie des champs internes (ID de base de données, mots de passe hachés, indicateurs d'administrateur) au client je ne devrais jamais voir.

Scénario d'attaque : Une application SaaS permet aux utilisateurs de mettre à jour leur profil via PUT /api/users/:id. Le backend accepte le corps complet de la requête et l'écrit dans la base de données. Un attaquant ajoute "plan": "enterprise" à la demande et obtient un accès gratuit aux fonctionnalités premium.

Réparer: Use explicit allowlists for writable fields. Never bind raw request data to your modèle de données. Utilisez des DTO de réponse distincts qui excluent les champs internes. Validate every incoming property against a schema before processing.

API4 : 2023 Consommation illimitée des ressources

Les API qui acceptent des requêtes illimitées permettent aux attaquants d'augmenter votre facture d'infrastructure et d'épuiser la base de données. connections, or trigger denial-of-service. Cela s'applique aux limites de débit manquantes et aux requêtes illimitées. paramètres (par exemple, ?limit=1000000), les téléchargements de fichiers sans limite de taille et les points de terminaison qui déclencher des travaux d’arrière-plan coûteux.

Scénario d'attaque : An API endpoint generates PDF reports. Un attaquant envoie 500 demandes simultanées, chacune demandant un rapport de 200 pages. Your worker pool fills up, and legitimate users get 503 errors for the next 20 minutes.

Réparer: Ajoutez une limitation de débit par utilisateur et par IP. Limiter les limites de pagination côté serveur maximales. Définissez les limites de taille de téléchargement de fichiers. Utilisez le traitement basé sur la file d’attente pour les opérations coûteuses.

// Express rate limiter per user
import rateLimit from "express-rate-limit";

const apiLimiter = rateLimit({
  windowMs: 60 * 1000, // 1 minute
  max: 30,             // 30 requests per minute per IP
  standardHeaders: true,
  legacyHeaders: false,
  message: { error: "Rate limit exceeded. Try again in 60 seconds." },
});

app.use("/api/", apiLimiter);

API5 : 2023 Autorisation rompue au niveau de la fonction

Des failles d'autorisation au niveau des fonctions permettent aux utilisateurs réguliers d'appeler des points de terminaison d'administration. Le modèle typique : un appels du panneau d'administration DELETE /api/admin/users/:id. Le frontend cache le bouton utilisateurs non-administrateurs, mais le point de terminaison de l'API lui-même ne vérifie pas les rôles. Tout utilisateur authentifié qui découvre que l'URL peut supprimer des comptes.

Scénario d'attaque : Un développeur trouve /api/admin/export-all-users dans le bundle JavaScript. Ils l'appellent avec leur jeton d'utilisateur habituel et téléchargent l'utilisateur complet base de données.

Réparer: Vérifiez le rôle de l'utilisateur au niveau de la couche API pour chaque point de terminaison d'administrateur. Ne comptez pas sur le frontend pour masquer les fonctionnalités. L'administrateur du groupe achemine derrière un middleware qui vérifie role === "admin" avant de traiter la demande.

API6:2023 Accès illimité aux flux métiers sensibles

Certains flux API sont dangereux à grande échelle, même lorsque chaque requête individuelle est autorisée. Acheter articles en inventaire limité, création de comptes d'essai gratuits, soumission de codes de parrainage ; ces flux se briser lorsqu'il est automatisé. Un robot ouvre 10 000 comptes gratuits ou achète chaque billet lors d'une vente flash avant qu'un utilisateur réel charge la page.

Scénario d'attaque : Un revendeur de baskets écrit un bot qui appelle POST /api/checkout 500 fois dans la première seconde d'une baisse limitée. Chaque paire se vend aux robots. Les clients humains voient « épuisé » avant la fin du chargement de la page.

Réparer: Ajoutez des CAPTCHA ou des défis de preuve de travail aux flux à forte valeur ajoutée. Suivre l'appareil empreintes digitales pour détecter l’automatisation. Fixez des limites d’achat par utilisateur. Utiliser l'accès basé sur la file d'attente pour des ventes flash au lieu de points de terminaison du premier arrivé, premier servi.

API7 : 2023 Falsification de requêtes côté serveur (SSRF)

SSRF se produit lorsqu'une API accepte une URL du client et la récupère côté serveur sans valider la cible. Un attaquant fournit http://169.254.169.254/latest/meta-data/ et votre serveur renvoie les informations d'identification de l'instance AWS. Ou ils ciblent http://localhost:6379/ et interagissez avec votre instance Redis.

Scénario d'attaque : Une intégration de webhook permet aux utilisateurs de spécifier une URL de rappel. Un attaquant définit le rappel sur http://169.254.169.254/latest/meta-data/iam/security-credentials/ et reçoit les informations d'identification du rôle IAM de votre fournisseur de cloud dans la charge utile du webhook.

// Block internal network requests
const BLOCKED_RANGES = [
  /^10\\./, /^172\\.(1[6-9]|2\\d|3[01])\\./, /^192\\.168\\./,
  /^127\\./, /^0\\./, /^169\\.254\\./,
  /^localhost$/i, /^\\[::1\\]$/,
];

function isSafeUrl(urlString) {
  try {
    const url = new URL(urlString);
    const hostname = url.hostname;
    return !BLOCKED_RANGES.some((re) => re.test(hostname));
  } catch {
    return false;
  }
}

app.post("/api/fetch-url", async (req, res) => {
  const { url } = req.body;
  if (!isSafeUrl(url)) {
    return res.status(400).json({ error: "URL targets a blocked network range" });
  }
  // proceed with external fetch
});

Réparer: Validez et ajoutez les URL de destination à la liste autorisée. Bloquer les plages d'adresses IP privées et le cloud points de terminaison des métadonnées. Résolvez le DNS avant de faire la demande pour empêcher la nouvelle liaison DNS. Exécuter à l'extérieur requêtes provenant d’un segment de réseau isolé.

API8 : 2023 Mauvaise configuration de la sécurité

Une mauvaise configuration constitue la catégorie de risque la plus large. Il inclut les restrictions CORS manquantes et une erreur détaillée messages qui fuient des traces de pile, informations d'identification par défaut sur les panneaux d'administration, méthodes HTTP inutiles activées, TLS non appliqué et en-têtes de sécurité manquants. Toute mauvaise configuration crée un point d’entrée.

Scénario d'attaque : Une API renvoie des traces de pile complète dans les réponses d'erreur de production. Un l'attaquant déclenche volontairement des erreurs, lit les traces de la pile, identifie l'ORM et la version de la base de données, crée ensuite une charge utile d'injection basée sur les vulnérabilités connues de cette version.

Réparer: Supprimez les traces de pile des réponses de production. Définissez CORS pour autoriser uniquement vos domaines. Désactivez les méthodes HTTP que vous n'utilisez pas. Appliquez TLS partout. Exécutez des vérifications automatisées des en-têtes de sécurité. Désinfectez toutes les sorties HTML pour empêcher XSS.

La API de désinfection HTML publiée bandes balises et attributs malveillants du code HTML fourni par l'utilisateur : 

curl -s -X POST https://api.botoi.com/v1/html-sanitize \\
  -H "Content-Type: application/json" \\
  -d '{
    "html": "<p>Hello</p><script>document.cookie</script><img onerror=alert(1) src=x>"
  }'

Réponse:

{
  "success": true,
  "data": {
    "sanitized": "<p>Hello</p><img src=\\"x\\">"
  }
}

La <script> étiquette et le onerror attribut sont supprimés. Le HTML sécurisé est retourné. Appelez ce point de terminaison avant de stocker ou de restituer un code HTML fourni par l'utilisateur.

API9 :2023 Mauvaise gestion des stocks

Les anciennes versions d'API, les points de terminaison oubliés et les routes non documentées créent une surface d'attaque pour vous. ne surveillez pas. Les attaquants recherchent /v1/, /v2/, /api-dev/, et /internal/ chemins. Ils trouvent un point de terminaison obsolète qui ne dispose pas des contrôles de sécurité vous avez ajouté à la version actuelle.

Scénario d'attaque : Votre équipe a expédié /v2/users avec accès basé sur les rôles contrôle. Mais /v1/users fonctionne toujours en production sans aucune autorisation. Un attaquant découvre le chemin v1 via un fichier public Swagger et extrait l'intégralité de la table utilisateur.

Réparer: Maintenir un inventaire complet des API. Mettre hors service les anciennes versions ; ne les laisse pas en cours d'exécution "au cas où quelqu'un les utiliserait encore". Gérez chaque version derrière le même middleware d’authentification. Numériser votre propre infrastructure pour des sentiers exposés selon un horaire régulier.

API10 :2023 Consommation dangereuse des API

Votre API fait appel à des services tiers : processeurs de paiement, fournisseurs de messagerie, API de géocodage. Si vous faites confiance à leurs réponses sans validation, un tiers compromis ou malveillant peut injecter des données dans votre système. Cela inclut la confiance dans les URL de redirection, l'analyse du JSON non validé ou le stockage réponses de tiers sans désinfection.

Scénario d'attaque : Votre application récupère les données de l'entreprise à partir d'une API d'enrichissement tierce et stocke le company_name champ directement dans votre base de données. L'API d'enrichissement obtient compromis, et l'attaquant injecte <script> des balises dans les noms d’entreprises. Chaque l'utilisateur qui consulte un profil d'entreprise dans votre tableau de bord exécute le script.

Réparer: Validez et désinfectez toutes les réponses tierces avant de les stocker ou de les rendre eux. Utilisez la validation de schéma sur les données entrantes. Définissez des délais d'attente pour les appels externes. Appliquer la même entrée validation des données tierces que vous appliquez à la saisie de l'utilisateur.

Détectez l'exposition des données sensibles dans vos réponses API

Les risques API1 et API3 entraînent souvent la sortie de données sensibles de votre API. Le API de détection des informations personnelles botoi scanne le texte pour Numéros de sécurité sociale, numéros de carte de crédit, adresses e-mail, numéros de téléphone, adresses IP et dates de naissance. Exécutez-le sur les corps de réponse de votre API dans les tests d'intégration pour détecter les erreurs accidentelles. fuites de données avant le déploiement. 

curl -s -X POST https://api.botoi.com/v1/pii/detect \\
  -H "Content-Type: application/json" \\
  -d '{
    "text": "Customer SSN is 123-45-6789 and card is 4111111111111111"
  }'

Réponse:

{
  "success": true,
  "data": {
    "found": true,
    "count": 2,
    "findings": [
      {
        "type": "ssn",
        "value": "123-45-6789",
        "start": 17,
        "end": 28,
        "masked": "***-**-6789"
      },
      {
        "type": "credit_card",
        "value": "4111111111111111",
        "start": 42,
        "end": 58,
        "masked": "************1111"
      }
    ]
  }
}

Si votre réponse API déclenche des résultats, votre point de terminaison renvoie des données que le client ne devrait pas voir. Corrigez la requête ou le DTO pour exclure ces champs.

Chiffrer les données sensibles au repos

Lorsque votre API stocke une configuration, des jetons ou des informations d'identification sensibles, chiffrez-les avant d'écrire à la base de données. Le API de chiffrement botoi fournit le cryptage AES-256-CBC : 

curl -s -X POST https://api.botoi.com/v1/encrypt/encrypt \\
  -H "Content-Type: application/json" \\
  -d '{
    "text": "sensitive-api-token-abc123",
    "password": "your-secret-key"
  }'

Réponse:

{
  "success": true,
  "data": {
    "encrypted": "U2FsdGVkX1+abc...encrypted_output_here",
    "algorithm": "aes-256-cbc"
  }
}

Stockez la sortie chiffrée. Décrypter avec /v1/encrypt/decrypt seulement lorsque la valeur est nécessaire. Cela limite le rayon d'explosion si un attaquant obtient un accès en lecture à votre base de données via un Vulnérabilité d'injection BOLA ou SQL.

La liste de contrôle du Top 10 de la sécurité des API OWASP

Imprimez ce tableau ou ajoutez-le à votre modèle d'examen de sécurité. Vérifiez chaque élément avant toute version de l'API.

Risque Vérifier botoi endpoint
API1 ÉTAIT Chaque point de terminaison qui accepte un ID d'objet vérifie la propriété
API2 Authentification cassée Taux de connexion limité ; les jetons expirent ; MFA sur les opérations sensibles /v1/breach/check
Authentification de la propriété API3 Champs de demande ajoutés à la liste autorisée ; Les DTO de réponse excluent les internes /v1/pii/detect
Limite de ressources API4 Limites de débit, plafonds de pagination, limites de taille de fichier appliquées
Authentification de la fonction API5 Les points de terminaison d'administrateur vérifient le rôle au niveau de la couche API, pas du frontend
Flux commercial API6 CAPTCHA/proof-of-work sur les flux à forte valeur ; limites par utilisateur
API7 SSRF URL fournies par l'utilisateur validées ; plages privées bloquées
Mauvaise configuration de l'API8 Aucune trace de pile ; CORS restreint ; HTML nettoyé /v1/html-sanitize
Inventaire API9 Anciennes versions de l'API mises hors service ; tous les itinéraires documentés
Consommation dangereuse API10 Réponses tierces validées et nettoyées avant stockage /v1/html-sanitize

Où aller à partir d'ici

La documentation complète du Top 10 de la sécurité des API OWASP est disponible sur owasp.org/API-Security. Chaque page de risque comprend des méthodes de détection, des exemples de scénarios d'attaque et des références aux CWE.

Pour les contrôles automatisés, intégrez les points de terminaison botoi ci-dessus dans votre pipeline CI. Exécuter la détection des informations personnelles contre les appareils de réponse API. Désinfectez le HTML stocké lors de l’écriture. Vérifiez les e-mails des nouveaux utilisateurs contre toute violation bases de données lors de l’inscription. Ce sont de petits ajouts à votre suite de tests qui détectent les risques des scanners mademoiselle.

FAQ

Qu'est-ce que le Top 10 de la sécurité des API OWASP ?
Le Top 10 de la sécurité des API de l'OWASP est une liste des dix risques de sécurité des API les plus critiques, maintenue par l'Open Worldwide Application Security Project. L'édition 2023 couvre les autorisations rompues au niveau des objets, les authentifications rompues, les autorisations rompues au niveau des propriétés d'objets, la consommation illimitée de ressources, les autorisations rompues au niveau des fonctions, l'accès illimité aux flux commerciaux sensibles, la falsification de requêtes côté serveur, la mauvaise configuration de la sécurité, la gestion inappropriée des stocks et la consommation dangereuse d'API.
À quelle fréquence le Top 10 de la sécurité des API OWASP est-il mis à jour ?
L'OWASP a publié le premier Top 10 de la sécurité des API en 2019 et l'a mis à jour en 2023. Il n'y a pas de calendrier de mise à jour fixe. L'équipe du projet collecte des données sur les incidents de sécurité, les rapports de bug bounty et les contributions de la communauté, puis publie une nouvelle édition lorsque le paysage des menaces change suffisamment pour le justifier.
Qu’est-ce que BOLA et pourquoi est-ce le risque numéro un des API ?
BOLA (Broken Object-Level Authorization) se produit lorsqu'un point de terminaison d'API accepte un ID d'objet du client et renvoie des données sans vérifier que l'utilisateur demandeur possède cet objet. Un attaquant modifie l'ID dans la requête et accède aux données d'un autre utilisateur. Il occupe la première place car il est courant, facile à exploiter et expose souvent des enregistrements sensibles à grande échelle.
Les outils automatisés peuvent-ils détecter tous les 10 principaux risques de sécurité des API OWASP ?
Les scanners automatisés détectent les erreurs de configuration (API8), les limites de débit manquantes (API4) et certains modèles d'injection (via API8). Mais les failles d’autorisation (API1, API3, API5) nécessitent une compréhension de la logique métier qui manque aux scanners. Vous avez besoin d’une révision manuelle du code, de tests d’intrusion et de vérifications au niveau de l’architecture pour une couverture complète.
Comment puis-je prioriser les risques de l'API OWASP à corriger en premier ?
Commencez par API1 (BOLA) et API2 (Broken Authentication), car elles entraînent des violations directes de données. Adressez-vous ensuite à l'API4 (Unrestricted Resource Consumption) pour éviter tout déni de service. Après cela, éliminez les risques restants en fonction des points de terminaison qui gèrent les données les plus sensibles dans votre application.

Commencez a construire avec botoi

150+ endpoints API pour la recherche, le traitement de texte, la generation d'images et les utilitaires pour developpeurs. Offre gratuite, sans carte bancaire.

Voir la documentation API Voir tous les outils