Le fait que ce soit un problème dépend entièrement de votre cas d'utilisation et de votre modèle de menace. Considérez votre clé d'api comme publique si vous l'incluez ou l'envoyez de quelque manière que ce soit dans/à partir de votre application, et réfléchissez à des choses comme ce que les gens peuvent faire avec. Quel niveau de préjudice peuvent-ils vous causer ? Cela vous donne l'impact. Seraient-ils motivés, par exemple, y a-t-il un avantage financier pour eux d'une manière ou d'une autre ? Cela permet d'estimer la probabilité que cela se produise. L'ensemble, impact x probabilité = risque, que vous pouvez accepter (ne rien faire), atténuer (diminuer l'impact ou la probabilité), éliminer (réparer) ou transférer (par exemple, souscrire une assurance).
En ce qui concerne les mesures d'atténuation, pouvez-vous limiter la portée de la clé d'api, de sorte que seules les choses nécessaires puissent être faites sur l'api avec cette clé ? Pouvez-vous mettre en place une limitation du débit ? Surveillance, alerte ? Je ne suis pas familier avec l'api Books, mais il pourrait s'agir de contrôles d'atténuation.
Pour ce qui est de l'élimination des risques, vous ne devriez pas placer la clé d'accès dans l'application. Vous pourriez mettre en place votre propre serveur, qui détiendrait la clé d'api et transmettrait les demandes à l'apiBooks, augmentée de la clé d'api. Notez cependant que vous aurez toujours besoin d'une forme d'authentification et de contrôle d'accès dans votre serveur, sinon il peut simplement être utilisé comme un oracle par un attaquant pour effectuer n'importe quoi dans l'api Books réelle de la même manière que s'il avait la clé, sauf que dans ce cas, il n'en a pas besoin. Ce rôle pourrait également être rempli par une sorte de passerelle api, qui peut également ajouter des données aux requêtes api.
L'élimination du risque est évidemment plus coûteuse. Les défenses doivent être proportionnelles au risque, vous devez donc décider si cela en vaut la peine.
