Recently, I came across an article that referred to web application security as code security and I hope it was just a slip of the tongue. If you really think web application security is the same as code security, you are leaving a gaping hole in your security practices – and this hole has been the reason for the biggest web-based breaches in recent years.
I fully understand why a person with a development background or even a network security background may make the mistake of confusing code security with web application security. For someone who has been a developer for years, it is natural to assume that vulnerabilities in code are the primary cause of security breaches in applications. For someone who has worked in network security all their life and therefore never focused on code security, applications may still be perceived only through the perspective of their code.
However, in the case of web application security, many major security breaches happen not just because of vulnerabilities in the primary application code itself:
- Applications nowadays are not written 100% in-house. And it’s not just code that is being imported but very often runtime components as well. Obviously, neither third-party code nor third-party runtime components fall under the scope of code security (or rather they do but should be secured by their creators, whom you can never fully trust).
- Even the most secure application can be easily misconfigured to allow access by malicious third parties. For example, most breaches in recent years were due to exposed databases. The applications using those databases were secure but the databases themselves were open to anyone who could figure out their IP and port number.
- Web applications can have network security vulnerabilities, too. While it is, of course, most efficient to have a separate network security solution to cover such things as the configuration of TLS/SSL, password security, or web server configuration, many smaller businesses perceive this as something that their web application security tool should cover, too.
Who pushes code security and why?
The misconception that application security is code security is very much in line with the sales pitches of code security product vendors. For example, static application security testing (SAST) solutions are unable to cover third-party components or misconfigurations at all.
No wonder that some SAST vendors tend to publicly refer to web application security as code security – it helps them make their customers believe that a SAST solution is all they need to buy. And while, yes, SAST tools are very useful to improve the security of a web application, they alone are not even close to enough.
If due to budget constraints or for other reasons you can only use one class of web application security solutions, DAST is the best to start with. A DAST tool will cover all bases, including all third-party components and the configuration of your web application, but often adding even more, such as SCA capabilities.
So the next time you think about code security, think about the big picture. Think about all the vulnerabilities that you may be missing if code security is your only worry when it comes to your applications. And consider starting with a solution such as Acunetix, which will simply help you secure your web applications whether you call that code security or anything else. However, to improve your security stance, also consider expanding your security platform later with tools such as SAST or web application firewalls (WAF).
Get the latest content on web security
in your inbox each week.
THE AUTHOR
Principal Cybersecurity Writer
