Comment assurer la sécurité de l’API REST

Les interfaces de programmation d’applications Web (API) constituent le back-end des applications Web et mobiles modernes. Les appels d’API Web représentent plus de 80 % du trafic Web et les cybercriminels ciblent de plus en plus les API, il est donc crucial de garantir la sécurité des API Web. Les API REST sont le type d’API Web le plus courant pour les services Web. Voyons ce que vous pouvez faire pour assurer la sécurité de l’API REST.

Qu’est-ce qu’une API REST ?

REST (abréviation de REpresentational State Transfer) est un style d’architecture logicielle pour le développement Web, généralement utilisé avec la communication HTTP. Les API RESTful (ou simplement API REST) sont des interfaces de programmation d’applications qui suivent les principes REST, permettant aux clients Web et aux serveurs d’interagir avec une grande variété de ressources Web. Les API REST utilisent des verbes (méthodes) HTTP standard et des codes d’état pour fournir un certain niveau de normalisation. Ils sont accessibles via des URL HTTP et sont largement utilisés pour les services Web.

Remarque: Les API REST sont sans état comme le protocole HTTP lui-même, ce qui signifie qu’elles ne stockent aucune information sur les connexions ou les sessions en cours. Les services Web RESTful fournissent des moyens d’accéder aux ressources et de les manipuler, tandis que la gestion des sessions doit être gérée par l’application.

Deux niveaux de sécurité de l’API REST

Avant d’entrer dans les détails techniques, il y a une chose importante à noter. Une API web expose une interface à une application web, vous devez donc penser à la sécurité à deux niveaux : l’accès à l’API, puis l’accès à l’application.

Au niveau de l’API, vous avez besoin de l’authentification, de l’autorisation, des privilèges d’accès appropriés, etc., pour vous assurer que seuls les clients autorisés peuvent utiliser l’interface et exécuter uniquement les opérations autorisées. Au niveau de l’application, vous devez vous assurer que les points de terminaison de votre application (les URL utilisées pour accéder à l’interface) ne sont pas vulnérables aux attaques qui traversent l’interface ou la contournent.

Voyons comment vous pouvez assurer la sécurité de l’API REST à ces deux niveaux. Pour une discussion détaillée des meilleures pratiques de sécurité des API, consultez la feuille de triche de sécurité OWASP REST.

Assurer un accès sécurisé aux API

La plupart des API Web sont exposées à Internet, elles ont donc besoin de mécanismes de sécurité appropriés pour prévenir les abus, protéger les données sensibles et garantir que seuls les utilisateurs authentifiés et autorisés peuvent y accéder.

Sécurité de la connexion

La sécurité commence par la connexion HTTP elle-même. Les API REST sécurisées ne doivent fournir que des points de terminaison HTTPS pour garantir que toutes les communications de l’API sont cryptées à l’aide de SSL/TLS. Cela permet aux clients d’authentifier le service et protège les informations d’identification de l’API et les données transmises.

Contrôle d’accès aux API

De nombreuses API Web ne sont disponibles que pour les utilisateurs authentifiés, par exemple parce qu’elles sont privées ou nécessitent une inscription ou un paiement. Les API REST étant sans état, le contrôle d’accès est géré par des points de terminaison locaux. Les méthodes d’authentification API REST les plus courantes sont:

• Authentification de base HTTP: Les informations d’identification sont envoyées directement dans les en-têtes HTTP dans le codage Base64 sans cryptage. C’est la méthode d’authentification la plus simple et la plus facile à mettre en œuvre. Il est également le moins sécurisé, car les données confidentielles sont transmises sous forme de texte brut, elles ne doivent donc être utilisées qu’en combinaison avec HTTPS.
• Jetons Web JSON (JWT) : Les informations d’identification et autres paramètres d’accès sont envoyés sous forme de structures de données JSON. Ces jetons d’accès peuvent être signés cryptographiquement et constituent le moyen privilégié de contrôler l’accès aux API REST. Consultez la feuille de triche OWASP JWT pour un aperçu rapide des jetons Web JSON et la RFC 7519 pour la spécification complète.
• OAuth: Les mécanismes OAuth 2.0 standard peuvent être utilisés pour l’authentification et l’autorisation. OpenID Connect permet une authentification sécurisée sur OAuth 2.0. Par exemple, les API de Google utilisent OAuth 2.0 pour l’authentification et l’autorisation.

Autorisation de l’utilisateur avec des clés API

Les clés API permettent de contrôler l’accès aux services REST publics. Les opérateurs de services Web publics peuvent utiliser des clés d’API pour appliquer la limitation de débit pour les appels d’API et atténuer les attaques par déni de service. Pour les services monétisés, les organisations peuvent utiliser des clés API pour fournir un accès en fonction du plan d’accès acheté.

Restrictions des clients API

Pour minimiser les risques de sécurité, les opérateurs de service REST doivent limiter la connexion des clients aux capacités minimales requises pour le service. Cela commence par restreindre les méthodes HTTP prises en charge pour s’assurer que les clients mal configurés ou malveillants ne peuvent effectuer aucune action au-delà des spécifications de l’API et du niveau d’accès autorisé. Par exemple, si l’API n’autorise que les requêtes GET, les types de requêtes POST et autres doivent être rejetés, la méthode code de réponse 405 n’étant pas autorisée.

Protection des applications qui exposent les API

Une fois que le client dispose d’un accès légitime, vous devez protéger l’application Web sous-jacente contre les entrées mal formées et malveillantes. Les appels et réponses d’API REST peuvent également inclure des données confidentielles qui doivent être contrôlées.

Données sensibles dans la communication API

Les appels API incluent souvent des informations d’identification, des clés API, des jetons de session et d’autres informations sensibles. S’ils sont inclus directement dans les URL, ces détails pourraient être stockés dans les journaux du serveur Web et divulgués si les journaux sont accessibles par des cybercriminels. Pour éviter les fuites d’informations confidentielles, les services Web RESTful doivent toujours les envoyer dans les en-têtes de requête HTTP ou le corps de la requête (pour les requêtes POST et PUT).

Validation du type de contenu

Poursuivant le thème des restrictions des clients API, les services REST doivent définir avec précision les types de contenu autorisés et rejeter les demandes qui n’ont pas les déclarations correctes dans leurs en-têtes HTTP. Cela signifie spécifier soigneusement les types autorisés dans l’en-tête Content-Type et Accept, ainsi que le jeu de caractères (si possible). Si le service inclut JavaScript (ou un autre code de script), il doit s’assurer que le type de contenu dans l’en-tête est le même que dans le corps de la requête, par exemple application/javascript. Cela aide à prévenir les attaques par injection d’en-tête.

En-têtes de sécurité de réponse

Des en-têtes de sécurité HTTP supplémentaires peuvent être définis pour restreindre davantage le type et la portée des requêtes. Ceux-ci incluent X-Content-Type-Options: nosniff pour empêcher les attaques XSS basées sur le reniflage MIME et X-Frame-Options: deny pour empêcher les tentatives de clickjacking dans les navigateurs plus anciens.

Si le service ne prend pas en charge les appels inter-domaines, il doit désactiver CORS (partage de ressources inter-origines) dans ses en-têtes de réponse. Si de tels appels sont attendus, les en-têtes CORS doivent spécifier précisément les origines autorisées.

Validation des entrées

Les API sont conçues pour un accès automatisé sans interaction de l’utilisateur, il est donc particulièrement important de s’assurer que toutes les entrées sont valides et attendues. Toutes les demandes qui ne sont pas conformes à la spécification de l’API doivent être rejetées. Les lignes directrices typiques sur les meilleures pratiques pour la validation des intrants s’appliquent:

• Traitez tous les paramètres, objets et autres données d’entrée comme non fiables.
• Utilisez la fonctionnalité de validation intégrée lorsqu’elle est disponible.
• Vérifiez la taille de la requête, la longueur et le type du contenu.
• Utilisez un typage fort pour les paramètres de l’API (si pris en charge).
• Pour empêcher l’injection SQL, évitez de créer des requêtes manuellement – utilisez plutôt des requêtes paramétrées.
• Liste blanche des valeurs des paramètres et des entrées de chaîne dans la mesure du possible.
• Enregistre tous les échecs de validation d’entrée pour détecter les tentatives de remplissage d’informations d’identification.

Pourquoi la sécurité des API REST est importante

Les API Web sont l’épine dorsale du développement Web et mobile moderne. Ils permettent aux applications et aux services de communiquer et d’échanger des données sur des plates-formes matérielles et logicielles. Alors que d’autres formats d’API sont également toujours utilisés (par exemple SOAP), les API REST sont désormais le type dominant, représentant plus de 80% de toutes les API Web publiques. Ils fournissent le back-end pour la majorité des applications mobiles et des appareils IoT et permettent une intégration facile entre les systèmes et les applications.

Parce qu’elles utilisent les mêmes technologies que les applications Web, les API REST peuvent être vulnérables aux mêmes attaques. Dans le même temps, les API ne sont pas conçues pour un accès manuel, elles peuvent donc être difficiles à tester, en particulier si certains points de terminaison et fonctionnalités ne sont pas documentés. Les tests de sécurité des API nécessitent des outils automatisés précis pour assurer une couverture complète. Netsparker fournit une prise en charge complète de l’analyse des vulnérabilités de l’API REST avec diverses méthodes d’authentification et une réécriture automatique des URL.

Consultez la documentation du site de test de l’API REST de Netsparker pour obtenir des détails techniques complets et lisez notre article complet sur l’analyse des API REST pour détecter les vulnérabilités avec Netsparker.

À propos de l’auteur

Zbigniew Banach

Rédacteur de contenu technique chez Netsparker. S’appuyant sur son expérience de journaliste informatique et de traducteur technique, il fait de son mieux pour apporter la sécurité web à un public plus large sur le blog et le site Web de Netsparker.