Sécurité des API : authentification et chiffrement — Guide complet 2025

Vos outils de prospection, votre CRM, votre outil d’enrichissement… ils communiquent tous via des API. Et chaque appel API est une porte d’entrée potentielle dans vos données B2B. En 2024, Salt Security a recensé une augmentation de 167 % des attaques ciblant les API en un an. Pour une équipe sales ou growth, une clé API compromise peut signifier la fuite de milliers de contacts prospects, la compromission d’un compte LinkedIn, ou pire — l’exposition de données personnelles soumises au RGPD.

Ce guide vous explique concrètement comment fonctionne la sécurité des API, quelles méthodes d’authentification choisir selon votre usage, et comment chiffrer vos échanges pour travailler sereinement.

Enrichissez vos leads en toute sécurité

Derrick se connecte à vos workflows Zapier, Make et n8n avec des protocoles sécurisés. Essayez gratuitement sans carte bancaire.

Essayer gratuitement →

Pourquoi la sécurité des API est devenue critique pour les équipes B2B

Pendant longtemps, la sécurité des API était une préoccupation réservée aux équipes techniques. Ce temps est révolu.

Aujourd’hui, un SDR configure des webhooks Zapier, un Growth Marketer connecte Derrick à HubSpot via Make, et un Sales Ops exporte des leads vers Salesforce via une API RESTful. Chacun de ces workflows repose sur des appels API — et chacun expose potentiellement des données sensibles.

Les conséquences d’une faille sont concrètes pour un profil business :

• Vol de données prospects : une clé API exposée dans un repo GitHub ou un Notion public suffit à ce qu’un tiers accède à votre base de leads.
• Sanctions RGPD : si des données personnelles (emails, téléphones) transitent via une API non sécurisée, vous êtes en infraction. L’amende peut atteindre 4 % du chiffre d’affaires annuel mondial.
• Interruption de service : un attaquant peut épuiser vos crédits d’API (et donc votre budget) en quelques minutes via une attaque par force brute.

Comprendre les bases de la sécurité des API, c’est protéger à la fois votre pipeline commercial et vos obligations légales. Voyons d’abord de quoi il s’agit concrètement.

Qu’est-ce qu’une API et pourquoi attire-t-elle les cyberattaques

Une API (Application Programming Interface) est un canal de communication standardisé entre deux applications. Concrètement : quand Zapier demande à Derrick de trouver l’email d’un prospect, il passe par une API. Quand vous exportez vos leads vers HubSpot, votre outil envoie une requête à l’API HubSpot.

Ce qui rend les API attractives pour les attaquants, c’est leur nature même : elles sont accessibles depuis n’importe où, souvent documentées publiquement, et traitent des données à haute valeur (contacts, tokens d’accès, données financières).

Les vecteurs d’attaque les plus fréquents en contexte B2B sont :

• L’exposition de clés API dans du code versionné (GitHub), des fichiers de config partagés, ou des outils no-code mal configurés.
• Le credential stuffing : tester des milliers de combinaisons identifiant/mot de passe en exploitant des fuites de données.
• Les attaques MITM (Man-in-the-Middle) : intercepter des requêtes API non chiffrées sur un réseau peu sécurisé.
• L’abus de permissions : accéder à des données auxquelles un token n’aurait pas dû avoir accès (faute de scope restrictif).

Ces bases étant posées, passons au cœur du sujet : les méthodes pour authentifier et sécuriser vos appels API.

Les 4 méthodes d’authentification API à connaître

L’authentification répond à une question simple : “Êtes-vous bien qui vous prétendez être ?” Il existe quatre grandes approches, avec des niveaux de sécurité et des cas d’usage très différents.

1. API Key : simple, rapide, mais à manier avec précaution

L’API Key est la méthode la plus répandue dans les outils no-code et les intégrations B2B. C’est une chaîne de caractères unique (ex : sk_live_abc123xyz) que vous incluez dans chaque requête pour vous identifier.

Avantages : Facile à générer, à révoquer, et à utiliser dans Zapier ou Make sans configuration complexe.

Limites : Si la clé est compromise, n’importe qui peut s’en servir. Elle ne porte aucune information sur les permissions, ce qui impose de gérer les accès au niveau serveur.

Bonne pratique : Créez une clé par intégration (une pour Zapier, une pour Make, une pour n8n). Ainsi, si une clé fuite, vous révoquez uniquement celle-là sans tout casser.

2. OAuth 2.0 : le standard pour les accès délégués

OAuth 2.0 est le protocole que vous utilisez sans le savoir à chaque fois que vous cliquez sur “Connexion avec Google” ou “Autoriser l’accès à LinkedIn”. Il permet à une application d’accéder aux données d’un utilisateur sans que celui-ci ne partage son mot de passe.

Le mécanisme en pratique : l’application demande un access token temporaire (souvent valable 1 heure), que l’utilisateur approuve via une interface. Ce token est ensuite utilisé dans les requêtes API à la place des identifiants.

Pourquoi c’est important en B2B : Si vous connectez votre CRM à un outil tiers via OAuth, et que cet outil est compromis, l’attaquant n’obtient qu’un token temporaire — pas votre mot de passe. Vous pouvez révoquer l’accès en quelques clics depuis les paramètres de votre compte.

3. JWT (JSON Web Token) : l’authentification sans état

Un JWT est un token chiffré qui contient des informations (l’identité de l’utilisateur, ses permissions, une date d’expiration) encodées directement dans le token. Le serveur n’a pas besoin de consulter une base de données pour valider chaque requête — il déchiffre simplement le token.

En B2B, les JWT sont fréquents dans les architectures microservices et les plateformes SaaS qui gèrent de nombreux utilisateurs simultanément. La tokenisation des accès qu’ils permettent réduit la surface d’attaque par rapport aux sessions traditionnelles.

À retenir : Un JWT expiré n’est plus valide. Configurez toujours une durée de vie courte (15 minutes à 1 heure) pour les tokens sensibles.

4. Basic Authentication : à réserver aux environnements de test

La Basic Auth envoie un identifiant et un mot de passe encodés en Base64 à chaque requête. C’est simple à implémenter, mais dangereux en production : Base64 n’est pas du chiffrement, et les credentials sont facilement décodables si la connexion n’est pas chiffrée.

Règle absolue : N’utilisez jamais la Basic Auth sans HTTPS. En pratique, réservez-la aux environnements de développement ou aux outils internes où vous contrôlez totalement le réseau.

Comment fonctionne le chiffrement des API

L’authentification prouve qui vous êtes. Le chiffrement protège ce qui transite. Les deux sont indissociables d’une stratégie de sécurité solide.

TLS/HTTPS : le socle de toute communication sécurisée

TLS (Transport Layer Security) est le protocole qui chiffre les données entre votre navigateur (ou application) et le serveur. Quand une URL commence par https://, c’est TLS qui est à l’œuvre.

Pour les API, la règle est sans exception : toute API exposée sur internet doit fonctionner exclusivement en HTTPS. Une API en HTTP transmet ses données en clair, comme envoyer un courrier sans enveloppe.

En pratique, vérifiez systématiquement que les API tierces que vous intégrez (enrichissement de données, CRM, automation) utilisent TLS 1.2 ou 1.3. Les versions antérieures (SSL, TLS 1.0) présentent des vulnérabilités connues.

Chiffrement des données au repos vs en transit

Le chiffrement des données couvre deux états distincts :

Pour une équipe B2B, le chiffrement en transit est le plus critique : c’est là que vos listes de prospects, vos tokens et vos données personnelles transitent à chaque appel API. Le chiffrement au repos relève davantage de la responsabilité du fournisseur SaaS — demandez-lui explicitement s’il l’applique.

Signature des requêtes HMAC

Pour les intégrations critiques (webhooks notamment), la signature HMAC ajoute une couche supplémentaire : chaque requête est signée avec une clé secrète partagée. Le serveur receveur vérifie la signature avant de traiter la requête, ce qui garantit que la requête n’a pas été altérée en chemin.

En pratique, les plateformes comme Stripe ou HubSpot utilisent ce mécanisme sur leurs webhooks. Si vous construisez des workflows Make/Zapier qui reçoivent des webhooks, vérifiez que la signature est bien validée côté récepteur.

Les bonnes pratiques pour sécuriser vos API B2B

Maintenant que les concepts sont clairs, voici les règles d’or à appliquer concrètement dans vos workflows de prospection et d’enrichissement.

1. Appliquer le principe du moindre privilège

Chaque clé API ou token doit disposer uniquement des permissions strictement nécessaires à sa tâche. Un token qui sert à lire des contacts dans votre CRM n’a aucune raison d’avoir accès aux paramètres de facturation.

En pratique : Quand vous créez une API Key dans un outil, cherchez l’option “scopes” ou “permissions” et cochez uniquement ce dont vous avez besoin. La plupart des outils B2B (HubSpot, Salesforce, Zapier) proposent cette granularité.

2. Faire tourner vos clés régulièrement (rotation)

Une clé API utilisée depuis 2 ans a eu beaucoup d’occasions d’être exposée (changement d’équipe, migration de repo, logs non nettoyés). La rotation des clés — c’est-à-dire en générer une nouvelle et révoquer l’ancienne — est une pratique de base en cybersécurité.

Fréquence recommandée : Tous les 90 jours pour les clés critiques (enrichissement de données, accès CRM). Immédiatement en cas de départ d’un collaborateur ayant accès aux configurations.

3. Mettre en place le rate limiting

Le rate limiting consiste à limiter le nombre de requêtes qu’une clé API peut effectuer sur une période donnée. C’est une protection contre :

• Les attaques par force brute (tenter des milliers de combinaisons)
• La consommation abusive de vos crédits (si votre outil facture à l’appel)
• Les boucles infinies dans un workflow automation mal configuré

Côté fournisseur, vérifiez que l’API que vous utilisez impose bien des limites de débit. Côté consommateur, configurez des alertes si vos quotas sont dépassés de façon anormale.

4. Logger et monitorer chaque appel API

Vous ne pouvez pas protéger ce que vous ne voyez pas. Un bon journal de logs API vous permet de détecter des schémas suspects : appels depuis une IP inconnue, volume anormal à 3h du matin, accès à des endpoints inhabituels.

Pour les équipes non techniques, les plateformes d’automation comme Make et Zapier proposent des historiques d’exécution que vous pouvez consulter régulièrement. C’est moins puissant qu’un SIEM, mais suffisant pour détecter des anomalies évidentes.

5. Ne jamais stocker de clés API en dur dans votre code ou vos fichiers partagés

C’est l’erreur la plus fréquente, et la plus coûteuse. Une clé API hardcodée dans un fichier Google Sheets, un repo GitHub public, ou un Notion partagé avec tout le bureau suffit à exposer l’ensemble de votre stack.

Les bonnes alternatives :

• Utilisez les gestionnaires de secrets des plateformes d’automation (Zapier, Make ont des sections dédiées aux credentials)
• Stockez les clés dans des variables d’environnement si vous utilisez du code
• Utilisez un gestionnaire de secrets dédié (1Password for Teams, HashiCorp Vault) pour les équipes plus larges

Les erreurs de sécurité API les plus courantes (et comment les corriger)

Problème 1 : Clé API exposée dans un fichier partagé

Impact : N’importe qui ayant accès au fichier peut utiliser votre clé pour consommer vos crédits, accéder à vos données ou faire des requêtes en votre nom.

Solution : Révoquez immédiatement la clé exposée depuis l’interface de l’outil concerné, puis générez-en une nouvelle. Auditez l’ensemble de vos fichiers partagés (Notion, Confluence, Google Drive) à la recherche d’autres occurrences.

Problème 2 : Token OAuth jamais révoqué après un départ d’équipe

Impact : Un ancien collaborateur conserve un accès valide à votre CRM, votre outil d’enrichissement ou votre compte LinkedIn business.

Solution : Maintenez une liste des intégrations OAuth actives dans chaque outil (section “Applications autorisées” dans les paramètres). Lors de chaque offboarding, passez cette liste en revue et révoquez les accès concernés.

Problème 3 : Utilisation de HTTP au lieu de HTTPS

Impact : Toutes les données transitant via cet appel API (emails, tokens, données prospects) sont lisibles en clair par quiconque intercepte le trafic.

Solution : Vérifiez que l’URL de base de chaque API que vous intégrez commence bien par https://. Refusez d’utiliser tout outil qui proposerait des endpoints en http:// pour des données sensibles.

Problème 4 : Scopes trop larges accordés à une intégration tierce

Impact : Si l’outil tiers est compromis, l’attaquant dispose d’accès bien au-delà de ce qui était nécessaire (lecture des emails, accès à la facturation, etc.).

Solution : Révisez les permissions accordées à chaque intégration. Sur HubSpot, Salesforce ou votre CRM, la section “Intégrations connectées” vous indique précisément ce que chaque application peut faire. Réduisez au strict minimum.

Problème 5 : Absence de rotation des clés après un incident de sécurité

Impact : Même si l’incident est contenu, une clé non révoquée reste un vecteur d’exploitation potentiel.

Solution : Adoptez une politique de révocation systématique dès qu’une clé a pu être exposée, même si vous n’avez pas de preuve d’utilisation malveillante. Le coût de reconfigurer une intégration est toujours inférieur à celui d’une fuite de données.

API, RGPD et données personnelles : ce que vous devez savoir

En B2B, les API d’enrichissement de données traitent des informations personnelles : noms, adresses email professionnelles, numéros de téléphone. À ce titre, elles tombent dans le périmètre du RGPD.

Ce que cela implique concrètement :

• Base légale : Vous devez pouvoir justifier d’une base légale pour traiter ces données via API (intérêt légitime en B2B dans la majorité des cas, à documenter dans votre registre des traitements).
• Transferts hors UE : Si l’API d’un fournisseur américain transfère des données personnelles vers des serveurs aux États-Unis, des mécanismes de transfert adéquats doivent être en place (clauses contractuelles types, Data Privacy Framework).
• Durée de conservation : Les données récupérées via API ne doivent pas être conservées indéfiniment. Définissez une politique de purge dans vos Google Sheets ou CRM.
• Sécurité technique : Le RGPD (Article 32) exige des mesures techniques appropriées, dont le chiffrement. Une API sans HTTPS n’est pas compatible avec les exigences de sécurité du règlement.

Questions à poser à vos fournisseurs d’API B2B :

1. Où sont hébergées les données traitées (UE ou hors UE) ?
2. Le chiffrement TLS est-il appliqué sur tous les endpoints ?
3. Existe-t-il un DPA (Data Processing Agreement) disponible ?
4. Comment les données sont-elles chiffrées au repos ?

Un fournisseur sérieux répondra clairement à ces quatre questions. Pour aller plus loin sur la conformité RGPD dans vos workflows de prospection, consultez notre article dédié au cold emailing et RGPD.

Comment choisir une API d’enrichissement B2B sécurisée

Quand vous évaluez un outil d’enrichissement de données B2B — que ce soit pour trouver des emails, des téléphones ou des informations d’entreprises — la sécurité doit faire partie de vos critères de sélection au même titre que la précision des données.

La checklist de sécurité à vérifier :

Derrick, par exemple, s’intègre nativement à Google Sheets et supporte des connexions sécurisées via Zapier, Make et n8n. Vous pouvez configurer des clés par workflow et révoquer les accès individuellement depuis votre tableau de bord — ce qui facilite la gestion des accès par équipe.

Pour approfondir le sujet de l’enrichissement de données B2B dans vos workflows, consultez notre guide sur l’enrichissement de base de données.

À retenir

• Authentification ≠ chiffrement : les deux sont nécessaires et complémentaires — l’un prouve votre identité, l’autre protège ce qui transite.
• OAuth 2.0 est le standard recommandé pour les accès délégués (connexion via un service tiers) ; les API Keys restent pertinentes pour les intégrations machine-to-machine, à condition de bien gérer leur cycle de vie.
• HTTPS/TLS est non négociable : toute API exposée sur internet sans chiffrement en transit est une faille de sécurité.
• Une clé = une intégration : créez des clés distinctes par workflow pour pouvoir révoquer précisément en cas d’incident.
• Le RGPD s’applique aux données personnelles traitées via API : base légale, transferts, durée de conservation et sécurité technique sont tous concernés.
• Faites tourner vos clés tous les 90 jours et systématiquement lors de changements d’équipe.

Conclusion : par où commencer pour sécuriser vos API aujourd’hui

La sécurité des API n’est pas réservée aux équipes IT. En tant que profil business qui configure des workflows d’enrichissement, d’automation ou d’export de données, vous êtes en première ligne.

Commencez par un audit simple : recensez toutes les API Keys et tokens OAuth actifs dans vos outils (Zapier, Make, votre CRM, votre outil d’enrichissement). Pour chacun, posez-vous trois questions : qui y a accès, depuis quand, et avec quels droits.

Les gains sont immédiats : moins de risques de fuite de données prospects, une meilleure conformité RGPD, et une posture de sécurité qui rassurera vos prospects eux-mêmes quand ils vous confient leurs données.

Des workflows d'enrichissement sécurisés, dès maintenant

Derrick vous permet de configurer des intégrations avec contrôle fin des accès, directement dans Google Sheets. Aucune carte bancaire pour démarrer.

Essayer gratuitement →

FAQ

Quelle est la différence entre authentification et chiffrement d’une API ? L’authentification vérifie l’identité de celui qui fait la requête (via une clé API, un token OAuth ou un JWT). Le chiffrement protège les données qui transitent dans cette requête (via TLS/HTTPS). Les deux sont nécessaires : une requête authentifiée mais non chiffrée est lisible en clair par un attaquant.

Une API Key est-elle suffisante pour sécuriser une intégration B2B ? Elle suffit pour des cas simples (accès en lecture depuis un outil de confiance), à condition d’appliquer les bonnes pratiques : une clé par intégration, rotation régulière, stockage sécurisé dans les paramètres de votre outil d’automation (jamais en dur dans un fichier). Pour des accès plus sensibles ou impliquant des données personnelles, OAuth 2.0 offre une meilleure isolation.

Comment savoir si une API que j’utilise est sécurisée ? Vérifiez que l’URL commence par https://, que le fournisseur propose un DPA (accord de traitement des données) et que sa documentation mentionne TLS. Vous pouvez aussi vérifier si les endpoints utilisent des mécanismes de rate limiting et si l’authentification prend en charge des scopes granulaires.

Mes workflows Zapier ou Make sont-ils concernés par le RGPD ? Oui, si vos workflows traitent des données personnelles (emails, téléphones, noms de prospects). Les plateformes d’automation comme Zapier et Make sont considérées comme des sous-traitants au sens du RGPD. Vérifiez qu’un DPA est signé avec elles et que les données ne transitent pas hors UE sans encadrement adéquat.

Que faire si je découvre qu’une de mes clés API a été exposée ? Révoquez-la immédiatement depuis l’interface de l’outil concerné, sans attendre. Générez une nouvelle clé et reconfigurez vos intégrations. Consultez ensuite les logs d’utilisation pour évaluer si la clé a été utilisée de façon anormale. Si des données personnelles ont potentiellement été compromises, la notification à la CNIL peut être obligatoire dans les 72 heures.