Security-related vocabulary includes a lot of words with imprecise meanings. Two such terms that give me a headache when used in the web application security context are the verbs to secure and to protect. But this headache is nothing compared to the one I get when I see that businesses actually believe that tools alone can secure/protect their web applications.
Proactive vs. reactive
When I asked myself what it means to secure a web application and what it means to protect it, I obviously started by looking at how others see this topic. However, the searches yielded unsatisfactory results – I found out that in most cybersecurity contexts, securing means protecting against external threats, and protecting means… securing against internal threats. These definitions make no sense in the web application security context (and I also highly doubt that they make sense anywhere else…). The only sensible definitions for me are based on the fact that securing is proactive and protecting is reactive.
To understand it, imagine that you want to secure/protect your house against robbers. For me, securing a house would mean installing strong doors, window security films, and good quality locks. All these measures are proactive – they are taken before an actual break-in attempt happens. They all make it much more difficult for a burglar to make their way into the house. On the other hand, protecting a house would mean installing a burglar alarm, hiring a monitoring company, or even having aggressive dogs in the backyard. All these measures are useful only if an actual break-in attempt happens – they are all reactive.
That’s exactly how I see securing/protecting in the context of web application security. Securing means scanning the application for vulnerabilities and fixing any issues, using authentication and authorization for sensitive content, and encrypting sensitive data in the application. On the other hand, protecting means installing a web application firewall, intrusion detection/prevention system, or a runtime application self-protection solution.
Antiviruses have made us lazy
Even with the definitions out of the way, I realized one very important fact that may be at the heart of so many failures in web application security. There are many businesses, especially smaller ones, that expect to buy a web application security solution, install and configure it, and then tada! You’re safe!
Well, I have sad news – this is one of the common cybersecurity myths. You are not going to be safe. The only one who can actually secure/protect your web applications is you (using the right tools, of course).
Antivirus/anti-malware solutions and personal firewalls, which are the most common and the most recognized IT security solutions, have made us lazy. Many of us think that all we need to do is install an antivirus and a firewall on our computer and the computer is safe from harm no matter what we do. We don’t even have to configure anything – default settings usually include automatic nightly scans and auto-updates.
Unfortunately, this is not the case with web application security. No web application security solution will be able to secure your web application or protect it from attacks. It is you who needs to take charge and eliminate the dangers.
Take on the responsibility!
The function of dynamic application security testing software is to help you realize what is wrong with your web applications and, possibly, teach you how to fix them. We can help you make this process much easier and more efficient by prioritizing what needs to be fixed as well as automating fix management. However, in the end, the application developer is the only person who can rectify the problem – whether this is someone hired directly by you or someone working for the third party that you got the application from (an open-source team or another business).
I’m emphasizing this very strongly because even if we say that we help secure your application, in the end, you must be aware of the responsibility and take it on.
You may also ask yourself: will reactive solutions, such as web application firewalls or RASP systems, be better, and will they fix problems automatically? They may promise to do so but, in reality, they will just make the break-in harder. There is only one way to eliminate the possibility of a breach – you must eliminate the root cause, which is the programming error.
Remember the comparison with securing/protecting your house? Well, assuming that tools will handle your security for you it is like buying an expensive lock system and an expensive alarm and then not locking the door at all. There’s a good chance that the burglars will be able to disable the alarm system and then just go through the open door.
What’s the solution?
First, start securing your web application by finding out its weak spots. For this, you can use different types of solutions including SAST, DAST, and IAST, but DAST is the best one to start with (because it covers all the bases, unlike the other two).
Then, secure the application by fixing discovered vulnerabilities as soon as you can. We understand that it may not always be possible right away. And that is why you need reactive measures to protect your web application until you can fix the vulnerabilities, for example, a web application firewall. This protection is not meant to guarantee that vulnerabilities won’t be exploited but will make it much more difficult to exploit them while they are being fixed.
And don’t forget – in the end, whichever terms you use: securing, protecting, safeguarding… with web applications all these terms point in the same direction – to you.
Get the latest content on web security
in your inbox each week.
THE AUTHOR
Principal Cybersecurity Writer
