31 oktober 2026 · 11 min leestijd · Door Michael van Mameren, Lead Penetration Tester (OSCP)
SaaS pentest: wat u test, wanneer een startup begint en wat enterpriseklanten zullen opvragen
Een SaaS-product draagt de gegevens van elke klant achter één codebase, één identiteitslaag en één cloudaccount. De kwetsbaarheden die ertoe doen, zijn die waarmee de ene tenant de andere kan zien, een gebruiker beheerder kan worden of een gelekt token het hele platform opent. Deze gids beschrijft wat een SaaS-penetratietest moet dekken, hoe een startup zijn eerste test plant en wat SOC 2-auditors en inkoopteams van enterprises daarna willen zien.
Waarom SaaS anders wordt getest
Een traditionele webapplicatietest behandelt de applicatie als grens: de aanvaller staat buiten, de gegevens staan binnen. Een SaaS-platform kent die grens niet. Elke klant is al binnen, ingelogd, en deelt dezelfde applicatieservers, databaseclusters, objectopslag en identity provider met elke andere klant. De beveiligingsvraag is daarom niet alleen of een buitenstaander binnenkomt, maar of een insider (een legitieme gebruiker van tenant A) iets van tenant B kan bereiken, binnen de eigen tenant rechten kan uitbreiden of de platformlaag kan bereiken die iedereen bedient. In onze ervaring zijn de bevindingen die in SaaS-omgevingen de meeste schade veroorzaken autorisatiefouten, geen injecties: een voorspelbare identifier, een ontbrekende tenantcontrole op één van vierhonderd endpoints, of een OAuth-flow die een redirect-URI vertrouwt die hij niet zou moeten vertrouwen.
Het tweede verschil is snelheid van verandering. SaaS-teams rollen doorlopend uit, dus het aanvalsoppervlak op het moment van een jaarlijkse test is niet het aanvalsoppervlak dat een klant zes maanden later gebruikt. Dat bepaalt hoe de test wordt gescopet (geef voorrang aan het autorisatiemodel en de gedeelde lagen, die het minst veranderen en het meest tellen) en hoe vaak hij wordt herhaald. Het derde verschil is dat het testresultaat zelf een producteis is: enterpriseklanten, SOC 2-auditors en cyberverzekeraars vragen ernaar, en een goed gescopet rapport is vaak wat de eerste grote deal sluit.
Het SaaS-aanvalsoppervlak: wat een test moet dekken
Zes gebieden, in de volgorde waarin wij ze doorgaans prioriteren. Elk gebied hoort bij een klasse van echte incidenten.
Multi-tenant-isolatie
Kan een gebruiker van de ene tenant gegevens van een andere lezen, wijzigen of verwijderen? Wij testen elk objecttype en elk endpoint met twee tenants en verwisselde identifiers, inclusief achtergrondtaken, exports, zoekindexen, webhooks en bestandsopslagpaden: de plekken waar isolatie het vaakst wordt vergeten.
Autorisatie en IDOR
Gebroken autorisatie op objectniveau (OWASP API Security Top 10 2023, API1) en op functieniveau (API5): een kijker die een beheerdersendpoint kan aanroepen, een lid dat de facturering kan wijzigen, een ID in een URL die nooit tegen de sessie wordt gecontroleerd. Hier komen de meeste kritieke SaaS-bevindingen vandaan.
SSO, OAuth en SAML
Enterpriseklanten eisen SSO, en SSO is waar één fout elke klant raakt. Wij testen de validatie van OAuth 2.0-redirect-URI's, de afhandeling van state en PKCE, tokenlevensduur en intrekking, SAML-handtekeningvalidatie en assertion-afhandeling, just-in-time provisioning en of een gebruiker een account kan koppelen aan een identity provider die hij niet beheert.
API-oppervlak
De publieke API, de interne API die de front-end gebruikt, mobiele API's, GraphQL-endpoints, webhooks en partnerkoppelingen. Rate limiting, mass assignment, overmatige gegevensblootstelling, geversioneerde endpoints die nooit zijn uitgefaseerd en API-sleutels met een bredere reikwijdte dan de interface toestaat.
CI/CD en toeleveringsketen
Geheimen in repositories en buildlogs, pipelinerechten waarmee een pull request productiecredentials bereikt, niet-vastgezette afhankelijkheden en containerbasisimages, en de route van een gecompromitteerde ontwikkelaarslaptop naar een productiedeployment. Gekoppeld aan de OWASP Top 10 CI/CD Security Risks.
Cloudconfiguratie
IAM-rollen en -policies, publiek leesbare storage buckets, blootstelling van de metadataservice vanuit de applicatielaag, te brede security groups, secrets managers, en of een server-side request forgery in de applicatie een route naar cloudcredentials wordt. Beoordeeld tegen de CIS Benchmarks voor AWS, Azure of Google Cloud.
Penetratietest, bug bounty en geautomatiseerd scannen voor een SaaS-bedrijf
De drie vullen elkaar aan. Ze verwarren is de meest voorkomende fout die wij in vroege beveiligingsprogramma's zien.
| Aspect | Penetratietest | Bug-bountyprogramma | Geautomatiseerd scannen (DAST/SAST/SCA) |
|---|---|---|---|
| Dekking | Systematisch, op een afgesproken scope en methodiek | Opportunistisch; onderzoekers testen wat hen interesseert | Breed maar ondiep; alleen bekende kwetsbaarheidsklassen |
| Autorisatie en tenantlogica | Kern van de test, met meerdere rollen en tenants | Soms gevonden, zelden volledig | Niet gevonden; scanners begrijpen uw datamodel niet |
| Bewijs voor auditors en klanten | Gedateerd, gescopet rapport met testers bij naam; geaccepteerd door SOC 2-auditors en inkoop | Niet geaccepteerd als vervanging; nuttig als ondersteunende maatregel | Ondersteunend bewijs voor doorlopende monitoring, geen pentest |
| Kostenmodel | Vaste scope, geoffreerd per opdracht of als retainer | Betaling per geldige bevinding plus platformkosten; onvoorspelbaar | Abonnement per tool |
| Wanneer het past | Vóór de eerste enterprisedeal, vóór SOC 2, jaarlijks en na grote wijzigingen | Na de eerste pentest, zodra de voor de hand liggende problemen zijn opgelost | Vanaf de eerste commit, in de pipeline |
Hoe een startup zijn eerste penetratietest plant
Het juiste moment wordt bepaald door klanten en auditors, niet alleen door de financieringsronde. Dit is de volgorde die voor de meeste B2B-SaaS-bedrijven werkt.
1. Pre-seed en seed: leg het fundament, koop nog geen pentest
In deze fase vindt een volledige penetratietest problemen die u over drie maanden wegrefactort. Zet afhankelijkheidsscanning en geheimdetectie in de pipeline, dwing MFA af op cloud-, broncode- en identity-provider-accounts, schrijf uw tenantisolatiemodel op en maak een dreigingsmodel van de authenticatie- en factureringsflows. Die stappen kosten weinig en maken de eerste echte test veel waardevoller.
2. Eerste enterpriseprospect of Series A: de eerste gescopete test
De aanleiding is meestal een beveiligingsvragenlijst van een prospect of het besluit om SOC 2 na te streven. Laat een grey-box-test uitvoeren op de webapplicatie en API met inloggegevens voor elke rol in minimaal twee tenants, plus een configuratiereview van het productiecloudaccount. Los de kritieke en hoge bevindingen op, laat hertesten, en u heeft een rapport en een attestatiebrief die u door de inkoopprocedure dragen.
3. SOC 2 Type II: maak het jaarlijks en koppel het aan verandering
Auditors verwachten een penetratietest binnen de observatieperiode en bewijs dat bevindingen zijn verholpen. Herhaal de test jaarlijks en na wezenlijke wijzigingen: een nieuwe authenticatiemethode, de lancering van een publieke API, een nieuwe cloudregio, een overname. Onze gids over de SOC 2 pentest beschrijft wat de auditor zal opvragen.
4. Schaal: doorlopend testen plus periodieke diepte
Zodra releases wekelijks zijn en het aantal applicaties groeit, stapt u over op een retainer voor doorlopend testen van de applicaties en API's, houdt u een jaarlijkse diepe opdracht voor de cloud- en identiteitslaag en overweegt u een bug-bountyprogramma zodra de voor de hand liggende problemen weg zijn. Voeg een red-team-oefening toe wanneer u een detectiecapaciteit heeft die het testen waard is.
Wat inkoopteams van enterprises en SOC 2-auditors opvragen
Houd dit gereed voordat de eerste beveiligingsvragenlijst binnenkomt. Het zijn dezelfde stukken die een SOC 2-auditor onder CC4.1 en CC7.1 zal opvragen.
- Een penetratietestrapport van de afgelopen twaalf maanden, of een samenvatting en attestatiebrief van het testbureau met de testers, de methodiek, de scope en de data
- Bewijs dat kritieke en hoge bevindingen zijn verholpen en hertest, met data
- Een scopeverklaring waaruit blijkt dat de test de productieapplicatie, de API's en het authenticatie- en autorisatiemodel dekte, en niet een stagingkopie van de marketingsite
- Kwalificaties van de testers (OSCP, OSWE, CREST) en hun onafhankelijkheid van uw engineeringteam
- De gevolgde methodiek: OWASP Web Security Testing Guide, OWASP API Security Top 10 2023, OWASP ASVS v5.0 als verificatiestandaard, NIST SP 800-115 voor het proces
- Uw beleid voor kwetsbaarheidsbeheer en hersteltermijnen per ernst, met de pentestbevindingen als bewijs dat het proces werkt
- Voor klanten in gereguleerde sectoren: of de test de maatregelen dekte die zij van u overnemen (versleuteling in rust en onderweg, logging, tenantisolatie, afgedwongen SSO)
- Standaardantwoorden op vragenlijsten in SIG- en CAIQ v4-formaat, zodat niet elke enterprisedeal het proces opnieuw start
Een SaaS-penetratietest goed scopen
Het scopinggesprek bepaalt het grootste deel van de waarde. Geef de testers inloggegevens voor elke rol in minimaal twee afzonderlijke tenants, inclusief een eigenaar of beheerder, een gewoon lid en de meest beperkte rol, zodat tenantisolatie en rechtengrenzen goed kunnen worden getest; een black-box-test van een SaaS-platform besteedt dagen aan verkenning en vindt een fractie van wat een test met inloggegevens vindt. Neem de publieke API en de interne API met hun documentatie op, de SSO-configuratie met een test-identity-provider, de mobiele applicatie als u die heeft, en leestoegang tot het productiecloudaccount voor een configuratiereview. Benoem wat buiten de scope valt (pagina's van de betaalverwerker, ingesloten widgets van derden) en spreek af hoe het testen verstoring van andere klanten voorkomt: een speciale testtenant in productie is meestal beter dan een stagingomgeving die ervan is afgedreven.
Vraag het testbureau hoe bevindingen worden geclassificeerd. CVSS v3.1 of v4.0 is standaard, maar een SaaS-bedrijf heeft ook een impactbeeld nodig: een bevinding van gemiddelde ernst die de gegevens van de ene tenant aan een andere blootstelt, is voor uw salespipeline een kritiek probleem, ongeacht de score. Spreek escalatie van kritieke bevindingen op dezelfde dag af en een hertestvenster, en vraag om een attestatiebrief als aparte oplevering naast het rapport.
Wat u in uw trust center publiceert
Enterpriseklanten verwachten steeds vaker een trust center: een pagina of portaal met uw certificeringen, beleid en testbewijs. Publiceer de attestatiebrief of een managementsamenvatting van de penetratietest (scope, data, methodiek, kwalificaties van de testers, aantal bevindingen per ernst, bevestiging van herstel), niet het volledige rapport. Het volledige rapport bevat reproductiestappen en architectuurdetails die een aanvaller helpen; deel het onder NDA met klanten die het nodig hebben, via de afgeschermde aanvraagflow van het trust center. Werk de samenvatting bij na elke test en na de hertest, zodat de gepubliceerde status de verholpen bevindingen weergeeft en niet het aanvankelijke aantal.
Combineer het testbewijs met uw SOC 2-rapport (afgeschermd), uw ISO 27001-certificaat als u dat heeft, uw lijst van subverwerkers, uw verklaring over dataresidentie en uw beleid voor responsible disclosure. Inkoopteams die dat alles op één plek vinden, keuren leveranciers sneller goed en stellen minder maatwerkvragen. Onze gids over hoe vaak u een pentest laat uitvoeren beschrijft een frequentie die u publiek kunt noemen en kunt volhouden.
Hoe HackersHub SaaS-platforms test
Onze SaaS-opdrachten worden geleid door OSCP-gecertificeerde testers die tien jaar ervaring hebben met het vinden van autorisatie- en isolatiefouten in multi-tenant-applicaties. Wij testen grey box, met rollen over meerdere tenants, volgens de OWASP Web Security Testing Guide en de OWASP API Security Top 10 2023, met een configuratiereview van het productiecloudaccount en, waar relevant, de CI/CD-pipeline. Elke bevinding bevat bewijs, een impactverklaring en concrete herstelaanwijzingen voor uw stack; kritieke bevindingen worden dezelfde dag geëscaleerd. U ontvangt het rapport, een hertest na herstel en een attestatiebrief ondertekend door de lead tester, waarop uw SOC 2-auditor en uw enterpriseklanten kunnen vertrouwen. Scope en inspanning worden na een scopinggesprek schriftelijk vastgelegd; wij publiceren geen prijzen. Voor bedrijven die wekelijks uitrollen, levert hetzelfde team doorlopend testen als retainer.
Veelgestelde vragen
Bereidt u zich voor op uw eerste enterprisedeal of SOC 2-audit?
Een scopinggesprek van 30 minuten bepaalt welke tenants, rollen, API's en cloudaccounts worden getest en wat uw auditor en klanten daarna moeten zien. U ontvangt een schriftelijke scope, OSCP-testers bij naam en de attestatievoorwaarden. Praat met een expert.