LinkedIn
Instagram
WhatsApp
Telegram
Google Agenda
Word lid van de Slack-gemeenschapBouw e-mailintegraties waar uw gebruikers van kunnen profiteren vertrouwen
Het verbinden met de inboxen van je gebruikers brengt reële beveiligingsrisico's met zich mee. Opgeslagen wachtwoorden, te brede OAuth-bereiken en niet-geroteerde tokens creëren allemaal aanvalsoppervlakken die het vertrouwen van gebruikers schaden en de AVG schenden.
Unipile E-mail API-handleiding bespreekt het volledige integratiebeeld. Dit artikel richt zich op de beveiligingslaag: wat een veilige e-mail API moet garanderen, welke risico's te vermijden, en hoe Unipile is ontworpen om de gegevens van uw gebruikers te beschermen.
Gmail
Outlook
IMAP
Wat maakt een e-mail-API "veilig"?
Beveiliging in een e-mail API is geen individuele functie. Het is een architecturale keuze die authenticatie, autorisatie, gegevensverwerking en infrastructuur omvat. Een veilige e-mail API moet vier dingen tegelijk garanderen.
Gebruikers autoriseren toegang via de officiële OAuth-workflow van hun provider. Er verlaat nooit een wachtwoord de server van de provider of komt terecht in jullie database.
Elke gekoppelde account vraagt alleen om de machtigingen die hij daadwerkelijk nodig heeft - alleen-lezen wanneer er geen verzending nodig is, alleen verzenden wanneer dit expliciet nodig is.
Alle API-verkeer gebruikt TLS 1.2+. Opgeslagen tokens worden versleuteld opgeslagen met AES-256. E-mailinhoud wordt nooit langer bewaard dan de levenscyclus van de aanvraag.
OAuth 2.0 versus het opslaan van een wachtwoord
De meest fundamentele beveiligingsbeslissing bij elke e-mailintegratie is hoe u authenticatie uitvoert. Veel oudere IMAP-integraties vragen gebruikers om hun e-mailwachtwoord in te voeren en deze op te slaan. Deze aanpak creëert een enkel storingspunt: één databreach stelt de inbox van elke gebruiker bloot. OAuth 2.0 elimineert dit volledig. Zie hoe Google OAuth 2.0 en Microsoft OAuth 2.0 implementeer deze flow.
Token-scopes: alleen-lezen versus verzenden
OAuth-scopes bepalen precies wat uw applicatie kan doen met het postvak van een gebruiker. Het aanvragen van brede scopes wanneer specifiekere voldoende zouden zijn, is een ernstig beveiligings-anti-patroon. Voor een CRM dat alleen e-mails leest om activiteiten te loggen, is het aanvragen van gmail-aanpassen is onnodig en stelt gebruikers bloot aan groter risico als uw token kwetsbaar is. Als uw toepassing moet e-mail Verzenden API aanvragen, vindt u ook een volledige uitsplitsing van de vereiste scopes per provider in onze send email API-handleiding.
| Reikwijdte | Provider | Wat het toestaat | Risiconiveau |
|---|---|---|---|
| gmail.alleenlezen | Gmail | E-mails lezen | Minimaal |
| gmail.verzenden | Gmail | Verzenden namens gebruiker | Gedekt |
| Mail.lezen | Outlook | E-mails lezen | Minimaal |
| Mail.verzenden | Outlook | Verzenden namens gebruiker | Gedekt |
| https://mail.google.com/ | Gmail | Volledige toegang tot mailbox | Breed |
| Mail.ReadWrite | Outlook | Lezen, schrijven, verwijderen | Breed |
Encryptie onderweg en in rust
Een veilige e-mail API vereist TLS 1.2 of hoger op alle API-eindpunten. Geen platte tekst communicatie is acceptabel. Naast de transit, moeten alle tokens of referenties die moeten worden opgeslagen - bijvoorbeeld OAuth refresh tokens - versleuteld worden opgeslagen, gebruikmakend van een sterke symmetrische cipher (AES-256). Even belangrijk: de inhoud van de e-mail zelf mag nooit langer worden opgeslagen dan wat de aanvraag vereist. Het lezen en tonen van een e-mail in uw UI vereist niet het opslaan van de body ervan in uw database.
E-mail API-beveiligingsrisico's om te vermijden
De meeste beveiligingsproblemen bij e-mailintegratie zijn geen exotische aanvallen - het zijn voorspelbare fouten in de manier waarop inloggegevens, tokens en gegevens worden behandeld. De vier onderstaande patronen zijn verantwoordelijk voor de meerderheid van de incidenten in de praktijk bij integratie van e-mail-API's.
Gebruikers vragen om hun e-mailwachtwoord in te voeren en deze op te slaan - zelfs versleuteld - is het patroon met het hoogste risico bij e-mailintegratie. Het maakt uw database tot een waardevol doelwit. Als een aanvaller toegang krijgt tot uw gegevensopslag voor inloggegevens, krijgt hij directe toegang tot de inbox van elke gebruiker. Naast het beveiligingsrisico verbieden Google en Microsoft expliciet toegang op basis van wachtwoorden tot Gmail- en Outlook-accounts voor apps van derden. IMAP met wachtwoord is alleen acceptabel voor zelf-gehoste of oude mailservers waarbij OAuth werkelijk niet beschikbaar is.
Aanvraag https://mail.google.com/ (volledige Gmail-toegang) wanneer u alleen de postvak IN van de gebruiker hoeft te lezen, is een anti-patroon voor de reikwijdte. Brede reikwijdtes vergroten het aangetaste gebied van een tokencompromis en ondermijnen het vertrouwen van de gebruiker tijdens het OAuth-verleningsscherm - gebruikers die "al uw e-mail lezen, opstellen, verzenden en permanent verwijderen" zien, aarzelen terecht. Zowel Google als Microsoft markeren nu onnodig bereikgebruik tijdens app-beoordelingen.
OAuth-toegangstokens zijn ontworpen om kortstondig te zijn - meestal één uur voor Gmail en Outlook. Vernieuwingstokens kunnen maanden of zelfs onbeperkt blijven bestaan. Als u vernieuwingstokens opslaat zonder een rotatiestrategie, geeft een gelekt vernieuwingstoken langdurige toegang tot de mailbox van de gebruiker. Sommige integraties slaan ook toegangstokens op die lang na de vervaldatum worden gebruikt en falen bij het verwerken van intrekkingsevenementen (wanneer een gebruiker uw app verwijdert uit hun Google- of Microsoft-accountinstellingen).
Toepassingslogs zijn vaak minder goed beschermd dan primaire databases, worden langer bewaard en gerepliceerd naar meerdere systemen (log aggregators, monitoring services, error trackers). Het loggen van volledige e-mail body's, headers met persoonlijke gegevens of ontvangerslijsten creëert een aanzienlijke GDPR-blootstelling: je verwerkt persoonlijke gegevens in een context waar de gebruiker nooit toestemming voor heeft gegeven en die je niet kunt controleren. Foutlogs die onbewerkte API reacties bevatten kunnen onbedoeld hele e-mail threads vastleggen.
AVG-naleving voor API-integraties via e-mail
E-mailgegevens behoren tot de meest gevoelige categorieën van persoonsgegevens onder de AVG. Wanneer uw toepassing via een API toegang krijgt tot de inbox van een gebruiker, wordt u een gegevensverwerker. Dat brengt concrete wettelijke verplichtingen met zich mee rond residentie, toestemming en verwijdering die uw e-mail-API-architectuur moet ondersteunen.
EU-persoonsgegevens moeten binnen de EU blijven of in landen met een adequaatheidsbesluit. Uw e-mail-API-infrastructuur moet endpointen bieden die in de EU worden gehost.
Gebruikers moeten expliciet toestemming geven voor toegang tot hun postvak. Het OAuth-verklaringenscherm moet duidelijk aangeven welke gegevens worden geraadpleegd en met welk doel.
Wanneer een gebruiker de verwijdering aanvraagt of zijn account verbreekt, moeten alle bijbehorende tokens, gecachte gegevens en persoonlijke gegevens worden verwijderd binnen de GDPR-termijnen.
Gegevensresidentie
Volgens GDPR artikel 44 vereist de overdracht van persoonsgegevens buiten de Europese Economische Ruimte een adequaatheidsbesluit, standaard contractuele bepalingen (SCC's) of een ander geldig rechtsmiddel. Voor e-mail API-integraties die EU-gebruikers bedienen, moet de infrastructuur die OAuth-tokens opslaat, e-mail metadata verwerkt of berichteninhoud cachet, in de EU worden gehost. Het kiezen van een API-provider zonder opties voor data-residentie in de EU dwingt u om te vertrouwen op SCC's en extra compliance-overhead. Voor zorg- of financiële use cases waarbij HIPAA-gerelateerde vereisten van toepassing zijn, wordt data-residentie nog kritischer.
Uw e-mail API-provider is een sub-verwerker onder de AVG. U moet een Verwerkersovereenkomst (DPA) met hen hebben gesloten, en hun infrastructuur moet EU-gegevenssoevereiniteit ondersteunen voor alle EU-gebruikersgegevens die zij namens u verwerken.
Gebruikers toestemmingsstroom
De OAuth-autorisatiestroom dient als de technische implementatie van GDPR-toestemming voor e-mailtoegang - maar alleen als deze correct is ontworpen. Het toestemmingsscherm moet in duidelijke taal nauwkeurig beschrijven waarop de applicatie toegang krijgt. Het aanvragen van scopes die verder gaan dan wat uw privacybeleid beschrijft, creëert een compliance-kloof. Gebruikers moeten deze stroom ook zonder dwang kunnen voltooien: het verbinden van hun e-mailaccount mag geen verplichte voorwaarde zijn voor toegang tot uw kernservice, tenzij e-mailtoegang daadwerkelijk de service zelf is.
Recht op verwijdering - ontkoppeling van account
Artikel 17 van de AVG verleent gebruikers het recht op vergetelheid. In de context van een e-mailintegratie betekent dit dat uw applicatie alle sporen van de e-mailtoegang van een gebruiker onmiddellijk en volledig moet kunnen verwijderen wanneer daarom wordt verzocht. Dit gaat niet alleen over het verwijderen van de OAuth-token - het omvat elk artefact dat tijdens de levensduur van de integratie is gemaakt.
Hoe Unipile E-mail API-beveiliging aanpakt
Beveiliging is geen functie die u aan Unipile toevoegt - het is het standaardgedrag van het platform. Unipile is speciaal gebouwd om een veilige e-mail-API te leveren waarbij authenticatie, beveiliging van e-mailgegevens en nalevingscontroles standaard zijn ingebouwd - niet achteraf toegevoegd. Elke architecturale beslissing over hoe Unipile verbinding maakt met Gmail-, Outlook- en IMAP-accounts wordt genomen met de beveiliging en privacy van eindgebruikers als de belangrijkste beperking.
Unipile maakt verbinding met Gmail via Google OAuth 2.0 en naar Outlook en Microsoft 365 via Microsoft OAuth 2.0. Uw gebruikers authenticeren rechtstreeks via het officiële toestemmingsscherm van de provider. Er gaat nooit een wachtwoord door de infrastructuur van Unipile. Voor IMAP-accounts waar OAuth niet beschikbaar is, worden inloggegevens versleuteld opgeslagen met AES-256 en worden ze nooit blootgesteld via enige API-respons - inclusief de IMAP API-gids dekt deze architectuur in detail.
Unipile vraagt de smalste OAuth-scopes die nodig zijn voor de functionaliteit die uw SaaS-applicatie mogelijk maakt. Als uw integratie alleen e-mails leest om een CRM-activiteitenfeed te vullen, vraagt Unipile scopes voor alleen-lezen. Verzendbereik wordt alleen toegevoegd wanneer uw implementatie expliciet verzenden vereist. Dit vermindert het "blast radius" -effect van problemen met inloggegevens en maakt het OAuth-toestemmingsscherm van uw app eenvoudig en duidelijk voor eindgebruikers om goed te keuren.
Voor SaaS-teams die EU-klanten bedienen, biedt Unipile infrastructuuropties die binnen de EU worden gehost. OAuth-tokens, metadata van gekoppelde accounts en alle tijdelijk verwerkte e-mailgegevens blijven binnen de EU-soevereiniteit. Hierdoor kunt u een schone GDPR-gegevensverwerkingsregistratie bijhouden en een Verwerkersovereenkomst aangaan met Unipile als uw sub-verwerker - een wettelijke vereiste onder GDPR Artikel 28 voor elke verwerker die namens u EU-persoonsgegevens verwerkt.
Unipile biedt een DELETE-eindpunt voor gekoppelde accounts. Door dit aan te roepen, wordt de OAuth-token direct op providerniveau ingetrokken, worden alle gerelateerde metadata uit de infrastructuur van Unipile verwijderd en worden actieve webhookabonnementen geannuleerd. Dit biedt een schone, enkelvoudige API-call om te voldoen aan GDPR-verzoeken tot verwijdering met betrekking tot e-mailtoegang - geen handmatige opschoning in meerdere providerdashboards nodig.
Lees de volledige API-referentie - authenticatiestromen, tokenbeheer en webhookbeveiliging.
Nalevingcertificeringen
Unipile wordt onafhankelijk gecontroleerd en gecertificeerd volgens de drie compliancekaders die het meest relevant zijn voor veilige API-integraties voor e-mail: beveiligingsoperaties, gegevensbescherming en toegang tot Google API's.
Gecontroleerd door een onafhankelijke derde partij. Behandelt beveiligings-, beschikbaarheids- en vertrouwelijkheidscriteria voor vertrouwensdiensten op de infrastructuur van Unipile's.
Volledige naleving van de EU-regelgeving inzake gegevensbescherming. Unipile treedt op als gegevensverwerker. Alle gegevens worden uitsluitend in de EU gehost. DPA beschikbaar op aanvraag.
Google Cloud-applicatiebeveiligingsbeoordeling. Valideert beveiligingscontroles voor applicaties die toegang hebben tot Google-gebruikersgegevens, inclusief Gmail OAuth-scopes.
Wanneer u bouwt op Unipile, profiteert uw veilige e-mailintegratie van dezelfde beveiligingscontroles die deze audits hebben doorstaan. Dit is met name relevant voor CASA Tier II: apps die bovenop een CASA-gecertificeerde beveiligde e-mail-API zijn gebouwd, kunnen hun eigen compliance-status behouden over de gehele integratieketen – zonder een aparte audit van de e-maillaag.
Veiligheidschecklist voor E-mail API Integratie
Gebruik deze checklist voordat u e-mail API-integraties naar productie verzendt. Alle items moeten worden gevalideerd voordat de integratie vanuit beveiligingsperspectief als productieklaar kan worden beschouwd.
OAuth 2.0, minimale scopes, EU data residentie, directe accountontkoppeling - allemaal inbegrepen in één veilige e-mail-API. Koppel Gmail, Outlook en IMAP met versleutelde e-mailtoegang en zonder wachtwoordopslag.
Veilige E-mail API - Veelgestelde Vragen
Veelgestelde vragen over beveiliging van e-mail API's, OAuth en naleving
IMAP kan veilig zijn, maar het hangt volledig af van de implementatie. Het protocol zelf verzendt data over TLS wanneer correct geconfigureerd, dus de transitlaag is niet het probleem. Het risico zit in de manier waarop inloggegevens worden beheerd. IMAP vereist een gebruikersnaam en wachtwoord - in tegenstelling tot Gmail en Outlook die OAuth 2.0 ondersteunen, heeft IMAP geen gestandaardiseerde gedelegeerde autorisatie. Dit betekent dat uw applicatie het wachtwoord van de gebruiker moet opslaan of ophalen telkens wanneer er verbinding wordt gemaakt. Dat is beheersbaar als inloggegevens versleuteld zijn opgeslagen met AES-256, de toegang tot de inloggegevensopslag strikt is beperkt, en wachtwoorden nooit worden gelogd of blootgelegd via API-reacties. Voor Gmail en Outlook, geef altijd de voorkeur aan OAuth 2.0 boven IMAP met wachtwoord - beide providers vereisen dit voor applicaties van derden. IMAP met wachtwoord is alleen geschikt voor zelf-gehoste mailservers of verouderde bedrijfsomgevingen waar OAuth werkelijk niet beschikbaar is. Lees meer in de IMAP API-gids.
HIPAA compliance voor een e-mail API integratie is haalbaar, maar vereist een zorgvuldige architectuur. HIPAA certificeert geen e-mailproviders, maar vereist dat elk systeem dat omgaat met beschermde gezondheidsinformatie (PHI) specifieke technische beveiligingen implementeert: encryptie bij doorgifte en in rust, auditcontroles, toegangscontroles en automatisch afmelden voor inactieve sessies. Voor een e-mail-API betekent dit: OAuth 2.0 gebruiken zodat er geen wachtwoorden worden opgeslagen, ervoor zorgen dat tokens en metadata in de cache in rust worden versleuteld, nooit e-mailinhoud loggen die mogelijk PHI bevat en een Business Associate Agreement (BAA) hebben met uw API-provider. Gmail en Outlook bieden beide configuraties die in aanmerking komen voor HIPAA onder respectievelijk Google Workspace en Microsoft 365 Business-plannen, met een ondertekende BAA van de provider. Uw e-mail API-laag moet ook een BAA met u ondertekenen als het PHI namens u verwerkt of verzendt. Vanuit praktisch oogpunt is het veiligste HIPAA-pad om e-mailcontent als tijdelijk te behandelen - lees het, verwerk het, geef het weer - maar bewaar nooit de body of bijlagen in uw eigen database.
Het intrekken van de toegang tot het e-mailadres van een gebruiker omvat twee afzonderlijke acties die beide moeten plaatsvinden. Herroep eerst de token op provider niveau. Voor Gmail, bel Google's token intrekking endpointhttps://oauth2.googleapis.com/revoke. Voor Outlook, bel Microsofts intrekkings-endpoint of verwijder de app uit het Microsoft-account van de gebruiker. Het simpelweg verwijderen van de token uit uw database is niet voldoende - de token blijft geldig bij de provider totdat deze expliciet wordt ingetrokken. Vervolgens, wis alle lokale gegevens. Verwijder de refresh token, alle gecachte access tokens, alle e-mailmetadata die u hebt opgeslagen voor dat gekoppelde account, webhookabonnementen en het gekoppelde accountrecord zelf. Met Unipile, een enkele VERWIJDEREN /accounts/{id} de aanroep voert beide stappen uit: het annuleert de token bij de provider en ruimt alle bijbehorende gegevens op de infrastructuur van Unipile tegelijkertijd op.
E-mailbeveiliging verwijst doorgaans naar de bescherming van de e-mailcommunicatie zelf: spamfiltering, phishingdetectie, DKIM/SPF/DMARC-authenticatie en versleuteling van het bericht tijdens verzending tussen mailservers. E-mail-API-beveiliging is een heel andere laag: het gaat erom hoe een applicatie van derden programmatisch toegang krijgt tot de mailbox van een gebruiker, welke gegevens het daarbij verwerkt en hoe het die toegang beschermt. Je kunt uitstekende e-mailbeveiliging hebben (DMARC geconfigureerd, TLS afgedwongen tussen servers) terwijl je slechte e-mail-API-beveiliging hebt (wachtwoorden opgeslagen in platte tekst, te brede OAuth-scopes). Beide zijn onafhankelijk van elkaar belangrijk. Dit artikel richt zich op de API-beveiligingslaag: de architecturale beslissingen die uw ontwikkelingsteam neemt bij het integreren met Gmail, Outlook of IMAP via een API.
Unipile slaat e-mailinhoud niet permanent op. Wanneer uw applicatie de Unipile API aanroept om e-mails op te halen, haalt Unipile de gegevens in realtime op bij de provider (Gmail, Outlook of IMAP-server) en retourneert deze aan uw applicatie. E-mailteksten en bijlagen worden niet opgeslagen in de cache of op de infrastructuur van Unipile buiten de levenscyclus van het verzoek. Wat Unipile wel opslaat, is de OAuth-token (versleuteld tijdens opslag) en basiskoppelingen aan accountmetadata die nodig zijn om de verbinding te onderhouden - provider type, account-identificatie en verbindingsstatus. Deze architectuur betekent dat de e-mailinhoud tussen uw applicatie en de provider blijft, waarbij Unipile fungeert als de veilige tussenpersoon in plaats van een gegevensopslag. Raadpleeg voor volledige details over hoe Unipile gegevens verwerkt de ontwikkelaarsdocumentatie en vraag een DPA aan bij het Unipile-team.
OAuth 2.0 verbetert de beveiliging van e-mailintegratie op vier concrete manieren. Geen blootstelling van inloggegevens het wachtwoord van de gebruiker verlaat nooit de server van de provider - uw applicatie ontvangt alleen een kortstondige toegangstoken. Gedetailleerde machtigingen OAuth-scopes laten u precies de benodigde toegang aanvragen (alleen lezen, alleen verzenden) in plaats van volledige controle over de mailbox. Herroepbaarheid Een gebruiker kan op elk moment de toegang van uw applicatie verwijderen uit de instellingen van hun Google- of Microsoft-account, zonder hun wachtwoord te wijzigen, en de token wordt onmiddellijk ongeldig. Kortstondige tokens: access tokens verlopen (meestal na een uur), wat de blootstelling beperkt als een token gecompromitteerd raakt. Deze eigenschappen maken OAuth 2.0 het enige acceptabele authenticatiemechanisme voor Gmail- en Outlook-integraties in productie SaaS-applicaties. Leer hoe u dit implementeert voor Google OAuth 2.0 en Microsoft OAuth 2.0.
Heb je nog vragen? Ons team staat klaar om te helpen.
NL 
EN 
FR 
ES 
DE 
IT 
BR 
PL 
TR