Pour sécuriser une API qui traite des données réglementées, modélisez qui pourrait en abuser, vérifiez l'autorisation sur chaque objet et chaque champ, collectez et renvoyez le moins de données possible, et gardez les secrets et les journaux d'audit sous contrôle strict. En pratique, les faiblesses qui comptent le plus sont les failles d'autorisation et les réponses qui exposent trop de données, pas un chiffrement défaillant.
Partez d'un modèle de menaces sur les données, pas sur le framework
Avant de choisir des outils, écrivez ce que l'API expose et qui pourrait en abuser. Pour une banque, ce sont des données de comptes et de transactions ; pour une entreprise de l'énergie ou des services publics, il peut s'agir de données de comptage, de contrats clients et de mesures opérationnelles issues du réseau.
Un modèle de menaces utile est court. Il liste les données sensibles, chaque appelant qui peut y accéder, les actions que chaque appelant doit pouvoir effectuer, et ce qui se passe si l'un d'eux est compromis. Ce document guide ensuite chacun des contrôles ci-dessous, et indique aux relecteurs ce qu'il faut tester.
- Quelles données sont personnelles, confidentielles ou réglementées, et où elles sont stockées.
- Chaque consommateur de l'API : services internes, partenaires, applications mobiles et administrateurs.
- Ce que chaque consommateur est autorisé à lire, modifier ou déclencher.
- L'impact d'un jeton divulgué, d'un initié malveillant ou d'un système partenaire compromis.
Authentifiez chaque appelant, puis autorisez chaque objet
Utilisez un protocole standard comme OAuth 2.0 avec OpenID Connect pour les utilisateurs, et des jetons de courte durée ou le TLS mutuel pour les appels de service à service. Évitez les clés d'API partagées de longue durée, car personne ne peut savoir quel système les a utilisées ni les révoquer sans casser les autres.
L'authentification prouve seulement qui appelle. La première entrée de l'OWASP API Security Top 10 est la faille d'autorisation au niveau de l'objet (broken object level authorization) : un utilisateur valide modifie un identifiant dans la requête et lit l'enregistrement de quelqu'un d'autre. Vérifiez côté serveur la propriété ou l'appartenance au bon locataire pour chaque objet, chaque fonction et chaque champ sensible, et ne faites jamais confiance à un identifiant ou à un rôle envoyé par le client.
Donnez à chaque client et à chaque service le moindre privilège nécessaire
Le moindre privilège limite les dégâts quand quelque chose tourne mal. Émettez des identifiants distincts par consommateur, limitez les jetons à des opérations précises, et placez les endpoints d'administration sur un chemin séparé avec des contrôles renforcés.
Appliquez la même règle sous l'API. Le compte de service qui lit les données de comptage ne doit pas pouvoir les supprimer, et une tâche de reporting doit se connecter avec un rôle de base de données en lecture seule. Revoyez les permissions à intervalles réguliers, car un accès accordé pour une tâche ponctuelle a tendance à rester pour toujours.
Collectez moins, renvoyez moins et conservez moins longtemps
La minimisation des données est à la fois un principe du RGPD et un contrôle de sécurité efficace : une donnée jamais stockée ne peut pas fuiter. Demandez-vous pour chaque champ si le service en a vraiment besoin, et supprimez ou pseudonymisez ce qui n'est pas nécessaire.
Appliquez la même discipline aux réponses. Définissez des schémas de réponse explicites au lieu de sérialiser des objets de base de données entiers, masquez les identifiants comme les numéros de compte quand la valeur complète n'est pas nécessaire, et fixez des durées de conservation pour que les anciens enregistrements soient supprimés. Documentez la base légale de chaque finalité de traitement et signez des accords de sous-traitance avec tout prestataire qui manipule les données. Il s'agit de pratiques d'ingénierie, pas d'un conseil juridique : associez votre délégué à la protection des données ou votre conseil à l'évaluation juridique.
Validez chaque entrée et limitez ce qu'un appelant peut consommer
Considérez chaque requête comme hostile tant qu'elle n'est pas validée. Imposez un schéma pour chaque endpoint, rejetez les champs inconnus et utilisez des requêtes paramétrées pour qu'une entrée ne devienne jamais partie d'une commande de base de données.
Plusieurs risques OWASP pour les API viennent de limites absentes plutôt que de code défaillant. Limitez le débit par client, plafonnez la taille des pages et des charges utiles, et protégez les parcours métier sensibles, comme les paiements ou les modifications de contrat, contre les abus automatisés. Si l'API récupère des URL distantes pour le compte des appelants, restreignez les destinations pour empêcher la falsification de requêtes côté serveur (SSRF).
Tenez les secrets hors du code, des images et des journaux
Les mots de passe de base de données, les clés de signature et les identifiants partenaires ont leur place dans un gestionnaire de secrets dédié, injectés à l'exécution et renouvelés à intervalles réguliers. Analysez les dépôts et les images de conteneurs à la recherche de secrets dans le pipeline de build, et considérez comme compromis tout secret qui atteint le contrôle de version.
Séparez les secrets par environnement pour qu'un identifiant de test divulgué n'ouvre jamais la production. Restreignez qui peut lire les secrets en production, et journalisez chaque accès.
Journalisez pour l'audit et concevez pour avoir moins d'incidents
Les environnements réglementés doivent pouvoir répondre après coup à une question simple : qui a accédé à quelles données, quand et par quel client. Enregistrez-le pour chaque lecture et écriture sensible, stockez les journaux là où les opérateurs de l'application ne peuvent pas les modifier, et tenez les données personnelles hors des messages de journal.
Associez la journalisation à des alertes sur les comportements inhabituels, comme un client qui lit bien plus d'enregistrements que d'habitude, et à un plan de réponse aux incidents testé. Via Sopra Steria, nos ingénieurs ont construit des API sécurisées pour des données sensibles de services publics sous contraintes réglementaires et mené un outil de supervision opérationnelle où l'application des standards de sécurité est allée de pair avec moins d'incidents de production. SDK Enterprises applique aujourd'hui les mêmes pratiques aux projets de ses clients.
À retenir
- Un modèle de menaces court et écrit sur les données doit guider chaque contrôle de sécurité de l'API.
- Vérifiez l'autorisation côté serveur pour chaque objet, chaque fonction et chaque champ sensible, pas seulement à la connexion.
- Le moindre privilège s'applique aussi bien aux jetons qu'aux comptes de service et aux rôles de base de données.
- La minimisation des données réduit à la fois l'exposition au RGPD et l'impact de toute violation.
- Les journaux d'audit doivent montrer qui a accédé à quoi et quand, sans divulguer eux-mêmes de données personnelles.
FAQ
HTTPS suffit-il à sécuriser une API ?
Non. TLS protège les données en transit, mais de nombreuses violations d'API impliquent des appelants authentifiés qui accèdent à des données qu'ils ne devraient pas voir. Les contrôles d'autorisation, la validation des entrées, la limitation de débit et la journalisation d'audit restent indispensables.
Qu'est-ce qu'une faille d'autorisation au niveau de l'objet ?
C'est une faille où l'API vérifie qu'un appelant est connecté, mais pas que l'enregistrement demandé lui appartient. Modifier un identifiant dans l'URL ou le corps de la requête expose alors les données d'autres utilisateurs. La correction consiste à vérifier côté serveur, pour chaque objet, la propriété ou l'appartenance au bon locataire.
Le RGPD impose-t-il des contrôles de sécurité précis pour les API ?
Le RGPD exige des mesures techniques et organisationnelles appropriées au risque, sans imposer d'outils précis. Des contrôles comme la restriction des accès, la minimisation, la pseudonymisation et la journalisation sont des moyens courants de satisfaire cette exigence, et vos conseillers juridiques doivent confirmer ce qui s'applique à votre cas.