Wat een pentester in uw applicatie onderzoekt
Een pentest van een bedrijfsapplicatie gaat verder dan een scan op bekende kwetsbaarheden. We testen met echte gebruikersaccounts in verschillende rollen en zoeken naar fouten in logica en rechten.
- Toegangsrechten: kan gebruiker A gegevens van klant B zien door een nummer in de URL of API-aanvraag te wijzigen? Kan een medewerker zichzelf beheerder maken?
- Authenticatie en sessies: wachtwoordbeleid, bescherming tegen brute force, multifactor, sessieduur, veilig uitloggen, wachtwoordherstel.
- Bedrijfslogica: kan een korting gemanipuleerd worden, een goedkeuring omzeild, een factuur aangepast na verzending, een bestelling met negatieve aantallen geplaatst?
- Invoer en uitvoer: injectie in zoekvelden en formulieren, bestandsuploads, export naar Excel of PDF, cross-site scripting in gedeelde velden.
- API’s en koppelingen: autorisatie per endpoint, rate limiting, tokens die te lang geldig blijven, lekken via foutmeldingen, koppelingen met boekhouding of ERP.
- Configuratie en infrastructuur: beveiligingsheaders, verouderde componenten, open beheerinterfaces, back-ups en logging.
De fouten die we het vaakst vinden
In bedrijfsapplicaties, meer dan in publieke websites, draait het om rechten. De meest voorkomende ernstige bevinding is dat een ingelogde gebruiker gegevens van andere klanten of afdelingen kan opvragen, vaak via de API achter de schermen. Daarna volgen zwakke of ontbrekende multifactorauthenticatie, onveilige exports en koppelingen die met te ruime rechten werken.
Deze fouten vindt geen automatische scanner, omdat ze afhangen van uw eigen logica. Precies daarom testen bij N-innovative mensen die zelf software bouwen: zij herkennen de patronen waar ontwikkelaars de mist in gaan.
Zo bereidt u een pentest voor
- Bepaal de scope: welke applicatie, welke omgevingen (bij voorkeur een acceptatieomgeving gelijk aan productie), welke koppelingen.
- Voorzie testaccounts per rol: klant, medewerker, beheerder. Grey box-testen met accounts geeft de beste verhouding tussen diepgang en kost.
- Regel de schriftelijke toestemming, ook van de leverancier als de applicatie extern gehost wordt.
- Spreek een testvenster en een contactpersoon af voor kritieke bevindingen.
Het rapport omzetten in actie
Een goed rapport bevat per bevinding de ernst, de reproductiestappen, de impact voor uw bedrijf en een concrete oplossing. Uw ontwikkelaar of leverancier lost de kritieke en hoge bevindingen eerst op; daarna hertesten we en bevestigen we schriftelijk dat ze gesloten zijn. Dat document is meteen uw bewijs voor klanten, verzekeraar, ISO 27001 of NIS2.
Laat uw bedrijfsapplicatie minstens jaarlijks testen en na elke grote release. Beveiliging is geen eenmalige controle maar een gewoonte.