Exploring The Top Vulnerabilities Of Web Applications

Attacks are more numerous and more sophisticated than ever before, making it essential to identify and neutralize threats as soon as possible. Organizations know they need to audit code for vulnerabilities, but there’s a lot more to securing a web application. Given the wide exposure, frequent lack of a web application firewall, and multiple possible attack vectors of a web app, they make enticing targets.

IMAGE: UNSPLASH

Almost All Web Applications Are Vulnerable

According to Dark Reading, 95% of web apps have misconfigurations or vulnerabilities, and 25% of those are considered severe or critical. The rest of the web apps with an issue are medium or low-severity, and while companies may be tempted not to worry about the less critical problems, it’s still important to update those apps quickly.

Many web apps are built on open-source software, so attackers who discover an exploit in that code will be able to attack any web app that uses it. Once an attacker finds a vulnerability, whether high-severity or not, things are about to get expensive.

Ponemon and IBM’s report on the cost of a data breach indicated that a vulnerability in third-party software takes an average of 214 days to discover and another 70 to contain. The average cost to an organization for this type of breach (i.e., the third-party software vulnerability is the primary attack vector) is approximately $4.5 million, though this may vary based on the size of a company and number of users affected.

Many web apps are developed first and secured second, which contributes to many vulnerabilities. As an illustration, consider building a robot. If you were going to build it, presumably you would build its body and wiring at the same time.

If you waited to wire it up until after the entire robot was complete (or close to it), you’d probably need to undo much of the work you’d already done, and once everything is done, it’s bound to look a little janky.

So it is with adding security protocols after much of the app has already been built. The code is bound to be at least a little buggy, and thus vulnerable.

What Are The Main Threats?

The most obvious vulnerability in a web app is its code, particularly the parts of its code that may be open-source. However, SSL/TLS misconfigurations, missing or insecure CSP headers, HTTPS errors, and poor password policy are some of the major contributors to vulnerable web apps, with the SSL/TLS issues accounting for 82% of vulnerabilities found in testing.

Weak passwords and CSP issues, while a significantly smaller proportion of attack vectors at 26% and 46% of attacks respectively, are still major contributors.

Supply chain attacks are also a concern. 85% of open-source code collections have unpatched vulnerabilities, so any open-source-based web app is likely to have some vulnerability in the code, and users interacting with that web app are then also at risk whenever the publisher releases an update, for example.

A challenge for many companies is securing their web apps, for example, by using Oxeye, without blocking legitimate traffic. Addressing every code or configuration vulnerability is a bit like playing Whack-A-Mole: Hit one, and another pops up. Fortunately, there are solutions that can help with security through automation and limited traffic.

Securing Web Applications

A popular and effective solution to code and configuration vulnerabilities is DevSecOps (short for development, security, and operations). This is a holistic strategy that builds compliance and security into the app when it’s developed. Releasing applications built this way avoids problems that crop up when security is not prioritized early in development, resulting in more secure code and consistent configuration.

Many of the previously mentioned issues occur because pieces of the app have to be recoded or reconfigured to patch security holes. Although it may take a bit more time to release the web app, building it with security in mind will reduce the costs of downtime and security breaches in the long run.

For web apps that are already in use, a web application firewall (WAF) can help. Through automated filtering, a WAF protects web apps from malicious traffic and prevents sensitive data from being pulled out. It helps companies filter traffic by identifying patterns typical of malicious traffic, atypical patterns of anomalous traffic, and patterns typical of desirable consumer traffic.

WAFs can go a long way toward improving a company’s web app security, but it should be part of a broader security implementation. To stop bot attacks, DDoS attacks, and others, additional measures are required. Ideally, companies would fully secure their web apps with things including (but not limited to) WAFs, DevSecOps protocols, bot and DDoS protection, and API security.

Organizations should bear in mind that all web apps, including their own, are vulnerable to expensive, damaging attacks. To prevent attacks and to minimize damage from them, companies should implement security measures during app development and WAFs after development.