Rethinking web application security in an ever-changing threat landscape

By Yaz Bekkar, Principal Consulting Architect XDR – International, Member of The Office of the CTO Barracuda

A recent research revealed that web applications carry on average 20 vulnerabilities, potentially exposing the application to data theft, account compromise and unauthorized access. That’s a significant number, but it is important to remember that not all vulnerabilities carry equal risk. The same vulnerability can represent a completely different level of risk depending on the application.

Severity depends on context
Thinking of the security flaw as a weak lock. On the door of an empty storage room, it may be a relatively minor issue. The same lock on a bank vault, and the risk changes completely.

It is the same with web applications. An outdated component on a simple marketing site with no login or customer data may be relatively low risk. The same component on a customer portal connected to personal information and backend systems, and it can become an immediate priority.
This is the reason why vulnerability management cannot simply be reduced to severity scores. Attackers do not exploit severity scores. They exploit paths.

A small information disclosure issue might reveal the version of the software version running. Another weakness might expose an administrative endpoint. A third could affect session security. Individually, these findings may appear low or medium risk. Taken together, they can create a credible route to compromise. The research shows that lower-risk vulnerabilities can be combined to expose sensitive information, steal credentials or gain unauthorized access.

For business leaders, the question to ask the security team shouldn’t be “How many vulnerabilities do they have?” but “Which ones, or which combinations, do they have that could offer an attacker an easy path to something they cannot afford to lose?”

One should prioritise by exposure, exploitability and business impact. In other words: can an attacker reach it, how easily can they exploit it, and what could they access next?

Twenty vulnerabilities do not mean 20 equal emergencies. They are 20 pieces of a puzzle, and the priority is to understand which pieces an attacker can connect. And then to break that path before they do.

A web application is not static

The research highlighted that many weaknesses stem from basic oversights, such as misconfiguration, inadequate access controls, outdated software or weak encryption. This isn’t always a question of poor security; it also reflects the fact that the environment security teams are protecting never stops changing.

A web application is not a static product. It is continuously updated, reconfigured and connected to new APIs, cloud services and third-party components. Every change can alter the attack surface. For example, a software update may close several known vulnerabilities while introducing new code, dependencies or behaviours. A weakness in one of those components may only be discovered weeks or months later. Every update is part of the security cycle, not the end of it.

Imagine a company updating a customer portal to correct an authentication weakness. The update fixes the original issue but also introduces a new software library and modifies how the portal communicates with its backend API. A vulnerability in that library may later be discovered, or the new configuration may unintentionally expose additional data.

The organisation closed yesterday’s door, but the architecture changed, and another door appeared. This is why basic vulnerabilities persist despite increased investment.

Better tools provide greater visibility, but they cannot freeze a constantly evolving environment. The objective is not to achieve a permanent state of zero vulnerabilities. It is to reduce the time between a weakness appearing, being discovered and being safely corrected.

Effective security: how it looks in practice
For a typical SMB or mid-market company looking to protect its web applications the following approach may help:

1. See the business as an attacker sees it
Start by identifying every internet-facing website, customer portal, API, domain and subdomain, including old applications, test environments and services managed by external agencies.
Each asset should have a named owner, a defined business purpose, the type of data it handles and the date of its latest security scan.

Remove obvious and unnecessary exposure: abandoned applications, directory listings, debugging information and publicly accessible administrative or internal endpoints. This is particularly important because information disclosure represented 25% of the vulnerabilities detected in the study.

2. Break the shortest attack paths first
At an average of 20 vulnerabilities per application, an organisation operating ten public-facing applications could be looking at roughly 200 findings. This shows why a small security team cannot treat every vulnerability as an equal item in one long queue.

The priority should be what is exposed, exploitable and consequential.

In practice, that means addressing internet-facing outdated software, known exploited vulnerabilities, exposed administrative interfaces, sensitive-data leakage and weak authentication or session controls first. The study recommends continuous scanning, hardened configurations, removal of obsolete software and consistent enforcement of multifactor authentication.

Where a permanent correction cannot be applied immediately, the company should temporarily reduce the exposure by restricting access, disabling the vulnerable function or isolating the affected service.

3. Prove that the door is really closed
A ticket marked “resolved” does not prove that the vulnerability has disappeared.
The application should be rescanned or retested after every important patch or configuration change. The correction may not have reached every system, may have been applied incorrectly or may have introduced another weakness.

This matters because attackers can combine several apparently low- or medium-risk findings into a path leading to credential theft, sensitive-data exposure or unauthorised access.

The objective for web application security is not zero vulnerabilities. It is zero ambiguity: know every public door, know who is responsible for closing it, and know that it is truly locked.