Documentation API Hop
Sécurité et configuration
Création des clés API, contrôle des permissions, rotation et pratiques de sécurité.
Les principes essentiels de protection des clés API sont de ne pas les exposer, d'appliquer le moindre privilège, de les renouveler régulièrement et de garder leur utilisation traçable.
Comment gérer et protéger mes clés API ?
Pratiques recommandées :
- Ne placez pas de clés API dans des dépôts publics, pages frontend, paquets mobiles ou captures d'écran.
- Lisez les clés depuis des variables d'environnement ou un gestionnaire de secrets sur le serveur.
- Créez des clés distinctes pour le développement, les tests et la production.
- Créez des clés séparées par service ou application pour améliorer la traçabilité et l'isolation.
- Configurez les permissions de modèles selon les besoins et définissez des dates d'expiration si approprié.
- Renouvelez les clés régulièrement, immédiatement après un changement de personnel, l'arrêt d'un service ou une suspicion de fuite.
Si une clé API a pu être divulguée :
- Désactivez, supprimez ou renouvelez immédiatement l'ancienne clé.
- Créez une nouvelle clé et mettez à jour tous les services dépendants.
- Examinez l'utilisation récente, les variations de solde et les dépenses anormales.
- Resserrez les permissions de modèles et envisagez une expiration plus courte.
- Examinez la voie de fuite : dépôts, journaux, configuration CI ou clients tiers, par exemple.
Une fuite de clé API peut entraîner des appels non autorisés et des pertes financières. Même les clés de test doivent être protégées comme des secrets de production.
Puis-je revoir la clé API complète après sa création ?
Non. La clé complète n'est affichée que lors de sa création réussie. Ensuite, la console ne montre qu'un aperçu masqué.
Avant de fermer la boîte de création, conservez la clé dans une variable d'environnement côté serveur ou un gestionnaire de secrets. Une clé perdue ne peut pas être récupérée via les API utilisateur ou administrateur. Créez une clé de remplacement, mettez à jour l'appelant, puis supprimez l'ancienne. Le modèle d'intégration IA de la documentation utilise un espace réservé <API_KEY> et ne charge pas les anciennes clés.
Comment envoyer une clé API ?
Envoyez les clés API uniquement dans les en-têtes de requête. Nous recommandons :
Authorization: Bearer YOUR_API_KEYVous pouvez aussi utiliser :
X-API-Key: YOUR_API_KEYNe placez jamais d'identifiants API RequestBeam dans les paramètres d'URL. Les noms évoquant des identifiants (apiKey, api_key, apikey, x-api-key et key) déclenchent normalement HTTP 400. Les exceptions limitées des paramètres métier Similarweb concernent uniquement les requêtes GET : /v1/similarweb/websites/backlinks accepte un seul nom d'hôte dans Key, avec majuscule ; /v1/similarweb/websites/outgoing-traffic, /websites/incoming-referrals et /websites/similar-sites/suggestions acceptent un seul nom d'hôte dans key, avec minuscule (tous sous /v1/similarweb). Ces champs identifient un site cible, pas un identifiant API. Les noms d'hôte doivent être valides. Les doublons, casses incorrectes, valeurs ressemblant à des identifiants et champs de requête supplémentaires pour identifiants restent bloqués. Authentifiez-vous toujours avec un en-tête de requête, y compris sur les routes Similarweb. Consultez l'exemple de requête Similarweb.
Cette règle n'affecte pas les autres paramètres métier tels que token OAuth, apiKeyId, username ou pagination_token.