Using the OWASP Top 10 to Improve Security in Your Web Applications
This article is written purely as information and is not advice or an endorsement of any resources mentioned. Smashed Crab Studio Ltd is not responsible for any issues that may arise in your products or services as a result of implementing these mentioned techniques.
***
What is the OWASP Top 10?
The OWASP Top 10 is a list of the most critical risks facing organisations and developers when maintaining web-based products or services. It is maintained and regularly updated by the Open Web Application Security Project, or OWASP.
The list was last updated in 2021, and compiled data from over 40 partner organisations.
What are the Top 10 risks for 2021?
- Broken Access Control
- Cryptographic Failures
- Injection
- Insecure Design
- Security Misconfiguration
- Vulnerable and Outdated Components
- Identification and Authentication Failures
- Software and Data Integrity Failures
- Security Logging and Monitoring Failures
- Server-Side Request Forgery
How can I avoid making these mistakes?
Smashed Crab Software is a software development house and as we build products for our customers we need to be mindful of exposing vulnerabilities where possible. Although it is impossible to make a system 100% secure, it is relatively easy to avoid the common pitfalls - which is the aim of the OWASP Top 10.
Ensuring security is built in from git-init is the key to this.
How does this look in practice?
Dynamic code analysis
Most organisations with a development team comprising more than one or two developers will be using hosting build and testing pipelines, using systems such as Azure DevOps (our preference) or Jenkins.
Assuming automated testing exists already, implementing a testing suite to look at the OWASP recommendations shouldn’t be too difficult. Using a tool such as this OWASP ZAP Scanner, can plug straight into an existing Azure DevOps pipeline to make sure all builds are compliant before being released into production.
Static code analysis
Implementing testing in the release pipeline is a fantastic way to make sure nothing too scary gets out to your customers, but in some cases, we can capture these vulnerabilities before they are even pulled into main.
This is where static code analysis comes into play. Not only will we stop committing buggy code, it means that we save time waiting for the release to fail to fix the problems.
Typically there will be plug-ins for your IDE and language of choice that will help pick up vulnerabilities as your developers write them - much like a spell checker. A good list of static code analysis tools is available here: https://owasp.org/www-community/Source_Code_Analysis_Tools
A dual approach
Both static and dynamic analysis will pick up different things. It is comparable to the difference between compile-time and run-time errors. Both should be employed for maximum security risk mitigation.
Further scanning
Once you have a product in testing, it may also be worth performing a bit more of a destructive test to check for compliance and test your Disaster Recovery (DR). Tools such as the official ZAP scanner (which is what the Azure DevOps plug-in is based upon), will perform a proper penetration test and will check for the risks mentioned in the Top 10.
Do not run this on a production site, this will actively attack your software to expose and exploit vulnerabilities leading to unspeakable destruction.
More information here: https://owasp.org/www-project-top-ten/
