Résumer:
- Vous avez une clé d'API qui vous est délivrée par un fournisseur afin que vous puissiez utiliser son API, et vous avez l'obligation d'empêcher cette clé d'être connue de quelqu'un d'autre
- Vous passez des appels à l'API de ce fournisseur (qui nécessite la clé API) dans votre code d'application
- Vous déployez l'application sur des systèmes où les clients ont accès aux fichiers binaires et pourraient ainsi potentiellement décompiler / désobfusquer le code ou intercepter le trafic
La meilleure façon d'empêcher la compromission de cette clé est d'en garder le contrôle. Cela signifie qu'il ne doit jamais être déployé sur un serveur où n'importe qui d'autre que vous pourrait lire le binaire, et ne jamais passer par un lien de communication que vous ne contrôlez pas.
En fin de compte, si les fichiers binaires sont hors de votre contrôle, tout ce qu'ils contiennent est hors de votre contrôle. De même, si quelqu'un peut intercepter le trafic, il peut capturer la clé API ( potentiellement même si vous utilisez SSL ).
Je peux voir deux façons principales d'accomplir cela, qui n'incluent pas toutes les deux votre clé API privée dans votre application déployée:
Obtenez une clé API unique pour chaque déploiement
Cela nécessiterait une relation supplémentaire avec le fournisseur, où vous pouvez obtenir des clés ou demander à vos clients d'obtenir des clés.
C'est en fait assez courant avec, par exemple, les produits qui utilisent l'API Google Maps. Le créateur du logiciel a sa propre clé qu'il utilise lors du développement / de l'exécution de sa copie, mais il ne l'inclut pas dans le logiciel et, à la place, vous oblige, en tant qu'utilisateur installant ledit logiciel, à aller sur Google et à obtenir votre propre API clé. Le logiciel a simplement une option de configuration pour définir la clé API Google Maps à utiliser.
En fait, de nombreux fournisseurs qui émettent des clés d'API exigent contractuellement que vous fassiez les choses de cette façon, de sorte que vous pouvez même être sur le mauvais chemin de toute façon, et cela peut être la seule solution que vous êtes autorisé à utiliser conformément aux conditions d'utilisation du fournisseur et / ou tout contrat légal que vous pourriez avoir avec eux.
Utilisez un proxy
Configurez une API proxy, où votre application appelle votre API (sur vos serveurs) et, à son tour, votre API appelle l'API du fournisseur à l'aide de la clé.
Vous pouvez avoir besoin d'une protection supplémentaire sur votre API, par exemple, quelque chose pour vous assurer que seule votre application l'utilise. Cela pourrait être fait par:
- rendant la fonctionnalité si spécifique, mais votre application peut l'utiliser
- Listes blanches IP
- Certains mécanismes de licence / autorisation existants que vous avez déjà pour vos serveurs
- Votre propre système de clés API où vous pouvez émettre des clés à vos clients
La chose à garder à l'esprit ici est que vous ne pouvez pas être autorisé à le faire. Votre fournisseur peut avoir des conditions d'utilisation ou des contrats légaux qui vous empêchent de créer un "service d'agrégation" ou un proxy, vous devez donc vérifier cela.
Gérer les mauvais comportements
Même si votre clé n'est pas compromise, si l'un de vos clients fait quelque chose qui oblige le fournisseur à bloquer votre clé, soudain TOUS vos clients sont désactivés, et votre seul correctif est de mettre à jour tout le monde.
De même, si vous souhaitez bloquer l'un de vos clients (par exemple, ils ont cessé de payer, ont piraté le logiciel, etc.), vous ne pouvez pas le faire sans publier une mise à jour pour tout le monde, puis désactiver la clé.
La logistique de tout cela au-delà d'une poignée de clients deviendra rapidement intenable.
Que vous agissiez en tant que proxy ou ayez une clé unique pour chaque installation, vous pouvez gérer n'importe laquelle de ces situations relativement facilement (et avec peu ou pas d'impact pour quiconque).
Essayer de protéger la clé lorsqu'elle est intégrée à votre logiciel est finalement un effort futile. Peu importe ce que vous faites, tout attaquant qui a accès aux binaires, à la source et / ou au canal de communication et qui est suffisamment déterminé pour accéder à sa clé pourra le faire.
Alors ne l'intégrez pas. "Le seul coup gagnant n'est pas de jouer."