Tokendiefstal is een belangrijke oorzaak van SaaS-inbreuken. Ontdek waarom OAuth- en API-tokens vaak over het hoofd worden gezien en hoe beveiligingsteams de tokenhygiëne kunnen versterken om aanvallen te voorkomen.
De meeste bedrijven in 2025 vertrouwen op een hele reeks software-as-a-service (SaaS)-applicaties om hun activiteiten uit te voeren. De veiligheid van deze toepassingen is echter afhankelijk van kleine stukjes gegevens die tokens worden genoemd. Tokens, zoals OAuth-toegangstokens, API-sleutels en sessietokens, werken als sleutels voor deze toepassingen. Als een cybercrimineel er één in handen krijgt, kan hij of zij zonder veel moeite toegang krijgen tot relevante systemen.
Recente inbreuken op de beveiliging hebben aangetoond dat slechts één gestolen token multi-factor authenticatie (MFA) en andere beveiligingsmaatregelen kan omzeilen. In plaats van kwetsbaarheden rechtstreeks te misbruiken, maken aanvallers gebruik van tokendiefstal. Het is een beveiligingsprobleem dat aansluit bij het bredere probleem van de wildgroei van SaaS en de moeilijkheid om talloze integraties van derden te monitoren.
Recente schendingen waarbij tokendiefstal betrokken is
Veel gebeurtenissen uit de echte wereld laten ons zien hoe gestolen tokens beveiligingsinbreuken in SaaS-omgevingen kunnen veroorzaken:
1. Slack (januari 2023). Aanvallers stalen een aantal Slack-werknemerstokens en gebruikten deze om ongeautoriseerde toegang te krijgen tot de privé GitHub-codeopslagplaatsen van Slack. (Er zijn geen klantgegevens openbaar gemaakt, maar het was een duidelijke waarschuwing dat gestolen tokens interne veiligheidsbarrières kunnen ondermijnen.)
2. CircleCI (januari 2023). Door informatiestelende malware op de laptop van een ingenieur konden bedreigingsactoren sessietokens voor de systemen van CircleCI kapen. Deze tokens gaven de aanvallers dezelfde toegang als de gebruiker, zelfs als MFA aanwezig was, waardoor ze klantgeheimen van het CI-platform konden stelen.
3. Cloudflare/Okta (november 2023). Als gevolg van een inbreuk op de identiteitsprovider heeft Cloudflare ongeveer 5.000 inloggegevens gerouleerd. Eén niet-geroteerd API-token en enkele inloggegevens van een serviceaccount waren echter voldoende voor cybercriminelen om de Atlassian-omgeving van Cloudflare in gevaar te brengen. Dit incident liet zien hoe een enkel vergeten token een overigens grondige incidentreactie kan ondermijnen.
4. Salesloft/Drift (augustus 2025). De Drift-chatbot (eigendom van Salesloft) kreeg te maken met een inbreuk op de toeleveringsketen waardoor aanvallers OAuth-tokens konden verzamelen voor integraties zoals Salesforce en Google Workspace. Met behulp van deze gestolen tokens hadden ze toegang tot de SaaS-gegevens van honderden klantorganisaties. Door dit OAuth-tokenmisbruik konden de aanvallers lateraal toegang krijgen tot e-mails, bestanden en ondersteuningsrecords op verschillende platforms.
SaaS-wildgroei zorgt voor token-blinde vlekken
Waarom blijven deze op tokens gebaseerde inbreuken plaatsvinden?
Het probleem is groter dan welke app dan ook; het is een ecosysteemprobleem dat wordt aangewakkerd door het uitgebreide SaaS-gebruik en verborgen token-vertrouwensrelaties tussen apps.
Tegenwoordig maakt elke afdeling gebruik van SaaS-tools en integreert deze in verschillende systemen. Werknemers maken gebruik van meerdere clouddiensten van derden, en bedrijven beheren ongeveer 490 cloud-apps, waarvan er vele niet goedgekeurd zijn of niet goed beveiligd zijn.
Dit hoge gebruik van SaaS (vaak SaaS-wildgroei genoemd) betekent een explosie van OAuth-tokens, API-sleutels en app-verbindingen. Elke integratie introduceert een niet-menselijke identiteit (in wezen een referentie) die doorgaans niet zichtbaar is voor IT of wordt bijgehouden door traditionele oplossingen voor identiteitsbeheer.
Het algehele resultaat hiervan is een niet-beheerd aanvalsoppervlak. Een paar factoren dragen over het algemeen bij aan deze blinde vlek:
• Gebrek aan zichtbaarheid. Veel organisaties zijn niet op de hoogte van alle SaaS-apps en -integraties die hun medewerkers hebben ingeschakeld, of van wie ze hebben geautoriseerd. Schaduw-IT (werknemers die apps toevoegen zonder goedkeuring) floreert, en beveiligingsteams ontdekken mogelijk pas een OAuth-verbinding nadat deze een probleem heeft veroorzaakt.
• Geen goedkeuring of toezicht. Zonder een controleproces kunnen gebruikers apps zoals marketingplug-ins of productiviteitstools vrijelijk koppelen aan zakelijke SaaS-accounts. Deze apps van derden vragen vaak om brede machtigingen en krijgen deze ook, zelfs als ze maar tijdelijk nodig zijn. Ongecontroleerde en overbevoorrechte apps kunnen voor onbepaalde tijd verbonden blijven als niemand ze beoordeelt.
• Geen regelmatige monitoring. Zeer weinig bedrijven dwingen beveiligingsinstellingen af voor OAuth-integraties of bekijken deze verbindingen in realtime. Tokens hebben standaard zelden een korte levensduur of een strikt bereik, en organisaties beperken hun gebruik vaak niet per IP-adres of apparaat. Logboeken van SaaS-integraties worden mogelijk ook niet meegenomen in de beveiligingsmonitoring.
Waarom Legacy Security het tokenprobleem mist
Als zodanig hebben traditionele beveiligingstools dit probleem helemaal niet volledig kunnen oplossen.
Single sign-on (SSO) en multi-factor authenticatie beschermen gebruikersaanmeldingen, maar OAuth-tokens omzeilen deze controles. Ze bieden aanhoudend vertrouwen tussen apps zonder verdere verificatie.
Een token handelt namens een gebruiker of dienst zonder dat er een wachtwoord nodig is. Een aanvaller die een geldig token verkrijgt, heeft dus toegang tot de gegevens van de verbonden app alsof deze al zijn geverifieerd. Er is geen pop-up om MFA opnieuw te controleren wanneer een OAuth-token wordt gebruikt. Als gevolg hiervan zijn OAuth- en API-tokens, zonder speciaal toezicht, een achilleshiel geworden in SaaS-beveiliging. Andere oudere oplossingen, zoals beveiligingsmakelaars voor cloudtoegang, richten zich op verkeer van gebruiker naar app en monitoren deze app-naar-app-verbindingen niet.
Deze kloof heeft geleid tot de komst van dynamische SaaS-beveiligingsplatforms die tot doel hebben SaaS-integraties te ontdekken en te beveiligen te midden van de wildgroei van SaaS. Deze platforms proberen alle gebruikte apps, tokens en privileges van derden in kaart te brengen, waardoor de zichtbaarheid en controle terugkomt. Of het nu gaat om geautomatiseerde detectie (scannen op verbonden apps) of het afdwingen van beleid inzake OAuth-gebruik, het doel is om het SaaS-beveiligingsgat te dichten dat wordt gecreëerd door niet-gecontroleerde tokens.
Uiteindelijk kan elke organisatie, met of zonder nieuwe tools, betere symbolische hygiënepraktijken toepassen. Wat je niet kunt zien, kun je niet beschermen. De eerste stap is weten waar uw tokens en SaaS-integraties zich bevinden. De volgende is het controleren en monitoren ervan, zodat ze geen achterdeurtjes worden.
Token-hygiënechecklist
De volgende checklist kan worden gebruikt om het risico op tokencompromis te verminderen:
| Oefening | Actie | J/N |
|---|---|---|
| Onderhoud OAuth-app-inventaris | Ontdek en volg alle applicaties van derden die zijn verbonden met uw SaaS-accounts. Houd een bijgewerkte inventaris bij van OAuth-tokens, API-sleutels en integraties. Dit geeft inzicht in uw tokenvoetafdruk. | |
| App-goedkeuring afdwingen | Zet een controleproces op voor nieuwe SaaS-integraties. Vereis een beveiligingsbeoordeling of goedkeuring van de beheerder voordat medewerkers OAuth-toegang tot hun accounts verlenen. Dit beperkt niet-doorgelichte apps en zorgt ervoor dat elk uitgegeven token noodzakelijk is en bekende risico’s met zich meebrengt. | |
| Minste privilege-tokens | Beperk het bereik en de machtigingen van tokens tot het vereiste minimum. Vermijd het verlenen van al te brede toegang (“alles toestaan”) bij het autoriseren van een app. Als een app bijvoorbeeld alleen leestoegang nodig heeft, geef hem dan geen beheerdersrechten voor lezen en schrijven. Least privilege verkleint de impact als een token wordt gestolen. | |
| Roteer tokens regelmatig | Behandel tokens met een lange levensduur als verlopende inloggegevens. Configureer tokens zo dat ze na een korte periode verlopen, indien mogelijk, of trek ze periodiek in en geef ze opnieuw uit. Regelmatige rotatie (of een korte levensduur) betekent dat een gestolen token snel onbruikbaar wordt, waardoor de kans voor een aanvaller kleiner wordt. | |
| Verwijder of waarschuw voor ongebruikte tokens | Identificeer tokens en app-verbindingen die al weken of maanden niet zijn gebruikt. Ongebruikte tokens zijn latente bedreigingen. Trek ze in als ze niet nodig zijn. Implementeer waarschuwingen of rapporten voor slapende tokens, zodat deze proactief kunnen worden opgeschoond en voorkomen dat vergeten inloggegevens voor onbepaalde tijd blijven hangen. | |
| Bewaak de tokenactiviteit | Schakel logboekregistratie en monitoring in voor tokengebruik op al uw SaaS-platforms. Let op ongebruikelijke tokenactiviteiten, zoals een normaal ongebruikte integratie die plotseling grote gegevensverzoeken doet of toegang krijgt vanaf vreemde locaties. Stel waarschuwingen in voor afwijkingen in het tokengebruik (bijvoorbeeld een piek in API-aanroepen of gebruik van een token van een onbekend IP-adres). | |
| Integreer tokens in Offboarding | Wanneer werknemers vertrekken of wanneer een app van derden buiten gebruik wordt gesteld, zorg er dan voor dat hun tokens en toegangssleutels onmiddellijk worden ingetrokken. Maak van het intrekken van tokens een standaardstap bij het offboarden van gebruikers en het beheer van de app-levenscyclus. Dit voorkomt dat oude referenties blijven bestaan nadat ze niet langer nodig zijn. |
