Blog
Dit is hét lek waar je securitytest blind voor is
Vraag een willekeurige CIO of IT-manager wat de grootste securityrisico’s zijn en je hoort al snel termen als phishing, ransomware of misconfiguraties in de cloud. Maar bijna niemand noemt het risico van … trage software.
En toch is dat precies waar het vaak misgaat.
Securitytesten worden meestal netjes uitgevoerd. Er zijn functionele tests, er zijn pentests en er is hier en daar ook nog een performance test. Maar vrijwel nooit worden die in samenhang gedaan. En precies dat is een probleem. Dat betekent namelijk dat we niet weten hoe veilig software nog is wanneer de performance onder druk staat.
- Wat gebeurt er met je login-processen wanneer duizenden gebruikers tegelijk inloggen en de responstijd piekt?
- Hoe gedraagt een API zich als latency oploopt en time-outs ontstaan?
- Wat als load balancing ervoor zorgt dat verkeer ineens door een niet-getest pad gaat?
De meeste securitytests worden uitgevoerd in een ‘schone’ laboratoriumsituatie, vaak met een beperkt aantal gebruikers en een gezonde responstijd. Zodra de software wordt opgeschaald naar de echte wereld – met piekbelastingen, trage queries en haperende gebruikerservaring – ontstaan de gaten.
En daar zitten serieuze risico’s aan, denk bijvoorbeeld aan:
- Gebruikers die inloggen via alternatieve routes.
- Sessie-tokens die onbedoeld langer geldig blijven.
- Time-outs die leiden tot onvolledige validatie.
- Of simpelweg: ontwikkelaars die ‘tijdelijke’ shortcuts inbouwen om trage software bruikbaar te houden.
Het resultaat: een systeem dat er op papier veilig uitziet, maar in de praktijk openingen biedt waar kwaadwillenden met groot gemak zo doorheen lopen.
In dit blog laat ik zien hoe performanceproblemen security ondermijnen – en wat je hieraan kan doen.
De deur die wagenwijd openstaat naar datalekken
Software gedraagt zich op schaal anders dan in de testomgeving. Altijd. Toch worden de meeste securitytests uitgevoerd met … één gebruiker. Misschien twee. En heel soms met een handvol.
Maar de echte wereld werkt niet met één of een handvol gebruikers. Er loggen duizenden mensen tegelijk in op gangbare systemen. Daar draaien meerdere API’s tegelijk queries op dezelfde database. Daar ontstaan wachtrijen, time-outs en race conditions. En precies daar sluipen de gaten in je beveiliging.
Wat er daardoor allemaal kan gebeuren?
- Sessie-lekken: data van gebruiker A belandt per ongeluk in de sessie van gebruiker B.
- Lock timeouts: gelijktijdige transacties blokkeren elkaar, waarna foutafhandeling ‘tijdelijk’ wordt omzeild – met blijvende gevolgen.
- API-vervuiling: endpoints die perfect geïsoleerd leken, blijken in de praktijk toch afhankelijkheden te hebben.
- Timing attacks: kleine vertragingen geven hackers net genoeg informatie om validaties te omzeilen.
Het verraderlijke is: dit soort problemen duiken pas op als software onder druk staat. In je pentest-rapport of QA-dossier ziet alles er keurig uit. Maar zodra de belasting piekt – door schaal, groei, of onverwachte piekbelasting – open je de deur naar datalekken en misbruik.
De realiteit: software die veilig lijkt in een laboratoriumsituatie, kan gevaarlijk zijn zodra deze écht wordt gebruikt. Het is alsof je een brug test met één auto en daarna verwacht dat hij ook vrachtwagens en files moeiteloos aan kan.
Wie schaal niet test, test veiligheid eigenlijk helemaal niet.
Aanvallers zijn dol op containers
Containers hebben de wereld veroverd. Ze zijn flexibel, schaalbaar en lijken de perfecte oplossing voor moderne applicaties. Van tien naar honderd instances opschalen kost je tegenwoordig slechts een paar regels configuratie. Maar … met die flexibiliteit komt een risico dat veel bedrijven onderschatten: veiligheid.
Nu kan je denken: “jij ziet ook achter iedere boom een beer staan.”
Ik zeg je: we moeten alle beren zien te vinden als je je security echt serieus neemt.
Want hoe stabiel – en dus veilig – blijft je applicatie als honderd containers tegelijk moeten samenwerken? Het antwoord: veel minder stabiel dan je wellicht denkt.
Neem sessies. Wanneer een gebruiker door een load balancer naar een andere container wordt gestuurd, moet zijn volledige sessie – inclusief alle data en rechten – meeverhuizen. Maar waar wordt die sessie eigenlijk beheerd? Hoe betrouwbaar is die overdracht? En wat gebeurt er als dezelfde gebruiker meerdere sessies opent die op verschillende containers landen?
Daar komt nog iets bij: locking. In een ideale wereld praten containers netjes met elkaar en voorkomen ze dat transacties door elkaar heen lopen. In de praktijk loopt dit vaak mis. Met als resultaat: race conditions, onvolledige validaties en in het ergste geval datalekken.
En hoe meer containers je toevoegt, hoe groter de kans dat er iets knapt. Eén container die een sessie verkeerd afhandelt is al een probleem. Honderd containers die allemaal kans hebben op dat probleem is een nachtmerrie. Zeker wanneer dit scenario nooit getest is.
Containers zijn briljant om snel te groeien. Maar als je securitytests niet meegroeien met die schaal, creëer je precies het soort gaten waar aanvallers op wachten.
De conclusie is simpel: wie containers zonder stress-testen opschaalt, schaalt zijn risico’s net zo hard mee.
Hoe performancefouten je security exposen
Iedereen kent het wel: een applicatie loopt vast, de gebruiker krijgt een foutmelding in beeld en probeert het opnieuw. Voor de gebruiker een frustratie. Voor een aanvaller een goudmijn.
Want wat staat er eigenlijk in die foutmelding?
Bij functionele tests worden foutmeldingen vaak netjes gecontroleerd. Securitytests doen dat meestal ook. Maar zodra het om performance gaat, kijkt men alleen naar het aantal time-outs of mislukte requests. Niet naar de inhoud van die foutmeldingen.
En daar gaat het mis.
Performancefouten geven vaak méér prijs dan je lief is. Een vertraagde query die niet meer reageert, kan zomaar een interne exception tonen. Een time-out kan laten zien onder welke databasegebruiker de query draaide. Of welke module en functie er crashte. Soms zelfs met parameters erbij. Allemaal bedoeld voor ontwikkelaars, zodat ze het probleem snel kunnen oplossen.
Maar voor kwaadwillenden zijn dit routekaarten. Ze leren zo welke interne architectuur je hebt, welke onderdelen zwak zijn, welke accounts toegang hebben en hoe de dataflow in elkaar steekt. Precies de informatie die nodig is om een volgende aanval te plannen.
Het wrange: dit soort fouten ontstaan niet bij één gebruiker die rustig doorklikt in een testomgeving. Ze ontstaan pas bij échte belasting. Wanneer honderden gebruikers tegelijk inloggen. Wanneer een API overloopt. Wanneer het systeem traag wordt en gaat haperen.
Met andere woorden: zolang je alleen in ‘happy flow’-situaties test, hou je deze lekken volledig buiten beeld. Totdat een hacker ze voor je vindt.
Conclusie: slechte performance is niet alleen een gebruiksprobleem. Het is een directe uitnodiging aan indringers.
Het is nu tijd voor actie.
Op papier is bijna elke applicatie veilig. In het lab ook. Maar met honderden gebruikers, piekbelasting en trage responstijden ontstaan de gaten.
De vraag is dus niet: is mijn software veilig?
De vraag is: hoe onveilig is mijn software op schaal?
Als je dit wil weten, als je wil weten hoe onveilig jouw software op schaal is, maak dan een afspraak. De eerste afspraak is altijd gratis maar nooit voor niks. Samen kijken we waar in jouw organisatie de verborgen risico’s liggen en hoe je die oplost voordat ze jou (en je data) duur komen te staan.
👉 Boek nu je gesprek. Want veilig zijn op schaal is geen luxe, maar een voorwaarde.