Tests de sécurité d'API REST et GraphQL
Gjethe teste les API directement, comme le font les attaquants : autorisation sur chaque objet, authentification, quantité de données renvoyées par les réponses, mass assignment, limites de débit et flux métier. Les tests suivent l'OWASP API Security Top 10, et chaque constat est accompagné de preuves, d'une correction et d'un nouveau test.
- Première consultation gratuite
- Devis écrit pour votre projet
- Paiements échelonnés par étapes, avec souplesse
En un coup d'œil
- Types d'API
- REST, GraphQL, WebSocket
- Standard
- OWASP API Security Top 10
- Axe de travail
- Autorisation, exposition des données, limites de débit
- Livrable
- Rapport, corrections et nouveau test
Definition
Qu'est-ce que les tests de sécurité des API?
Le test de sécurité d'API est l'évaluation d'une interface de programmation à la recherche de faiblesses permettant à des appelants d'atteindre des données ou des fonctions qui leur sont interdites, en envoyant des requêtes forgées directement à ses endpoints.
Applications mobiles, applications web monopage, partenaires et intégrations communiquent tous avec votre API. L'interface peut masquer des champs et des boutons, mais l'API répond à quiconque envoie la bonne requête. C'est pourquoi les API exposent souvent plus que prévu : des enregistrements complets alors que l'application n'affiche qu'un nom, des actions accessibles en changeant une adresse, ou aucune limite à la vitesse à laquelle quelqu'un peut tenter des connexions ou extraire des données. Le test d'API met l'interface de côté et vérifie ce que le serveur lui-même autorise.
À qui s'adresse-t-elle ?
Équipes avec une API publique ou partenaire
Tout ce qui est exposé à d'autres développeurs l'est à quiconque lit votre documentation.
Backends d'applications mobiles
L'application n'est qu'un client parmi d'autres ; l'API doit se défendre contre n'importe quelle requête.
Architectures de microservices
Les services internes se font souvent trop confiance ; nous vérifions ces frontières.
Produits avec paiements ou crédits
L'argent, les soldes et les quotas sont des cibles de choix pour les abus de logique et de limites de débit.
Ce qui est inclus, et ce que vous conservez
Ce qui est inclus
- Revue de la documentation et du schéma de l'API
- Découverte des endpoints et des opérations
- Tests d'autorisation au niveau des objets
- Tests d'autorisation au niveau des fonctions
- Revue de l'authentification et de la gestion des jetons
- Contrôles de l'exposition excessive de données
- Tests de mass assignment et de traitement des entrées
- Tests de limitation de débit et d'abus de ressources
- Tests des flux métier et des séquences
- Contrôles spécifiques à GraphQL si pertinent
- Revue du transport et de la configuration
- Rapport avec preuves, corrections et nouveau test
Ce que vous recevez
Remis en fin de mission. À vous pour toujours.
- Rapport de test de sécurité d'API
- Constats associés à l'OWASP API Top 10
- Description claire de chaque problème confirmé
- Recommandations de correction pour chaque constat
- Rapport de nouveau test
Domaines de l'OWASP API Security Top 10 que nous couvrons
| Domaine | Exemple de ce que nous vérifions |
|---|---|
| Autorisation défaillante au niveau des objets | Lire l'enregistrement d'un autre utilisateur en changeant un identifiant |
| Authentification défaillante | Jetons faibles, expiration absente, identifiants devinables |
| Autorisation défaillante au niveau des propriétés d'objet | Définir des champs que l'appelant ne devrait pas contrôler |
| Consommation de ressources sans restriction | Aucune limite de débit sur des opérations coûteuses ou sensibles |
| Autorisation défaillante au niveau des fonctions | Appeler des opérations d'administration en tant qu'utilisateur normal |
| Accès sans restriction aux flux métier | Automatiser un flux prévu pour n'être exécuté qu'une fois |
| Falsification de requêtes côté serveur | L'API qui récupère des adresses contrôlées par l'appelant |
| Mauvaise configuration de sécurité | Erreurs trop détaillées, endpoints de débogage, paramètres trop permissifs |
| Gestion d'inventaire inadaptée | Anciennes versions oubliées qui acceptent encore des requêtes |
| Utilisation non sécurisée de services tiers | Faire confiance aux données d'une API externe sans contrôle |
Pourquoi les API divulguent plus que ce que l'application affiche
Une page web montre à un client son propre nom et rien de plus. La requête qui se cache derrière peut pourtant renvoyer l'intégralité de la fiche utilisateur, y compris des champs que la page ignore discrètement. Les attaquants lisent directement les réponses : tout ce que le serveur envoie est de fait public pour quiconque peut appeler l'endpoint.
Nous testons du côté de l'appelant : chaque endpoint est sollicité sous différents utilisateurs et rôles, avec des identifiants et des champs modifiés, pour voir si le serveur vérifie qui demande et ne renvoie que ce que la personne a le droit de voir. GraphQL reçoit une attention supplémentaire, car une seule requête flexible peut atteindre bien plus qu'une route REST fixe si les règles ne sont pas appliquées champ par champ.
Pourquoi les API demandent leurs propres tests
Il est tentant de croire que tester le site web teste aussi l'API qui le soutient. Ce n'est pas le cas. Le site utilise l'API comme l'ont voulu ses concepteurs, à travers les boutons et les écrans qu'ils ont construits. Un attaquant ignore tout cela et appelle directement les endpoints, dans n'importe quel ordre, avec n'importe quelles valeurs, depuis n'importe quel compte qu'il peut obtenir. Des catégories entières de problèmes n'apparaissent que sous cet angle : un endpoint qui fait confiance à un identifiant d'utilisateur présent dans la requête, un champ censé être en lecture seule mais modifiable, une opération sans limite de fréquence d'exécution.
Tester l'API séparément protège aussi chaque client qui en dépend. Une même API dessert généralement une application web, une application mobile et souvent des intégrations partenaires en même temps. Une faiblesse à ce niveau est exposée à tous ; la corriger au niveau de l'API protège donc l'ensemble du produit plutôt qu'un seul écran.
Comment fonctionnent les tests de sécurité des API, étape par étape
Chaque étape produit un résultat clair que vous pouvez relire. Le calendrier est convenu dans votre devis.
- 1
Périmètre
API, environnements, rôles et identifiants de test convenus par écrit.
- 2
Carte
Endpoints, opérations et rôles répertoriés à partir de la documentation et du trafic.
- 3
Tester
Autorisation, authentification, exposition des données et abus testés à la main.
- 4
Vérifier
Chaque constat confirmé avec soin, avec des preuves sans danger.
- 5
Rapport
Constats associés à l'API Top 10, avec corrections.
- 6
Contre-test
Corrections vérifiées et rapport mis à jour.
Les outils, et ce qui détermine votre devis
Le prix dépend de votre projet et est convenu dans votre devis. Voici ce qui le fait varier.
| Facteur | Pourquoi c'est important |
|---|---|
| Nombre d'endpoints | Plus d'opérations impliquent plus de tests d'autorisation et de traitement des entrées. |
| Nombre de rôles | Chaque rôle doit être testé sur chaque opération sensible. |
| REST ou GraphQL | GraphQL demande des contrôles champ par champ et des tests du coût des requêtes. |
| Qualité de la documentation | De bons schémas et de bonnes collections rendent les tests plus rapides et plus complets. |
| Flux métier | Les paiements, les quotas et les flux à plusieurs étapes demandent des tests de logique soignés. |
| Domaine | Tools |
|---|---|
| Test | Burp Suite, Postman, scripts sur mesure |
| GraphQL | outils d'introspection de schéma, outillage de requêtes |
| Support | outillage OpenAPI, capture du trafic |
| Conseils | OWASP API Security Top 10, OWASP ASVS, CVSS |
Erreurs courantes à éviter
Ce qui tourne le plus souvent mal, et comment un bon projet l'évite.
Ne vérifier les permissions que dans l'application
Si l'API ne revérifie pas à chaque requête, les restrictions de l'application ne valent rien.
Renvoyer des objets entiers
Envoyer des enregistrements complets et laisser le client choisir les champs expose tout à quiconque lit les réponses.
Aucune limite de débit
Sans limites, les connexions peuvent être devinées et les données extraites en masse.
Anciennes versions oubliées
Les anciennes versions d'API laissées en service n'ont souvent pas les correctifs ajoutés à la version actuelle.
Questions fréquentes
Avez-vous besoin de notre documentation d'API ?
Cela aide beaucoup. Un schéma, une collection Postman ou une définition OpenAPI ou GraphQL accélère les tests et améliore la couverture. Lorsqu'elle manque, nous cartographions les endpoints à partir du trafic de vos clients.
Pouvez-vous tester une API GraphQL ?
Oui. GraphQL demande des contrôles d'autorisation champ par champ et des tests du coût des requêtes, que nous couvrons avec les domaines habituels des API.
Les tests affecteront-ils nos données de production ?
Nous privilégions un environnement de préproduction avec des données de test. Si nous devons tester la production, nous utilisons des comptes de test, convenons de fenêtres et évitons les actions qui modifient de vrais enregistrements.
Testez-vous les fournisseurs d'authentification comme OAuth ?
Nous testons la façon dont votre API utilise les jetons et les sessions : expiration, périmètre, validation et gestion. Le fournisseur d'identité lui-même est généralement hors périmètre, sauf si vous l'exploitez.
En quoi est-ce différent d'un test d'application web ?
Un test d'application web passe par l'interface ; un test d'API s'attaque directement aux endpoints, là où se connectent réellement les applications mobiles, les intégrations et les applications monopage.
Incluez-vous un nouveau test ?
Oui. Après correction des constats, nous les testons de nouveau et mettons le rapport à jour.
Pouvez-vous aider à corriger les constats ?
Oui. Nos développeurs peuvent mettre en œuvre les corrections ou relire les changements de votre équipe avant le nouveau test.
Signez-vous un accord de confidentialité ?
Oui. Les constats sont confidentiels et partagés uniquement avec les contacts que vous désignez, et les données de test sont supprimées ensuite.
Testez-vous aussi les anciennes versions d'API ?
Oui, lorsqu'elles sont dans le périmètre. Les anciennes versions laissées en service sont un point faible courant, car les correctifs ajoutés à la version actuelle ne leur sont souvent jamais appliqués.
De quoi avez-vous besoin de notre part pour commencer ?
L'adresse de base de chaque API, des identifiants pour chaque rôle, les schémas ou la documentation dont vous disposez et un contact désigné au cas où quelque chose nécessiterait une attention pendant les tests.
Services associés
Tests d'intrusion
Tests de sécurité autorisés et cadrés, avec un rapport de correction.
Tests d'intrusion d'applications web
Tests manuels OWASP des connexions, du contrôle d'accès et de la logique métier.
Revue de code sécurisée
Passez votre base de code en revue pour y déceler des failles de sécurité avant la mise en production.
Développement d'API sur mesure
API REST, GraphQL et WebSocket documentées.
Intégration d'API
Connectez les outils que vous utilisez déjà pour que les données circulent d'elles-mêmes.
Évaluation des vulnérabilités
Identifier, hiérarchiser et planifier la correction des failles connues.
Tests de sécurité des API par secteur
Découvrez ce que votre API autorise réellement.
Dites-nous ce dont vous avez besoin. Vous recevez une évaluation honnête, un plan clair et un devis écrit. La première consultation est toujours gratuite.
- Et ensuite ?
- 1Vous nous dites ce dont vous avez besoin
- 2Nous nous efforçons de répondre sous 24 heures avec des questions
- 3Vous recevez un devis écrit pour votre projet