Comment sécuriser une API web ?

Une API est une porte d'entrée technique par laquelle un logiciel dialogue avec un autre. Contrairement à un site, elle n'a pas d'interface visible : on croit facilement qu'elle passe inaperçue. C'est une erreur de raisonnement. Une API mal protégée s'explore méthodiquement, et elle donne souvent un accès plus direct aux données que le site lui-même.

Authentifier chaque appel

Une API ne connaît pas de session comme un navigateur : chaque appel doit porter sa propre preuve d'identité. Trois formes sont courantes.

Dans tous les cas, la clé ne circule jamais dans l'adresse de la requête, où elle finirait enregistrée dans les journaux et les historiques. Elle voyage dans un en-tête, sur une connexion chiffrée.

Vérifier les droits sur chaque objet

C'est la faille la plus fréquente des interfaces techniques. L'appel est authentifié, donc accepté, mais personne ne vérifie que l'objet demandé appartient bien à ce client. Un identifiant modifié suffit alors à consulter le document d'un autre. La règle est de contrôler, pour chaque appel, non seulement qui parle mais ce à quoi cette identité donne droit. Le raisonnement rejoint celui de notre article sur la gestion des droits d'accès.

Limiter, valider, mesurer

• Limitation du débit : un plafond d'appels par client et par minute empêche l'extraction massive de données et les essais répétés.
• Volume des réponses : imposer une pagination plutôt que renvoyer des listes entières sur simple demande.
• Validation des données reçues : type, format et longueur attendus, avec rejet explicite du reste.
• Champs renvoyés : ne retourner que ce qui est nécessaire, en évitant de laisser passer des champs internes par facilité.
• Journalisation : conserver l'identité, l'horodatage, l'origine et l'opération, afin de repérer un usage anormal.

Des messages d'erreur sobres

Une erreur détaillée aide le développeur, mais renseigne aussi celui qui cherche une faiblesse : version du logiciel, structure de la base, existence d'un compte. Renvoyez un message générique au client et conservez le détail dans vos journaux internes. Évitez notamment de répondre différemment selon qu'un identifiant existe ou non.

Ne pas oublier la documentation et les environnements

1. La documentation technique n'a pas à être publique si l'API ne l'est pas : restreignez son accès comme celui de l'interface elle-même.
2. Les outils d'essai interactifs, très pratiques en développement, n'ont pas leur place sur l'environnement réel.
3. Les anciennes versions de l'API restent souvent en service après une évolution, sans bénéficier des corrections apportées à la nouvelle : fixez une date de retrait.
4. Les clés d'accès se révoquent au départ d'un prestataire ou à la fin d'un partenariat, au même titre que les comptes nominatifs.

Ces règles s'appliquent aussi bien à une interface que vous publiez qu'à celles que vous consommez, sujet abordé dans notre article sur la façon de relier ses logiciels entre eux. NexSecure conçoit et sécurise ces interfaces dans ses projets de développement web sur mesure.