LinkedIn
Instagram
WhatsApp
Telegram
Google Agenda
Rejoindre la communauté SlackIntégrez des courriels que vos utilisateurs peuvent confiance
La connexion aux boîtes de réception de vos utilisateurs comporte de réels enjeux de sécurité. Les mots de passe stockés, les étendues OAuth trop larges et les jetons non renouvelés créent autant de surfaces d'attaque susceptibles de rompre la confiance des utilisateurs et de violer le RGPD.
Unipile's Guide de l'API e-mail couvre l'image complète de l'intégration. Cet article se concentre sur la couche de sécurité : ce qu'une API d'e-mail sécurisée doit garantir, quels risques éviter et comment Unipile est architecturé pour protéger les données de vos utilisateurs par conception.
Gmail
Outlook
IMAP
Qu'est-ce qui rend une API d'e-mail "sécurisée" ?
La sécurité dans une API d'e-mails n'est pas une fonctionnalité unique. C'est un choix architectural qui englobe l'authentification, l'autorisation, la gestion des données et l'infrastructure. Une API d'e-mails sécurisée doit garantir quatre choses simultanément.
Les utilisateurs autorisent l'accès via le flux OAuth officiel de leur fournisseur. Aucun mot de passe ne quitte jamais le serveur du fournisseur ni n'atterrit dans votre base de données.
Chaque compte lié ne demande que les autorisations dont il a réellement besoin - lecture seule lorsqu'aucun envoi n'est requis, portée d'envoi uniquement lorsqu'elle est explicitement nécessaire.
Tout le trafic API utilise TLS 1.2+. Les jetons stockés sont cryptés au repos en utilisant AES-256. Le contenu des courriels n'est jamais conservé au-delà du cycle de vie de la demande.
OAuth 2.0 par rapport au stockage d'un mot de passe
La décision la plus fondamentale en matière de sécurité dans toute intégration de messagerie électronique est le mode d'authentification. De nombreuses intégrations IMAP anciennes demandent aux utilisateurs de saisir leur mot de passe et de le stocker. Cette approche crée un point de défaillance unique : une violation de la base de données expose la boîte de réception de chaque utilisateur. OAuth 2.0 élimine complètement ce problème. Voir comment Google OAuth 2.0 et Microsoft OAuth 2.0 mettez en œuvre ce flux.
Jetons d'autorisation : lecture seule vs. envoyer
Les étendues OAuth définissent exactement ce que votre application peut faire avec la boîte aux lettres d'un utilisateur. Demander des étendues larges alors que des étendues plus restreintes suffiraient est un anti-modèle de sécurité grave. Pour un CRM qui ne fait que lire les e-mails pour enregistrer l'activité, demander gmail.modifier est inutile et expose les utilisateurs à un plus grand risque si votre jeton est compromis. Si votre application a besoin de API d'envoi d'e-mails requests, vous trouverez également une description complète des scopes requis par fournisseur dans notre guide de l'API d'envoi d'e-mails.
| Portée | Fournisseur | Ce que cela permet | Niveau de risque |
|---|---|---|---|
| gmail.lecture seule | Gmail | Lire les courriels uniquement | Minime |
| gmail.envoyer | Gmail | Envoyer au nom de l'utilisateur | Portée |
| Mail.Read | Outlook | Lire les courriels uniquement | Minime |
| Mail.Send | Outlook | Envoyer au nom de l'utilisateur | Portée |
| https://mail.google.com/ | Gmail | Accès complet à la boîte aux lettres | Large |
| Mail.ReadWrite | Outlook | Lire, écrire, supprimer | Large |
Chiffrement en transit et au repos
Une API d'email sécurisée impose TLS 1.2 ou supérieur sur tous les points d'accès de l'API. Aucune communication en clair n'est acceptable. Au-delà du transit, tous les jetons ou identifiants qui doivent être conservés - les jetons de rafraîchissement OAuth, par exemple - doivent être chiffrés au repos à l'aide d'un chiffrement symétrique fort (AES-256). Tout aussi important : le contenu de l'email lui-même ne doit jamais être stocké au-delà de ce qui est requis par la requête. La lecture et l'affichage d'un email dans votre interface utilisateur ne nécessitent pas de conserver son corps dans votre base de données.
Risques de sécurité des API d'e-mail à éviter
La plupart des échecs de sécurité des intégrations de messagerie ne sont pas des attaques exotiques, mais des erreurs prévisibles dans la manière dont les informations d'identification, les jetons et les données sont gérés. Les quatre modèles ci-dessous expliquent la majorité des incidents réels dans les intégrations d'API de messagerie.
Demander aux utilisateurs d'entrer leur mot de passe d'e-mail et de le stocker - même chiffré - est le schéma le plus risqué en matière d'intégration d'e-mails. Cela fait de votre base de données une cible de grande valeur. Si un attaquant accède à votre magasin d'identifiants, il accède directement à la boîte de réception de chaque utilisateur. Au-delà du risque de sécurité, Google et Microsoft interdisent explicitement l'accès aux comptes Gmail et Outlook via mot de passe pour les applications tierces. IMAP avec mot de passe n'est acceptable que pour les serveurs de messagerie auto-hébergés ou hérités où OAuth n'est vraiment pas disponible.
Demande https://mail.google.com/ (accès complet à Gmail) lorsque vous n'avez besoin que de lire le dossier d'envoi d'un utilisateur est un anti-modèle de portée. Les portées larges augmentent la zone d'impact d'une compromission de jeton et érodent la confiance des utilisateurs lors de l'écran de consentement OAuth - les utilisateurs qui voient "lire, composer, envoyer et supprimer définitivement tous vos e-mails" ont raison d'hésiter. Google et Microsoft signalent désormais l'utilisation inutile de portées lors des examens d'applications.
Les jetons d'accès OAuth ont une durée de vie limitée par conception - généralement une heure pour Gmail et Outlook. Les jetons d'actualisation peuvent persister pendant des mois, voire indéfiniment. Si vous stockez des jetons d'actualisation sans stratégie de rotation, un jeton d'actualisation divulgué accorde un accès à long terme à la boîte aux lettres de l'utilisateur. Certaines intégrations mettent également en cache les jetons d'accès bien au-delà de leur expiration et ne parviennent pas à gérer les événements de révocation (lorsqu'un utilisateur supprime votre application de ses paramètres de compte Google ou Microsoft).
Les journaux d'application sont souvent moins protégés que les bases de données principales, conservés plus longtemps et répliqués sur plusieurs systèmes (agrégateurs de journaux, services de surveillance, pisteurs d'erreurs). La journalisation de corps d'e-mails complets, d'en-têtes contenant des données personnelles ou de listes de destinataires crée une exposition RGPD importante : vous traitez des données personnelles dans un contexte auquel l'utilisateur n'a jamais consenti et qu'il ne peut pas auditer. Les journaux d'erreurs qui incluent des réponses brutes d'API peuvent capturer involontairement des fils d'e-mails entiers.
Conformité RGPD pour les intégrations d'API d'e-mail
Les données de messagerie font partie des catégories de données personnelles les plus sensibles au titre du RGPD. Lorsque votre application accède à la boîte de réception d'un utilisateur via une API, vous devenez un sous-traitant de données. Cela crée des obligations légales concrètes en matière de résidence, de consentement et d'effacement que votre architecture d'API de messagerie doit prendre en charge.
Les données personnelles de l'UE doivent rester au sein de l'UE ou dans des pays disposant d'une décision d'adéquation. Votre infrastructure d'API d'e-mail doit proposer des points de terminaison hébergés dans l'UE.
Les utilisateurs doivent autoriser explicitement l'accès à leur boîte aux lettres. L'écran de consentement OAuth doit indiquer clairement quelles données seront accessibles et dans quel but.
Lorsqu'un utilisateur demande la suppression ou la déconnexion de son compte, tous les jetons associés, les données mises en cache et les données personnelles doivent être purgés dans les délais du RGPD.
Résidence des données
En vertu de l'article 44 du RGPD, le transfert de données personnelles en dehors de l'Espace économique européen nécessite soit une décision d'adéquation, des clauses contractuelles types (CCT), soit un autre mécanisme juridique valide. Pour les intégrations d'API d'e-mail desservant des utilisateurs de l'UE, l'infrastructure qui stocke les jetons OAuth, traite les métadonnées des e-mails ou met en cache le contenu des messages doit être hébergée dans l'UE. Choisir un fournisseur d'API sans options de résidence des données dans l'UE vous oblige à vous fier aux CCT et à une complexité de conformité supplémentaire. Pour les cas d'utilisation dans les domaines de la santé ou de la finance où des exigences similaires à la HIPAA s'appliquent, la résidence des données devient encore plus critique.
Votre fournisseur d'API d'e-mails est un sous-traitant au titre du RGPD. Vous devez avoir un accord de traitement des données (ATD) en place avec lui, et son infrastructure doit prendre en charge la résidence des données dans l'UE pour toutes les données d'utilisateurs de l'UE qu'il traite pour votre compte.
Flux de consentement de l'utilisateur
Le flux d'autorisation OAuth sert d'implémentation technique du consentement RGPD pour l'accès aux e-mails - mais uniquement s'il est correctement conçu. L'écran de consentement doit décrire avec précision ce à quoi l'application accédera, en langage clair. La demande de scopes au-delà de ce qui est décrit dans votre politique de confidentialité crée un écart de conformité. Les utilisateurs doivent également pouvoir terminer ce flux sans coercition : connecter leur compte de messagerie ne doit pas être une condition forcée pour accéder à votre service principal, sauf si l'accès aux e-mails est véritablement le service lui-même.
Droit à l'effacement - déconnexion du compte
L'article 17 du RGPD accorde aux utilisateurs le droit à l'effacement. Dans un contexte d'intégration d'e-mails, cela signifie que votre application doit pouvoir supprimer immédiatement et complètement toute trace d'accès d'un utilisateur à ses e-mails lorsqu'elle en fait la demande. Il ne s'agit pas seulement de supprimer le jeton OAuth, mais de couvrir tous les artefacts créés pendant la durée de vie de l'intégration.
Comment Unipile gère la sécurité des API d'e-mail
La sécurité n'est pas une fonctionnalité que l'on ajoute à Unipile – c'est le comportement par défaut de la plateforme. Unipile est spécialement conçu pour offrir une API d'envoi de courriels sécurisée, où l'authentification, la sécurité des données d'envoi de courriels et les contrôles de conformité sont intégrés par défaut – et non ajoutés après coup. Chaque décision architecturale concernant la façon dont Unipile se connecte aux comptes Gmail, Outlook et IMAP est prise en considérant la sécurité et la confidentialité des utilisateurs finaux comme la contrainte principale.
Unipile se connecte à Gmail via Google OAuth 2.0 et vers Outlook et Microsoft 365 via Microsoft OAuth 2.0. Vos utilisateurs s'authentifient directement via l'écran de consentement officiel du fournisseur. Aucun mot de passe ne transite par l'infrastructure d'Unipile. Pour les comptes IMAP où OAuth n'est pas disponible, les identifiants sont chiffrés au repos avec AES-256 et ne sont jamais exposés via une quelconque réponse d'API - y compris l' Guide de l'API IMAP couvre cette architecture en détail.
Unipile demande les scopes OAuth les plus restreints nécessaires aux fonctionnalités que votre application SaaS permet. Si votre intégration ne fait que lire les e-mails pour alimenter un flux d'activités CRM, Unipile demande des scopes en lecture seule. L'envoi de scopes est ajouté uniquement lorsque votre implémentation nécessite explicitement l'envoi. Cela réduit le rayon d'impact de tout problème de credential et rend l'écran de consentement OAuth de votre application simple à approuver pour les utilisateurs finaux.
Pour les équipes SaaS servant des clients de l'UE, Unipile propose des options d'infrastructure hébergées dans l'UE. Les jetons OAuth, les métadonnées de compte liés et toutes les données d'e-mail traitées de manière transitoire restent sous juridiction européenne. Cela vous permet de maintenir un enregistrement propre du traitement des données RGPD et de conclure un accord de traitement des données avec Unipile en tant que sous-traitant – une exigence légale en vertu de l'article 28 du RGPD pour tout sous-traitant traitant des données personnelles de l'UE en votre nom.
Unipile expose un point de terminaison DELETE pour les comptes liés. L'appeler révoque immédiatement le jeton OAuth au niveau du fournisseur, purge toutes les métadonnées associées de l'infrastructure d'Unipile et annule tous les abonnements webhook actifs. Cela vous offre un chemin d'accès propre, en un seul appel API, pour satisfaire les demandes d'exercice du droit à l'effacement du RGPD liées à l'accès par e-mail - aucun nettoyage manuel sur plusieurs tableaux de bord de fournisseurs requis.
Lisez la référence complète de l'API - flux d'authentification, gestion des jetons et sécurité des webhooks.
Certifications de conformité
Unipile est audité et certifié indépendamment selon les trois cadres de conformité les plus pertinents pour les intégrations sécurisées d'API d'e-mails : opérations de sécurité, protection des données et accès aux API Google.
Audité par un tiers indépendant. Couvre les critères de confiance en matière de sécurité, de disponibilité et de confidentialité sur l'infrastructure d'Unipile et#39;s.
Conformité totale avec les réglementations européennes sur la protection des données. Unipile agit en tant que sous-traitant des données. Toutes les données sont hébergées exclusivement dans l'UE. Contrat de traitement des données disponible sur demande.
Validation des contrôles de sécurité pour les applications accédant aux données utilisateur Google, y compris les scopes OAuth Gmail.
Lorsque vous construisez sur Unipile, votre intégration d'e-mail sécurisée bénéficie des mêmes contrôles de sécurité qui ont réussi ces audits. Ceci est particulièrement pertinent pour CASA Tier II : les applications construites sur une API d'e-mail sécurisée certifiée CASA peuvent maintenir leur propre statut de conformité sur l'ensemble de la chaîne d'intégration — sans audit séparé de la couche e-mail.
Liste de contrôle de sécurité pour l'intégration d'API d'e-mail
Utilisez cette liste de contrôle avant de déployer une intégration d'API d'e-mail en production. Tous les éléments doivent être validés avant que l'intégration ne soit considérée comme prête pour la production d'un point de vue sécurité.
OAuth 2.0, scopes minimaux, résidence des données dans l'UE, déconnexion instantanée du compte - le tout inclus dans une seule API d'e-mail sécurisée. Connectez Gmail, Outlook et IMAP avec un accès e-mail crypté et aucun stockage de mot de passe.
API de messagerie sécurisée - FAQ
Questions fréquentes sur la sécurité des API d'e-mail, OAuth et la conformité
IMAP peut être sécurisé, mais cela dépend entièrement de la mise en œuvre. Le protocole lui-même transmet les données via TLS lorsqu'il est correctement configuré, de sorte que la couche de transit n'est pas le problème. Le risque réside dans la manière dont les informations d'identification sont gérées. IMAP nécessite un nom d'utilisateur et un mot de passe – contrairement à Gmail et Outlook qui prennent en charge OAuth 2.0, IMAP n'a pas de norme d'autorisation déléguée. Cela signifie que votre application doit stocker ou récupérer le mot de passe de l'utilisateur chaque fois qu'elle se connecte. C'est gérable si les informations d'identification sont chiffrées au repos avec AES-256, si l'accès au magasin d'informations d'identification est strictement limité, et si les mots de passe ne sont jamais enregistrés ou exposés via les réponses d'API. Pour Gmail et Outlook, privilégiez toujours OAuth 2.0 par rapport à IMAP avec mot de passe – les deux fournisseurs l'exigent pour les applications tierces. IMAP avec mot de passe est approprié uniquement pour les serveurs de messagerie auto-hébergés ou les environnements d'entreprise hérités où OAuth n'est vraiment pas disponible. En savoir plus dans le Guide de l'API IMAP.
La conformité à la HIPAA d'une intégration d'API de messagerie est réalisable, mais nécessite une architecture soignée. L'HIPAA ne certifie pas les fournisseurs de messagerie, mais exige que tout système traitant des informations de santé protégées (PHI) mette en œuvre des mesures de protection techniques spécifiques : cryptage en transit et au repos, contrôles d'audit, contrôles d'accès et déconnexion automatique pour les sessions inactives. Pour une API de messagerie, cela signifie : utiliser OAuth 2.0 afin qu'aucun mot de passe ne soit stocké, s'assurer que les jetons et toutes les métadonnées mises en cache sont chiffrés au repos, ne jamais enregistrer le contenu des courriels susceptibles de contenir des PHI, et avoir un accord d'association commerciale (BAA) en place avec votre fournisseur d'API. Gmail et Outlook proposent tous deux des configurations éligibles à l'HIPAA dans le cadre des plans Google Workspace et Microsoft 365 Business respectivement, avec un BAA signé par le fournisseur. La couche API de votre messagerie doit également signer un BAA avec vous si elle traite ou transmet des PHI en votre nom. D'un point de vue pratique, la solution HIPAA la plus sûre consiste à traiter le contenu des courriels comme étant transitoire - le lire, le traiter, le faire apparaître - mais ne jamais conserver le corps du message ou les pièces jointes dans votre propre base de données.
Révoquer l'accès à l'e-mail d'un utilisateur implique deux actions distinctes qui doivent toutes deux se produire. D'abord, révoquez le jeton au niveau du fournisseur. Pour Gmail, appelez le point de terminaison de révocation de jeton de Google (https://oauth2.googleapis.com/revokePour Outlook, appelez le point de terminaison de révocation de Microsoft ou supprimez l'application du compte Microsoft de l'utilisateur. Supprimer simplement le jeton de votre base de données n'est pas suffisant - le jeton reste valide chez le fournisseur jusqu'à révocation explicite. Deuxièmement, purgez toutes les données locales. Supprimez le jeton de rafraîchissement, tous les jetons d'accès mis en cache, toutes les métadonnées d'e-mails que vous avez stockées pour ce compte lié, les abonnements aux webhooks et l'enregistrement du compte lié lui-même. Avec Unipile, un seul SUPPRIMER /comptes/{id} L'appel gère les deux étapes : il révoque le jeton auprès du fournisseur et nettoie simultanément toutes les données associées sur l'infrastructure d'Unipile.
La sécurité des e-mails fait généralement référence à la protection de la communication par e-mail elle-même - filtrage du spam, détection du phishing, authentification DKIM/SPF/DMARC et chiffrement du message pendant le transit entre les serveurs de messagerie. La sécurité des API d'e-mail est une couche entièrement différente : il s'agit de la manière dont une application tierce obtient un accès programmatique à la boîte aux lettres d'un utilisateur, des données qu'elle traite en conséquence et de la manière dont elle protège cet accès. Vous pouvez avoir une excellente sécurité des e-mails (DMARC configuré, TLS appliqué entre les serveurs) tout en ayant une mauvaise sécurité des API d'e-mail (mots de passe stockés en clair, étendues OAuth trop larges). Les deux sont importants indépendamment. Cet article se concentre sur la couche de sécurité des API - les décisions architecturales que votre équipe de développement prend lors de l'intégration avec Gmail, Outlook ou IMAP via une API.
Unipile ne stocke pas le contenu des e-mails de manière permanente. Lorsque votre application appelle l'API Unipile pour récupérer des e-mails, Unipile récupère les données du fournisseur (serveur Gmail, Outlook ou IMAP) en temps réel et les renvoie à votre application. Le corps des e-mails et les pièces jointes ne sont ni mis en cache ni stockés sur l'infrastructure d'Unipile au-delà de la durée de vie de la requête. Ce qu'Unipile stocke, ce sont le jeton OAuth (chiffré au repos) et les métadonnées de base du compte lié nécessaires pour maintenir la connexion – type de fournisseur, identifiant du compte et état de la connexion. Cette architecture signifie que le contenu des e-mails reste entre votre application et le fournisseur, Unipile agissant comme un courtier sécurisé plutôt qu'un système de stockage de données. Pour plus de détails sur la manière dont Unipile gère les données, veuillez vous référer à documentation développeur et demandez une DPA à l'équipe Unipile.
OAuth 2.0 améliore la sécurité de l'intégration de messagerie de quatre manières concrètes. Aucune exposition de données d'identification : Le mot de passe de l'utilisateur ne quitte jamais le serveur du fournisseur - votre application ne reçoit qu'un jeton d'accès de courte durée. Autorisations granulaires : Les champs d'application OAuth vous permettent de demander exactement l'accès dont vous avez besoin (lecture seule, envoi seul) plutôt qu'un contrôle complet de la boîte aux lettres. Révocabilité un utilisateur peut supprimer l'accès de votre application à tout moment depuis les paramètres de son compte Google ou Microsoft, sans changer son mot de passe, et le jeton devient immédiatement invalide. Jetons à courte durée de vie les jetons d'accès expirent (généralement après une heure), ce qui limite la fenêtre d'exposition en cas de compromission d'un jeton. Ces propriétés font d'OAuth 2.0 le seul mécanisme d'authentification acceptable pour les intégrations Gmail et Outlook dans les applications SaaS en production. Apprenez à l'implémenter pour Google OAuth 2.0 et Microsoft OAuth 2.0.
Vous avez encore des questions ? Notre équipe est là pour vous aider.
FR 
EN 
ES 
DE 
IT 
BR 
NL 
PL 
TR