How Australian Businesses Can Manage Web Application Security Risk

Australian businesses run more of their operations online than ever, through customer portals, booking systems, online stores and the APIs that tie them together. Every one of those web applications is also a potential way in for an attacker.

Recent Barracuda research found that web applications carry on average 20 vulnerabilities, potentially exposing the application to data theft, account compromise and unauthorised access.

That’s a significant number. But not all vulnerabilities carry equal risk, and the same vulnerability can represent a completely different level of risk depending on the application.

Risk depends on context

Let’s think of the security flaw as a weak lock. On the door of an empty storage room, it may be a relatively minor issue. Put 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. Put that same component on a customer portal connected to personal information and backend systems, and it can become an immediate priority.

This is 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 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. Our research shows that lower-risk vulnerabilities can be combined to expose sensitive information, steal credentials or gain unauthorised access.

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

I would 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.

Web applications never stand still

The research showed 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.

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. 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.

What good security looks like 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 per cent of the vulnerabilities detected in our 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.

Yaz Bekkar is Principal Consulting Architect XDR at Barracuda

Last Updated on September 24, 2026 by Yaz Bekkar