Sécuriser vos tokens, clés API et secrets

Public ? Privé ? Quoi ?

Quand protéger vos jetons ?

La sécurisation des clés et jetons API est extrêmement importante !

Une seule erreur peut entraîner une perte de contrôle totale de votre serveur et de vos données face aux pirates informatiques !

Il ne devrait pas être si difficile de déterminer si un jeton particulier doit être caché - même en se basant sur la documentation officielle !

Cela est souvent aggravé par la confusion entre les termes liés que vous rencontrerez : tokens, keys, credentials, secrets, private, et public.

Réexaminons cela en distinguant clairement secret et non-secret.

🔒 Clés secrètes DOIVENT rester cachées. En général, elles NE DOIVENT JAMAIS quitter votre serveur privé (ou service comme Heroku, Netlify ou Travis-CI).
🌍 Clés non secrètes désignent des chaînes pouvant être partagées librement et incluses dans les requêtes du navigateur.

🔒 `Clés secrètes`

‼️ Important : les clés secrètes DOIVENT être ignorées par Git ET exclues de tout code de navigateur. Comment utiliser dotenv

Comment savoir quand vous travaillez avec une clé secrète ?

👍 Règle empirique : les serveurs qui renvoient des erreurs CORS n’ont pas de support navigateur. Cela indique fortement que vous DEVEZ proxifier le service, en traitant ce dernier comme s’il s’agissait d’une clé secrète.

👍 Règle empirique : les services coûteux devraient presque toujours être proxifiés ou masqués.

👍 Règle empirique : si vous effectuez une opération d’écriture (upload de fichier, insertion d’une ligne dans la base de données), vous manipulez probablement des clés secrètes.

Cas d’utilisation & fonctionnalités : clés secrètes

Autorisation à long terme (identifiants, jetons d’accès, JSON Web Tokens)
Autorisation à court terme (tokens OAuth, stockage de session)
Accès à des services payants/coûteux (pour l’authentification, le géocodage, le stockage de fichiers, etc.)
Partie privée d’une paire publique/privée (RECAPTCHA, Stripe, Auth0)
Identifiants de service (Email/SMTP, LDAP/Services de répertoire)
Chiffrement des données et vérification de l’intégrité

Liste de vérification : Gestion sécurisée des secrets

Aperçu rapide

Pour éliminer les secrets de votre code, suivez ces étapes :

Remplacez les clés codées en dur par des variables d’environnement. Exemple : process.env.API_SECRET
Utilisez une bibliothèque comme dotenv accompagnée d’un fichier .env. Ajoutez-y les secrets précédemment codés en dur.
Ajoutez une ligne .env dans votre fichier .gitignore !

NE PAS créer de fichier .env sur les serveurs déployés. Utilisez les outils de gestion des variables d’environnement fournis par votre service d’hébergement (ex. : Heroku, Netlify, AWS EC2) : interface de gestion ou ligne de commande.

Article lié : Utilisation sécurisée de dotenv dans NodeJS

🌍 `Clés non secrètes`

👍 Bonne pratique : lorsqu’une clé doit être envoyée au navigateur en code ou en inline (par exemple via une balise <script src="https://my-api/?apiKey=123-abc-456">), il s’agit inévitablement d’une clé non confidentielle. Un exemple courant est Google Maps.

Cas d’usage & fonctionnalités : clés non confidentielles

Accès à court terme (identifiants de session utilisateur, JSON Web Tokens)
Limiter l’accès à l’API par application/développeur (authentification, géocodage, etc.)
Partie publique d’une paire publique/privée (RECAPTCHA, Stripe, Auth0)
Identifiants d’analytique

✅ Gestion des clés non confidentielles :

Il est sécurisé de coder en dur les clés non confidentielles (publiques) !

Rendez cela plus facile à gérer à long terme avec un fichier config.js partagé pour votre application.

Exemple :

module.exports = {
  googleMapsKey: '123-abc'
};

const config = require('./config.js');
const key = config.googleMapsKey;
const src = `//maps.googleapis.com/maps/api/js?key=${key}`;
// ...

Remarque : Il existe d’autres Cas d’utilisation pour les variables d’environnement. Certains que je n’ai pas abordés : CI/CD/tests, drapeaux de fonctionnalité et configuration au runtime pour des environnements spéciaux !