Web applications are one of the most common applications where data breaches can take place. Most of our pen-tests find significantly more vulnerabilities in the application later of the test than the infrastructure. So it’s important to make sure that penetration testing is done thoroughly to minimise the risk of a data breach happening to your customers.
So, what can developers miss when they carry out a pen test?
Parental feelings towards their code
When it comes to looking for issues in your own work can sometimes be difficult to do so. Developers can be oblivious to the flaws in their own creation and in some cases struggle to find fault with their coding. Although as an outsider looking in on another developer’s code it will most probably be identifiable to them.
Achieving requested results
Developers have one thing in mind, how to achieve results through creating a line of code. They want to write a piece of code that performs adequate actions. A pen tester ultimately breaks into a system to find security weaknesses and potential entrances to cyber criminals to exploit any vulnerabilities. Developers are focused on solving problems, not creating problems. So to switch to a pen testing mindset of destroying existing components instead of building new ones can be difficult.
Developers are known to simplify complex problems
Developers are focused on looking at complex problems and solving them with simple lines of code. Whereas testing is to focus on taking simple features and exploring complex scenarios that could be exploited by cyber criminals.
Overlooking small details
Developers are inclined to creating/finding patterns that work for a desired action. Creating codes and patterns is easy for a developer. Whereas testers are inclined to finding the small details that break the pattern. Testers are minded to discover small details of patterns that can be at fault.
Lack of customer knowledge and user viewpoint
Most developers don’t have a direct relationship with the customer, so they carry out the task of creating code and developing web applications that have been sent to them.
The user stories are left to managers of the agency. So developers in essence cannot always provide a suitable product where the customer will be able to work with the system.
Which then means they won’t take the time to think about the potential risks of users when using the system regarding security risks.
What can be done to minimise developer mistakes?
1. Best practice
- Agree a set of development guidelines.
- Peer to peer code reviews will often find things developers might miss.
- Adhere to an open standard such as OWASP’s ASVS for web applications or MASVS for mobile applications.
2. Lower cost activities include:
- For mobile application developers, mobile application pen test can help identify issues.
- For those developing on the web, web app pen testing will help show the code is free
- API developers will benefit from API penetration testing to help make sure their code is secure.
- External validation through OWASP ASVS audit for web applications or look to undertake a OWASP MASVS audit for mobile applications.
3. Higher cost activities include:
- Secure code audits will go beyond a pen-test and often find things which a pen-test will not. This can be beneficial for any high risk code, or where developers can not be fully trusted. Our secure code audits have found backdoors into systems that can only be found through code audits.
- Code audit reviews can be useful, but can get expensive and are more for M&A
- FOSS audits can be a risk for and are worth checking to confirm that the application does not suffer from any open source risk, but is mainly used when going through an investment merger or accusation