Beveiliging van e-mail-API-sleutels: rechten, rotatie en opslag

Een e-mail-API-sleutel is een korte tekenreeks met veel macht. Wie hem heeft, kan mail versturen vanaf je domein, naar iedereen, onder jouw naam. Gelekte sleutels zijn een van de meest voorkomende manieren waarop phishingcampagnes uiteindelijk worden verstuurd via de infrastructuur van legitieme bedrijven.

Het goede nieuws: met een paar gewoontes maak je een lek onwaarschijnlijk, en beperk je de schade als het toch gebeurt. Deze gids behandelt ze, aan de hand van de instellingen die Inbixio voor elke sleutel biedt.

Wat een Inbixio-sleutel kan

Elke sleutel die je aanmaakt via API Keys → Create Api Key (API-sleutels → API-sleutel aanmaken) heeft drie instellingen:

• Name (naam), voor je eigen administratie, bijvoorbeeld prod-auth-service.
• Server Access (servertoegang): All Server (alle servers; verstuurt via de eerste SMTP-server die je hebt gekoppeld) of Selected Server (geselecteerde server; precies de server die je kiest).
• Permissions (rechten): Send (versturen), Read (lezen) en Manage (beheren). De API heeft momenteel één endpoint, e-mail versturen, dus Send is het recht dat je services nodig hebben.

Sleutels zien eruit als ibx_ gevolgd door 32 hexadecimale tekens. Door dat voorvoegsel zijn ze makkelijk te herkennen, ook voor secret scanners.

Regel 1: één sleutel per service en omgeving

Deel niet één sleutel binnen je hele bedrijf. Maak een aparte sleutel voor elke service, en voor elke omgeving:

Aparte sleutels betekenen:

• Een lek blijft beperkt. Als je prod-billing intrekt, vallen je inlogmails niet weg.
• Elke service verstuurt vanaf het juiste adres. Een sleutel die vastgezet is op de billing@-server verstuurt vanaf billing@, niet vanaf de server die je toevallig als eerste hebt gekoppeld. Verwijder je een vastgezette server, dan valt de sleutel terug op je eerste server, dus zet sleutels opnieuw vast wanneer je servers verwijdert.
• Rotatie is pijnloos. Je kunt de sleutel van één service vernieuwen zonder de andere aan te raken.

Regel 2: geef de minste rechten die volstaan

Een backend die e-mail verstuurt, heeft Send nodig en verder niets, dus laat Read en Manage uitgevinkt. Hoe minder een sleutel mag, hoe minder een lek kan kosten.

Regel 3: sleutels horen op servers, nooit in clients

Alles wat naar een browser of mobiele app gaat, kan worden uitgelezen, geminificeerd of niet. Dat geldt voor:

• JavaScript-bundels (React, Vue, Next.js-clientcomponenten),
• omgevingsvariabelen met een voorvoegsel voor de browser, zoals NEXT_PUBLIC_, VITE_ of REACT_APP_,
• iOS- en Android-appbestanden.

Moet een actie van een gebruiker in je frontend een e-mail triggeren, roep dan je eigen backend-endpoint aan. Je backend controleert of de gebruiker dat mag, past rate limits toe en roept pas daarna Inbixio aan met de sleutel die in zijn omgeving staat.

// ✅ 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
});

Regel 4: bewaar sleutels als wachtwoorden

• Zet sleutels in een secrets manager (AWS Secrets Manager, Google Secret Manager, Doppler, 1Password, Vault) of in de versleutelde omgevingsvariabelen van je platform.
• Commit ze nooit. Voeg .env toe aan .gitignore en zet secret scanning aan voor je repositories; de push protection van GitHub blokkeert veel lekken voordat ze gebeuren.
• Houd sleutels uit je logs. Log je uitgaande verzoeken, verwijder dan eerst de X-API-Key-header.
• Plak sleutels niet in tickets, chats of screenshots. Deel toegang tot het secret, niet de waarde ervan.

Regel 5: roteer volgens schema, en direct bij twijfel

Inbixio kan een sleutel vernieuwen: klik op het vernieuwicoon naast de sleutel op de pagina API Keys. Vernieuwen geeft een nieuwe waarde uit onder dezelfde naam, servertoegang en rechten, en de oude waarde werkt per direct niet meer. Zo roteer je een productiesleutel zonder mislukte verzendingen:

1. Maak een tweede sleutel met dezelfde instellingen (bijvoorbeeld prod-auth-2).
2. Deploy de nieuwe sleutel naar de service en controleer dat de verzoeken 200 teruggeven, bijvoorbeeld in de logs van je eigen applicatie.
3. Verwijder de oude sleutel.

Gebruik het vernieuwicoon wanneer snelheid belangrijker is dan een naadloze overdracht, zoals direct na een lek. Roteer routinesleutels om de paar maanden, en telkens wanneer iemand met toegang het team verlaat.

Als een sleutel lekt

Behandel het als een incident, maar wel een beheersbaar incident:

1. Vernieuw (vernieuwicoon) of verwijder de sleutel direct. Daarmee stopt elk gebruik van de oude waarde.
2. Controleer de logs op het dashboard op ongebruikelijke activiteit: aanroepen op vreemde tijdstippen of een piek in het volume. Het log toont wanneer aanroepen zijn gedaan, niet met welke sleutel, dus vergelijk het met de logs van je eigen services.
3. Kijk bij je mailprovider naar bounces of spamklachten door berichten die jij niet hebt verstuurd.
4. Zoek uit hoe het lek ontstond, via een commit, een logregel of een frontendbundel, en sluit die route af.
5. Informeer betrokken gebruikers als er berichten namens jou zijn verstuurd, zodat ze weten dat ze die kunnen negeren.

Een snelle checklist

• Eén sleutel per service en omgeving, met duidelijke namen
• Sleutels vastgezet op de server (het afzenderadres) die elke service moet gebruiken
• Alleen het recht Send voor services die versturen
• Geen sleutels in frontendcode, mobiele apps of repositories
• Sleutels opgeslagen in een secrets manager en weggefilterd uit logs
• Een rotatiedatum in de agenda, en een plan voor lekken

Beveiliging houdt je ook uit de spamfolder: berichten die via een gecompromitteerde sleutel worden verstuurd, beschadigen de reputatie van je domein. Combineer deze checklist met SPF, DKIM en DMARC voor het volledige plaatje.