NodeGoat is a deliberately insecure NodeJS web application maintained by a small collection of OWASP leaders/members, designed to teach web application security and the importance of moving the finding and fixing of defects to within the Development Teams Sprints, thus significantly reducing costs. NodeGoat comes with a tutorial that walks the practitioner through what, where, and how to fix the baked-in OWASP Top 10 defects in a NodeJS context.
Where does the community benefit most from this project and where do we want to take it? I’ve got lots of ideas, because I’m constantly running both public and private Working-Sessions demonstrating the value that Security Regression Testing utilising NodeGoat and Zap API brings to organisations, but input and bouncing ideas off each other can only improve NodeGoat.
Work to be done
- Take the coverage of Security Regression Testing with Zap API further, not just a high level active scan, but more granular and across more than a single route, and possibly create a branch (or whatever provides the least amount of overhead) with all tests passing (by default tests are supposed to fail until fixed)
- Get all components of the Security Regression Testing working within their containers and visible
- Move the security fixes added in the code comments to separate branches or a single branch and automate patch per fix. In this way, we would have a master branch for the insecure app, and multiple branches or automated patches (one per OWASP Top 10 vulnerability) with fixes incorporated in it
- Address the same defect types with examples using different Node libraries and architectures
- Upgrade dependencies and make sure the same defect approaches are being applied across the entire application
The target audience for this Working Session is:
Related Working Session(s)
- Evaluation/Optimization/Creation of Training Slides
- Teaching Attacker perspective to Developers
Back to list of all Working Sessions and Tracks
Edit this page here