AppSec Zelfevaluatie
Voer zelf een snelle analyse uit van je applicatie
Alle gegevens blijven in je browser.
Basisevaluatie Applicatiebeveiliging
Bereikbaarheid
Gebruikersimpact
ⓘGevoeligheid van data
ⓘGevoeligheid van acties
ⓘReflectievragen
ⓘ
ⓘ
ⓘ
Checklist
Generiek advies
Procesadvies
Voer per iteratie een mini-threatmodel uit
Bespreek per use case of deze een malafide actie mogelijk zou kunnen maken. Bijvoorbeeld: als de use case het ophalen van factuurgegevens is, kan iemand dan de factuurgegevens van een ander opvragen? Schrijf een test, of voer een test uit, om te bewijzen dat dit niet kan.
Scan op kwetsbare patronen
Automatiseer het zoeken naar kwetsbare patronen. Semgrep (of Opengrep) is een uitstekende engine waarin je custom regels kunt schrijven, bijvoorbeeld om te controleren of al je endpoints de juiste security-annotaties hebben, of om te voorkomen dat een eerdere kwetsbaarheid zich herhaalt. Je kan ook zoeken ook naar hardcoded secrets of het gebruik van gevaarlijke functies. Als je geen scanpatroon wilt schrijven biedt de Semgrep-community duizenden patronen om kwetsbare patronen te herkennen, al geeft dit veel false-positives.
Maak offline backups
Zorg voor periodieke backups van je data, zodat als iemand alles encrypt, je niet hoeft te kiezen tussen betalen of inpakken. Test minimaal één keer of het terugzetten van backups werkbaar is.
Onderhoud een simpel patchmanagementproces
Update alles (packages, framework, images) elke x tijd (sprint, maand). Schrijf je met een apart e-mailadres in voor alerts over security-updates van je software, zodat je op de hoogte blijft van high-risk issues die je direct moet patchen.
Blijf opruimen
Maak er een gewoonte van om elke iteratie iets op te ruimen, zoals oude accounts, endpoints, code, documentatie en backlog-items.
Vraag je collega's naar beveiligingsrisico's
Dit lijkt triviaal, maar het komt te vaak voor dat iemand in het team eigenlijk van een tekortkoming wist, maar dacht dat iedereen het al wist, of dat het risico te klein was om te benoemen.
RTFM
Maak er een gewoonte van om bij elk nieuw framework, tool of package even in de handleiding te kijken of er beveiligingswaarschuwingen zijn, en of er standaardaccounts bestaan. Vooral bij complexe, beveiligingstechnische software is dit van belang, zoals template engines, security filters, file parsers/generators, database ORM-packages en webservers.
Ontwikkeltips
Programmeer vanuit Secure Defaults waar mogelijk
Begin in een veilige state waar niks mag, en sta pas iets toe na expliciete validatie. Dit werkt van code-niveau tot fysieke beveiliging. Geef daarom ook de voorkeur aan een allowlist in plaats van een denylist. Pas wel op met partial matches. Met een partial match wordt code bedoeld zoals
if (url_path.includes('/static')) { /* dit zal wel veilig zijn */ }. Dit lijkt op een allowlist, waarbij je alleen het pad '/static' toelaat, maar omdat het een partial match is komt een pad als /admin/users?a=/static er misschien ook door.
Gebruik beveiligingsmechanismen die je al ter beschikking hebt
Gebruik waar mogelijk de beveiligingsmechanismen die je framework al biedt, zoals CSRF- en XSS-bescherming. Hetzelfde geldt voor je cloudprovider, je database-engine en file parsers. Voor het bovenstaande voorbeeld om een pad te matchen op '/static', hebben de meeste webservers en frameworks standaard configuratie-opties. Ook voor het parsen van gebruikersinvoer, zoals een e-mailadres, is het vaak beter om een standaardpackage te gebruiken in plaats van zelf iets te bouwen. Als er dan een kwetsbaarheid is, is deze waarschijnlijk al breder bekend — mits je de handleiding goed hebt gelezen.
Beperk mogelijkheden van een aanvaller met veiligere datatypes en invoerbeperking
Gebruik datatypes met minimale complexiteit. Een bool of enum biedt een aanvaller minder ruimte dan een string of XML-bestand. Soms kun je variabelen weghalen — bijvoorbeeld als gebruikers een organisatie-ID meegeven terwijl er maar één geldig is, en je deze gewoon uit de sessie kunt halen.
Detecteer packages met bekende kwetsbaarheden
De meeste IDE's waarschuwen tegenwoordig automatisch als packages high-risk CVE's bevatten. Zet dit aan, of scan zelf met tools zoals pip-audit, npm audit, of ingebouwde scanners in je toolchain.
Zoek op wat een hacker zou doen voor jouw stack
Zoek kort in de OWASP Cheat Sheets of HackTricks naar zaken uit jouw stack (zoals JWT, XML, OAuth, Kubernetes, etc.), om te zien wat een hacker zoal zou proberen. Schrijf tests of test handmatig om te valideren dat de aanvallen niet werken.
Achtergrondinformatie
De items op deze pagina zijn zorgvuldig samengesteld. Een decennium aan ervaring in pentestwerk en het begeleiden van ontwikkelaars is meegenomen, eveneens kennis van governance- en risicomanagementeisen. We hopen hiermee zowel ontwikkelteams als Security Officers te ondersteunen om beveiliging betekenisvol inzichtelijk te maken.