In the cybersecurity world, it’s only natural to balance risks and security measures. After all, there is no way to achieve absolute security and therefore you have to say stop somewhere. However, if you rely on excuses and underestimate the threats, you’re very likely to become a victim of a serious attack. Cybercriminals are smart – they attack those who make it easy for them.

I’ve seen businesses treat web application security as less important than, for example, having an antivirus. I can understand such an approach if a business just has a simple marketing site on WordPress. However, I cannot get my head around such carelessness if the business develops professional B2B web applications for huge corporations, which use these web applications to process tons of sensitive information! And yet, yes, this happens!

Here are some of the excuses that I’ve heard when it comes to web application security. I’m including them to help you avoid similar pitfalls when you decide how to proceed with your journey.

“Our software is only for internal use so there’s no attack risk”

The assumption that malicious hackers only attack web applications that are exposed to the public is one of the primary reasons for major data breaches. Not only are inside jobs quite common in the world of cybersecurity but attackers can find a way into the internal network and access internal web applications from there.

You should always treat the security of your web applications the same way no matter whether they are exposed to the public, used through internal networks and VPNs only, or protected by IP filtering and authentication. That means that, for example, if your application is accessible only from a selected range of IPs and requires authentication, it doesn’t mean it’s secure by design. Even worse, criminals may actually seek entry into such applications, in particular, knowing that their creators often treat vulnerabilities as less of a threat and therefore do not even check for them.

In conclusion, scan every application for security vulnerabilities, no matter how well it is protected by network security measures and authentication!

“Our implementation makes it impossible to have vulnerabilities”

I’ve heard this argument from a company, which uses Hibernate ORM for its Java development. The construction of Hibernate supposedly eliminates SQL injection vulnerabilities because the database always returns a single result set. Unfortunately, that is not true. Only some SQL injection attacks are eliminated by this feature of Hibernate but not all of them. This feature also has no impact whatsoever on vulnerabilities that are not related to SQL.

While modern development and implementation environments make some attacks more difficult, there is no environment that can help you prevent all of them – or even a majority of them. If you think that the way that you designed your development and implementation is enough without any security testing included, think again.

In conclusion, test all your applications for security vulnerabilities no matter what development and implementation environments you use (even if they supposedly eliminate security errors).

“We run a security scan once in a while and we never found anything serious”

Some businesses believe that it’s enough to scan their applications every few months, for example, only before a major release. They do not see the need to verify the security of each release candidate and are even less keen to include security scanning as part of their regular DevOps pipelines. The argument is that the scans yielded no major problems up to date.

Such an approach may be compared to leaving your car door unlocked (and your keys in the ignition) in front of the supermarket. Sure, in the majority of cases, nothing will happen because there will be no car burglars around. However, if just one burglar is around and notices that your car is not locked, your vehicle will change its owner pretty quickly. Same in this case: just one major vulnerability that goes undetected between major releases may result in a security breach exposing all your sensitive data and ruining your business reputation.

In conclusion, test your supposedly safe applications even more thoroughly than the ones you’d think are unsafe.

Better safe than sorry

The phrase “better safe than sorry” is very applicable for cybersecurity (and security in general). In my opinion, whatever security decisions you make for your business, you should compare these with the security of your own personal assets. For example, if your apartment is in a block with security at the front door, does it mean you can leave your door unlocked? If no break-in happened in your neighborhood recently, does it mean that you can leave your window wide open when you go to work?

If instead of making excuses you try to assume the worst scenarios, you are much less likely to be the hero of the next headline news about a data breach. And the cost of including web application security in your SDLC compared to the losses that you could incur as a result of the data breach is just like the cost of a door lock compared to the cost of all the valuables in your home.

Make the right choice, not excuses.

Source: Acunetix