Bonnes pratiques

Vos clés et jetons d’API doivent être protégés avec le plus grand soin.

Ces informations d’identification sont directement liées à votre App développeur ainsi qu’aux comptes X qui vous ont autorisé à effectuer des requêtes en leur nom. Si vos clés sont compromises, des acteurs malveillants pourraient les utiliser pour envoyer des requêtes aux endpoints X au nom de votre App développeur ou de ses utilisateurs autorisés, ce qui pourrait vous faire atteindre des limites de taux inattendues, épuiser votre quota d’accès payant, voire entraîner la suspension de votre App développeur.

Les sections suivantes présentent des bonnes pratiques à prendre en compte lors de la gestion de vos clés et jetons d’API.

​

Régénérer des clés et jetons d’API

Si vous pensez que vos clés d’API ont été exposées, vous devez les régénérer en suivant ces étapes :

1. Accédez à la page « Projects and Apps » du developer portal.
2. Cliquez sur l’icône « Keys and tokens » (🗝) à côté de l’App concernée.
3. Cliquez sur le bouton « Regenerate » à côté de l’ensemble de clés et jetons que vous souhaitez régénérer.

Si vous préférez régénérer vos Access Tokens ou votre Jeton Bearer par programmation, vous pouvez le faire à l’aide de nos endpoints d’authentification.

• Si vous souhaitez régénérer vos Access Tokens, vous devez invalider vos jetons à l’aide de l’endpoint POST oauth/invalidate_token, puis régénérer vos jetons à l’aide du flux OAuth à 3 étapes.
• Si vous souhaitez régénérer votre Jeton Bearer, vous devez invalider votre jeton à l’aide de l’endpoint POST oauth2/invalidate_token, puis régénérer votre jeton à l’aide de l’endpoint POST oauth2/token.

​

Disposer d’un fichier central pour vos secrets

Utiliser un fichier, par exemple un fichier .env ou un fichier .yaml, pour stocker vos secrets peut être utile, mais assurez-vous d’avoir un .gitignore solide afin d’éviter de les commit par inadvertance dans un dépôt Git. 

​

Variables d’environnement

Écrire du code qui utilise des variables d’environnement peut être utile.

Voici un exemple en Python :

import os

consumer_key = os.environ.get("CONSUMER_KEY")

consumer_secret = os.environ.get("CONSUMER_SECRET")

Dans votre terminal, vous écririez quelque chose comme ceci :

export CONSUMER_KEY='xxxxxxxxxxxxxxxxxxx'
export CONSUMER_SECRET='xxxxxxxxxxxxxxxxxxxxxxx'

​

Code source et gestion de versions

Les erreurs de sécurité les plus courantes commises par les développeurs consistent à avoir des API Key et des clés et jetons déposés dans le code source au sein de systèmes de gestion de versions accessibles comme GitHub et BitBucket. De nombreux dépôts de code sont accessibles publiquement. Cette erreur est si fréquente dans les dépôts publics qu’il existe des bots lucratifs qui parcourent ces dépôts à la recherche d’API Key.

• Utilisez des variables d’environnement côté serveur. En stockant les API Key dans des variables d’environnement, vous les tenez à l’écart de votre code et de la gestion de versions. Cela vous permet également d’utiliser facilement des clés différentes selon les environnements.
• Utilisez un fichier de configuration exclu du contrôle de version. Ajoutez le nom du fichier à votre fichier .gitignore pour empêcher le suivi du fichier par la gestion de versions.
• Si vous retirez les API Key de votre code après les avoir commitées, elles resteront probablement accessibles via les versions précédentes de votre base de code. Régénérez vos API Key, comme décrit dans la section suivante.

​

Bases de données

Si vous devez stocker des access tokens dans une base de données, veuillez garder les points suivants à l’esprit :

• Restreignez l’accès à la base de données de sorte que les access tokens ne soient lisibles que par le propriétaire du jeton.
• Limitez les privilèges de modification/écriture sur la table dédiée aux access tokens — ceci doit être automatisé via le système de gestion des clés.
• Chiffrez les access tokens avant de les stocker dans tout système de stockage de données.

​

Outils de gestion des mots de passe

Les outils de gestion des mots de passe comme 1Password ou LastPass peuvent être utiles pour conserver vos clés et jetons en lieu sûr. Vous pouvez envisager d’éviter de les partager dans un gestionnaire de mots de passe d’équipe partagé.

​

Stockage Web et cookies

Il existe deux types de stockage Web : LocalStorage et SessionStorage. Ils ont été introduits comme une amélioration par rapport aux cookies, car leur capacité de stockage est bien plus élevée. Chaque option présente toutefois des avantages et des inconvénients distincts.  

Stockage Web : LocalStorage

Tout ce qui est stocké dans le stockage Web local est persistant. Autrement dit, les données restent présentes jusqu’à suppression explicite. Selon les besoins de votre projet, cela peut être un atout. Cependant, soyez prudent avec LocalStorage : toute modification ou tout ajout de données restera disponible lors de toutes les visites ultérieures de la page concernée. Nous ne recommandons pas l’usage de LocalStorage dans la plupart des cas, même s’il peut exister quelques exceptions. Si vous optez pour LocalStorage, sachez qu’il applique la politique de même origine : toutes les données stockées ne seront accessibles qu’à partir de la même origine. Un avantage de performance supplémentaire est la diminution du trafic client‑serveur, puisque les données n’ont pas à être renvoyées au serveur à chaque requête HTTP.  

Stockage Web : SessionStorage

SessionStorage est similaire à LocalStorage, mais la différence principale est qu’il n’est pas persistant. Une fois la fenêtre (ou l’onglet, selon le navigateur) ayant servi à écrire dans SessionStorage fermée, les données sont perdues. Cela est utile pour restreindre l’accès en lecture à votre jeton le temps d’une session utilisateur. D’un point de vue sécurité, l’utilisation de SessionStorage est généralement préférable à LocalStorage. Comme LocalStorage, il bénéficie de la politique de même origine et de la réduction du trafic client‑serveur.  

Cookies

Les cookies sont le moyen traditionnel de stocker des données de session. Vous pouvez définir une date d’expiration pour chaque cookie, ce qui facilite la révocation et la restriction d’accès. En revanche, le trafic client‑serveur augmente avec les cookies, car les données sont renvoyées au serveur à chaque requête HTTP. Si vous choisissez d’utiliser des cookies, vous devez vous protéger contre le détournement de session. Par défaut, les cookies sont envoyés en clair via HTTP, ce qui rend leur contenu vulnérable à l’écoute de paquets et/ou aux attaques de l’homme du milieu, au cours desquelles des attaquants peuvent modifier votre trafic. Vous devez toujours imposer HTTPS pour protéger vos données en transit. Cela assure la confidentialité, l’intégrité (des données) et l’authentification. Toutefois, si votre application Web ou votre site est accessible à la fois en HTTP et en HTTPS, utilisez également l’attribut « Secure » sur le cookie. Cela empêchera des attaquants d’envoyer à un utilisateur des liens vers la version HTTP de votre site et d’intercepter la requête HTTP ainsi générée.

Une mesure de défense supplémentaire contre le détournement de session lors de l’utilisation de cookies consiste à revérifier l’identité de l’utilisateur avant toute action à fort impact. Un autre attribut à envisager pour renforcer la sécurité de vos cookies est « HttpOnly ». Cet attribut indique au navigateur que le cookie concerné ne doit être accessible qu’à partir du serveur. Toute tentative d’accès par des scripts côté client sera bloquée, ce qui aide à se prémunir contre la plupart des attaques de type cross‑site scripting (XSS).