Sécurité des clés API e-mail : permissions, rotation et stockage

Une clé API e-mail est une courte chaîne de caractères aux pouvoirs considérables. Quiconque la détient peut envoyer des e-mails depuis votre domaine, à n’importe qui, en votre nom. Les clés divulguées sont l’un des moyens les plus courants par lesquels des campagnes de phishing finissent par être envoyées depuis l’infrastructure d’entreprises légitimes.

La bonne nouvelle : quelques bonnes habitudes rendent une fuite peu probable, et limitent les dégâts si elle se produit malgré tout. Ce guide les passe en revue, à l’aide des contrôles qu’Inbixio offre pour chaque clé.

Ce que peut faire une clé Inbixio

Chaque clé créée dans API Keys → Create Api Key (clés API → créer une clé API) comporte trois réglages :

• Name (nom), pour votre propre organisation, par exemple prod-auth-service.
• Server Access (accès aux serveurs) : All Server (tous les serveurs ; envoie via le premier serveur SMTP que vous avez connecté) ou Selected Server (serveur sélectionné ; exactement celui que vous choisissez).
• Permissions : Send (envoyer), Read (lire) et Manage (gérer). L’API ne compte actuellement qu’un seul point de terminaison, l’envoi d’e-mails : Send est donc la permission dont vos services ont besoin.

Les clés se présentent sous la forme ibx_ suivi de 32 caractères hexadécimaux. Ce préfixe les rend faciles à reconnaître, et faciles à détecter pour les outils d’analyse de secrets.

Règle 1 : une clé par service et par environnement

Ne partagez pas une même clé dans toute votre entreprise. Créez une clé distincte pour chaque service, et pour chaque environnement :

Des clés distinctes signifient :

• Une fuite reste circonscrite. Révoquer prod-billing n’interrompt pas les e-mails de connexion.
• Chaque service envoie depuis la bonne adresse. Une clé rattachée au serveur billing@ envoie depuis billing@, et non depuis le premier serveur que vous avez connecté. Si vous supprimez un serveur rattaché, la clé se rabat sur votre premier serveur : rattachez donc à nouveau vos clés lorsque vous supprimez des serveurs.
• La rotation est indolore. Vous pouvez renouveler la clé d’un service sans toucher aux autres.

Règle 2 : accordez le minimum de permissions nécessaire

Un backend qui envoie des e-mails a besoin de Send et de rien d’autre : laissez donc Read et Manage décochés. Moins une clé est autorisée à faire, moins une fuite peut coûter cher.

Règle 3 : les clés restent sur les serveurs, jamais côté client

Tout ce qui est livré à un navigateur ou à une application mobile peut être extrait, minifié ou non. Cela inclut :

• les bundles JavaScript (React, Vue, composants client Next.js),
• les variables d’environnement préfixées pour le navigateur, comme NEXT_PUBLIC_, VITE_ ou REACT_APP_,
• les binaires d’applications iOS et Android.

Si une action de l’utilisateur dans votre frontend doit déclencher un e-mail, appelez votre propre point de terminaison backend. Votre backend vérifie que l’utilisateur a le droit de le faire, applique des limites de débit, et seulement ensuite appelle Inbixio avec la clé qu’il conserve dans son environnement.

// ✅ Browser → your API → Inbixio
await fetch('/api/invite', { method: 'POST', body: JSON.stringify({ email }) });

// ❌ Never do this in frontend code
fetch('https://backend.inbixio.com/api/send-email/', {
  headers: { 'X-API-Key': 'ibx_…' }, // visible to every visitor
});

Règle 4 : stockez les clés comme des mots de passe

• Placez les clés dans un gestionnaire de secrets (AWS Secrets Manager, Google Secret Manager, Doppler, 1Password, Vault) ou dans les variables d’environnement chiffrées de votre plateforme.
• Ne les commitez jamais. Ajoutez .env à .gitignore et activez l’analyse des secrets sur vos dépôts ; la protection des push de GitHub bloque de nombreuses fuites avant qu’elles ne se produisent.
• Tenez les clés à l’écart des journaux. Si vous journalisez les requêtes sortantes, supprimez d’abord l’en-tête X-API-Key.
• Ne collez pas de clés dans des tickets, des messageries ou des captures d’écran. Partagez l’accès au secret, pas sa valeur.

Règle 5 : renouvelez régulièrement, et immédiatement en cas de doute

Inbixio peut renouveler une clé : cliquez sur l’icône d’actualisation à côté de celle-ci sur la page API Keys. Le renouvellement génère une nouvelle valeur avec le même nom, le même accès aux serveurs et les mêmes permissions, et l’ancienne valeur cesse immédiatement de fonctionner. Pour faire la rotation d’une clé de production sans aucun envoi en échec :

1. Créez une deuxième clé avec les mêmes réglages (par exemple prod-auth-2).
2. Déployez la nouvelle clé dans le service et vérifiez que ses requêtes renvoient 200, par exemple dans les journaux de votre propre application.
3. Supprimez l’ancienne clé.

Utilisez l’icône d’actualisation lorsque la rapidité compte plus qu’une transition sans coupure, par exemple juste après une fuite. Renouvelez les clés courantes tous les quelques mois, et chaque fois qu’une personne ayant accès quitte l’équipe.

En cas de fuite d’une clé

Traitez-la comme un incident, mais un incident maîtrisable :

1. Renouvelez (icône d’actualisation) ou supprimez la clé immédiatement. Cela bloque toute utilisation de l’ancienne valeur.
2. Consultez les journaux du tableau de bord pour repérer une activité inhabituelle : des appels à des heures étranges ou un pic de volume. Le journal indique quand les appels ont été effectués, pas quelle clé les a effectués : comparez-le donc avec les journaux de vos propres services.
3. Vérifiez chez votre fournisseur de messagerie les rebonds ou plaintes pour spam causés par des messages que vous n’avez pas envoyés.
4. Identifiez l’origine de la fuite, qu’il s’agisse d’un commit, d’une ligne de journal ou d’un bundle frontend, et refermez cette brèche.
5. Prévenez les utilisateurs concernés si des messages ont été envoyés en votre nom, pour qu’ils sachent les ignorer.

Checklist rapide

• Une clé par service et par environnement, avec des noms explicites
• Des clés rattachées au serveur (adresse d’expédition) que chaque service doit utiliser
• Uniquement la permission Send sur les services d’envoi
• Aucune clé dans le code frontend, les applications mobiles ou les dépôts
• Des clés stockées dans un gestionnaire de secrets et retirées des journaux
• Une date de rotation dans l’agenda, et un plan en cas de fuite

La sécurité, c’est aussi ce qui vous tient à l’écart des dossiers spam : les messages envoyés depuis une clé compromise nuisent à la réputation de votre domaine. Associez cette checklist à SPF, DKIM et DMARC pour avoir une vue complète.